When the mastermind hackers of the notorious Carberp Banking Trojan were arrested, we thought the story had ended. But a sample that we received on May 7th, a month after the arrests, looked very suspicious. It connected to a well known URL pattern and it really was the Carberp Trojan. Moreover, the domain it connected to was registered on April 9th!

Taking a closer look into the PE header, it was observed that the TimeDateStamp (02 / 27 / 13 @ 12:19:29pm EST) displayed a bit earlier date than the date of the arrests of the cybercriminals, and the URL was a part of larger botnet where plenty of Russian bots are involved. So the case was closed as a lost sample within a distribution process.

After using our internal Malware Similarity Search to catch as many malware samples as possible, a cluster appeared. It contained some well-known families like Zbot, Dofoil, Gamarue, and some fresh families like Win32/64:Viknok and Win32:Lyposit. The latter is a dynamic link library and it caught our attention by a quite sophisticated loader and a final payload.

Loader Analysis

The starting dropper is a Microsoft Visual Basic executable that unpacks and loads the first hidden layer - another x86 PE executable. This layer decrypts data in newly allocated memory and the next step is performed there. Analysis is made more difficult by resolving WINAPI functions on the fly by a hash and using a multiple cooperating threads. The main decryption is done by repeating calls of RC2 cipher algorithm provided by Microsoft Base Cryptographic Provider v1.0. The next layer is a dynamic linked library and it drops the proper binary of the lockscreen.

Payload

Lockscreen tries to communicate with its servers through Background Intelligent Transfer Service (BITS) . It creates a single BITS Control Class with a background job that downloads files to the client (a parameter BG_JOB_TYPE_DOWNLOAD for the IBackgroundCopyManager:CreateJob method). It was reported that malware in the past used to bypass firewall rules in order to perform additional actions.

URL names are encoded in the data section of a binary file and they appear non-standard on the first sight:

An example of a query to a C&C server:

The string before the equality sign is randomly generated for length between 1 and 5 and the sequence of numbers after the equality contains packed information about the victim's location and computer name. The following picture reveals what's behind the previous request after a decryption ( the first double word is a return of GetTickCount() call, followed by a constant byte 0x18 and an internal code of procedure that calls the request; then we see a magic string "RLA5", a value of local identifier, a hash of the DigitalProductId xored with the value of the InstallDate and finally a hash of Computer Name ).

A reverse algorithm that reveals this buffer works like this:

Communication protocol is encrypted and the following decryption algorithm is used:

Applying decryptBITS algorithm twice on a received buffer an archive with a complete HTML page finally displayed is obtained.

Depending on the location setting of the victim's computer, particular content for a ransom message is chosen on a the server-side. If it is not Switzerland, Italy, Spain, Germany, Russia, Ukraine or possibly other non-US countries, it could look like this:

Observe that the background picture (btw. it is called "US.jpg" in the archive) and the font style of commands output is definitely not a Microsoft Windows command line. Moreover, the highlighted string "MacOs vers" whispers what the platform pretends to be. But we did not get tricked; this is not another threat for Mac OS systems. We can only speculate about the reasons why the malware authors chose this strange masking. One that comes to mind is the fact that Mac OS X has a bigger market share in North America and users are more used to this style. Who knows...

Persistence
The lockscreen secures its execution after every start-up using two methods. The first one is fairly regular and its idea is to silently register malicious library with the correct setting in the registry:

The second method is more unconventional. The malware registers itself as an extension of the command processor. It means that the malware would become a common component after every run of cmd.exe:

Manual Removal of Win32:Lyposit

1. Boot your computer with a live CD

2. Find upper mentioned registry keys that serve for the persistance of the lockscreen.

3. Find and delete the referenced file in those keys.

4. Restart your computer in Normal Mode.

Sources

Finally MD5 of some selected samples with the detections of avast! engine:

Acknowledgment

Sincere gratitude goes to my colleague Jaromír Hořejší for cooperation on this analysis.