PowerShell Language Modes-Part 2
In this article we will learn about PowerShell Language Modes.
PowerShell Language Modes:
Part 1 of this series explored the basics of PowerShell language modes, their types, and the limited language mode. Also reviewed Device Guard and Code Integrity (UMCI & KMCI).
In this article, we will look at how to bypass UMCI enforcement. In what we saw in Part 1, the skipping logic is similar to changing mode from a restricted state to a full language state to run all PowerShell elements. Other ways would be to bypass the restrictions imposed by the restricted language mode.
Technique 1
PowerShell downgrade attack
A PowerShell Downgrade attack is a straightforward code execution to modify configurations, such as changing the language mode from limited to full language mode.
PowerShell v2 must be enabled for this technique to work as shown in the screenshot below:
Once this is done, the default PowerShell language is in full mode, and then we change it back to a limited state. Then the shell is opened with v2 and then the language mode is set to Full again. This means that if a cyber attacker can turn on the v2 feature, the full language mode can be easily obtained using the method as shown below:
Technique 2
Revisions: CVE-2017-8715 & CVE-2017-0218
In Part 1, we reviewed the limitations of Limited Language mode. One of them was the limited Add-Type routine. It was also discussed how such functions that were explicitly exported by modules could be used. Now imagine a scenario where a cyber attacker can use the exported functions of a signed MS PowerShell script to launch and execute arbitrary code.
Also Read:The Rise of MBR Ransomware-by Blackhat Pakistan 2023
Before the official patch known as “CVE-2017-0218”, it was possible to run arbitrary code from a signed MS PowerShell script. After the patch, Microsoft introduced additional restrictions, such as Limited Language Mode (CLM) no longer being able to import scripts.
An additional restriction was introduced to prevent scripts from being renamed from .ps1 to .psm1. This made it possible to import those modules that were exported using the Export-ModuleMember technique.
The above limitation was bypassed using the PowerShell Module Manifest(.PSD1). It contains information about the Powershell script, such as author, payload type, file type, etc. An interesting feature of these manifest files is that the functions to be exported can be explicitly defined using the “FunctionsToExport” element. It specifies the function that can be exported and even the wildcards that are supported.
PSD1 files do not need to be signed as .ps1 and .psm1 and therefore can be moved to the top-level directory that contains the module to expose these functions. Microsoft later imposed restrictions even on .PSD1 files to be signed as allowed. psm1 files. More details on this technique can be found here.
Technique 3
Revision of CVE-2017-0007
Many restrictions are imposed when a PowerShell session is in Restricted Language Mode (CLM). For example, if the Device Guard policy is enforced, only signed MS binaries can be run.
However, it is the code (wintrust.dll) that checks if the binary is signed or not. That’s what CVE-2017-0007 is about. It has been found that wintrust.dll never performs validation checks on the returned error code if the integrity of the file is compromised.
How is this possible?
Authenticode signatures can be extracted from signed files and then copied into custom .ps1 files. The contents of the signed binary are replaced with their own contents, leaving the Signature block intact.
It is important to note that the digital signature cannot be verified, but the error returned is never handled by the wintrust.dll file. This allows running custom scripts that can run arbitrary code on the machine. Even though Device Protection Mode and Restricted Language Mode are in full enforcement mode.
More details about CVE-2017-0007 can be found here.
Three separate techniques have been explored so far, but this is by no means an exhaustive list. There are many other techniques that have been discovered in the past to bypass enforced device protection policies and restricted language mode.
The good news is that Microsoft is very active in fixing these kinds of bugs and isn’t shy about introducing new features that make PowerShell a really great tool to use for pen testing applications.
