While I was reviewing last month Wildlist samples, I found out W32/Lethic was still alive. Although being one of World's topmost spambot, it seems to stick with the "KISS" principle (aka: Keep It Simple, Stupid). Comparing to contemporary malware, Lethic looks small, and low-profile. Almost feeble... Which may be the secret of its longevity.
It's so simple that displaying its data structures suffices to reveal its structure, and to partly understand how it operates:
Figure 1, Coding Structures
Lethic operates in two distinct steps: first injection, then spamming.
The target is the explorer.exe process; the malware piece relies on pre_hdr (see figure 1 above) to know how many bytes will be injected, and where; the address relocation of the injected code is also featured in pre_hdr. Before the injection part of the malware calls CreateRemoteThread on the injected code, it also injects cc_hdr into target, which is the main structure used to operate the spamming step of Lethic.
The operation flow looks something like this:** **
Figure 2, Spamming Flow
After connecting to the C&C via a simple TCP socket, the Zombie receives commands and data from the C&C as seen in the buffer below:
Figure 3, Commands and Data
Let's list and explain what the different commands sent by the C&C can be, and what they do:
Add Server (0x01): the data includes a public mail server IP address and a port. Lethic then creates a socket and connects to the said mail server. Upon success, it initializes a new MailServerRecord with ID, the given IP and port, socket, and then inserts the record in cc_hdr->Chain. Now that the record has been added to the chain, should any of the following operations on the record fail, Lethic will inform the C&C server; and the latter will then send a "Remove Server" command to remove the faulty record.
Remove Server (0x02): removes record corresponding to ID from the mail server record chain.
Send Mail (0x03): sends the buffer data to a mail server, via the MailServerRecord pointed to by ID. The result is sent back to the C&C server, which in turns decides whether it should set the RecvFeedBack flag or not.
Clean (0x04, 0x05): do some cleaning work, such as freeing the whole MailServerRecords chain, deleting the malware installer, and exit.
Reserved (0x06), no further operation except for sending the received data back.
Add Server By Name (0x11), the same as Add Server, the only difference is that a hostname is given instead of an IP address.
Receive FeedBack (0x13), a flag which is used to set MailServerRecord.bfbFlag.
If the received buffer doesn't include any of the aforementioned commands, Lethic checks each record of the chain. If the bfbFlag is set to TRUE, that means the Send Mail operation was successful, and feedback was received from the mail server. It thus initializes FEEDBACK with the record ID, command, feedback data and size, and sends it all to the C&C server.
In all aspects, the Zombie acts as a slightly improved mail relay; it forwards received data from the C&C server to mail servers chosen in a managed list. That is not very efficient, in terms of bandwidth consumption, as compared to the traditional template-based approach: Indeed here the C&C server has to send almost as much data as is sent by each Zombie. Logically, it seems to indicate that Lethic botnets all need to be small to operate smoothly.
Figure 4 shows an example of the spam content.
Figure 4, Spam Content
But we must recognize that as basic as it may be, Lethic has been around for years. Actually, it seems that taking down Lethic botnets is like playing the whack-a-mole game. This is because Lethic's C&C server changes upon each variant (it is harcoded in the malware piece), which makes it hard to gather all the numerous C&C servers. Lethic authors clearly made the choice of fragmenting their infrastructure in many small, low-profile, very simple Botnets. A choice that, apparently, has paid off.