I came across a sample recently that looked interesting because of the number of steps in the infection chain and the use of PowerShell to inject shell code into an existing legitimate process so I though I would have a go at analysis. For this analysis I will go as far as I can using just static analysis and fall back to dynamic analysis when I hit my limits.
The initial payload is a PDF file which I will take a look at now.
PDF Analysis
PDF hash: 4817f198a8492e267eff9f76767abfbbef2631667d4dc6a334d7499405f9ce6c
PDF Filename: PO_2023.pdf
Checking for suspicious elements with peepdf we see only one suspicious element, "/AcroForm [12]", is listed.
Now using the peepdf interactive mode with "peepdf -i" we can further explore the objects.
Checking the "/Acroform" object we can see the following references now lets inspect them.
Nothing stands out when inspecting the referenced objects.
Now lets inspect some of the object streams staring with the first in the list object 15. Ok interesting we can see object 15 contains a URL for the domain name mega.nz.
After parsing the various object i am pretty satisfied that there is no other malicious content in the PDF. Before we move on though we can also dump all the PDF elements including attachments, images, scripts and streams from the PDF.
Parsing the extracted elements I don't see anything interesting apart form some of the imbedded images.
LNK File Analysis
Ok now lets move on to the mega.nz link in the PDF file. Checking the link it contains a file hosted on mega.nz. The filename indicates this is a lnk file masquerading as a PDF, the lnk file extension would be hidden on most endpoints showing just the filename "Purchase Order.pdf".
md5: 10236eed5a51edf0d1fa70bd27e02a00
filename: Purchase Order.pdf.lnk
Using Eric Zimmerman's LECmd lnk file parser we can quickly parse the lnk file. Checking the output from LECmd we can see the lnk file contains a link to PowerShell with the arguments seen below highlighted.
VBS File Analysis
Filename: skivesvamps.vbs
md5: 7b458417e456edfb8816b9f063dd7f4a
Opening up the file we see a bunch of obfuscated VBS code with 2 main variables being set 'Ra6' and 'Fe8'.
The contents of 'Ra6' is written to a registry key and 'Fe8' is executed with the command "Citrometer.Run 'powershell.exe' &
chrW(34) & Fe8 & chrW(34), 0"
Checking the documentation for the "Wscript.run" function we can see that the '0' is an argument that will "Hides the window and activates another window"and the chrW(34) will be replaced with quotation marks.
Ok rather than run the script lets write it to console by commenting out the "Citrometer.Run" command and adding a write to console with "WScripte.StdOut.Write Fe8"
Ok now we have the second layer.
We can see a similar layout to the previous so lets again comment out the execution line and add a print to console.
Ok we have another obfuscated layer.
After cleaning up the code formatting using JSFormat module for NotePad++ on Remnux we can see at the top what appears to be an de-obfuscating function.
Ok lets use this to find the whole bunch of variable names we can see at the top.
Alright now we can see that line 54 is setting an alias for 'IEX' to the name 'Ensnarled9' so lets findall occurrences of this and replace with 'IEX' so we can see the code that is executed. After that we can comment out the IEX statements with a 'Write-Host' so we can understand what the code does.
After cleaning up the code a bit we can try and understand what is going on, I am no expert at PowerShell so I did a bunch of googling to help understand and may be inaccurate on some of the details but we should still get a good idea of what is happening.
Scanning through the code a few things immediately stand out:
- Function fkp looks like it gets reference to unsafe Windows Native APIs specifically:
- NtProtectVirtualMemory: used for changing memory permissions
- VirtualAlloc: allocate memory probably for injecting some code
- function GDT:
- define modules for assembly (something to do
- line 70 /71: The code from the registry key we saw set earlier is retrieved and converted from base64. This is looks like shellcode to be injected.
- line 75 /76: We see the code being copied to memory and executed.
Looking at some of the functions on google it looks very similar to a Cobalt Strike PowerShell shellcode injection module. There is a good break down of that
here.
Next I dumped the shellcode out to a file. I am not sure why there are 2 separate bits of code written to memory so I dumped them both out to different files using PowerShell:
[System.Text.Encoding]::ASCII.GetString($shell_code, 0, 6785)
[System.Text.Encoding]::ASCII.GetString($shell_code, 6785, 115616)
Next I tried to create a PE file using
shellcodetoexe.bat and then loading the file into a debugger I wasn't really sure if it compiled properly and I had hit the limits of my assembly analysis skills which is very limited. Looking at other GuLoader samples the shellcode is always encoded and contains a bunch of anti-analysis features so I wont be able to get any more out this analysis this way unless I was able to step through and find the point where the code is decoded so now I will have to fallback to running the malicious VBS if I want to continue analysing the sample.
Using my Windows REM machine I started process hacker so I could monitor any new processes and procmon so I could find any registry changes.
After I ran the script I could see a new PowerShell process was spawned and then the process ieinstal.exe. I then used Process Hacker to dump the process memory.
Grepping over the memory dump i can see reference a registry key being set which appears to be the initial persistence mechanism. Also we see a number of references to an IP with the filename DrWSIClDcaj128.psm which looks like an additional payload.
Comments
Post a Comment