Skip to content
PowerShellparser

Glossary

PowerShell downgrade attack

Launching PowerShell version 2 to escape the script block logging and AMSI that only exist in version 5.

A PowerShell downgrade attack starts PowerShell with -Version 2 so the session runs on the old PowerShell 2.0 engine instead of version 5. The 2.0 engine predates the security features added in version 5: it has no Script Block Logging, no module logging and no AMSI integration. If the Windows PowerShell 2.0 feature and the .NET Framework 2.0/3.5 runtime it depends on are present, an attacker gets a full scripting environment that leaves far less evidence and is not scanned by antivirus at run time.

Why it matters in investigations

A downgrade is a deliberate choice to avoid visibility, so its presence is significant even when you cannot see what ran afterwards. It also explains gaps: a host with script block logging enabled but no 4104 events for a suspicious session may have been running the v2 engine. The good news is that the classic Windows PowerShell log is still written by the v2 engine, so the attempt itself remains visible.

Defenders prevent it by removing the Windows PowerShell 2.0 optional feature, which leaves -Version 2 with no engine to load.

Example

The command line, as recorded in the HostApplication field of a classic-log event 400:

HostApplication=powershell.exe -Version 2 -NoProfile -Command whoami
EngineVersion=2.0

The two fields tell the same story from two angles: the switch shows the request, and EngineVersion=2.0 shows the engine that actually started. The parser raises a high-severity downgrade finding for a -Version 2 (or -v 2) switch on a PowerShell command line, and for any event 400 or 403 whose engine version is 2.x.

Check event 400 engine versions in the PowerShell Parser, read the PowerShell event-log guide, and see Lee Holmes on downgrade attacks.