Shulou(Shulou.com)06/02 Report--

This article mainly shows you "how to use Winrm.vbs to bypass whitelist restrictions on the execution of arbitrary code", the content is easy to understand, clear, hope to help you solve your doubts, the following let the editor lead you to study and learn "how to use Winrm.vbs to bypass whitelist restrictions on the implementation of arbitrary code" this article.

For reference and study only.

Bypass method description

Winrm.vbs (a Windows-signed script file located in the system32 directory) can be used to invoke a user-defined XSL file, resulting in arbitrary, unsigned code execution. When the user provides the'- format:pretty' or'- format:text' parameter to winrm.vbs, winrm.vbs reads the WsmPty.xsl or Wsmtxt.xsl file from the directory where cscript.exe is located. This means that if the cscript.exe is copied to a directory that the attacker can control, and the malicious XSL file is placed in the same path, the attacker will be able to execute arbitrary code by bypassing signature protection. This attack is very similar to Casey Smith's wmic.exe technology.

Bypass the method's POC

The entire workflow is as follows:

1. Place malicious WsmPty.xsl or WsmTxt.xsl files in directories that an attacker can control.

two。 Copy cscript.exe or wscript.exe to the same directory.

3. According to the malicious XSL file (WsmPty.xsl or WsmTxt.xsl) in the first step, execute winrm.vbs and provide different parameters ('- format:pretty' or'- format:text'). The following is an example of a malicious XSL file. The file can be placed in the path in the first step above (for this example, C:\ BypassDir\ WsmPty.xsl):

A more offensive XSL file can execute Payload generated through DotNetToJScript, resulting in the execution of arbitrary unsigned code by an attacker. After placing a malicious XSL file, the following batch files can be used to start paylaod:

Mkdir% SystemDrive%\ BypassDircopy% windir%\ System32\ cscript.exe% SystemDrive%\ BypassDir%SystemDrive%\ BypassDir\ cscript / / nologo% windir%\ System32\ winrm.vbs get wmicimv2/Win32_Process?Handle=4-format:pretty how I discovered the problem

I found that the problem was entirely accidental. I worked with Casey on how to use wmic.exe 's XSL bypass, and soon after, I began to examine the various VBS and JScript files that came with the system, looking for more ways to bypass. I started checking these built-in scripts because I was inspired by Matt Nelson's .vbs injection technology. When I looked up the winrm.vbs source code, the 'WsmPty'' and 'WsmTxt'' in the file immediately caught my attention, because Casey once said in his blog that for files that use XSL, they have the potential to execute arbitrary code by embedding WSH script content in the XSL file. There is no doubt that winrm.vbs is no exception. I'm very focused on finding scripts or binaries with Windows signatures that can cause arbitrary code to execute. This is because not only can they bypass the defenses of applying whitelists, but they are also not easily detected by security software (at least when they have not yet been published). I will always be on the way to find them!

Detection strategy

In order to effectively detect and protect the above methods, it is important to find the minimum set of components needed for this kind of attack.

WsmPty.xsl or WsmTxt.xsl files controlled by an attacker must be created

Winrm.vbs hardcodes the names of the two files and explicitly binds them to the 'pretty' or' text' parameter. For now, these two files can only be obtained in the current working directory (in most cases, the same directory where cscript.exe is located) and are unlikely to be redirected to another location. From a defensive point of view, if a WsmPty.xsl or WsmTxt.xsl file has a different hash value from their version in the System32 directory, we can assume that the XSL file is suspicious. Fortunately, legitimate XSL files rarely change.

A winrm.vbs with a valid signature is executed. To take advantage of the bypass method in this article, the attacker cannot modify the contents of the winrm.vbs

This defense is inadequate by looking for the 'winrm.vbs' string on the command line, because an attacker can change the file name of the winrm.vbs at will.

The 'format' parameter when calling winrm.vbs must be specified as' pretty' or 'text', so that winrm.vbs can call the corresponding xsl file.

Attackers can take not only the 'format' parameter, but also the following variants (case-sensitive):

-format:pretty

-format: "pretty"

/ format:pretty

