We can see the plain code by hitting space, and see the encrypted code segment
The file does some decryption of the actual program and runs it in memory
Static Analysis
Set a breakpoint on jmp ebx and run the program (F9)
Step into the call (F8) until you reach call eax
What this usually means is that the unpacker has finished unpacking, and now its calling the unpacked program
In this case, eax points to VirtualProtect, which means that itās changing the protection on a region of memory to inject their code for execution
Looking at the stack, the first argument in the start of the memory region (40000), the second argument is the size of the memory region (22000) and the last argument is the memory protect option (40) or RWX permissions
Open the program in x32dbg and press Run to user code to get to the main entry point of the application
In IDA, the address of jmp ebx was ending with 411A34. This address would be the same in x32dbg
Set a breakpoint there and execute the program
On the console, run bp WaitForSingleObject to set a breakpoint on that function
Run the code to hit the BP, then click Run to user code
We are now in the unpacked code of Panda!
Analysis of unpacked code
Checks for Installed Programs
It calls CreateFileW to see if the files of programs are present on the machine. This is an anti-debugger technique, as normal machines wonāt have WireShark or ProcessHacker installed
It also called CreateToolhelp32Snapshot to get a list of running processes, and checks if certain programs are running. Also an anti-debugger technique
Copying itself to another location
The binary then creates a new file, and copies itās entire contents to that file located at ~/AppData/Roaming/JetBrains/dotPeek/v183/
It copies itself to Internet Explorer.exe which is 145KB
Calls CreateProcessInternalw on Internet Explorer.exe to execute the program
Debugging the copied program
When we attach the debugger to Internet Explorer.exe, the control flow is different. This means that the binary was checking if we executed the file in the correct location.
Now the application creates svchost.exe, and it will start to inject code into it
It calls WriteProcessMemory to write code into the newly created svchost.exe
The initial memory space for svchost.exe is completely empty
After WriteProcessMemory is called, the contents are written to svchost.exe
PandaBanker creates 2 svchost.exe.
Fixing the import address with PE-Bear
Analyzing the copied program in svchost.exe
Obfuscated way of calling LoadLibrary -> GetProcAddress to get find library address, and then calls LoadLibrary to loads libraries into the executable
We see 0EDB88320 being called, which in cryptography, there is usually some fixed crypto constants for cryptographic functions. If we google for 0x0EDB88320, we see that CRC32 turns up. This means that this whole code block probably pertains to calculating a CRC32 value
Ā
Some how you need to know that this code block is RC4
Calls RC4 decryption with key of 0x0FECC3257 (change the endianess), and we see it decrypting a string C:/, and it calls GetVolumeInformationW on C:/
More crypto constants, this time related to SHA256
After we allowing the program to decrypt the strings, we can observe them in the application. For example we can start seeing strings like InstallDate, Windows_NT_Current_Version, and DigitalProductID
Checking if itās running in a 64 bit environment
Creates an exe file with the filename jumbled up using Mersenne Twister
Executes the executable that was created
Loading the encrypted config contents for decryption. The encrypted config is 0x560 long
Contents of the encrypted config. The first 32 bytes are the SHA2 check sum of the remainder of the body
After finding the Key and the IV used for AES encryption, we are able to decrypt the body to get the config data