9.2.9 Validate the remote services your Windows identity can access Windows Remote-Access Validation

← Stage index · RDP access procedure · Cheatsheet | Strategy map | Study methods: Extract opportunities from services

Recognize: RDP commonly uses TCP/3389; WinRM commonly uses 5985/HTTP and 5986/HTTPS. Goal: determine whether one known credential is accepted in the correct local/domain context and whether it is authorized for a usable session.

9.2.9.1 RDP baseline: authentication-only check

xfreerdp3 /v:TARGET /u:USER /d:DOMAIN /auth-only /cert:ignore

Some distributions expose the binary as xfreerdp. Omit /d:DOMAIN for the intended local-account context; use /u:TARGET\\USER if needed to make that context explicit.

Decisive output: successful authentication-only validation supports that the credential is accepted for RDP/NLA. It does not prove an interactive desktop will be granted under every policy/session condition.

9.2.9.1.1 Variant — open an RDP desktop

xfreerdp3 /v:TARGET /u:USER /d:DOMAIN /dynamic-resolution /cert:ignore

Let FreeRDP prompt for the password. /cert:ignore suppresses certificate validation and is suitable only in the controlled lab context; it removes server-identity protection.

9.2.9.1.2 Variant — identify RDP security requirements

nmap -p 3389 --script rdp-enum-encryption,rdp-ntlm-info TARGET

This can disclose supported security layers, NLA and NTLM host/domain clues. It does not validate a credential.

9.2.9.2 RDP host-side inspection: local administrative context

Use this read-only sequence after obtaining an authorized local administrative session on the destination, or when the exercise explicitly supplies equivalent remote-management access. It answers four different questions: is RDP enabled, is a listener actually present, what security layer/NLA policy applies, and does the candidate identity have an effective remote-interactive logon right? Do not change registry values or policy merely to make a credential work.

9.2.9.2.1 Listener, service and configured port

Get-Service TermService
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber
qwinsta

netstat -ano | findstr LISTENING | findstr ":3389"

Read: fDenyTSConnections = 0 permits RDP at the local setting; 1 denies new RDP connections. PortNumber is displayed as a registry DWORD, commonly hexadecimal 0xD3D for 3389. A running TermService plus an RDP-Tcp listener in qwinsta and a listening socket establishes host-side listener state. A missing :3389 socket is not decisive if PortNumber is nondefault. Policy can override the local value, so inspect resultant policy before treating this as effective configuration.

9.2.9.2.2 NLA, transport security and policy precedence

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v MinEncryptionLevel

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fDenyTSConnections
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v UserAuthentication
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v SecurityLayer

gpresult /scope computer /v

Read: UserAuthentication = 1 requires Network Level Authentication. For SecurityLayer, 0 is native RDP security, 1 negotiates, and 2 requires TLS. MinEncryptionLevel further constrains client compatibility. A missing policy value means “not configured at this policy path,” not that the feature is absent. Use gpresult to identify the winning computer policy when local and policy-backed values conflict or revert after refresh. These settings explain negotiation failures; they do not grant a user logon rights.

9.2.9.2.3 Candidate membership and effective logon rights

net localgroup "Remote Desktop Users"
whoami /groups

From an elevated PowerShell or Command Prompt, export the currently applied user-right assignments and inspect only the RDP entries:

$policy = Join-Path $env:TEMP 'rdp-user-rights.inf'
secedit /export /mergedpolicy /areas user_rights /cfg $policy /quiet
Select-String -Path $policy -Pattern '^SeRemoteInteractiveLogonRight','^SeDenyRemoteInteractiveLogonRight'

Read: the candidate must be covered by SeRemoteInteractiveLogonRight; membership in local Administrators or Remote Desktop Users commonly supplies that right, but the actual applied policy is decisive. SeDenyRemoteInteractiveLogonRight overrides the allow right. Exported entries can be names or SIDs, so resolve unfamiliar SIDs before deciding. whoami /groups proves only the current process token; use it for the candidate only when you are actually running in that candidate's context. A group listing alone does not prove an effective right when domain policy or nested membership changes the result.

9.2.9.2.4 Source-relative validation and decision

