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

This article is about how to use Winrm.vbs to bypass the application whitelist to execute arbitrary unsigned code. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Solemn statement: this article is limited to technical discussion and is strictly forbidden to be used for other purposes.

Bypass technique

Winrm.vbs (a Windows signed script in System31) is able to execute an attacker-controlled XSL, which is not restricted by the relevant script host, and implements arbitrary unsigned code execution.

When you provide "- format:pretty" or "- format:text" to winrm.vbs, it will export WsmPty.xsl or WsmTxt.xsl accordingly from the directory where cscript.exe is located. This means that if attackers can copy cscript.exe to a location he can control and store malicious XSL, they can execute arbitrary unsigned code. In fact, this problem is exactly the same as Casey Smith's wmic.exe technology.

PoC

The attack operation mechanism is as follows:

1. Store the WsmPty.xsl or WsmTxt.xsl in a place controlled by the attacker

2. Copy cscript.exe to the same location

3. Use "- format" to specify "pretty" or "text" to execute winrm.vbs, depending on whether you are using WsmPty.xsl or WsmTxt.xsl.

The following is a sample of malicious XLS, which we need to place in a directory controlled by the attacker, where C:\ BypassDir\ WsmPty.xsl is selected:

In fact, we can also embed malicious DotNetToJScript Payload in WsmPty.xsl and execute arbitrary unsigned code. Next, you can use the following batch file to execute Payload:

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 detect and bypass policy

In the process of implementing this technology, what must be used is WsmPty.xsl or WsmTxt.xsl that can be controlled by the attacker.

Winrm.vbs hardcodes WsmPty.xsl or WsmTxt.xsl and explicitly binds them to the "pretty" and "text" parameters. From this point of view, there seems to be no way to control winrm.vbs to execute different xls files in the current directory. From a detection perspective, the hashes of WsmPty.xsl or WsmTxt.xsl files are different from the original file hashes in System 32, so they are treated as suspicious files because the hashes of legitimate xls files rarely change.

In addition, legal WsmPty.xsl or WsmTxt.xsl files should be directory signed, and they will not be signed when the hash value changes. That is, any unsigned WsmPty.xsl or WsmTxt.xsl file on disk should be suspicious. It is important to note that directory signature verification requires the "cryptsvc" service to run.

The scenario of detecting the existence of winrm.vbs based on the command line is relatively weak because attackers can rename winrm.vbs to the file of their choice.

In order to use the xls file, you must specify "pretty" or "text" in the "format" parameter. Here are the supported "format" parameters (case-insensitive):

-format:pretty-format: "pretty" / format:pretty/format: "pretty"-format:text-format: "text" / format:text/format: "text"

Although building a detection scheme based on the existence of "format" can capture all the changes, this detection scheme is problematic. The legitimate use of the "format" parameter will depend on the scheme adopted by the organization. However, it is unlikely to be legally invoked from anywhere other than cscript.exe and winrm.vbs in System32.

The following is an updated version of. Bat PoC, which bypasses cscript.exe detection:

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:prettyWSH/XSLScript script

There is no doubt that attackers will continue to use XSL and WSH to attack. Ideally, an attacker can know whether the Payload is executed from the hard disk or entirely in memory. Although Powershell has this ability to use scriptblock logs, there is no tool for WSH. With the introduction of the Anti-malware scanning Interface (AMSI), we will be able to capture WSH content.

Here we can use logman.exe to track ETL events. For example, the following command will be able to control the tracking operation of ETW and save the event information related to AMSI in the early AMSITrace.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.