Detecting and Preventing PowerShell Downgrade Attacks

With the advent of PowerShell v5’s awesome new security features, old versions of PowerShell have all of the sudden become much more attractive for attackers and Red Teams.

PowerShell Downgrade Attacks

There are two ways to do this:

Command Line Version Parameter

The simplest technique is: “PowerShell –Version 2 –Command <…>” (or of course any of the –Version abbreviations).

PowerShell.exe itself is just a simple native application that hosts the CLR, and the –Version switch tells PowerShell which version of the PowerShell assemblies to load.

Unfortunately, the PowerShell v5 enhancements did NOT include time travel, so the v2 binaries that were shipped in 2008 did NOT include the code we wrote in 2014.  The 2.0 .NET Framework (which is required for PowerShell’s V2 engine) is not included by default in Win10+, but an attacker or Red Teamer could enable it or install it. Prior to Windows 10, where it is available by default, they could just use it.


Hosting Applications Compiled using V2 Reference Assemblies

When somebody compiles a C# application to leverage the PowerShell engine, they link against reference assemblies when they do that. If they link against the PowerShell v2 reference assemblies during development, Windows will use the PowerShell v2 engine (if available) when the application runs. Otherwise, PowerShell's type forwarding will run the application using the currently installed PowerShell engine.

This is what happens when PowerShell Empire's "psinject" module attempts to load PowerShell into another process (such as notepad).


Detection and Prevention

You have several options to detect and prevent PowerShell Downgrade Attacks.

Event Log

As a detection mechanism, the “Windows PowerShell” classic event log has event ID 400. This is the “Engine Lifecycle” event, and includes the Engine Version. Here is an example query to find lower versions of the PowerShell engine being loaded:

