Skip to content
HackIndex logo

HackIndex

RDP encryption NLA

4 min read May 15, 2026

NLA: Network Level Authentication

RDP security settings dictate what you can do pre-auth and which clients/attack paths will work. rdp-enum-encryption is the quickest way to see supported security layers and RDP encryption levels on a target.

Nmap encryption probe with rdp-enum-encryption

┌──(kali㉿kali)-[~]
└─$ nmap -Pn -p $PORT --script rdp-enum-encryption $TARGET_IP 
PORT     STATE SERVICE
3389/tcp open  ms-wbt-server
|   Security layer
|     CredSSP (NLA): SUCCESS
|     CredSSP with Early User Auth: SUCCESS
|     Native RDP: SUCCESS
|     RDSTLS: SUCCESS
|     SSL: SUCCESS
|   RDP Encryption level: High
|     40-bit RC4: SUCCESS
|     56-bit RC4: SUCCESS
|     128-bit RC4: SUCCESS
|     FIPS 140-1: SUCCESS
|_  RDP Protocol Version:  RDP 5.x, 6.x, 7.x, or 8.x server

This tells you what the server will negotiate, not what you “should” use. Your next move changes based on which entries succeed.

Reading the result in a way that drives next actions

If CredSSP (NLA) is the only thing that succeeds, treat it as NLA enforced for real connections and credential testing. Plan for tooling that supports CredSSP and don’t waste time on classic RDP-only brute clients.

If Native RDP succeeds, the target will negotiate legacy RDP security. That’s where you can sometimes do more pre-auth interaction and where older RDP-era issues tend to be more relevant. It’s also where “grab a screenshot without creds” becomes more likely.

If RDSTLS / SSL succeeds, you’re getting TLS-backed RDP. That’s normal on modern Windows. You can usually pivot to certificate extraction and hostname harvesting from the cert if you need naming context.

If RDP Encryption level is Low or Client Compatible, assume older/looser settings. Prioritize deeper checks for legacy exposure and validate what’s actually reachable with a real client handshake.

If FIPS 140-1 is the only working encryption mode, expect some client/tooling friction. Test with a modern RDP client early so you don’t burn time later.

Confirm what actually works with a real client handshake

Nmap tells you “supported”. A quick FreeRDP negotiation confirms what’s usable from your box and what fails during negotiation.

Try negotiation and let it pick the best mode:

┌──(kali㉿kali)-[~]
└─$ xfreerdp /v:$TARGET_IP:$PORT /cert:ignore +nego

Force specific modes when negotiation is flaky or when you want to prove NLA enforcement:

┌──(kali㉿kali)-[~]
└─$ xfreerdp /v:$TARGET_IP:$PORT /cert:ignore /sec:nla
xfreerdp /v:$TARGET_IP:$PORT /cert:ignore /sec:tls
xfreerdp /v:$TARGET_IP:$PORT /cert:ignore /sec:rdp

What changes your next move:

  • /sec:rdp fails but /sec:nla works: treat as NLA enforced and focus on credentialed checks or spraying with tools that support NLA — see RDP Brute Force and Password Spray.

  • /sec:rdp succeeds: NLA is not enforced — document the finding and proceed to RDP NLA Not Enforced.

  • /sec:tls works but you get hostname/cert clues: pivot into cert-based naming and service mapping.

  • Everything negotiates but auth fails: that’s fine. You’ve confirmed the transport/security mode; move to credential strategy.

Combine with NTLM identity leakage in one pass

If you want a single pre-auth profile (naming + security posture), run both scripts:

┌──(kali㉿kali)-[~]
└─$ nmap -Pn -p $PORT --script "rdp-enum-encryption,rdp-ntlm-info" $TARGET_IP 
PORT     STATE SERVICE
3389/tcp open  ms-wbt-server
| rdp-ntlm-info:
|   Target_Name: W2016
|   NetBIOS_Domain_Name: W2016
|   NetBIOS_Computer_Name: W16GA-SRV01
|   DNS_Domain_Name: W2016.lab
|   DNS_Computer_Name: W16GA-SRV01.W2016.lab
|   DNS_Tree_Name: W2016.lab
|   Product_Version: 10.0.14393
|_  System_Time: 2019-06-13T10:38:35+00:00
|   Security layer
|     CredSSP (NLA): SUCCESS
|     CredSSP with Early User Auth: SUCCESS
|     Native RDP: SUCCESS
|     RDSTLS: SUCCESS
|     SSL: SUCCESS
|   RDP Encryption level: High
|     40-bit RC4: SUCCESS
|     56-bit RC4: SUCCESS
|     128-bit RC4: SUCCESS
|     FIPS 140-1: SUCCESS
|_  RDP Protocol Version:  RDP 5.x, 6.x, 7.x, or 8.x server

If rdp-ntlm-info returns domain/host naming, set $DOMAIN from DNS_Domain_Name and use that consistently across SMB/LDAP/Kerberos work.

If NLA is disabled: quick screenshot of the login UI

When the probe suggests non-NLA access is viable, grabbing the login screen can confirm hostname/domain branding and sometimes exposes local/user hints.

┌──(kali㉿kali)-[~]
└─$ nxc rdp $TARGET_IP --port $PORT --nla-screenshot

If that works, it’s strong confirmation that NLA is not enforced and you can prioritize pre-auth RDP interaction paths.

Timeouts and noisy targets

Some RDP endpoints are slow or weird during negotiation. If the script is dragging, set a hard cap so your scan doesn’t stall:

┌──(kali㉿kali)-[~]
└─$ nmap -Pn -p $PORT --script rdp-enum-encryption --script-timeout 20s $TARGET_IP

References