- sha1: 34a4c5f28c7df23662962c3eaa0a15b7ae48b488
Description
A malicious Windows malware dropper program written in C++. The executable file is obfuscated with XOR encryption and packed with a custom packer. It is used to deliver Trojan.Siggen28.53599 to compromised PCs.
Trojan unpacking
The trojan is packed using a custom packer that is characterized by the zero physical size of sections bearing “traditional” names such as “.text”, “.rdata” and others.
In this case, one of the following sections (“.(>@”) contains some code. It also contains the entry point.
Once initialized, the source code containing the original entry point is extracted into empty sections.
Operating routine
Initialization
The trojan reads the KUSER_SHARED_DATA struct, which contains system information. The trojan checks the value of this struct’s NtMajorVersion field, which must equal 10.
It then initializes the struct containing the pointers to the ntdll.dll, kernel32.dll, user32.dll, ole32.dll libraries, which are used to call functions from this struct. Then the three threads responsible for anti-debugging are initialized. After that, the struct for working with the wevtapi.dll library is initialized and pointers to the libraries and various functions are obtained.
Use of WinAPI
The trojan uses WinAPI system functions via a wrapper struct that contains a table of functions, library pointers, library load addresses, and an anti-debugging flag.
The table contains the following functions:
- Functions for working with WinAPI, i.e., finding a function pointer and calling it
- Helper functions—ad hoc implementation of the LoadLibrary and GetProcAddress calls
- The configuration of input parameters for a range of functions
When launched, the trojan initializes its main struct. It does this by using a modified CRC32 algorithm to find library load addresses in the PEB_LDR_DATA system struct. The trojan uses two methods to access functions stored in the libraries:
- Ad hoc implementation of the LoadLibrary and GetProcAddress calls
The trojan has two functions that mimic the implementation of LoadLibrary and GetProcAddress. This method is used when the trojan needs access to the API contained in a library that has not yet been loaded into the process memory. - Searching for libraries by their hashes in the PEB_LDR_DATA system struct
The trojan searches for a required library in the PEB_LDR_DATA struct using the InMemoryOrderModuleList list, which contains pointers to all the libraries loaded into the process memory and their names. The library name is matched by comparing the hash value generated using the modified CRC32 algorithm with the requisite library name. Next, the required library function is found in the table of exported library functions, in which case the function names are hashed in the same way. The library name and function are read using the modified CRC32 algorithm.
Debugger evasion
Checking the debug registers
The trojan obtains the context of the parent thread and checks that the values of the Dr0–Dr7 registers are set to 0.
Checking for a debugged environment
In the KUSER_SHARED_DATA struct, the trojan checks the first two bits in the KdDebuggerEnabled field; the value of these bits must be set to 0.
Using the NtQueryInformationProcess function, the trojan checks for the presence of a debugger by reading various parameters of the PROCESSINFOCLASS struct: ProcessDebugFlags, ProcessDebugPort, ProcessDebugObjectHandle, ProcessTlsInformation.
Checking for debugger drivers
The trojan scans the %WINDIR%\System32\drivers directory for files that indicate the presence of debugging software. It then calculates the filename hash using the modified CRC32 algorithm and compares the result to the blacklist hashes.
Each check is timed, and if the check fails, a flag is set in a global variable that is checked at various stages of execution. If the flag check fails, the trojan terminates its process.
Environment check
To protect itself from running in a virtualized environment, the trojan scans a number of OS logs, using the wevtapi.dll library. It searches for the below strings:
- In the logs Microsoft-Windows-Shell-Core/Operational, System, Application:
\npcap.sys Wireshark API_Monitor apimonitor API Monitor rohitab.com hex-rays.com processhacker.sys ProcessHacker PROCMON2 ida64.exe - In the logs Microsoft-Windows-Storage-Storport/Operational, System, Microsoft-Windows-Storsvc/Diagnostic, Microsoft-Windows-StorageSpaces-Driver/Operational, Microsoft-Windows-Partition/Diagnostic, Microsoft-Windows-Kernel-PnP/Configuration, Application:
VMTools VMUpgradeHelper VirtualBox Guest VBoxService.exe VBOX HARDDISK _FLOPPY_ \VMWVM _VBOX& NECVMWar prl_ VMware - Additionally, in the Application log:
VMware Player VMware NAT Service \Device\VBoxNet Oracle VM VirtualBox
After performing these checks, the dropper unpacks Trojan.Siggen28.53599, the payload contained in the resources. This is done using a modified RC4 algorithm; the key for the cipher is 8 bytes long. The dropper then decrypts the payload configuration, which is encrypted using the XOR cipher. The resulting configuration is stored in a string labeled with the characters "DANTEMARKER", which are overwritten.
After all the prep work is done, the dropper projects the payload into the memory and transfers control to it.
