If we open the file up in IDA or any debugger, it’s going to look really weird, which hints at it being packed.
We can unpack the file by opening it with x32dbg, and setting breakpoints on VirtualAlloc and VirtualProtect
Once we hit the breakpoint of VirtualAlloc, we want to follow the dump of the allocated memory region, and allow the process to continue running. Soon the unpacked file will be written to memory.
We dump out the unpacked file and perform analysis on it instead. We can do this by right clicking on the memory region → Follow in Memory Map, and clicking Dump Memory to File
Dumped file Analysis. Anti-Debug + Process Injection
We open up the newly dumped file and when stepping through the program, we notice 2 anti-debug mechanism in place.
The first of which is calling IsDebuggerPresent , and the second technique calls CreateToolehelp32Snapshot to get a list of running programs on the machine, and calling Process32FirstW and Process32Next to iterate through all the programs. What it’s doing is likely checking for known analysis programs being open like IDA, X32dbg or Wireshark
We can set breakpoints on the test eax eax which checks if the anti-debug is present, and change the value of eax to 0 or simply modify the binary to bypass the checks
A XOR deobfuscation then takes place, which creates the string C:\Windows\System32\svchost.exe . Subsequently CreateProcessA is called to create svchost.exe, and we can see this happening in ProcessHacker
Further down, the binary calls WriteProcessMemory, which when we look at the syntax, the 3rd parameter to the function specifies the buffer to read from.
32 bit programs have their parameters written to the stack (64 bit programs use a mix of registers and stack), and on the 3rd item in the stack we see the address 0x008E0000, which is the memory address of the contents to be written.
When we follow in dump to view what will be written to svchost.exe, we see a binary, indicating that a process injection is taking place
However, when we dump the program out and try to execute it, we get an error.
Even after we use PE-bear to align the Raw Addresses and Virtual Address, executing the program results in an access violation.
We can therefore speculate that the real entry function of the program is somewhere else.
This is confirmed by stepping through the binary, and seeing that it calls CreateRemoteThread which the 4th parameter being 0x02AD1DC0
If we look at the syntax of CreateRemoteThread, the 4th parameter specifies the starting address of the thread. This means that the entry function of the injected process lies at 0x02AD1DC0
Debugging the Injected Process
Since we know that the starting address of the injected process is 0x02AD1DC0, we can open up another instance of x32dbg and attach it to the process that was created by the main binary
Then we hit ctrl-G to enter 0x02AD1DC0 as the address, and set a breakpoint on it
Now in the main binary, when we execute CreateRemoteThread, it will hit the breakpoint of the injected process which we can now debug
Injected Process Analysis - Downloading the Image
The first few actions by this process is to resolve handles to a few functions, namely InternetOpenA, InternetOpenUrlA, InternetReadFile and InternetCloseHandle
Down the program, deobfuscation takes place to generate the string https://pastebin.com/raw/mLem9DGk
The program then calls InternetReadFile on the URL, and fetches the contents from pastebin which turn out to be another URL, https://i.ibb.co/KsfqHym/PNG-02-Copy.png
The program calls InternetReadFile again on this URL, which downloads a PNG file
👨🏼💻
I faced an error where calling InternetOpenUrlA kept failing. I managed to dig out the solution, which is to enable TLS1.2 in Internet Options
The program then deobfuscates another string, which is likely the name of the output it will write to, which is output.jpg
It then resolves a few more functions getTempPathW, CreateDirectoryW, CreateFileW and WriteFile, which are then used for creating a folder in the temp directory, and creating the image there
Injected Process Analysis - Process Hollowing
The program does another deobfuscation to create the string redaolurc
It scans through the contents of the downloaded image, and tries to find the instance of the string redaolurc within the jpg file
After it has located the string in the file, it starts another deobfuscation routine which eventually creates another executable. What’s likely happen is that the contents after the string redaolurc contains the obfuscated (encrypted?) contents of the new process to spawn.
At the same time, another svchost.exe is spawned. Another process injection is likely going to take place!
A series of functions are called, which are GetThreadContext, ReadProcessMemory and VirtualAllocEx which returns 0x006F0000
If we use ProcessHacker to open up the newly spawned svchost.exe , we see a newly created memory region within it at 0x06F0000 which is currently empty
SetThreadContext is then called, followed by a series of deobfuscation and WriteProcessMemory calls (specifically 5 times)
At the end of the loop, we look at the same memory region at 0x06F0000 and see the new process being written to the allocated memory space of svchost.exe
When it finally calls ResumeThread, it executes the program, which gives us a pop up. And we’re done!
Summary
Unpacking the file to get the main binary
main binary spawns svchost.exe and performs PE injection (proc2)
proc2 downloads and image from the internet, spawns another svchost.exe
proc2 deobfuscates the program which was embedded in the image, and performs process hollowing (proc3)
proc3 is the final payload that gives us the alert box