Remote Desktop Protocol Server Man-in-the-Middle Weakness

This finding maps to CVE-2005-1794: older Microsoft RDP/Terminal Services behavior used a publicly known hard-coded RSA private key to sign the server side of the handshake, which lets an attacker spoof a legitimate RDP server during a man-in-the-middle attack. The original affected stack was Microsoft Terminal Server using RDP 5.2 and Remote Desktop Connection 5.1.2600.2180; in practice, Tenable still uses this plugin as a configuration-risk check for hosts that allow classic RDP security instead of enforcing TLS (SecurityLayer=2) or NLA.

Tenable's MEDIUM label is fair in a vacuum, but for a modern enterprise this is overstated operationally. The decisive friction is attacker position: this is not internet-to-shell or unauthenticated RCE, it is an on-path interception problem that usually assumes the adversary already owns a LAN segment, VPN edge, Wi-Fi, branch router, or other transit point; that sharply cuts the exposed population and pushes the real-world priority down to LOW.

Why this verdict

• Downshift 1 — requires privileged network position: unauthenticated-from-anywhere this is not. The attacker must already control a LAN/VPN/Wi-Fi/transit point or equivalent middlebox position.
• Downshift 2 — exposed population is narrowed by modern baselines: if you already require NLA, force TLS, or front RDP with RD Gateway/VPN, the classic invisible spoofing path collapses.
• Downshift 3 — impact is stolen trust, not instant shell: the outcome is credential/session interception and possible follow-on lateral movement, which is serious but operationally slower and narrower than one-packet RCE.

Why not higher?

It is not higher because the vulnerability chain starts with a prior access assumption: the adversary has to be on the traffic path. That prerequisite alone removes the huge exposed population you would need for a MEDIUM-to-HIGH fleet emergency, and there is no strong current exploitation signal like KEV listing or active campaign reporting to offset that friction.

Why not lower?

It is not lower because if the weak posture still exists on admin jump boxes, terminal servers, or help-desk paths, the attacker can steal credentials that matter a lot. This is also one of those findings that looks academic until it intersects with flat internal networks, branch links, unmanaged Wi-Fi, or legacy remote-access habits.

1. Require NLA or force TLS — Set RDP listeners to require NLA and preferably SecurityLayer=2 so the classic unauthenticated server-spoofing path is closed. For a LOW verdict there is no SLA (treat as backlog hygiene), but if you find this on privileged admin hosts, fold it into your next Windows baseline change rather than letting it drift.
2. Put RDP behind RD Gateway or VPN — Reduce raw listener exposure and make on-path interception materially harder by forcing users through a controlled access plane. For LOW, there is no SLA (treat as backlog hygiene), but prioritize this first anywhere RDP still crosses shared or semi-trusted networks.
3. Bind trusted server-auth certificates — Use certificates with the correct Server Authentication purpose and names matching what users connect to; this removes the anonymous, unverifiable server identity problem. For LOW, there is no SLA (treat as backlog hygiene), but fix admin infrastructure before general workstation use cases.
4. Constrain who can admin over RDP — Use tiered admin accounts, PAWs, and restricted source networks so a stolen session has less downstream value. For LOW, there is no SLA (treat as backlog hygiene), but this materially lowers blast radius even if a session were intercepted.

Run this on the target Windows host or through PowerShell Remoting with local administrator rights. Example: powershell.exe -ExecutionPolicy Bypass -File .\check-rdp-mitm.ps1; it reads the local RDP listener config and reports VULNERABLE, PATCHED, or UNKNOWN.

# check-rdp-mitm.ps1

# Purpose: Detect classic RDP MiTM exposure associated with Nessus plugin 18405 / CVE-2005-1794 posture.

# Exit codes:

#   0 = PATCHED

#   1 = VULNERABLE

#   2 = UNKNOWN


$ErrorActionPreference = 'Stop'

function Write-Result {
    param(
        [string]$State,
        [int]$Code,
        [string]$Reason
    )
    Write-Output "$State - $Reason"
    exit $Code
}

try {
    $tsKey = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server'
    $rdpTcpKey = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

    $tsProps = Get-ItemProperty -Path $tsKey
    $rdpEnabled = $true
    if ($null -ne $tsProps.fDenyTSConnections -and [int]$tsProps.fDenyTSConnections -eq 1) {
        $rdpEnabled = $false
    }

    if (-not $rdpEnabled) {
        Write-Result -State 'PATCHED' -Code 0 -Reason 'RDP listener is disabled (fDenyTSConnections=1).'
    }

    $securityLayer = $null
    $userAuth = $null
    $sslThumb = $null
    $source = $null

    try {
        $wmi = Get-CimInstance -Namespace 'root/cimv2/terminalservices' -ClassName 'Win32_TSGeneralSetting' -Filter "TerminalName='RDP-tcp'"
        if ($wmi) {
            $securityLayer = [int]$wmi.SecurityLayer
            $userAuth = [int]$wmi.UserAuthenticationRequired
            $sslThumb = [string]$wmi.SSLCertificateSHA1Hash
            $source = 'WMI/CIM'
        }
    }
    catch {
        # fall through to registry

    }

    if ($null -eq $securityLayer -or $null -eq $userAuth) {
        $rdpProps = Get-ItemProperty -Path $rdpTcpKey
        if ($null -ne $rdpProps.SecurityLayer) { $securityLayer = [int]$rdpProps.SecurityLayer }
        if ($null -ne $rdpProps.UserAuthentication) { $userAuth = [int]$rdpProps.UserAuthentication }
        if ($null -ne $rdpProps.SSLCertificateSHA1Hash) { $sslThumb = [string]$rdpProps.SSLCertificateSHA1Hash }
        $source = 'Registry'
    }

    if ($null -eq $securityLayer -or $null -eq $userAuth) {
        Write-Result -State 'UNKNOWN' -Code 2 -Reason 'Could not read RDP SecurityLayer/UserAuthentication settings.'
    }

    $securityLayerName = switch ($securityLayer) {
        0 { 'RDP' }
        1 { 'Negotiate' }
        2 { 'TLS' }
        default { "Unknown($securityLayer)" }
    }

    $nlaEnabled = ($userAuth -eq 1)
    $tlsForced = ($securityLayer -eq 2)

    # Nessus 18405 guidance: force SSL/TLS and/or require NLA.

    # We treat the host as vulnerable when RDP is enabled and neither TLS is forced nor NLA is required.

    if (-not $tlsForced -and -not $nlaEnabled) {
        $reason = "RDP enabled; SecurityLayer=$securityLayerName; NLA disabled; config source=$source"
        if ([string]::IsNullOrWhiteSpace($sslThumb)) {
            $reason += '; no bound SSL thumbprint observed'
        }
        Write-Result -State 'VULNERABLE' -Code 1 -Reason $reason
    }

    $reason = "RDP enabled; SecurityLayer=$securityLayerName; NLA=$nlaEnabled; config source=$source"
    if (-not [string]::IsNullOrWhiteSpace($sslThumb)) {
        $reason += '; SSL certificate thumbprint present'
    }
    Write-Result -State 'PATCHED' -Code 0 -Reason $reason
}
catch {
    Write-Result -State 'UNKNOWN' -Code 2 -Reason $_.Exception.Message
}

Sources

1. Tenable plugin 18405
2. Tenable RDP security blog
3. NVD CVE-2005-1794
4. Microsoft SecurityLayer documentation
5. Microsoft Win32_TSGeneralSetting documentation
6. Microsoft Using certificates in Remote Desktop Services
7. CISA KEV data repository
8. Montoro/oXid.it advisory mirror