So much malicious JavaScript out there. Thought I'd share a few of the deobfuscation techniques I use! The first method is deobfusacting the JS manually. This can be pretty time-consuming, but I do enjoy peeling back each layer. This JS begins with a massive array of hex strings
I changed the name of the array, formatted the hex (removed '\x'), and wrote a few lines of python to loop through the array for decoding.
The decoded array bears another level of obfuscation - simple base64 encoding.
I then piped this out to base64 --decode to peel back the next layer, only to find more obfuscation.
This appears to be a regex replace() obfuscation technique.
The highlighted string appears to be a ShellExecute function.
Removing that odd string cleans up the script a bit. It appears to be a PowerShell downloader.
Spaces and special characters appear to be hex-encoded, we can confirm this theory with a few sed commands.
The special characters were indeed encoded. Instead of writing a script, or continuing to do this manually, we can use a JS emulator such as SpiderMonkey.
SpiderMonkey easily deobfuscated the JS. Notepad++ will give us a better look. This JS will download and spawn an executable via a ActiveXObject/WScript Shell through PowerShell.
Another interesting method I have found, (thanks to OALabs!) is debugging WScript.exe with x64dbg.
We can isolate the text in the dump window for a better look.
I changed the name of the array, formatted the hex (removed '\x'), and wrote a few lines of python to loop through the array for decoding.
The decoded array bears another level of obfuscation - simple base64 encoding.
I then piped this out to base64 --decode to peel back the next layer, only to find more obfuscation.
This appears to be a regex replace() obfuscation technique.
The highlighted string appears to be a ShellExecute function.
Removing that odd string cleans up the script a bit. It appears to be a PowerShell downloader.
Spaces and special characters appear to be hex-encoded, we can confirm this theory with a few sed commands.
The special characters were indeed encoded. Instead of writing a script, or continuing to do this manually, we can use a JS emulator such as SpiderMonkey.
SpiderMonkey easily deobfuscated the JS. Notepad++ will give us a better look. This JS will download and spawn an executable via a ActiveXObject/WScript Shell through PowerShell.
Another interesting method I have found, (thanks to OALabs!) is debugging WScript.exe with x64dbg.
- Load WScript.exe into x64dbg
- Change command line argument (point to JS file...."C:\Windows\SysWOW64\wscript.exe" C:\Users\REM\Desktop\mal.js)
- Set a breakpoint on the entry of Shell32.dll
- Set a breakpoint on ShellExecute
- Run until ShellExecute!
ShellExecuteEx takes one argument, the SHELLEXECUTEINFOA struct. There are three members that are particularly interesting to us in this struct - verb, file, and parameters.
Here is the struct in memory. A pointer to this struct is what is passed to the ShellExecuteEx function.
The verb parameter specifies the action, the "open" verb this malware employs is self-explanatory.
If you highlight the 4th DWORD in the struct, right click, and select follow DWORD in Dump, you can see the action. "Open" is the action taken on the file specified in the 5th DWORD.
Next, the "file" parameter....this malware spawns cmd.exe.
And finally, the "parameters" passed to the "file". This member is optional, I have also seen command strings such as this one included in the previous member ("file").
We can isolate the text in the dump window for a better look.
Downside to this method is that it is reliant on certain API calls/dependencies. You would also have to manipulate the malware to show all of its code, whereas taking the malware apart statically we were able to see its true inner workings. All IOCs were right in front of our face.
Hope this helps and hope you enjoyed!
Comments
Post a Comment