The Document that Microsoft Eluded AppLocker and AMSI

Pierluigi Paganini March 20, 2019

Experts analyzed an Office document containing a payload that is able to bypass Microsoft AppLocker and Anti-Malware Scan Interface (AMSI),


Few days ago, during intel sources monitoring operation, the Cybaze-Yoroi ZLAB team encountered an interesting Office document containing some peculiarities required a deeper analysis: its payload includes techniques suitable to bypass modern Microsoft security mechanisms such as AppLocker, the application whitelisting security feature in place in well-configured Windows OSes, and the newer Anti-Malware Scan Interface (AMSI), a vendor agnostic security interface enabling anti-virus controls on running scripts, macro code and even memory blocks, designed to tackle obfuscation and file-less threats.

For this reason, the sample has been further dissected and analyzed by Cybaze-Yoroi ZLAB.

Technical analysis

Brief descriptionDoc Document dropper

Table 1. Sample information

The initial document invites the user to enable MACRO execution to display the real content, silently starting the infection chain in background while other decoy components are shown to the victim.

Figure 1. Initial document view
Figure 2. Fake pop-up error

After a few seconds, a pop-up window is shown, reporting an error related to the decryption of the document, and then the Word document is automatically closed. 

At this time, the unaware victim may think there is a problem with the document and nothing malicious happened, but actually the malware already proceeded with its operation in stealthy way. Analyzing the document view with more attention it possible to notice a suspicious chunk of strings in the smallest box in the left of the document:

Figure 3. Zoom on suspicious Word label

The box named “Kplkaaaaaaaz”contains a base64 encoded payload, subsequently extracted by macro execution and assigned to the “dopzekaoooooooo” variable. It will be used to fill the next-stage bat file. This technique, include part of the payload into a Word Label object or cells, allows to hide and embed more code directly into the attack vector, lowering the chances of detection. 

Also, the malware adopts an evasion technique to determine if it is execute in a sandboxed environment. In fact, it checks if the machine’s domain name is equal to the computer name and if this condition holds the previous “Kplkaaaaaaaz” variable is set to “This document contains VBA.”, causing the infection chain to stop. This trick is able to bypass all the major sandboxing services, like and Hybrid Analysis.  

Figure 4. Obfuscated macro code

After a deobfuscation phase, the malware behavior emerges. The next actions to performed are contained into “%temp%\errors.bat” script, which is executed by a copy of “cmd.exe” stored into %appdata% folder, named “msutil.exe”.

Figure 5. Deobfuscated macro function

The screen above shows the instruction used to pop up the fake error window (Figure 2), which is a simple Visual Basic MsgBox. Unlike most malwares, this one uses a different technique to automatically start the macro code at the document opening time. Instead of using the Workbook_Open or Auto_Open functions, it exploits the Word InkEdit object to use the InkEdit1_GotFocus function, which will be launched as soon as the InkEdit1 is displayed.

Figure 6. Function to start macro at open

The “errors.bat” file contains a Base64 encoded powershell script which will close the initial Word document by killing its process and definitively delete it from the file system. The script shows another evasion technique by checking the memory amount available on the system: if it is less than 1 GB the malware terminates its execution and removes all the infection evidences. 

Figure 7. Powershell code embedded into “errors.bat” file

The check against available memory is done through a CIM (Common Information Model) server instance. Strangely, the return value of this cmdlet is assigned to a variable named “diskSizeGB” even if the function returns the amount of the available RAM (a probable error made by the author) and not the disk’s one.

After the evaluation of the previous conditions, the BAT file proceeds to set a new Registry Key, named as the victim’s username, storing a random value in it. 

Figure 8. RegKey set by malware

The random value is necessary to create a new TXT file which will be filled with a base64 payload. Then, the file content is then decoded using the “certutil” Windows utility and finally executed using the instruction:

start /b regsvr32 /u /n /s /i:%appdata%\9711.txt scrobj.dll 

