Reverse engineering Gootkit
After successfully unpacking we should be standing at the original entry point at address 4040C7:
Next what we spot is an Aplib decompression routine. Note the magic header check of the DWORD ‘AP32’ in little-endian order:
Placing a breakpoint at this address and dumping the content of the decompressed buffer, we find another tiny embedded executable which later on will be injected into explorer.exe. This binary indeed contains suspicious strings regarding to VM detection:
Interesting fact about this, that it can be controlled by an environment variable. The malware authors must have reserved this feature for themselves for testing purposes but we can benefit from it too:
What we see here is checking the presence of the environment variable “crackme”, then a checksum of its value is calculated and if it matches a certain value it would skip VM detection. The checksum is a variant of the well known CRC32 algorithm. It did not take long to crack it, ‘aHzkxc’ is a value that Gootkit gladly accepts.
The malware uses hardcoded User-Agent which is checked by the C&C server. The URLs where further payloads are downloaded from:
- hxxps://lovemeating.space:80/rbody320 (its purpose is not yet known)
- hxxps://lovemeating.space:80/rpersist2/56080258 (may be persistence module)
- hxxps://lovemeating.space:80/rbody32 (core)
It uses HTTPS connection over port 80 to communicate. These payloads are decompressed with the API RtlDecompressBuffer.
These records contain offset and size information about each individual script file. You can find the complete list of the embedded script files below in the table. Their names give us a pretty good guess about what each one does:
As a courtesy, you can download these files from GitHub.
Okay, straight to the point. Where are the webinjects stored?
In ‘client_proto_spyware.js’ we can find reference to a registry key: