Tracking the 2012 Sasfis campaign

Researchers at Fortinet have been tracking the Sasfis malware campaign since a surge of new samples surfaced in late May 2012. By early August, the Sasfis botnet had already undergone five major changes. In this article we will unveil all the important nuts and bolts of the latest instalment of the Sasfis botnet by analysing its packers, core payloads and botnet operations (including its relationship with the Asprox spambot). We will also discuss its connection with the Dofoil campaign, which was highly active until the rise of the new Sasfis botnet.

From the samples we have collected since May, it is evident that the Asprox spambot is used by Sasfis as its sole spreading mechanism. Carrying on its tradition, Asprox initially used the name of a trusted delivery company as the bait to trick users into opening an executable email attachment with a document icon. In early August, however, it was observed that the spam had been improved by replacing the email content with an image containing the same text. The image (Figure 1) encourages the user to click on it – in doing so downloading another malicious executable with a document icon. After executing the file, the payload deletes the executable and opens a blank text file in Notepad at the current location to divert the user’s attention. These changes provide some benefits to Asprox in that the malware sample is no longer attached to the spam (which previously could easily be blocked by firewalls with up-to-date malware definitions). In addition, storing the malware online makes the botnet operation more dynamic and effective; rapid replacement of the sample makes effective sample collection difficult and hence challenges anti-virus vendors that use checksum-based detection.

Figure 1. New Asprox spam with picture linked to the malicious attachment stored online.

The new Sasfis is packed with a custom packer which releases a DLL PE file into memory. While unpacking the malware, you will notice that the initial part of the custom packer consists of obfuscating instructions, sometimes combined with anti-debug or anti-virtual-environment techniques that aim to make it difficult for humans or emulators to determine the start of the malicious code.

After successfully unpacking the custom packer, we find in the allocated memory a payload DLL wrapped in a DLL loader, which in turn is wrapped in a decoder (illustrated in Figure 2).

Figure 2. The structure of Sasfis samples.

The injection technique that is used in the DLL loader is rather new and had not been seen until the Dofoil campaign last year. (We will discuss the relationship between the 2012 Sasfis campaign and Dofoil later in the article.) It is also worth mentioning that some of the custom packers used by Sasfis were found to be identical to the packers being used for packing the Andromeda botnet client – however, a discussion of Andromeda is outside the scope of this article.

The payload of Sasfis acts as a listening client in the botnet operation. It does not have a predefined task and only listens for commands that are issued by the C&C server. The traffic that would be accepted by the C&C server is described below:

[C&C server URL]/forum/index.php?r=gate&id=XXXXXXX&group=XXXXX&debug=0

And in later versions (appeared on 23 July):

[C&C server URL]/forum/index.php?r=gate&id=XXXXXXX&group=XXXXX&debug=0&ips=XXX 

And when the host has been infected more than once in the later edition (first appeared on 6 August) the following traffic pattern will appear:

[C&C server URL]/forum/index.php?r=gate/getipslist&id=XXXXXXX 

where:

The first two request formats will allow the client to make contact with the C&C server. The third request format is used for getting a new IP list of ‘possible’ C&C servers. In addition, the second and third request formats will be encrypted in the TCP traffic by RC4 with the volume serial number as a key.

http://[IP derived from IP List]:[Port from the IPList]/[RC4 key]index.php?r=gate&id=[Volume serial Number]
&group=[groupID]&debug=0&ips=[local IP] 

For example:

If the randomly chosen server is determined as 62.75.163.172 with port 84 from the IP list, the following line shows what the request looks like before encryption:

http://62.75.163.172:84/ac197b68index.php?r=gate&id=ac197b68&group=n1308rcm&debug=0&ips=192.168.153.130 

After encrypting the later part with the key using RC4, the hex value of the result will be converted to an ASCII string and attached to the request expression as indicated below:

