If you still rely on PowerShell 2.0, you should think about updating your code to work with PowerShell 5.0. Starting in the Windows 10 Fall Creators Update, Microsoft will no longer support PowerShell 2.0. In this Ask the Admin, I’ll discuss why PowerShell 2.0 poses a security risk and how to remove it from Windows 10.
If you thought that PowerShell 2.0 had been killed off long ago, you might be surprised to find out that it is installed by default today in Windows 10. That is about to change in the Fall Creators Update. Microsoft has decided to deprecate it and is recommending organizations ensure its scripts are compatible with PowerShell 5.0.
As I recently discussed in Protect Against Malware by Enforcing PowerShell Constrained Language Mode on Petri, hackers have been using the PS>Attack and Mimikatz frameworks to exploit Windows, primarily to compromise users’ credentials. That is not to say PowerShell is vulnerable per se. As with any technology, Microsoft recommends running the latest version to benefit from recent security enhancements, such as script block logging and the ability to enforce the use of constrained language mode.
The Problem with PowerShell 2.0
New security features in PowerShell 5.0 make it much harder for hackers to uncover users’ credentials, using frameworks like Mimikatz, if you follow security best practices.
Anti-Malware Scan Interface
The Anti-Malware Scan Interface (AMSI) interface in Windows 10, which is supported out-of-the-box by Windows Defender and available to other antimalware products, can perform deep scans on obfuscated PowerShell code. This is code that has been encoded specifically for the purposes of avoiding detection. If a hacker manages to force the use of PowerShell 2.0, then AMSI is unable to de-obfuscate the code.
Constrained Language Mode
In PowerShell 5.0, administrators can enforce constrained language mode to protect devices from malicious activity. This helps in preventing hackers from loading COM objects, libraries, and classes into PowerShell sessions.
For more information on the restrictions imposed by constrained language mode, see Microsoft’s website here. Constrained language mode can be enforced using AppLocker or Device Guard, for which you will need Windows 10 Enterprise. For more details on how to enforce constrained language mode, take a look at the article from Petri that is mentioned above.
Script Block Logging
Script block logging was introduced in PowerShell 5.0 and can be added to the Windows Management Framework (WMF) 4.0 with KB3000850. Script block logging is important because malware writers obfuscate their wares to avoid detection.
But when script block logging is enabled, it writes de-obfuscated PowerShell code to the event log. You can see exactly what is going on. No more hiding behind Base64. To take advantage of script block logging, you will need to centralize the collection of logs using a Security Information and Event Management (SIEM) solution. Script block logging can be enabled in Group Policy using the Turn on PowerShell Transcription setting under Windows Components -> Administrative Templates -> Windows PowerShell.
Disable PowerShell 2.0
If you do not want to wait or are not planning to upgrade to the Fall Creators Update as soon as it becomes available, you can disable PowerShell 2.0 with the Disable-WindowsOptionalFeature cmdlet from an elevated PowerShell prompt. Alternatively, you can make sure that PowerShell 2.0 is disabled in your gold image from the get-go.
Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2
In this article, I discussed why Microsoft is deprecating PowerShell 2.0 in the next update to Windows 10. I also discussed some of the security enhancements in PowerShell 5.0, which leaves PowerShell 2.0 vulnerable.