RDP logon from loopback
An RDP session was authenticated from a LOOPBACK address (127.0.0.1 / ::1).
What it detects
An RDP session was authenticated from a LOOPBACK address (127.0.0.1 / ::1).
Nobody remotes into a machine from the machine itself. A loopback source address on a Terminal Services logon means the RDP connection arrived through a tunnel terminating locally — an SSH remote forward, a webshell relay, or a port-forwarding utility — and the recorded "source" is the local end of that tunnel rather than the operator's real address.
That makes this both a high-confidence detection and a warning about the evidence: the source IP in this event is NOT where the attacker is. Their address is in the logs of whatever established the tunnel, which is the next thing to find.
MITRE ATT&CK mapping
False positives and triage
Rare enough to treat every hit as real. The one benign pattern is an administrator testing an RDP listener locally, or some remote-support and virtualization products that proxy RDP through a local agent — establish once whether any such product is deployed on the host.
To confirm: do NOT chase the 127.0.0.1 source. Find what was listening: a port-forward utility (plink, ssh, chisel, ngrok), a webshell in a site directory, or an unexpected listening socket. The account named in the event is the one that was used, so treat it as compromised and check what the session did.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 90%. Source: rules/windows/rdp_logon_from_loopback.yaml, licensed under the Apache License 2.0.
id: windows.c2.rdp_logon_from_loopback
version: 1.0.0
status: stable
severity: critical
confidence: 0.9
platforms: [windows]
mitre_techniques: [T1572, T1021.001]
description: |
An RDP session was authenticated from a LOOPBACK address (`127.0.0.1` / `::1`).
Nobody remotes into a machine from the machine itself. A loopback source address on
a Terminal Services logon means the RDP connection arrived through a tunnel
terminating locally — an SSH remote forward, a webshell relay, or a port-forwarding
utility — and the recorded "source" is the local end of that tunnel rather than the
operator's real address.
That makes this both a high-confidence detection and a warning about the evidence:
the source IP in this event is NOT where the attacker is. Their address is in the
logs of whatever established the tunnel, which is the next thing to find.
match:
native_event_id: '1149'
raw_message_regex: '(?i)Param3=(127\.0\.0\.1|::1|0:0:0:0:0:0:0:1)\b'
correlation_keys: [hostname]
false_positive_guidance: |
Rare enough to treat every hit as real. The one benign pattern is an administrator
testing an RDP listener locally, or some remote-support and virtualization products
that proxy RDP through a local agent — establish once whether any such product is
deployed on the host.
To confirm: do NOT chase the 127.0.0.1 source. Find what was listening: a
port-forward utility (`plink`, `ssh`, `chisel`, `ngrok`), a webshell in a site
directory, or an unexpected listening socket. The account named in the event is the
one that was used, so treat it as compromised and check what the session did.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.