http://62.75.163.172:84/ac197b68988846E47A0F7C6C39E74966287DD0049B32136C54EA07AE3C6FDDC1E58A1CC6DF1D34128
63B821669AF61F182A561F7C7610AA15965570F6A4CF5AE1CA2EA30169A70FD08FE430D 

When a request is sent to a C&C server, a few different kinds of responses may be received by the client – see Figure 3.

Figure 3. When a request is sent to a C&C server, a few kinds of responses may be received by the client.

The traffic captured by Wireshark demonstrates two possible replies from the C&C server (c=run and c=rdl) in response to the same request message. Table 1 summarizes all the responses that can be accepted and interpreted by the client.

For better malicious file management on infected hosts, Sasfis has a set of rules to keep track of the downloaded items. For example, when a malicious executable such as FakeAV is downloaded through use of the c=rdl command, a registry entry will be created related to this downloaded file stored in the file system (Figure 4). The entry will be encrypted with a key either generated by some API function or simply by a hard-coded constant. When the Sasfis client wants to retrieve infomation regarding the downloaded files, it will iterate through the all keys in HKEY_CURRENT_USER/SOFWARE and XOR the first 16 digits of the registry data (e.g. /0x09/0x18/0x28/0x95/0x5F/0x19/0x2F/0x94/0x58) with its own key (e.g. VolumeSerialNumber = ‘AC197b68’ and equalivant to ‘/0x68/0x7b/0x97/0xAC’ in hex). The registry entry will be valid if the result is equal to the ASCII value of the key itself (‘AC197b68’ which is /0x61/0x63/0x31/0x39/0x37/0x62/0x36/0x38 in hex). The rest of the registry data after decryption is shown in Figure 5. Following the ASCII value of the key, the next eight bytes are the key for decrypting the downloaded file stored at %APPDATA% with the filename specified in the last eight bytes of data. The filename ‘svdll’ in Figure 5 is used for identifying the downloaded object, the server command ‘c=red&%1024s’ allows this name to be modified.

Figure 4. Registry of a host infected by Sasfis.

Figure 5. Registry data reveals information after decryption (XOR with DWORD key).

Another encrypted part of the payload is the C&C server address. In the newer versions, when the command ‘getipsList’ is requested, an IP list will be downloaded in the following structure:

Struct IP_LIST_ENTRY
{
     DWORD C&C_IP
     WORD C&C_Port_number
}

Struct IP_LIST
{
NUMBER_OF_ENTRY = list length / 6
IP_LIST_ENTRY[NUMBER_OF_ENTRY]
}

The IP list is encrypted with RC4 and the client will randomly choose one C&C IP for each request. Rather than the entire IP pool being decrypted and revealed in the dynamic memory, only the chosen C&C IP entry is decrypted using RC4. Figure 6 shows the location of the decryption method in the payload, the ‘default’ IP pool and hard-coded decryption key location. Figure 7 summarizes the IP pool decryption method.

Figure 6. Location of the IP pool being decrypted.

Figure 7. IP pool decryption method.

(For a larger version of Figure 7 please click here.)

Once it has registered itself on the C&C server, the Sasfis client will keep polling the server for possible downloads until it is no longer available. The downloaded files include the Asprox spambot (Dammec), a wide variety of password stealers (usually identified as Grabberz), and FakeAV. The Asprox spambot will download a template containing email recipients, the email content, and the attachment or link to download the attachment. FakeAV is downloaded as a pay-per-install element which allows the botnet owner to generate income. The traffic shows that a response will be sent back to another server to give notice that FakeAV has been run.

Figure 8 presents the major changes seen in the Sasfis network since its first discovery. From the timeline, we can see that Sasfis is a growing botnet with increasing functionality and complexity. The groupID is most likely the date when the sample was produced. Through our study of an active Sasfis botnet, we noticed that the uptime of new C&C servers has decreased from an average of one week in May to an average of one to two days in September. This decreasing trend could be explained by the fact that the botnet has already been operating for a few months and it might have reached a point when it has established an optimal number of spambots to keep the botnet growing. In addition, the rapid change of botnet server indicated that the operator has been shifting focus from infecting more computers to preserving the existing infected hosts. By using a pool of malicious IP server addresses to create dynamic traffic, the botnet operator attempts to avoid over exposure of his malicious IPs (which could lead to being blocked by security products). The ‘get IP list’ command, which is triggered by a reinfection condition, reinforces this goal by rapidly exchanging the IP pool.

