By: Ron Lifinski and Haim Zigel

A Cynet Research Blog – 

Cyberattacks are continuously evolving in the attempt to stay ahead of security products. The best way to do this is to avoid explicit malware and utilize essentially legitimate tools to achieve malicious objectives. The recent trend of using legitimate Windows binaries – known also as LOLbins – serves as a great example of how using benign code in the initial compromise stage can pose a severe challenge to most security products.

The Cynet research team has recently identified a new attack combining four different techniques to run malicious code and compromise the victim machine:

  • WMI function is used to initiate the very first stage – WMI call that is initiated by the Macro of the Word document.
    • Legitimate and signed file of Microsoft (“cmd.exe”) is copied to a different location with a different name.
  • Footprint deletion – The malicious code will use the “reg” command to erase registry keys in order to delete digital footprints.
  • LOLBin technique is used to evade AV (Anti-Virus) detection.
    • LOLBin (Using “certutil.exe”) is used to decode an encoded malicious code which is inserted into “temp.txt” – The command is written to the encoded disk in order to evade signature checks of known malicious actions.
    • LOLBin (Using “regsrv32.exe”) is used to run the payload in memory from a signed Microsoft binary.

The malicious powershell code “disarms” Microsoft AV checks in order to make itself invisible.

 

Attack Flow Overview:

This is the full attack chain that is executed by WMI:

 

Step 1 – Laying the Infrastructure with Word Macro

In this case, we have a doc file that runs a malicious macro after enabling the content of the macro in Word.

The malicious macro runs a flow of dumping files in the background while the malicious code deletes footprints and establishes persistency.

Here’s a screenshot of the code after de-obfuscation:

The Macro uses a WMI call to initiate copying and modifying of the file “CMD.exe” to a different folder, and then changes the name of the file to “msutil.exe”.

 

Step 2 – Disguise and Evade

After running the Macro, a file named “errors.bat” is created in the temp folder of the current user. It then copies cmd.exe to the temp folder, renames it “msutil.exe” and uses it to run the previously created batch script. This is probably done to throw off detection mechanisms and make analysis more difficult.

The .bat file includes an encoded PowerShell command that is run in the background.

The encoded PowerShell command performs two actions:

 

  1. It deletes footprints by deleting registry keys:
    1. It kills the winword.exe process
    2. It deletes the history of the opened doc file to cover its tracks
    3. It removes the footprint of the infected doc file from the auto backup feature
  2. It performs an anti VM check, the code simply checks if the machine has at least 50GB of disk space. If the machine has less than 50GB, the code will not run.

The batch script then dumps a base64 encoded SCT script to a file named “test.txt” that is later used to run JS code.

The last action in the .bat file is as follows:

It creates a new registry key which includes the username and a random number in the hive of HKCU\Software\Microsoft\Notepad.

Using the new random number, it then uses “Certutil.exe” to decode the “temp.txt” file into the roaming directory with the newly created random ID. It then uses “regsvr32.exe” to execute the SCT file that contains obfuscated JS code.

And finally, after it cleans up, the script ends.

Here is the SCT file that is passed to “regsvr32.exe” for execution:

 

Here is the de-obfuscated JS code inside the XML:

The JS code creates a Wscript Object and uses it to check if it has already established persistency. If not, it uses the “UserInitMprLogonScript” registry key to establish persistency.

 

Step 3: Disable Defense and Establish Malicious Communication Channel

Then JS runs another PowerShell encoded command.

Here is the de-obfuscated PS Command:

 

In this malicious PowerShell script, we see a few things being done in the code:

  1. It creates a WebClient object with a custom user agent and restores proxy settings to default.
  2. It checks if the operating system is Windows 10 and that the process name is “powershell.exe.” If so, it downloads the first script and executes it. (“The Anti-AMSI code”)
  3. It sets a special cookie that is most likely used as a key to get a response from the C&C web server.
  4. It attempts to download data every minute until it succeeds. After that, the first 4 bytes are used as the first part of the key. The rest is decrypted with the special “r” function. This results in a PowerShell script that is executed.

Here is the malicious code that will run if we’re using Windows 10 (“The Anti-AMSI” code):

 

At this stage, we can see that the code imports functions from the kernel32.dll – GetProcAddress, LoadLibrary and Virtual Protect. At the second stage of the code, we can see that it’s a bit hard to read. Let’s make it more readable:

The script overrides the “AmsiScanBuffer” function in memory, which is used by PowerShell to scan each script-block with an AV service. This basically makes the current PowerShell process invisible to services such as Windows Defender.

“AMSI.dll” exists only in Windows 10.  If we’re not using Windows 10, it will simply skip the whole “AMSI” stage.

Unfortunately, the infrastructure is not reachable anymore, therefore we cannot continue to see what is being downloaded and the continuation of the malicious activity.

 

Conclusion

Our analysis stops here, since the attacker’s networking infrastructure is no longer available. As a result, we don’t know what the final payload would have been. However, this attack can serve as an alarming illustration of how attackers continuously evolve their defense evasion techniques.