In the SOC, visibility is everything, and few protocols deserve more of it than RDP. It is how administrators manage servers, and how attackers move laterally, maintain access and stage ransomware. The events are all there; you just need to know which channels to read.
The event trail of an RDP session
An interactive RDP session leaves fingerprints across several logs:
| Event ID | Log channel | Meaning |
|---|---|---|
| 1149 | TerminalServices-RemoteConnectionManager | Network connection succeeded (pre-auth) |
| 4624 (Type 10) | Security | Interactive remote logon succeeded |
| 4625 | Security | Logon failed, brute force raw material |
| 21 / 22 | TerminalServices-LocalSessionManager | Session logon / shell start |
| 24 / 25 | TerminalServices-LocalSessionManager | Disconnect / reconnect |
| 4778 / 4779 | Security | Session reconnected / disconnected |
Reading them together turns “someone RDP’d in” into a timeline: where the connection came from (1149 carries the source IP), which account authenticated, when the session started, and whether it was reconnected from a different host, a classic lateral movement tell.
Detections worth building
- Brute force / spray: bursts of 4625 with logon type 10 from one source, or one password across many accounts.
- First-time source: 4624 Type 10 from an IP or subnet never seen for that account, cheap to build with a SIEM watchlist, high signal.
- Off-hours administration: interactive sessions to servers outside change windows.
- Reconnect chains: 4778 events where the client name differs from the original session, sessions hijacked or resumed from new hosts.
During incident response
RDP events answer scoping questions fast: filter 4624 Type 10 by the compromised account to enumerate every host it touched, then pivot to LocalSessionManager 21/25 on those hosts to bound session times. That timeline drives containment decisions, which is the whole point of logging.
This article was originally published on Medium.