Figure 8. Timeline of Sasfis development since May 2012.

Perhaps one of the most significant differences between this year’s Sasfis and older versions was its integration with Asprox. Traditionally, the Asprox spambot was hosted on different IPs separated from the Sasfis botnet. However, in the 2012 Sasfis samples (from the beginning of August when the IP list was used to replace the malicious domain list), we observed that the same pool of IP addresses was being used by both Asprox C&C servers (for keep-alive messages) and the Sasfis C&C servers. We indentified identical IPs in the Asprox spam template (Listing 1) and Sasfis samples (Listing 2).

<s>114.202.247.182:84
173.230.131.168:84
188.138.95.133:84
195.210.47.109:80
203.130.129.58:84
209.20.78.241:84
68.173.180.226:84
72.55.174.23:84
74.208.73.243:84
77.81.225.253:84
86.126.42.121:84

95.131.66.34:84
loftgun01.ru
postbox901.ru
sbolt71.ru
slopokan21.ru
teranian111.ru</s>

Listing 1: Asprox template downloaded from http://24.106.225.182:80 at 2012-09-07 06:32:47 with sample 
8cbfaf6f0334b993f0a69b70fcaea6a2.

195.210.47.109:80
72.55.174.23:84
74.208.73.243:84
114.202.247.182:84
209.20.78.241:84
203.130.129.58:84
188.138.95.133:84
77.81.225.253:84
173.230.131.168:84
95.131.66.34:84
79.52.163.227:80

Listing 2: Default C&C IP pool decoded from sample 8cbfaf6f0334b993f0a69b70fcaea6a2.

Comparing the IPs we acquired from the previous sample with the traffic we collected at around the time when this sample was collected (Table 2), it is clear that the pool of IPs we got from Listings 1 and 2 is just a small subset of the IP pools that are used for the C&C and Asprox server pool as very few identical IPs were observed. This has made tracking down the entire botnet very difficult because of how the botnet ‘branches out’ and becomes dynamic. The introduction of the IP pool has added an element of randomness to the botnet’s growth and creates a nightmare for sample replication.

During the process of unpacking Sasfis and its affiliate downloaded item, FakeAV, we discovered that these samples both use the word ‘work’ as one of the names of an important export function which contains the malicious routine. Looking back at the Dofoil samples we collected between last year and the beginning of this year, we also observed that the word ‘work’ was revealed during the process of unpacking, marking the location of the payload. There is also a striking resemblance between the injection techniques used by Sasfis and Dofoil. The injection technique provides a way to release the malicious code to a section and attach it to a suspended legitimate window process. The malicious code will be executed when the process is resumed in the end. Since this technique is not common in other malware, these similarities strongly suggest that Sasfis and Dofoil are the work of the same group of authors. Our suspicions were further confirmed by the traffic record we have collected. The history (Table 3) in our system provides evidence that the Dofoil campaign left the cybercrime scene in early May, and the Sasfis campaign stepped in half a month later with the same server (same IP) under a new hostname.

There is also an interesting observation about these two botnets. Though their request parameters resonate with one another, the two are actually at opposite ends of the botnet category, that is, Dofoil has a predefined ‘task’ that is hard-coded in the client, while Sasfis relies on commands from the C&C server to perform tasks.

We have concluded that there is a strong relationship between Sasfis and Dofoil. Through our comparison, it is apparent that the new Sasfis has many major improvements when compared to its older counterpart. As of today, the Sasfis 2012 campaign remains active because of its strong custom packer and we would probably expect more ‘features’ to become available in the near future.