Killing Sweet32 on Windows with PowerShell

The situation

If you run external or PCI ASV scans against Windows servers, you have seen this one. A quarterly scan came back with Sweet32 on a handful of internet-facing Windows hosts: IIS, an RD Gateway and a couple of boxes nobody remembered were exposed. Nothing exotic, just default Schannel configuration doing what it has done since 2016.

The finding is easy to fix once you know where Windows keeps the cipher suite list. The trap is fixing it the wrong way: a .reg file someone found on a forum, IIS Crypto run by hand on each box, or a GPO that quietly overrides everything you just did.

What Sweet32 is

Sweet32 is a birthday attack against block ciphers with a 64-bit block size. NVD describes the issue as a birthday bound of roughly four billion blocks for DES and Triple DES, which makes cleartext recovery practical against a long-lived encrypted session. It is scored CVSS 3.1 7.5 (confidentiality high).

The attack needs volume, not a clever exploit. The attacker has to observe a large amount of traffic on one session (collisions start around 32 GB, and the researchers needed 600 to 800 GB on one session to recover a cookie) and usually needs a way to make the victim generate it, such as injected JavaScript in a browser. That maps to T1557 Adversary-in-the-Middle and T1040 Network Sniffing. Practical risk on a typical server is low; scan and compliance risk is high, because a CVSS 7.5 finding fails a PCI ASV scan.

On Windows, these are the suites in scope:

Investigation

Which builds are affected by default

Microsoft’s per-version cipher suite tables answer this. TLS_RSA_WITH_3DES_EDE_CBC_SHA is enabled by default on Server 2016 through Server 2022 and on Windows 10 releases before 22H2. It was moved to supported-but-not-enabled in Windows 10 22H2, Server 2022 23H2, Windows 11 22H2 and Server 2025.

If a newer build is flagged, something turned it back on: a GPO, an old hardening script, or an application that sets its own list. That is worth chasing before you just disable it again.

What the host is actually offering

Get-TlsCipherSuite returns every enabled suite in priority order. You only need the names:

# Clean list of enabled suite names, in priority order
(Get-TlsCipherSuite).Name

Select-Object Name also works, but it returns objects with a header and can truncate long names in the console. The dot syntax gives you plain strings you can filter.

On some older builds (Server 2016 and early Windows 10), Get-TlsCipherSuite returns the list as a single collection object instead of one object per suite, and piping it to Select-Object Name comes back blank. The (Get-TlsCipherSuite).Name form avoids that.

Filter straight to the Sweet32 suspects:

# Anything with a 64-bit block cipher
(Get-TlsCipherSuite).Name -match '3DES|_DES_'

On a default Server 2016–2022 build this usually returns a single hit: TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Check for a policy before you change anything

# If this returns a Functions value, a GPO or MDM policy owns the suite list
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002' -ErrorAction SilentlyContinue |
    Select-Object -ExpandProperty Functions

If that returns a list, local changes will not stick. Microsoft’s documentation is explicit that a configured priority list overrides the default order and any suite not in it is not used. Fix it in the policy (see Remediation).

Root cause

Nothing is broken. Older Windows builds include 3DES in the default list for backward compatibility with clients that cannot negotiate AES. Scanners connect, offer 3DES, Schannel accepts it, and the finding fires. The fix is a configuration change, not a patch.

Remediation

Single host or RMM script

Disable the suite by name:

# Run elevated
Disable-TlsCipherSuite -Name 'TLS_RSA_WITH_3DES_EDE_CBC_SHA'

For an RMM script where you do not want to care what each box has, filter first and then loop:

# Only disable what is actually present
(Get-TlsCipherSuite).Name -match '3DES|_DES_' | ForEach-Object { Disable-TlsCipherSuite -Name $_ }

Filter first. Disable-TlsCipherSuite errors when handed a suite that is not in the current list, so a hard-coded list of every 3DES name will throw on most machines and make your RMM output useless.

The TLS module requires Windows 10 or Server 2016 or later, and an elevated session. Microsoft notes that cipher suite order changes take effect on the next boot, so schedule a reboot.

Fleet: Group Policy or Intune

For anything you manage centrally, put the list in policy so it survives rebuilds and drift:

• GPO: Computer Configuration › Policies › Administrative Templates › Network › SSL Configuration Settings › SSL Cipher Suite Order. Enable it and paste a comma-separated list of the suites you want.
• Intune: the Policy CSP setting Cryptography/TLSCipherSuites, via a settings catalog profile.

Build the list from a known-good reference host instead of typing it:

# Current enabled suites minus anything weak, ready to paste into the GPO
((Get-TlsCipherSuite).Name | Where-Object { $_ -notmatch '3DES|_DES_|NULL|RC4' }) -join ','

