DOSfuscation - Batch malware and a little shellcode

I noticed a rise in .bat malware over the summer, or at least a rise in commandline abuse/obfuscation.  This is likely due to the growing popularity of "DOSfuscation". Examples of this type of obfuscation can be found here: https://github.com/danielbohannon/Invoke-DOSfuscation

These obfuscation techniques are being used everywhere from straight .bat scripts, to macros and PowerShell launchers. Some of the techniques include:

• The use of the batch escape character '^' to muddy the waters
• Custom alphabets being defined, then accessing them using indices to encode payloads
• String reversing
• Lots of garbage code/white space
• and more!

This first sample leverages the alphabet technique. 'kkkkkkkkkk_KKKKKK' is the the variable storing said alphabet.  It is then accessed via indexing e.g. '%%kkkkkkkkkk_KKKKKK:~19' would refer to the character in the 19th position in the alphabet. In Python this would be 'kkkkkkkkkk_KKKKKK[19]', or 'alphabet[index#]. 

Here the alphabet is highlighted so we can see how it is being accessed by the malware. It is basically concatenating a string one character a time. Once fully formed, this string is passed as an argument to whatever action follows the pipe '|'.

This can be deobfuscated a couple ways, the first way is to re-write it in Python.  Here is a little script to decode that concatenated string leveraging the alphabet. I assigned the alphabet to the variable 'a', removed 'kkkkkkkkkk_KKKKKK' from the indices, then stored the indices in a list using the '.split()' function. I then looped through the indices, building the string one character at a time, and ended the script by printing the contents decoded to the console.

Here is some Python to concatenate the first 9 or so lines of the malware. These variables are being concatenated after the pipe in the last line of the code. This will be the action to take on the output of the decoded alphabet string, we can tell it's an action by the context. 'echo %var/param% | action'. This Python code is a simple string concatenation and print.

The output of the Python code shows the malware uses the DOS escape character '^' to break up the string. 

Here is an example of how in this context the '^' is ignored.

Cleaned up, the script decodes to a simple PowerShell downloader. The contents of the referenced text file on the C2 are passed to IEX or Invoke-Expression in memory, never touching disk.

After I decoded this batch malware in Python, I realized that there was a much easier solution. Modifying the batch code to print to the console instead of executing. First, I changed the '@echo' command to 'on', then removed the '|' , and added another 'echo' to print the second decoded string to the console.

I invoked this script with the '/k' switch so that the shell stayed open.  This solution is more of a self-decode approach to deobfuscating the malware.

The next sample is a DOSfuscated macro. oledump.py finds 3 pieces of macrocode.

After extracting the macros, we find pretty heavy obfuscation.

After removing garbage code, we are left with some string concatenation.  The 'vbKey(C|M)' are keyboard constants, which obviously resolve to "cm".

Special characters are used to create noise and break up legitimate code.
Example1: " ^do " + "^s^et " <- decodes to -> "do set" (batch)
Example2: "t/^" + "\-c/^\^-^e^-_" + "^\j/^" + "\^-^b^-^\/o^_" + "^-\^-\/-" + "^w^_^\" + "-e^" + "-_\n_/" <- decodes to -> "new-object" (reversed - PowerShell)

A bulk removal of these characters (without regex) cleans up the code, but removes some of the legitimate instances of the special characters.

Now reversing the payload string we can eyeball some of the special characters we removed and fix the script in notepad++.

Fully decoded, the payload is a simple downloader. Nothing out of the ordinary!

The last sample is literally a bat script that launches a massive PowerShell base64 payload. Does not appear to use DOSfuscation, but does some interesting things.

The decoded base64 payload reveals that the malware is attempting to leverage and abuse the WinAPI.

WinAPI + hardcoded domain + raw hex = shellcode downloader. We can extract this shellcode and load it into scdbg for a quick analysis, and confirm whether or not this is indeed shellcode. Notice the suspicious domain at the end of the hex data ('0.tcp.ngrok[.]io').

scdbg finds that this shellcode will load the wininet.dll library to send an http request, likely to download an additional payload.

The shellcode is loaded/executed via the WinAPI, which is leveraged through the 'add-type' PowerShell cmdlet. This cmdlet allows PowerShell to import a .NET Framework type. In this case, Windows APIs are being abused to load code dynamically and then execute it.

Hope you enjoyed! Thanks for reading!