# RDP encryption NLA - **URL:** https://hackindex.io/services/rdp/enumeration/rdp-encryption-and-nla-enumeration - **Path:** RDP > Enumeration - **Up:** [Enumeration](https://hackindex.io/services/rdp/enumeration.md) - **Published:** 2026-01-04 - **Updated:** 2026-05-15 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 ```bash 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: ```bash xfreerdp /v:$TARGET_IP:$PORT /cert:ignore +nego ``` Force specific modes when negotiation is flaky or when you want to prove NLA enforcement: ```bash 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](https://hackindex.io/services/rdp/exploitation/brute-force-password-spray). - `/sec:rdp` succeeds: NLA is not enforced: document the finding and proceed to [RDP NLA Not Enforced](https://hackindex.io/services/rdp/vulnerability-discovery/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: ```bash 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. ```bash 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: ```bash nmap -Pn -p $PORT --script rdp-enum-encryption --script-timeout 20s $TARGET_IP ``` ## References - [rdp-enum-encryption NSE script](https://nmap.org/nsedoc/scripts/rdp-enum-encryption.html) - Supported security layers and encryption levels enumeration - [rdp-ntlm-info NSE script](https://nmap.org/nsedoc/scripts/rdp-ntlm-info.html) - NTLM info extraction over RDP pre-auth - [NetExec RDP screenshot without NLA](https://www.netexec.wiki/rdp-protocol/screenshot-without-nla-not-connected) - --nla-screenshot usage and behavior - [NetExec RDP module reference](https://kb.offsec.nl/tools/framework/netexec/nxc-rdp/) - Flags including --port and screenshot options