← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:57690 · Disclosed 2012-01-25

Terminal Services Encryption Level is Medium or Low

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a frosted-glass office wall, not an unlocked front door

Tenable plugin 57690 flags Windows Terminal Services / Remote Desktop Services when the host is configured with MinEncryptionLevel 1 (*Low*) or 2 (*Client Compatible / Medium*). In Microsoft’s own definitions, Low encrypts only client-to-server traffic with 56-bit strength, while Client Compatible encrypts both directions at whatever the client supports; High is 3 and FIPS is 4. Practically, the affected population is any Windows RDP listener using native RDP encryption with that setting, not a specific patched/unpatched software version.

Tenable’s MEDIUM is defensible in a vacuum, but too generous for enterprise prioritization. This weakness does not give an unauthenticated remote attacker code execution or host takeover; it mainly helps an attacker who is already on-path or already inside the network observe session data more easily. Microsoft also notes this policy applies only to native RDP encryption and is not the control for SSL/TLS-protected RDP, which means many modern RDP deployments have meaningful real-world friction before this matters.

"Weak RDP crypto is an eavesdropping problem, not a break-in bug; fix it in baseline hardening, not the fire drill queue."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find RDP listeners and weak settings

An attacker first discovers exposed or reachable RDP services and tests supported security layers and encryption levels. Commodity tooling like nmap --script rdp-enum-encryption is enough to identify hosts that still allow native RDP security and weaker encryption levels.
Conditions required:
  • TCP reachability to the RDP service
  • RDP enabled on the target host
Where this breaks in practice:
  • Most enterprise RDP should sit behind VPN, RD Gateway, or internal segmentation
  • Internet exposure is easy to find, but internally scoped admin subnets sharply reduce reachable population
Detection/coverage: Excellent discovery coverage: Tenable/Nessus and Nmap both detect this reliably from the network side.
STEP 02

Get into the traffic path

The weakness becomes useful only if the adversary can observe or intercept the RDP session path. In practice that means a hostile Wi-Fi, compromised VPN/jump infrastructure, a malicious internal position, or another man-in-the-middle foothold rather than a clean unauthenticated internet-to-host exploit.
Conditions required:
  • On-path network position or equivalent interception capability
  • Victim initiates or uses an RDP session through that path
Where this breaks in practice:
  • Switched networks, VPN encapsulation, and managed admin paths reduce passive visibility
  • This prerequisite usually implies the attacker is already post-initial-access
Detection/coverage: Moderate. Network anomaly tooling may catch ARP spoofing, rogue gateways, or unusual admin-path interception, but passive sniffing on already-compromised infrastructure is hard to see.
STEP 03

Exploit the weaker channel

If the host is using native RDP security with Low or Client Compatible, the attacker can monitor a session with materially weaker protection than High or TLS-backed configurations. In the Low case, server-to-client traffic protection is especially poor, which is why screenshots and displayed data are the main exposure.
Conditions required:
  • Target uses native RDP encryption rather than enforced TLS/SSL
  • Encryption level is 1 or 2
Where this breaks in practice:
  • Microsoft notes this policy is for native RDP encryption and does not apply to SSL/TLS encryption
  • NLA, TLS, RD Gateway, and certificate-backed deployments reduce or eliminate the specific weakness Tenable is flagging
Detection/coverage: Limited direct alerting. Protocol inspection can sometimes reveal native RDP vs TLS, but many environments do not log this at scale.
STEP 04

Harvest session content

The realistic payoff is confidentiality loss: screen contents, typed secrets, or session metadata from privileged admin use. That can absolutely matter, but it is still a chained outcome that depends on prior network access and an active session, not a direct host compromise path.
Conditions required:
  • An active administrative or user RDP session exists
  • The intercepted session carries useful secrets or sensitive data
Where this breaks in practice:
  • No session means no payoff
  • Passwordless auth, PAM workflows, and segmented admin workstations reduce credential reuse value