/ format: "pretty"

-format:text

-format: "text"

/ format:text

/ format: "text"

If you just look up the 'format' string, you can detect all the variants mentioned above, this method will bring a lot of false positions.' Whether the content followed by format:' is legal or not will depend on the specific company environment. However, legitimate references to xsl files come more from csript.exe and winrm.vbs files in the system32 directory than from other locations.

Winrm.vbs should be executed by cscript.exe. The logic within winrm.vbs verifies this.

Winrm.vbs verifies that it is executed by cscript.exe by verifying that WScript.FullName contains the string 'cscript.exe'. This validation itself is not perfect because it simply checks whether the path to the executable contains the 'cscript.exe' string. This will allow attackers to launch winrm.vbs from a renamed cscript.exe or even to launch winrm.vbs with other script interpreters such as wscript.exe. The following example of a batch program illustrates how to bypass the validation of 'cscript.exe' in the winrm.vbs script:

Mkdir% SystemDrive%\ BypassDir\ cscript.execopy% windir%\ System32\ wscript.exe% SystemDrive%\ BypassDir\ cscript.exe\ winword.exe%SystemDrive%\ BypassDir\ cscript.exe\ winword.exe / / nologo% windir%\ System32\ winrm.vbs get wmicimv2/Win32_Process?Handle=4-format:pretty testing method robustness

The get wmicimv2/Win32_Process?Handle=4 in the POC example is just to show that the actual command-line arguments will return something meaningful. This does not mean that this method requires the WinRM service to be enabled. There are a number of options that support the 'format' parameter.

A sufficiently robust detection method should not detect 'cscript.exe'' or 'wscript.exe'' from the command line as a basis for judgment. Although this detection method can detect the attacks described above if the attacker does not deliberately circumvent the detection, there is nothing the attacker can do about it if the attacker copies the script.exe and renames it. A more robust detection method should consider detecting the signature of the binary file and its' original file name'.' The attribute 'original file name' is embedded in the binary file and protected by the signature, and if the attacker wants to modify this attribute, the binary file signature will be invalidated.

Mitigation and prevention measures

The bypass method mentioned in this article can be blocked by enabling the User Mode Code Integrity (UMCI) option of Windows Defender Application Control (WDAC). Since there is currently no other effective way to prevent these script files with Windows signatures from running, threatening script files will be disabled by their hashes. However, it can be difficult to get hashes for each version of the script file, given the large number of versions of Windows. This blog explains in detail why it is inefficient to disable files through hashes. As for mitigation measures, Microsoft can modify the contents of the script file and re-sign it. If you do so, this will invalidate the signature of the previous version of the script file. So if we enable signature protection for script execution through WDAC, the execution of those scripts will fail. However, such a scenario can only prevent an attack from a non-administrator account, because an attacker can recover the signature information of the script file by installing a previous version of Microsoft's catalog signature with administrator privileges. The above prevention and mitigation measures depend on the opening of WDAC. Considering that there are a large number of enterprises that do not turn on WDAC, even if winrm.vbs is fixed by Microsoft, there is nothing to prevent the attack from putting old versions of winrm.vbs files on the system and using them. So even if Microsoft fixes the winrm.vbs problem, there is no really robust way to protect against it.

WSH/XSL script detection

This is not the first time WSH/XSL has been abused by an attacker, and it won't be the last. Attackers should need to know whether their payload is executed from a file on disk or entirely in memory. Through ScriptLogging technology, Powershell is fully capable of this. For WSH, however, they do not have similar capabilities. However, as long as you are familiar with ETW, it is entirely possible to capture the contents of WSH using Antimalware Scan Interface (AMSI). AMSI is exposed through Microsoft-Antimalware-Scan-Interface ETW Provider. If you want to try to get ASMI events, KrabsETW is one of the best libraries you can use. However, for experimental purposes only, you can get ETL records through logman.exe. The following example starts and pauses the logging of ETL and logs ASMI-related events to ASMITrace.etl:

Logman start AMSITrace-p Microsoft-Antimalware-Scan-Interface Event1-o AMSITrace.etl-ets

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.