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.
4 steps from start to impact.
Find RDP listeners and weak settings
nmap --script rdp-enum-encryption is enough to identify hosts that still allow native RDP security and weaker encryption levels.- TCP reachability to the RDP service
- RDP enabled on the target host
- 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
Get into the traffic path
- On-path network position or equivalent interception capability
- Victim initiates or uses an RDP session through that path
- Switched networks, VPN encapsulation, and managed admin paths reduce passive visibility
- This prerequisite usually implies the attacker is already post-initial-access
Exploit the weaker channel
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.- Target uses native RDP encryption rather than enforced TLS/SSL
- Encryption level is
1or2
- 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
Harvest session content
- An active administrative or user RDP session exists
- The intercepted session carries useful secrets or sensitive data
- No session means no payoff
- Passwordless auth, PAM workflows, and segmented admin workstations reduce credential reuse value
The supporting signals.
| In-the-wild status | No CVE-backed active exploitation record found for this check; this is a configuration weakness, not an exploit primitive. |
|---|---|
| Proof-of-concept availability | Commodity detection exists via Nmap’s rdp-enum-encryption; there is no meaningful RCE-style PoC because the issue is weak session protection. |
| EPSS | N/A — FIRST EPSS scores published CVEs, and this Tenable finding is not a CVE. |
| KEV status | Not listed / not applicable — there is no associated CVE for CISA KEV to track. |
| Vendor score | Tenable 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 scope | Any 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 state | There 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 reality | RDP 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 timeline | Tenable published plugin 57690 on 2012-01-25 and the plugin page shows an update date of 2026-01-05. |
| Reporter / origin | This appears to be a Tenable-authored manual check (rdp_weak_crypto.nbin), not an externally disclosed vendor CVE. |
noisgate verdict.
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.
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:
Lowcan 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.
What to do — in priority order.
- Set RDP encryption to High — Push
Set client connection encryption leveltoHigh (3)by GPO/MDM so native RDP sessions cannot fall back toLoworClient 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. - Force TLS-backed RDP — Use the
SecurityLayersetting 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. - 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. - 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.
- Changing RDP off port
3389does 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.
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.
# 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
}
If you remember one thing.
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
- Tenable Nessus Plugin 57690
- Microsoft Learn - RemoteDesktopServices Policy CSP
- Microsoft Learn - Win32_TSGeneralSetting class
- Microsoft Security Blog - Security guidance for remote desktop adoption
- GreyNoise - RDP scanning concentration report
- Nmap NSE - rdp-enum-encryption
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS FAQ
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.