Backward compatibility is convenient, and attackers know it. MITRE ATT&CK T1689, Downgrade Attack, covers adversaries who use outdated, vulnerable versions of system features, or versions that lack newer security controls. It sits in the Defense Impairment tactic and applies to Linux, macOS and Windows.
How attackers use it
MITRE gives several examples. Newer PowerShell versions (5 and later) support Script Block Logging, which records executed script content. An adversary may run an older PowerShell version that does not, so scripts run without that record. Network protocols are another case: traffic can be pushed from encrypted HTTPS down to plain HTTP, exposing data in clear text and enabling Adversary-in-the-Middle (T1557) or Network Sniffing (T1040). On Windows, an adversary may downgrade the boot manager to a vulnerable version that bypasses Secure Boot, which then allows them to disable other operating system protections.
Procedure examples on the page include ransomware that enables SMBv1 during execution, a tool that can downgrade NTLM to capture hashes, and an incident in which firmware on devices was downgraded to reduce visibility into the process environment.
How to detect it
MITRE's strategy looks for the old version showing up or the new control being weakened:
- On Windows, processes that launch a downgraded PowerShell version such as v2, or other legacy binaries that lack logging or security features, found through command line arguments and process metadata. Also registry changes to Defender or HVCI keys that suggest a deliberate downgrade.
- On Linux and macOS, execution of older interpreters such as python2, TLS or SSL configuration downgrades, forced fallback to unencrypted protocols, and changes to kernel modules or boot loaders that lower integrity controls.
- Changes to EFI or system boot files that could indicate a downgrade used for persistence or to bypass integrity features.
A simple, high-value rule is to alert on the command line option that selects PowerShell version 2 and on any process that starts the legacy engine.
How to reduce the risk
- Software configuration. Use policies such as HTTP Strict Transport Security on internal web servers to enforce HTTPS and block insecure connections.
- Disable or remove features. Remove older versions of tools you do not need, such as legacy scripting engines and legacy protocols.
Check your own environment
Read-only checks, with the tool noted:
# Windows PowerShell, elevated: is the PowerShell 2 engine installed?
Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root
# Windows PowerShell, elevated: is SMBv1 enabled on the server side?
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol
Then confirm that PowerShell script block logging is on (event ID 4104 in the PowerShell operational log) and that your internal sites send an HSTS header.
Quick check
Why does running an old PowerShell version help an attacker?
Older versions do not support Script Block Logging, so the content of executed scripts may not be recorded. Removing the old engine closes that route.