Get-WinEvent -LogName "Windows PowerShell" |
    Where-Object Id -eq 400 |
    Foreach-Object {
        $version = [Version] ($_.Message -replace '(?s).*EngineVersion=([\d\.]+)*.*','$1')
        if($version -lt ([Version] "5.0")) { $_ }


AppLocker / File Auditing

When the CLR loads PowerShell assemblies, it will first load the managed assemblies from the GAC (if they are available). It will also load the native images that contain pre-jitted code if the assemblies are NGEN’d (which they are). Here is what loading PowerShell v2 looks like:

These can either be an audit trigger, or can be blocked outright.

Be careful to not be too selective on the directories you monitor, as the CLR can also load assemblies from specific directories. For example, it is possible to use the CLR’s undocumented / unsupported DEVPATH environment variable to force the CLR to use a specified version of the assemblies rather than the GAC’d version. And if you don’t have a GAC’d version to override, PowerShell will do regular LoadLibrary() probing to find one – including its installation directory.

In addition, PowerShell can either be launched as a 32-bit process, or 64-bit process. A 64-bit system will load 64-bit PowerShell by default. A 32-bit system will load 32-bit PowerShell. On a 64-bit system, though, Windows will implicitly change the version of PowerShell that gets launched by looking at the bitness of the launching application: a 32-bit app will load other 32-bit apps. It is also possible for users or applications to do this explicitly by launching PowerShell from the WOW directory: c:\windows\syswow64\windowspowershell\v1.0\powershell.exe.

PS > dir *.dll -rec -ea ig | % FullName | ? { $_ -match 'System\.Management\.Automation\.(ni\.)?dll' }


If you’re going down the enforcement route via AppLocker or Device Guard path, the most robust solution is to block earlier versions of the PowerShell engine by version. Be sure to block both the native image and MSIL assemblies:

C:\Users\leeholm>powershell -version 2 -noprofile -command "(Get-Item ([PSObject].Assembly.Location)).VersionInfo"

ProductVersion   FileVersion      FileName
--------------   -----------      --------
6.1.7600.16385   6.1.7600.16385   C:\WINDOWS\assembly\GAC_MSIL\System.Management.Automation\

C:\Users\leeholm>powershell -noprofile -command "(Get-Item ([PSObject].Assembly.Location)).VersionInfo"

ProductVersion   FileVersion      FileName
--------------   -----------      --------
10.0.14986.1000  10.0.14986.1000  C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0...

C:\Users\leeholm>powershell -version 2 -noprofile -command "(Get-Item (Get-Process -id $pid -mo | ? { $_.FileName -match '' } | % { $_.FileName })).VersionInfo"

ProductVersion   FileVersion      FileName
--------------   -----------      --------
6.1.7600.16385   6.1.7600.16385   C:\WINDOWS\assembly\NativeImages_v2.0.50727_64\System.Management.A#\8b1355a0339430...

C:\Users\leeholm>powershell -noprofile -command "(Get-Item (Get-Process -id $pid -mo | ? { $_.FileName -match '' } | % { $_.FileName })).VersionInfo"

ProductVersion   FileVersion      FileName
--------------   -----------      --------
10.0.14986.1000  10.0.14986.1000  C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Manaa57fc8cc#\4072bc1c91e324...

9 Responses to “Detecting and Preventing PowerShell Downgrade Attacks”

  1. Habib Shakir writes:

    I was searching this and you saved my time
    thanks for complete details about this problem

  2. Dew Drop - March 20, 2017 (#2443) - Morning Dew writes:

    […] Detecting and Preventing PowerShell Downgrade Attacks (Lee Holmes) […]

  3. clint writes:

    Hi Lee. Great idea using AppLocker for blocking PowerShell 2.0 DLLs. I tried creating a Deny rule using the Publisher type for both these cases: System.Management.Automation.dll and Creating the rule for the managed version worked fine but the unmanaged version (.ni.dll) fails with this error message:

    The publisher information cannot be extracted from the specified file: (file path here). Reason: The object identifier does not represent a valid object. (Exception from HRESULT: 0x800710D8).

    If I right click the unmanaged version and look at its properties, then the file version and product information display. Not sure why AppLocker is having a problem though. There is no Digital Signatures tab when I right click the unmanaged DLL though. I checked it with SysteInternals sigverify and it is unsigned which makes sense I guess since it was NGENed. The managed one is signed so that explains it why it works for one but not the other.

  4. clint writes:

    My untested workaround for the unmanaged version is to create a Deny rule using the Path type. Path is *\ with exceptions for %WINDIR%\assembly\NativeImages_v4.0.30319_32\* and %WINDIR%\assembly\NativeImages_v4.0.30319_64\*

  5. Ryan writes:

    Couldn’t you just remove it under windows features? Now if the attack gained elevated priv and bypassed UAC then yes they could prob just re-install/enable it.

  6. PowerShell Security: PowerShell Downgrade Attacks | Cloud OS writes:

    […] Holmes from the PowerShell product group already tackled this here, but I wanted to revisit the […]

  7. 【技术分享】利用PowerShell代码注入漏洞绕过受限语言模式-安全路透社 writes:

    […] 有个关于UMCI绕过二进制的有效的黑名单规则是文件名规则,其能基于PE文件中版本信息资源中的原始文件名来阻止程序执行。PowerShell很明显不是个PE文件,它是文本文件,因此文件名规则不适用。但是,你可以通过使用哈希规则强制阻止有漏洞的脚本。Okay…要是相同脚本有不止一个漏洞呢?目前为止你只阻止一个哈希。你开始注意这个问题了吗?为了有效的阻止之前所有有漏洞的版本的脚本,你必须知道所有有漏洞的版本的哈希。微软意识到了问题并尽最大努力来扫描所有之前发布的有漏洞脚本,且收集哈希将他们整合到了黑名单中。通过他们的哈希阻止所有版本的有漏洞的脚本有一定挑战性,但能一定程度上阻止攻击。这就是为什么一直迫切需要只允许PowerShell 5的执行并要开启scriptblock日志记录。Lee Holmes 有篇关于如何有效的阻止老版本的PowerShell的博文。 […]

  8. 利用PowerShell代码注入漏洞绕过受限语言模式 – 黑客视界 [Hackeye] writes:

    […] 有个关于UMCI绕过二进制的有效的黑名单规则是文件名规则,其能基于PE文件中版本信息资源中的原始文件名来阻止程序执行。PowerShell很明显不是个PE文件,它是文本文件,因此文件名规则不适用。但是,你可以通过使用哈希规则强制阻止有漏洞的脚本。Okay…要是相同脚本有不止一个漏洞呢?目前为止你只阻止一个哈希。你开始注意这个问题了吗?为了有效的阻止之前所有有漏洞的版本的脚本,你必须知道所有有漏洞的版本的哈希。微软意识到了问题并尽最大努力来扫描所有之前发布的有漏洞脚本,且收集哈希将他们整合到了黑名单中。通过他们的哈希阻止所有版本的有漏洞的脚本有一定挑战性,但能一定程度上阻止攻击。这就是为什么一直迫切需要只允许PowerShell 5的执行并要开启scriptblock日志记录。Lee Holmes 有篇关于如何有效的阻止老版本的PowerShell的博文。 […]

  9. From PowerShell to [email protected] – Detecting and Preventing PowerShell Attacks - EventSentry Blog writes:

    […] If you so wish, then you can read more about the PowerShell downgrade attack and detailed information on how to configure AppLocker here. […]

Leave a Reply