This trick is known as “Squiblydoo”. It allows to bypass Windows AppLocker, the application whitelisting technology introduced with Microsoft’s Windows 7 operating system. AppLocker restricts which programs users can execute via Group Policy. i.e. the enterprise administrator can disable the script execution on every machine belonging to the enterprise domain. So, using this AppLocker Bypass trick it is possible to launch any script, eluding the block.

Fundamental part of the trick bypass is the “scrobj.dll”, belonging to Windows Utility DLLs. It is able to create Component Object Model (COM) components using scripting languages such as Visual Basic Scripting Edition (VBScript) and JScript. So, as expected, “9711.txt” is a scripting file producing a new COM object, which will be registered using the “regsvr32” utility.

Figure 9. Scripting file used in Squiblydoo trick

Obviously, also this code is heavy obfuscated, but using a JScript interpreter it is possible to extract some interesting evidences.

Figure 10. ActiveXObject executed through Squiblydoo

The just created ActiveXObject uses the previously stored random value to set malware persistence into HKCU\\Environment\\UserInitMprLogonScript in order to start its malicious actions at logon time.

Figure 11. Malware persistence

After that, it starts a new obfuscated Powershell script which looks like that:

Figure 12. Final payload including an Empire stager

The malware shows also in this stage an evasion technique to avoid sandboxing analysis waiting for a long time period, over 5 minutes. So, it checks the OS version and retrieves code from “hxxp://riscomponents[.]pw/test[.]txt”: these Powershell instructions are used to bypass the Antimalware Scan Interface (AMSI). 

AMSI is a versatile interface standard that allows applications and services to integrate with any anti-malware product that is present on a machine. It is mainly designed to help two kind of stakeholders: application developers who want to make requests to anti-malware products from their apps and anti-virus vendors who want their products to offer their features directly to applications. Moreover, AMSI is  integrated by default into some Win10 components, such as User Account Control (UAC), PowerShell, Windows Script Host, JavaScript, VBScript and Office VBA and it allows to evaluate code just prior to its execution, after all the obfuscation has been stripped away. 

However, several AMSI bypass methods exist in Internet, many of them require only a few code lines, like the one found during the analysis:

Figure 13. AMSI bypass code used by the malware

This code retrieves the memory address of the AmsiScanBuffer function belonging to “amsi.dll”system library, then rewrites some of its bytes with the buffer {0xB8, 0x57, 0x00, 0x07, 0x80, 0xC3}, permanently disabling the AMSI scan capability. The attacker probably re-used one of the scripts publicly available in Internet, like this , written in C#. As shown in figure, the snippet seems to be almost the same used by the malware:

Figure 14. AMSI bypass snippet available on Github

The rest of code’s goal is to retrieve new commands to execute from its Command&Controls located at hxxps://185.198.57[.]142/admin/login.php. Analyzing the piece of script involved to download new instructions, it seems to be an Empire powershell stager, as shown in some examples reported by SANS in their paper. Unfortunately, the server is down at the analysis time, so it is impossible to carry on the investigation.

Due the malware complexity, a brief scheme of its behavior is shown in the following figure.

Figure 15. Malware infection scheme


Using a combination of multiple evasion techniques, some of them even trivial such as the exploiting of the lazy naming scheme adopted by popular sandboxes, the analyzed threat was able to evade advanced security mechanism in place in modern Windows systems like AppLocker and AMSI: controls designed to support the implementation of high level security requirements, such as application white-listing policies and the mitigation of file-less threats. Showing how a sufficiently motivated attacker could be able to set up a hardly detectable payload able to overcome even these strict security mechanism, providing another evidence of the gap between technology and human attackers.

Technical details, including Indicators of Compromise, are reported in the analysis published by the experts on the Yoroi blog:
[adrotate banner=”9″] [adrotate banner=”12″]

Pierluigi Paganini

(SecurityAffairs – AppLocker, evasion)

[adrotate banner=”5″]

[adrotate banner=”13″]

you might also like

leave a comment