The GPO field is limited to 1,023 characters, so trim suites you do not need (CBC-mode and DHE suites are the usual candidates) if the string runs long. Anything not in the list is disabled, so this one setting removes 3DES from every host in scope.

Optional: disable 3DES in Schannel

The Schannel Ciphers key turns 3DES off for everything that uses Schannel, independent of the suite list. Microsoft now recommends controlling ciphers through the suite order rather than these keys, so treat this as belt and suspenders for a scan, not the primary fix.

# .NET API because 'Triple DES 168/168' contains a slash, which the registry provider treats as a path separator
$base = [Microsoft.Win32.Registry]::LocalMachine.CreateSubKey('SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers')
foreach ($c in 'Triple DES 168', 'Triple DES 168/168', 'DES 56/56') {
    $k = $base.CreateSubKey($c)
    $k.SetValue('Enabled', 0, 'DWord')   # 0 = disabled
    $k.Close()
}
$base.Close()

Setting both 3DES key names is harmless and covers the odd legacy host. Reboot after changing Schannel keys.

While you are in there: NULL suites

You will notice suites like TLS_RSA_WITH_NULL_SHA256 in the list. NULL means no encryption, only integrity. Microsoft’s cipher suite documentation marks them as used only when an application explicitly requests them, and Schannel filters RC4, DES, export and NULL suites out when the application asks for strong crypto (SCH_USE_STRONG_CRYPTO). They are rarely negotiated, but they are still in the list. If a scanner flags them anyway or you want a clean list:

(Get-TlsCipherSuite).Name -match 'NULL' | ForEach-Object { Disable-TlsCipherSuite -Name $_ }

Verification

On the host, after the reboot:

# No output means nothing weak is left in the offer list
(Get-TlsCipherSuite).Name -match '3DES|_DES_|NULL'

Then reproduce what the scanner does, from another machine:

# Enumerate offered suites; 3DES should be gone and nothing should grade below A
nmap --script ssl-enum-ciphers -p 443 <host>

# Try to force a 3DES handshake; this should fail with a handshake error
openssl s_client -connect <host>:443 -tls1_2 -cipher DES-CBC3-SHA

Repeat for every TLS listener, not just 443: RDP (3389), LDAPS (636), SMTP with STARTTLS and anything else the scan touched. Then request a rescan to close the finding.

Caveats

• Group Policy wins. If SSL Cipher Suite Order is set by policy, local cmdlet changes are overridden. Change the GPO.
• Not everything uses Schannel. Java, OpenSSL-based apps, Apache and many appliances bring their own TLS stack and their own cipher configuration. If the finding is on a port served by one of those, this post does not fix it.
• Compliance. PCI DSS v4.0 Requirement 4.2.1 requires strong cryptography for cardholder data over public networks, and a CVSS 4.0 or higher finding fails an ASV scan. NIST SP 800-131A Rev. 2 disallows Triple DES for encryption after 2023, which matters for CMMC (SC.L2-3.13.11) and anything else that leans on NIST guidance. HIPAA transmission security (164.312(e)(1)) does not name ciphers, but auditors will.
• Risk acceptance. If a legacy dependency keeps 3DES alive on one host, document a compensating control (network segmentation, short session lifetimes, allow-listing the client) and get a formal exception. Do not leave it enabled fleet-wide for one printer.
• Sweet32 is rarely alone. TLS 1.0/1.1 and RC4 usually sit right next to it on the report. Plan those in the same change window.

Key takeaways

1. Sweet32 on Windows is a default-configuration finding on Server 2016–2022 and Windows 10 releases before 22H2, not a missing patch.
2. (Get-TlsCipherSuite).Name -match '3DES|_DES_' tells you exactly what a host offers in one line.
3. Filter before you disable; hard-coded lists throw errors and hide real failures in RMM output.
4. Use the SSL Cipher Suite Order GPO or Intune for anything managed centrally, and check for an existing policy before touching a host locally.
5. Prove the fix from outside with the same technique the scanner uses, on every TLS port, not just 443.

References

• CVE-2016-2183 (NVD)
• Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN
• Disable-TlsCipherSuite (Microsoft Learn)
• Manage Transport Layer Security (TLS) (Microsoft Learn)
• TLS registry settings (Microsoft Learn)
• Restrict cryptographic algorithms and protocols in Schannel.dll (Microsoft Learn)
• TLS cipher suites in Windows Server 2022 (Microsoft Learn)
• TLS cipher suites in Windows 10 v22H2 (Microsoft Learn)
• NIST SP 800-131A Rev. 2
• MITRE ATT&CK T1557