What Network Level Authentication does to your RDP hunt

Network Level Authentication is one of those defensive controls that is unambiguously worth turning on and that also, as a side effect, moves the furniture in your detection content without telling you. If your RDP hunting was built before NLA was enforced across the estate, some of it is now watching a door that traffic no longer comes through. This is a note on where the signal went.

What NLA changes about the sequence

Without NLA, a remote desktop connection reaches the host, a session spins up, and authentication happens inside it. That means an attacker hammering credentials produces session-level activity and logon failures that look like what most people picture when they think “RDP brute force.”

With NLA, the client has to authenticate through CredSSP before any session is created. Nothing spins up until the credentials are already good. The practical effect for a hunter is that a failed RDP attempt against an NLA-protected host no longer looks like a failed interactive remote logon. It looks like an authentication failure at the network layer, a 4625 with logon type 3, often with the NTLM or Negotiate package named, and not the type 10 event a lot of RDP rules key on. If your brute-force detection is “4625 where logon type is 10,” NLA has quietly emptied it out.

That is the trap. The control improved your security and degraded a specific detection at the same time, and unless someone re-tested the rule against an NLA host, you would not know.

Where the good signal actually lives

The event I care about most for RDP is not in the Security log at all. It is 1149 in Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational, which records a successful RDP network connection along with the source user and the source address. That last field is the one hunters keep wanting and keep not finding in 4624, and it is right here, in an operational channel that is off by default on a lot of builds.

The full picture of a legitimate interactive RDP logon, once you enable the right channels, is a small correlation:

• 1149 (RemoteConnectionManager, Operational) for the inbound connection, with the source IP.
• 4624 type 10 in Security for the RemoteInteractive logon that follows successful NLA.
• 21 and 25 in Microsoft-Windows-TerminalServices-LocalSessionManager/Operational for the session logon and reconnect, which carry the source address too.

Correlate those and you have who connected, from where, to which host, and when. Miss the TerminalServices operational logs and you are trying to reconstruct RDP from Security-log fragments that NLA has made less informative than they used to be.

What I’d actually do about it

Three things, in order. First, enable the TerminalServices RemoteConnectionManager and LocalSessionManager operational logs and forward them, because that is where the source IP and the reliable connection record live, and it is the single highest-value change here. Second, rewrite any RDP brute-force detection that assumes logon type 10 for failures; on an NLA estate the failure signal is a type-3 CredSSP or NTLM failure, so hunt that instead, ideally as a velocity pattern of failures from one source against the RDP-exposed hosts. Third, keep the 1149-to-4624-to-session correlation as your success-side detection for anomalous RDP, from unexpected sources or to hosts that never normally receive it. This is Remote Services: RDP, T1021.001, and the plumbing is documented in Microsoft’s 4624 reference for the logon-type detail.

NLA is not the problem. The problem is a detection written for the world before it, still enabled, still green on the dashboard, watching a logon type that the attacker’s failures no longer generate. When you tunnel RDP hunting into the TerminalServices logs you also pick up the odder variants, like the RDP-over-reverse-SSH case where the source address collapses to localhost, which the Security log alone would never have made obvious.