{
	"id": "c847e2e0-7ffd-4a35-bb26-31994599b1fa",
	"created_at": "2026-04-06T00:09:35.826567Z",
	"updated_at": "2026-04-10T03:22:07.006324Z",
	"deleted_at": null,
	"sha1_hash": "214fecfef43bcfa5e6a41622c5896dc3bca14cc1",
	"title": "Smokeloader is still alive and kickin’ – A new way to encrypt CC server URLs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 46950,
	"plain_text": "Smokeloader is still alive and kickin’ – A new way to encrypt CC\r\nserver URLs\r\nBy Deutsche Telekom AG\r\nPublished: 2020-12-17 · Archived: 2026-04-05 14:32:20 UTC\r\nThe malware downloader Smokeloader is one of the oldest malware families that is still in use today. A malware\r\ndownloader is a typically small program that fingerprints a target system, downloads one or more additional\r\nmalicious programs and executes them. Malware downloader forms part of the cybercrime ecosystem: there are\r\ncybercriminals that offer to distribute malware for other cybercriminals. They sell a number of installations for a\r\ncouple of dollars, depending on several factors such as the geographic position of the target and its operating\r\nsystem.\r\nSmokeloader emerged from the Russian cybercrime underground in 2011 but is still alive.\r\n© Copyright: Free-Photos on Pixabay\r\nSmokeloader emerged from the Russian cybercrime underground in 2011. Its developer “SmokeLdr” is known to\r\nbe customer friendly and they quickly act on customer complaints. Smokeloader is a crime kit that comes with a\r\nprebuilt bot, a PHP-based command and control panel, and a user manual. In addition, cybercriminals can\r\npurchase more domains for the bot (the default is just one domain) or additional modules that enhance the\r\ncapabilities of the main bot (e.g. DDoS attacks).\r\nThroughout the years, Smokeloader gained more and more anti-analysis measures to hinder its profound analysis.\r\nA recent detailed analysis described a wide variety of obfuscation techniques including opaque predicates,\r\nchecking for running analysis programs, and anti-hooking measures. One anti-analysis trick is indeed very\r\neffective to hinder a full dynamic analysis. Smokeloader resembles a Matryoshka doll: it comprises three layers of\r\nobfuscation with the third being the final layer carrying out malicious activities. Before the second layer hands\r\nover control to the third layer, it checks if the filename of the executed Smokeloader binary contains a certain\r\nstring. If this string is not found, then the third and final layer will not be unpacked. Since the filename of a\r\nsample is often either randomized or its hash itself, this is a severe problem for sandboxes in order to come to a\r\ncorrect verdict.\r\nWithin the last ten years, the cybercrime underground has changed significantly. There are many new contenders\r\nsuch as Buer or Zloader, and Smokeloader has to stand its ground in order to maintain its market share. This may\r\nexplain the above mentioned anti-analysis measures. But nevertheless the developer “SmokeLdr” has to continue\r\ndeveloping their project and improving it. \r\nIn this blog post, I will have a look at a recent change in the way how Smokeloader stores and decrypts its\r\nCommand and Control (CC) server URLs. Until recently this malware used the XOR cipher in a broken way and\r\nas a consequence its CC server URLs were trivial to bruteforce. Samples observed in November and December\r\n2020 implement a fix for this problem. In the following, I will show way the old implementation was flawed and\r\nhow “SmokeLdr” fixed it in recent samples.\r\nhttps://www.telekom.com/en/blog/group/article/a-new-way-to-encrypt-cc-server-urls-614886\r\nPage 1 of 4\n\nRecap: Broken XOR Encryption of CC URLs\r\nSmokeloader implemented a very weak way of encrypting the CC server URLs. N1ght-W0lf described this in\r\ndetail. An example of this algorithm can be found in sample 91879bdd73625ac38c31fe5225310e92.\r\nIn a nutshell, the bot relies on a XOR cipher. It comprises one or more encrypted buffers with encrypted CC server\r\nURLs. Each buffer’s first byte is the length of the encrypted URL, followed by the encrypted URL itself, and a\r\nfour byte XOR key. An encryption function takes each encrypted byte of the buffer, XORs consecutively each\r\nbyte of the XOR key with the encrypted byte. Finally, it applies another XOR operation with a hard-coded one\r\nbyte XOR key. Since XOR operations are associative, we can use this to our advantage.\r\nLet’s assume we have the following encrypted buffer. The size of the buffer is 0x1C (highlighted in red). This is\r\nfollowed by 0x1C encrypted bytes (highlighted in light green). Next, there is the XOR key 0x1AD4EC24\r\n(highlighted in dark green). Finally, there is a buffer of zeros that are actually not in the binary but only for\r\nillustration purposes. We will see later why they are quite helpful.\r\nFigure1 Encrypted URL buffer of Smokeloader\r\nLet’s see how the first letter of the URL is decrypted. Remember that first Smokeloader consecutively XORs the\r\nfirst byte 0x8A with each byte of the XOR key (0x1AD4EC24) and then it XORs this intermediate result again\r\nwith the hard-coded XOR key 0xE4. The following equations demonstrate this. I use the fact that XOR operations\r\nare associative, i.e. the order of the applications does not matter:\r\nThe following equations demonstrate this.\r\nAs you can see, in the end 0x8A gets decrypted to 0x68, the ASCII code of “h”. We can see as well that due to the\r\nproperties of the XOR operation and the consecutive application of five bytes (four bytes XOR key + one hard-coded XOR key), the effective XOR key deflates to a just a one byte long XOR key (0xE2).\r\nIn practice, it was easy to bruteforce the deflated XOR key: XORing the whole unpacked binary with bytes in the\r\nrange from 0x01 to 0xFF and looking for zero-terminated strings that begin with http was enough to find the CC\r\nserver URLs. The following figure illustrates this. We can see the CC server URL (highlighted in light green).\r\nNote that the buffer of zeros now mirrors the deflated XOR key 0xE2 since each value XORed by zero will result\r\nin the original value.\r\nFigure 2 Bruteforced Smokeloader CC server URL. Note that the buffer of zeros is now filled with\r\nthe deflated XOR key 0xE2.\r\nLong story short: never use the XOR cipher as Smokeloader did in the past if you are serious about obfuscating\r\n(or “encrypting”) something. Consecutively applying several one byte XOR keys does not increase security. The\r\nfinal key will still be one byte and easy to bruteforce with just 256 possible keys to choose from.\r\nImproved Obfuscation of Command and Control Server URLs\r\nI’ve already mentioned Smokeloader’s continuous development in the introduction. Recently, I came across a\r\nSmokeloader variant (6e5017e2d0407e74578d1121233da979) that had an improved algorithm for obfuscating the\r\nhttps://www.telekom.com/en/blog/group/article/a-new-way-to-encrypt-cc-server-urls-614886\r\nPage 2 of 4\n\nCC server URLs. This improved algorithm mitigated the easy bruteforce decryption of Smokeloader CC server\r\nURLs. \r\nThe following figure shows an encrypted URL buffer as found in a recent Smokeloader variant. Again, the first\r\nbyte is the length of the total buffer. But now the buffer is split in two parts. The first part is highlighted in purple\r\nand the second part is highlighted in light green. Finally, again, there is the four byte XOR key.\r\nFigure 3Encrypted URL buffer of Smokeloader's recent variant\r\nSo how does Smokeloader compute the final decrypted URL? Have a look at the decompiled code of the CC\r\nserver URL decryption function in the following figure.\r\nFirst of it all, at its heart is still the old XOR cipher. But now it takes two buffers into account. The algorithm starts\r\nat the beginning of the first part of the buffer (purple). It fetches the byte at this offset and checks if it is zero (lines\r\n27 – 29). If it is zero it sets the variable “is_second_part_buffer” to one and fetches a byte from the second part of\r\nthe buffer (light green) (lines 31 – 32). If the byte of the first part of the buffer is not equal zero, the variable\r\n“is_second_part_buffer” will remain zero. Consequently, it XORs the fetched byte with the four byte XOR key\r\n(dark green) (lines 34 – 42). Finally, and this depends on the origin of the byte, one of two hard-coded one byte\r\nxor keys is applied (lines 43 – 47). In the example, bytes from the first part of the buffer are XORed with 0x66\r\nand bytes from the second part of the buffer are XORed with 0xC9. If you compare the first part (purple) and the\r\nsecond part of the buffer (light green), then you will note that every time where a byte at an offset x is zero in the\r\nfirst part, it is not zero in the second part, and vice versa.\r\nFigure 4 Decompiled CC server URL decryption function of Smokeloader\r\nIf you write code for configuration extraction, then you have to go the long way now since bruteforcing will not\r\nwork anymore. This means that you have to first identify the function that decrypts the CC server URLs and\r\nextract the two one byte XOR keys. Next, you have to identify the encrypted URL buffer. First, you should extract\r\nthe four byte XOR key. Then, you can join part 1 and part 2 of the encrypted buffer, while XORing with the\r\ncorrect one byte key. Finally, you can XOR the joined buffer with the extracted four byte XOR key, and voilà: we\r\nhave our decrypted URL!\r\nNext year Smokeloader will turn ten years old, let’s see how this cybercrime veteran will celebrate its\r\nanniversary…\r\nAppendix: IoCs\r\nIoC Description\r\n91879bdd73625ac38c31fe5225310e92 Smokeloader\r\nhttps://www.telekom.com/en/blog/group/article/a-new-way-to-encrypt-cc-server-urls-614886\r\nPage 3 of 4\n\n6e5017e2d0407e74578d1121233da979 Smokeloader\r\nhxxp://penodux[.]com/xsmkld/index.php Smokeloader CC URL\r\nhxxp://tommusikirtyur[.]com/xsmkld/index.php Smokeloader CC URL\r\nhxxp://2831ujedkdajsdj[.]info/ Smokeloader CC URL\r\nhxxp://dkajsdjiqwdwnfj[.]info/ Smokeloader CC URL\r\nhxxp://928eijdksasnfss[.]info/ Smokeloader CC URL\r\nSource: https://www.telekom.com/en/blog/group/article/a-new-way-to-encrypt-cc-server-urls-614886\r\nhttps://www.telekom.com/en/blog/group/article/a-new-way-to-encrypt-cc-server-urls-614886\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.telekom.com/en/blog/group/article/a-new-way-to-encrypt-cc-server-urls-614886"
	],
	"report_names": [
		"a-new-way-to-encrypt-cc-server-urls-614886"
	],
	"threat_actors": [],
	"ts_created_at": 1775434175,
	"ts_updated_at": 1775791327,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/214fecfef43bcfa5e6a41622c5896dc3bca14cc1.pdf",
		"text": "https://archive.orkl.eu/214fecfef43bcfa5e6a41622c5896dc3bca14cc1.txt",
		"img": "https://archive.orkl.eu/214fecfef43bcfa5e6a41622c5896dc3bca14cc1.jpg"
	}
}