Detection/coverage: Weak. EDR on the target host usually will not see passive interception of the transport itself.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo CVE-backed active exploitation record found for this check; this is a configuration weakness, not an exploit primitive.
Proof-of-concept availabilityCommodity detection exists via Nmap’s rdp-enum-encryption; there is no meaningful RCE-style PoC because the issue is weak session protection.
EPSSN/A — FIRST EPSS scores published CVEs, and this Tenable finding is not a CVE.
KEV statusNot listed / not applicable — there is no associated CVE for CISA KEV to track.
Vendor scoreTenable rates it MEDIUM, CVSS v2 4.3, vector AV:N/AC:M/Au:N/C:P/I:N/A:N — a confidentiality-only story.
Affected scopeAny Windows RDP/Terminal Services host with MinEncryptionLevel set to 1 (*Low*) or 2 (*Client Compatible*). Microsoft says the policy applies only to native RDP encryption and doesn't apply to SSL encryption.
Fixed stateThere is no vendor patch version. The fixed state is configuration: set encryption to High (3) or FIPS (4), and preferably force TLS/SSL-backed RDP with NLA.
Exposure realityRDP remains a heavily targeted service. GreyNoise reported a 21-IP fleet responsible for 67.4% of observed global RDP Crawler activity in a 48-hour window from 2026-04-05 to 2026-04-07.
Disclosure / plugin timelineTenable published plugin 57690 on 2012-01-25 and the plugin page shows an update date of 2026-01-05.
Reporter / originThis appears to be a Tenable-authored manual check (rdp_weak_crypto.nbin), not an externally disclosed vendor CVE.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.1/10)

The decisive factor is attacker position requirement: this weakness is only valuable to someone who can already observe or intercept RDP traffic, which usually means post-compromise or privileged network placement. The blast radius is also narrower than Tenable’s label suggests because the finding is mainly about session confidentiality under native RDP encryption, not direct system compromise.

HIGH Technical understanding of what `Low` and `Client Compatible` mean on Windows RDP
MEDIUM Real-world severity across mixed enterprise RDP architectures

Why this verdict

  • Downgrade for attacker position: exploitation value requires an on-path adversary, not a clean unauthenticated remote shot from the internet.
  • Downgrade for deployment narrowing: Microsoft states this encryption-level policy applies to native RDP encryption and not SSL/TLS encryption, so modern RDP stacks often blunt the issue before it matters.
  • Keep it non-zero: Low can leave server-to-client data effectively exposed under native RDP, which is bad for privileged admin sessions and sensitive screen content.

Why not higher?

There is no direct code execution, no authentication bypass, and no host takeover path here. An attacker must first reach the service and then gain a useful interception position, which is a major compounding friction point that pushes this well below a true medium-priority break-in issue.

Why not lower?

This is still a real confidentiality weakness, especially when administrators use RDP from flat internal networks, branch links, or poorly controlled jump paths. If you still have raw RDP exposure or legacy native-RDP security settings, the downside is not theoretical.

05 · Compensating Control

What to do — in priority order.

  1. Set RDP encryption to High — Push Set client connection encryption level to High (3) by GPO/MDM so native RDP sessions cannot fall back to Low or Client Compatible. Because this is a LOW verdict, there is no SLA; treat it as backlog hygiene and land it in the next Windows baseline cycle.
  2. Force TLS-backed RDP — Use the SecurityLayer setting to prefer or require TLS/SSL-backed RDP rather than native RDP security, which is the mode this finding actually cares about. For a LOW verdict, fold this into your normal hardening program unless the host is unusually exposed.
  3. Require NLA — Enable Network Level Authentication so only modern RDP clients can connect and unauthenticated session setup is reduced. This does not directly 'fix' plugin 57690, but it materially improves the surrounding RDP posture and should be included in the same baseline change.
  4. Move admin RDP behind a gateway — Run administrative RDP through RD Gateway, VPN, or a managed jump tier so the reachable population and interception surface both shrink. Since this finding is LOW, schedule it through architecture hygiene unless the service is directly internet-facing.
What doesn't work
  • Changing RDP off port 3389 does not improve the session cryptography; it only changes discovery noise.
  • Relying on strong passwords alone does not address on-path observation of a weakly protected native RDP session.
  • EDR on the target host usually does not stop passive network interception of RDP transport data.
06 · Verification

Crowdsourced verification payload.

Run this on the Windows target host from an elevated PowerShell session. Example: powershell -ExecutionPolicy Bypass -File .\check-rdp-encryption.ps1; local Administrator is recommended because the script queries root\cimv2\terminalservices and related policy/registry state.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# check-rdp-encryption.ps1

# Verifies whether the local RDP listener is configured with a weak encryption level

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN


$ErrorActionPreference = 'Stop'

function Out-Result {
    param(
        [string]$Status,
        [int]$Code,
        [string]$Message
    )
    Write-Output "$Status - $Message"
    exit $Code
}

try {
    $ts = Get-CimInstance -Namespace 'root/cimv2/terminalservices' -ClassName 'Win32_TSGeneralSetting' -Filter "TerminalName='RDP-tcp'"
    if (-not $ts) {
        Out-Result 'UNKNOWN' 2 'RDP-Tcp listener not found in Win32_TSGeneralSetting.'
    }

    $encMap = @{ 1='Low'; 2='ClientCompatible'; 3='High'; 4='FIPS' }
    $secMap = @{ 1='RDP'; 2='Negotiate'; 3='SSL'; 4='Other' }
    $nlaMap = @{ 0='Disabled'; 1='Enabled' }

    $enc = [int]$ts.MinEncryptionLevel
    $sec = [int]$ts.SecurityLayer
    $nla = [int]$ts.UserAuthenticationRequired

    $encName = $encMap[$enc]
    if (-not $encName) { $encName = "Unknown($enc)" }
    $secName = $secMap[$sec]
    if (-not $secName) { $secName = "Unknown($sec)" }
    $nlaName = $nlaMap[$nla]
    if (-not $nlaName) { $nlaName = "Unknown($nla)" }

    $policyPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
    $rdpTcpPath  = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'

    $gpMin = $null
    $gpSec = $null
    if (Test-Path $policyPath) {
        $p = Get-ItemProperty -Path $policyPath -ErrorAction SilentlyContinue
        if ($null -ne $p.MinEncryptionLevel) { $gpMin = [int]$p.MinEncryptionLevel }
        if ($null -ne $p.SecurityLayer) { $gpSec = [int]$p.SecurityLayer }
    }

    $regMin = $null
    $regSec = $null
    if (Test-Path $rdpTcpPath) {
        $r = Get-ItemProperty -Path $rdpTcpPath -ErrorAction SilentlyContinue
        if ($null -ne $r.MinEncryptionLevel) { $regMin = [int]$r.MinEncryptionLevel }
        if ($null -ne $r.SecurityLayer) { $regSec = [int]$r.SecurityLayer }
    }

    $details = @(
        "MinEncryptionLevel=$encName($enc)",
        "SecurityLayer=$secName($sec)",
        "NLA=$nlaName($nla)",
        "PolicyMinEncryptionLevel=" + ($(if ($null -ne $gpMin) { $gpMin } else { 'unset' })),
        "PolicySecurityLayer=" + ($(if ($null -ne $gpSec) { $gpSec } else { 'unset' })),
        "RegistryMinEncryptionLevel=" + ($(if ($null -ne $regMin) { $regMin } else { 'unset' })),
        "RegistrySecurityLayer=" + ($(if ($null -ne $regSec) { $regSec } else { 'unset' }))
    ) -join '; '

    if ($enc -eq 1 -or $enc -eq 2) {
        Out-Result 'VULNERABLE' 1 $details
    }
    elseif ($enc -eq 3 -or $enc -eq 4) {
        Out-Result 'PATCHED' 0 $details
    }
    else {
        Out-Result 'UNKNOWN' 2 $details
    }
}
catch {
    Out-Result 'UNKNOWN' 2 $_.Exception.Message
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, separate architecture risk from this plugin: if any of these hosts expose raw RDP externally, fix that exposure immediately because public RDP is a broader access problem even though plugin 57690 itself is only LOW. For this finding alone, there is no noisgate mitigation SLA and no noisgate remediation SLA — treat it as backlog hygiene, verify which systems still use MinEncryptionLevel 1 or 2, and roll the GPO/MDM hardening change into the next Windows baseline cycle rather than burning emergency patch bandwidth on it.

Sources

  1. Tenable Nessus Plugin 57690
  2. Microsoft Learn - RemoteDesktopServices Policy CSP
  3. Microsoft Learn - Win32_TSGeneralSetting class
  4. Microsoft Security Blog - Security guidance for remote desktop adoption
  5. GreyNoise - RDP scanning concentration report
  6. Nmap NSE - rdp-enum-encryption
  7. CISA Known Exploited Vulnerabilities Catalog
  8. FIRST EPSS FAQ
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.