nmap -Pn -n -p 3389 --reason TARGET
xfreerdp3 /v:TARGET /u:USER /d:DOMAIN /auth-only /cert:ignore

Ready for an interactive attempt: the actual source reaches the configured RDP port; the listener is enabled; the client can meet the NLA/security requirements; the credential is accepted in the intended local/domain context; and the identity has the effective allow right without an applicable deny right. Ruled out in this context: a decisive required condition is absent, such as an effective deny assignment or no listener on the configured port. Inconclusive: access to policy data is denied, group/SID expansion is unresolved, GPO precedence is unclear, or network filtering prevents source-relative validation. Do not turn an inconclusive result into “bad password” or “RDP disabled.”

Security baseline: on a normally secured host, RDP may be disabled when not needed; when enabled, NLA is normally retained, access is limited to intended administrative/remote-user principals, deny assignments override broad membership, and the firewall limits exposure. The state machine records deviations and capabilities; it does not recommend weakening these controls.

9.2.9.3 WinRM baseline: interactive session

evil-winrm -i TARGET -u USER

evil-winrm -i TARGET -u 'DOMAIN\\USER'

Omitting -p makes the established Ruby client prompt for the password.

Decisive output: an interactive PowerShell prompt establishes WinRM authorization. Immediately verify identity and host context with whoami, hostname and Get-NetIPAddress.

9.2.9.3.1 Variant — WinRM over HTTPS

evil-winrm -i TARGET -u USER -S -P 5986

Check evil-winrm -h because the established Ruby client and newer evil-winrm-py use different long-option spelling. Do not assume a copied command matches the installed implementation.

9.2.9.3.2 Variant — Windows PowerShell remoting

$cred = Get-Credential
Enter-PSSession -ComputerName TARGET -Credential $cred

PowerShell remoting uses the configured WinRM endpoint. Local trusted-host, Kerberos/name-resolution and endpoint authorization settings can fail independently of password validity.

Failure cues: certificate warnings are different from authentication failure. RDP errors can reflect NLA, account context, expired/locked accounts or missing logon rights. WinRM 401 supports authentication/authorization failure; WinRM cannot process the request can be name resolution, trusted-host, listener or transport context. Valid SMB credentials do not guarantee RDP or WinRM rights.

Next action: after a session, re-enumerate identity, groups, privileges, files, local services/listeners and routes. Password spraying, pass-the-hash and ticket use belong to later credential/AD blocks.

Host-inspection sources: Microsoft RDP troubleshooting · Microsoft secedit /export · Microsoft account-right constants · Microsoft qwinsta · Microsoft Remote Desktop Services policy

9.2.9.4 Validate access to an exposed VNC desktop VNC

nmap -Pn -sV --script vnc-info -p PORT TARGET
vncviewer TARGET:PORT

VNC may expose a desktop without Windows logon semantics; the VNC server's authentication and the resulting OS session identity are separate. Use realvnc-auth-bypass or password testing only for a confirmed compatible product and explicit authorized objective, then verify the desktop identity.

9.2.9.5 Identify the Telnet service and validate available access Telnet

nmap -Pn -sV -p PORT TARGET
nc -nv TARGET PORT
telnet TARGET PORT

Telnet is plaintext and may expose a banner/login prompt. Validate only legitimately acquired credentials; do not make telnet-brute a baseline. After login, verify host and identity because appliance/application shells can differ from an OS shell. Source supplement: reviewed getSH Nmap VNC/Telnet blocks.

9.2.9.6 GNU Inetutils telnetd — conditional authentication-bypass check

Use only after identifying the affected GNU Inetutils telnetd/login chain and its patch status. CVE-2026-24061 concerns how a supplied USER value reaches login; it does not apply to every Telnet server. Distribution backports matter.

# Client supports sending the autologin USER environment value
USER='-f root' telnet -a TARGET PORT

Read: if a shell is obtained, verify hostname and id. A prompt or echoed username is not root access. A different daemon, fixed build, client negotiation mismatch or a rejected USER value → return to service identification. The affected upstream range and distribution fixes must be checked against the advisory rather than inferred from port 23.

Sources: upstream 1.