This blog post will walk you through on how to unpack Jscript malware. This sample is packed to make analysis difficult by packing the malware. The sample used in this writeup can be obtained from the open source repository malshare[.]com.
Tools used:
pestudio (static analysis)
ExEinfoPE (static analysis)
Sublime (static analysis)
x32/x64dbg (dissasembler)
Disclaimer
You are dealing with a real malware sample. Run and Analyze it in a controlled environment (sandbox) with no connections to the internal network or internet. I am not responsible for any consequences or damages caused by your actions.
Hash:
MD5 - 77996383ebb12476d1896eeb8dedf70b.
Analysis:
This malware sample uses a custom packer (Dean Edwards packer v1.0) and is classified as a JS.trojan downloader. Malware that uses customized pakers will not return any hits on tools such as DIE (detect it easy) or PEID which only detect known packers such as UPX. The script (JavaScript/VB script) is sent to WScript.exe in the Windows/System32 folder which interprets the script and when the script calls out to a windows API, Wscript calls out to the API itself. Two of the most commom DLL's with API's called and used to downlaoad/retrieve info from host and Execute malicious payloads respectivley are; WS2_32.dll (WSASocketW, GetAddrInfoExW, WSASend, WSAAddressToStringW,WSAStartup) and Shell32.dll(ShellExecuteExW).
We will place breakpoints or hooks in the aforementioned API's and watch the data sent to the API's. If the script uses any other API's other than the common API's mentioned above then we wount capture any data. Open the script in sublime and we see that it's obfuscated
To debug the Jscript executable, since scripts are interpreted by WScript (located in Windows\System32 folder), we will attach the later to a debugger inorder to debug our JScript. Open/attach the Wscript using x32/64dbg then change the command line parameters to the script (File >change commandline) and pass it the path to your malware as below.
Next, Set breakpoints on the 2 dlls (WS2_32.dll and Shell32.dll) as they arent loaded yet and you cant set break points on their API's.Once the DLL is loaded, then we can set a breakpoint on their API's. Right click on breakpoints and chose "add dll breakpoint" to add the 2 breakpoints.
Run the malware (F9), it will hit the entry point breakpoint first then run(F9) the malware again to hit the Shell32.dll breakpoint. When execution stops, we observe that we’re sitting inside Shell32.dll.
Go to Symbols tab and you see Shell32.dll and you should be able to search for ShellExecuteExW API and put a breakpoint (f2) on it. We then remove/disable the breakpoint on Shell32.dll as breaking on it will invoke other API's/other parts of the dll
Run (F9) the malware and when we hit the breakpoint, we should see EIP pointing to it and we will check whats being passed to the ShellExecuteExW API. On the stack window, we should see whats being passed to the API
The MSDN for ShellExecuteEx shows that the arguments passed are structs (check c or c++ programming for what structs are) so we will have to pass this one struct (ShellExecuteInfo). If you click on it on the MSDN page, we see a bunch of command parameters but we are interested in the lpverb and lpfile as lpverb has a "open" action which will be used to execute files and commands and the file will be the command line paramters executed. They are parameters 3 and 4 respectively when you count from 0.
Next, On the stack, follow the struct in the dump window to observe the arguments passed (3 & 4) by right click as below and chose follow DWORD in dump
On the dump window, click on the 3rd address (count from 0) or argument which should be lpverb, right click it and chose "follow Dword in dump 2" to view it's contents and we see it has "open" which means it's indeed using ShellExecute API
Next we go back to dump one window and pick argument 4 (lpFile) and repeat the same process as above and chose "follow Dword in Dump 3" to observe its contents. We see that CMD and powershell is being exectuted.
The dots between the strings (long string) represented by zeros/null bytes between the ascii bytes can be removed to view the command(s) passed for execution by right click on the dump in question> chose text> show as "Extended Ascii" which means wide string which will convert it to unicode. You can then copy it into sublime to pretty it up if you chose to
An automated method to analyze Jscript would be to use frida-wshook.py from github.
Shout out to @cybercdh, MalwareAnalysisForHedgehogs and OA labs
Comments
Post a Comment