So recently I came across a USB based malware spreading like a worm, which is accessing IndexerVolumeGUID file hidden as a system file in the same USB and contains encrypted malware payload.
The infection vector is mainly removable media, whereby the malware, when it infects the USB, it hides the original files and folder on the USB and creates .LNK files with the same name, tricking user to click on these .lnk files. The command in the .lnk files are to execute rundll32.exe from system directory and passed on the relative path of a hidden dll located in a sub directory followed by a comma and the entry function name in the dll. I got hold of multiple samples of the lnk files and the dlls and found that the hash of the dll is different every time and the name of the entry function also seems to be a randomly generated string of characters. The only thing which remains constant is the malicious dll, seeking IndexerVolumeGUID hidden system file, so that it can read the encrypted payload from it, decrypt it, load it into memory and execute it, resulting in CnC communication. This is done so that the load of suspicious libraries, which could point to malicious static indicators, is done at runtime by the encrypted loader. The first stage paylaod, the dll therefore gives low score on suspicion indicators.
One thing I noticed was that the dll filename was again a weird pattern of multiple dashes and underscores --__-___----....., like Gamarue (See my last Gamarue post).
We can see here the randomly generated entry function name of the dll
This is where the rundll32.exe calls the function which is the entry point to dll
The entry point:
We can see the malware using XMM registers to store state and other data possibly for decryption mechanism:
We can see some other function names within the dll, being called.
Again we see a lot of manipulation and assignment involving the XMM registers.
We can see here the mutex, "quvsbhprl" a handle to which is opened to check for any other instance of the same malware running
If not then it will create this mutex to ensure that it is the only copy of itself running:
The malware also creates an environment variable called "obj", with the value of the path to the malicious dll and the indexervolumeguid file:
The malware also looks to load a weird module
This is where it starts reading the IndexerVolumeGUID file
This is where the malware checks for powerstatus of the machine. As described in a FireEye blog the behavior of latent bot is similar, whereby it checks the power for the case of the malware running on a laptop to see if the battery is low. If it is low it executes SetThreadExecutionState to prevent the laptop from sleeping:
The malware then creates the Filemapping of the IndexerVolumeGUID
Maps ViewofFile into its address space
Starts decrypting the payload from the IndexerVolumeGUID using the values in the XMM register
Sets the memory location as execute_readwrite
I also noticed a name of a .bmp file..
This is where the execution flow is transferred to the decrypted paylaod in memory:
The execution of main payload starts here
VT For hash 85b77d0c1133a79e63bc7a92179a1367
VT for MD5 80b15bd6427cfec304bba9a3afea59d5
VT for MD5 8c610fa6b239bd71e7bd7b7cb85f3903
VT for MD5 9aa9764f1a7967319b6b9fb9b9377b2d