Back to News

An open detection rule to spot abnormal access to a TOS

Port Cyber Alliance Editorial Team

Published on November 10, 2026

Share on

The terminal operating system knows where every box is. Yet in many terminals, nobody would notice if someone opened a remote desktop session on it from the wrong place, at the wrong time.

This article gives you an open detection rule for exactly that case, written in Sigma, the vendor-neutral format most SIEMs can import. It explains what the rule sees, how to adapt it to your network in an afternoon, and what it will never see.

Security operations screens with code and a world map: an open rule to spot odd access to a TOS

Why abnormal access to a TOS matters

When the system that runs the terminal stops, the terminal stops. On 4 July 2023, the Port of Nagoya, Japan's busiest port, discovered a ransomware attack on its computer systems, and container operations were suspended until the systems were restored (The Maritime Executive, 5 July 2023). On 10 November 2023, DP World Australia detected a cyber incident, disconnected its systems from the internet and suspended operations at its container terminals in Sydney, Melbourne, Brisbane and Fremantle until the following Monday (The Record, 13 November 2023).

We do not know how either attacker got in, and this rule would not have stopped them on its own. What these incidents show is the price of a TOS that nobody watches. Remote desktop is one of the doors to watch: the US cyber agency's #StopRansomware Guide (CISA, September 2023) asks to limit RDP and other remote desktop services, to audit the network for systems using RDP, and to log RDP login attempts. Logging is the easy part. Someone reading the log is what this rule is for.

What the rule detects

Administrators, vendors and support teams need to reach the TOS servers. They should do it from a known place: a jump host, an admin network, a vendor access path you approved. An interactive session that starts from anywhere else is not proof of an attack, but it is exactly the event someone should look at the same day.

On Windows servers, a successful remote desktop logon is recorded as Security event 4624 with logon type 10 (Microsoft, event 4624). The rule fires when that event comes from one of your TOS servers and its source address is not in your approved list. It maps to MITRE ATT&CK T1021.001, remote services: remote desktop protocol.

The rule

Copy it as it is, or download the file. The server names and address ranges are examples you replace. Status experimental, level high, licence DRL 1.1.

# Port Cyber Alliance open detection rules · https://portcyberalliance.org/open-detection-rule-tos-remote-access/
# License: Detection Rule License (DRL) 1.1 · https://github.com/SigmaHQ/Detection-Rule-License
# Before you deploy: replace the example server names and address ranges below with your own (see README.md).
title: Remote Desktop Logon to a TOS Server From Outside the Admin Network
id: 28394c83-5505-4103-982e-364659fd8dbb
status: experimental
description: |
    Detects a successful remote desktop (RDP) logon to a terminal operating system (TOS) server
    from a source address outside the approved admin network (jump hosts, admin VLAN, approved vendor paths).
    Windows records a successful RDP logon as Security event 4624 with logon type 10 (RemoteInteractive).
    The server names and address ranges are examples: list your own TOS servers and your own approved paths.
references:
    - https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624
    - https://attack.mitre.org/techniques/T1021/001/
    - https://portcyberalliance.org/open-detection-rule-tos-remote-access/
author: Port Cyber Alliance
date: 2026-11-10
license: DRL-1.1
tags:
    - attack.lateral-movement
    - attack.t1021.001
    - attack.initial-access
    - attack.t1078
logsource:
    product: windows
    service: security
    definition: 'Requires "Audit Logon" (Success) on the TOS servers, and their Security log forwarded to the SIEM'
detection:
    selection_logon:
        EventID: 4624
        LogonType: 10
    selection_tos_servers:
        # EXAMPLE values: the host names of your TOS application, database and integration servers
        Computer|startswith:
            - 'TOS-'
            - 'TOSDB-'
    filter_main_admin_network:
        # EXAMPLE values: your jump hosts, admin network and each approved vendor access path, nothing more
        IpAddress|cidr:
            - '10.20.30.0/24'
            - '192.168.250.10/32'
    condition: selection_logon and selection_tos_servers and not 1 of filter_main_*
falsepositives:
    - A new jump host or admin subnet not yet added to the filter
    - An approved vendor session arriving through an access path not listed in the filter
    - RDP tunnelled through a local port forward, which shows a loopback source address
level: high

The rule file (.yml)
The whole package (.zip): both rules, sample events, the test script and the licence
Open detection rules in our open-source packages

How to deploy it, whatever your SIEM

Name your servers. Replace TOS- and TOSDB- with the names of your TOS application, database and integration servers. If they follow no pattern, list them one by one.
Name your admin paths. In the filter, list your jump hosts, your admin network and each approved vendor access path, one line each, and nothing more.
Check that the logs arrive. Search your SIEM for event 4624 from each TOS server over the last day. Many teams discover the gap here: no log, no alert.
Convert it for your SIEM with the open-source sigma-cli tool (below), and paste the result as a scheduled search.
Run it on the last 30 days first. Every hit is either a real question or a missing line in the filter. Fix the filter before you turn the alert on, so the first alert is worth reading.

pip install sigma-cli
sigma plugin install splunk        # or elasticsearch, microsoft365defender, qradar...
sigma convert -t splunk -p splunk_windows pca_tos_rdp_logon_outside_admin_network.yml

For Splunk, that gives the search below. Check the host name field your pipeline picks: collectors do not all fill the same one.

source="WinEventLog:Security" EventCode=4624 LogonType=10 Computer IN ("TOS-*", "TOSDB-*")
NOT (IpAddress="10.20.30.0/24" OR IpAddress="192.168.250.10/32")

A companion rule: a new administrator on the TOS

The package holds a second rule for the other question worth asking: would a new administrator on your TOS be noticed within a day? It fires on Security event 4732 when an account is added to the local Administrators group of a TOS server (the companion rule). Match each alert against your change tickets.

Limits and false positives

Stolen credentials from a legitimate jump host are not seen. Protect the jump host with multi-factor authentication and watch it too.
Linux TOS servers are not covered: the same signal lives in the SSH authentication log and needs its own rule.
Time of day (sessions at night, on weekends) is better added as a correlation in your SIEM, where your shift pattern is known.

Expected false positives: a new jump host or admin subnet not yet in the filter, an approved vendor session through a path you forgot to list, and RDP tunnelled through a local port forward, which shows a loopback address. The last one deserves a look anyway.

How we tested it

Both rules pass sigma check (sigma-cli 3.1, pySigma 1.5) with no error and no warning, and convert for Splunk and Elastic. The package ships sample Windows events and a small test script that parses each rule with pySigma and evaluates it against them.

Must match: an RDP logon on a TOS application server from an internet address; an RDP logon on the TOS database server from an office subnet; an RDP logon through a local tunnel.
Must not match: an RDP logon from the approved jump host network; a network logon (type 3) from outside; an RDP logon on an office PC.

$ python tests/test_rules.py
# pca_tos_rdp_logon_outside_admin_network.yml
PASS sample 1: match (expected match)
PASS sample 2: match (expected match)
PASS sample 3: match (expected match)
PASS sample 4: no match (expected no match)
PASS sample 5: no match (expected no match)
PASS sample 6: no match (expected no match)
2 rule(s), 0 failure(s)

What you can do tomorrow

Ask your IT team one question: if someone opened a remote session on our TOS server from an unknown address last night, who would know this morning? If the answer is not a name, start with this rule. If you improve it, share it back: a detection rule gets better each time another port runs it.

Want to know where your team stands first? Take the engineer cyber self-assessment: twelve questions like this one, about two minutes. You can also read ten cyber checks a terminal can run in one week.

Questions

Which SIEM does the rule work with?

Any SIEM that has a Sigma backend: Splunk, Elastic, Microsoft Sentinel and Defender, QRadar and others. You convert the rule once with the open-source sigma-cli tool and paste the query as a scheduled search.

What does the rule need to see?

The Windows Security event log of your TOS servers in your SIEM, with logon auditing on. Without event 4624 from those servers, the rule can never fire.

Will it catch an attacker who uses a legitimate jump host?

No. A session opened from an approved jump host with stolen credentials looks normal to this rule. It is one layer: pair it with multi-factor authentication on the jump host and with the companion rule on new administrators.

Can we change the rule and share it?

Yes. It is published under the Detection Rule License 1.1, the licence of the public SigmaHQ rules: use it, change it, share it, keep the licence and the author line.