{
	"id": "1cc7aef3-9dad-4bb6-8506-38b5fb357f82",
	"created_at": "2026-04-06T00:16:04.862003Z",
	"updated_at": "2026-04-10T03:21:26.740499Z",
	"deleted_at": null,
	"sha1_hash": "5be8afd49a185b0b43dfe5c99506101f94e2131b",
	"title": "XLoader aka FormBook Encryption Analysis, Malware Decryption",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 381719,
	"plain_text": "XLoader aka FormBook Encryption Analysis, Malware Decryption\r\nBy ANY.RUN\r\nPublished: 2023-02-28 · Archived: 2026-04-05 19:05:16 UTC\r\nToday ANY.RUN’s malware analysts are happy to discuss the encryption algorithms of XLoader, also known as\r\nFormBook. And together we’ll decrypt the stealer’s strings and C2 servers. \r\nXloader is a stealer, the successor of FormBook. However, apart from the basic functionality, the unusual\r\napproaches to encryption and obfuscation of internal structures, code, and strings used in XLoader are also of\r\ninterest. Let’s take a detailed look at the encryption of strings, functions, and C2 decoys. \r\nFirst, we should research 3 main cryptographic algorithms used in XLoader. These are the modified algorithms:\r\nRC4, SHA1, and Xloader’s own algorithm based on a virtual machine. \r\nThe modified RC4 algorithm \r\nThe modified RC4 algorithm is a usual RC4 with additional layers of sequential subtraction before and after the\r\nRC4 call. In the code one layer of subtractions looks like this:\r\n # transform 1\r\n   for i in range(len(encbuf) - 1, 0, -1):\r\n     encbuf[i-1] -= encbuf[i]\r\n   # transform 2\r\n   for i in range(0, len(encbuf) -1):\r\n     encbuf[i] -= encbuf[i+1]\r\nThe ciphertext bytes are subtracted from each other in sequence from right to left. And then they go from left to\r\nright. In the XLoader code, it looks like this:\r\nhttps://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/\r\nPage 1 of 11\n\nFunction performing RC4 encryption\r\nThe modified SHA1 algorithm \r\nThe SHA1 modification is a regular SHA1, but every 4 bytes are inverted:\r\ndef reversed_dword_sha1(self, dat2hash):\r\n   sha1Inst = SHA1.new()\r\n   sha1Inst.update(dat2hash)\r\n   hashed_data = sha1Inst.digest()\r\nhttps://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/\r\nPage 2 of 11\n\nresult = b\"\"\r\nfor i in range(5):\r\n     result += hashed_data[4*i:4*i+4][::-1]\r\n   return result\r\nXloader’s own virtual machine algorithm \r\nThe last algorithm is a virtual machine that generates one to four bytes of plaintext, depending on the current byte\r\nof the ciphertext. Usually, this algorithm is used as an additional encryption layer, which will be discussed later.\r\nThe entry of the VM decryption routine looks like this:\r\nAn example of transformations in a virtual machine’s decryption routine\r\nDecrypting XLoader Strings\r\nNext, let’s investigate how string encryption works in XLoader. All byte arrays containing encrypted strings or\r\nkey information are located in special kinds of blobs.\r\nhttps://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/\r\nPage 3 of 11\n\nAn example of a blob with encrypted data\r\nAs you can see in the screenshot above, this blob is a function that returns a pointer to itself, below this function\r\nare the bytes you are looking for.\r\nIn order to decrypt strings, first a key is generated. The key is generated from 3 parts, to which the above-described functions are applied.\r\nhttps://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/\r\nPage 4 of 11\n\nKey generation function to decrypt strings\r\nHere K1_blob, K2_blob, and K3_blob are functions that return data from the blocks described above, and the\r\nstring length is an argument for them. \r\nThe functions VM_Decrypt, RC4_with_sub_Layer and sha1_* are modified algorithms that we discussed earlier.\r\nSchematically, the key generation algorithm can be represented by the following diagram. \r\nhttps://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/\r\nPage 5 of 11\n\nScheme of key generation to decrypt strings\r\nHere E and K are the data and the key that is fed to the input of the RC4 function, respectively, and K1, K2, and\r\nK3 are the data obtained from the K1_blob, K2_blob, and K3_blob functions.\r\nThe strings themselves are also stored as a blob and are covered by two layers of encryption:  \r\nVM_decrypt\r\nRC4 that uses the key obtained above. \r\nAt the same time, RC4 is not used for the whole blob at once.\r\nAfter removing the first layer, the encrypted strings themselves are stored in the format:\r\nencrypted string length – encrypted string\r\nConsequently, to decrypt the strings, we need to loop through this structure and consistently decrypt all the strings.\r\nFunction for decrypting strings\r\nFunction for decrypting strings\r\nBelow is an example of the encrypted data after stripping the first layer. Length/string pairs for the first 3\r\nencrypted strings are highlighted in red.\r\nhttps://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/\r\nPage 6 of 11\n\nThe first 3 encrypted strings\r\nThe first 3 encrypted strings\r\nThe same strings after decryption:\r\nThe first 3 lines after decoding\r\nAlong with the encrypted strings, C2 decoys are also stored there. They are always located at the end of all\r\ndecrypted strings, beginning and ending with the f-start and f-end strings.\r\nDecrypting XLoader’s C2 Servers\r\nNext, let’s see how the main C2 encryption works. The main C2 is located elsewhere in the code, so you can get it\r\nseparately from the C2 decoys. \r\nCode snippet demonstrating C2 decryption.\r\nTo decrypt it, as well as to decrypt the strings, 3 keys are used. The C2 decryption scheme is shown below: \r\nEC2 is the encrypted C2\r\nDC2 is the decrypted C2\r\nThe algorithm itself is a 3 times sequential application of the RC4 algorithm with 3 different keys.\r\nC2 decoys’ decryption scheme\r\nC2 decoys’ decryption scheme\r\nhttps://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/\r\nPage 7 of 11\n\nAlso, in newer versions of XLoader C2 decoys, which usually lie along with all the other strings, turn out to be\r\ncovered by an additional layer of encryption, and, at first glance, it is completely unclear where exactly the\r\ndecryption of these strings occurs. \r\nSince XLoader has several entry points, each responsible for different non-intersecting functionality, with many\r\nfunctions turning out to be encrypted.\r\nThe C2 decoys are decrypted inside the XLoader injected into Explorer.exe. And in this case, it is passed to\r\nnetsh.exe, which also contains XLoader via APC injection. \r\nThe C2 life cycle in different XLoader modules\r\nIn order to understand how a C2 decoy is encrypted, first of all, you need to understand how the functions are\r\nencrypted. \r\nIt’s actually quite simple. RC4 is used as the encryption algorithm. This time, the key is hardcoded and written\r\nright in the code and then xored with the 4-byte gamma.\r\nAfter that, you should find pointers to the start and end of the function. This is how you do it:  a unique 4-byte\r\nvalue is placed at the beginning and end of each encrypted function. The XLoader looks for these values and gets\r\nthe desired pointers.\r\nhttps://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/\r\nPage 8 of 11\n\nCode snippet demonstrating the decryption of the function\r\nThen the function is decrypted, control is given to it, and it similarly searches for and decrypts the next function.\r\nThis happens until the function with the main functionality is decrypted and executed. So, functions should be\r\ndecrypted recursively.\r\nThe key to decrypting C2 decoys consists of 2 parts and is collected separately at two different exit points. One\r\nexit point gets the 20-byte protected key, and the second gets the 4-byte gamma to decrypt the key.\r\nExample of extracted XLoader malware configuration\r\nApplying the above algorithms we can extract the configuration from Xloader, including C2, C2 decoys,  and\r\nstrings. For your convenience, we have integrated automatic extraction of the Xloader configuration into\r\nANY.RUN interactive sandbox — just run the sample and get all the IOCs in seconds. \r\nhttps://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/\r\nPage 9 of 11\n\nExtracted malware configuration in ANY.RUN\r\nExtracted malware configuration in ANY.RUN\r\nExtracted malware configuration in ANY.RUN\r\nExamples of successfully executed samples:\r\nhttps://app.any.run/tasks/f6d29aa7-4054-44b6-b4cc-61684742da88/\r\nhttps://app.any.run/tasks/aa804b50-2c11-447e-a5a9-709b83634aa0/\r\nhttps://app.any.run/tasks/8bcca55f-99ae-4b8d-b60e-226562068d9a/\r\nSum it up\r\nIn this article, we discussed the encryption in xLoader stealer. It is based on both add-ons to existing algorithms\r\nand self-written algorithms.\r\nThe main tricky part of the decryption process is the key generation and the fact that the XLoader functionality is\r\nsplit into modules that can be run in different processes. Because of this, in order to extract strings, we have to\r\ndecrypt the executable code, among other things.\r\nFortunately, ANY.RUN is already set up to detect this malware automatically, making the relevant configuration\r\ndetails just a click away.\r\nIf you want to read more content like this, check out our analysis of the Raccoon Stealer, CryptBot, or Orcus RAT.\r\nAppendix\r\nhttps://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/\r\nPage 10 of 11\n\nAnalyzed files\r\nSample with new C2 decoys encryption\r\nTitle Description\r\nName MT10320221808-004. pdf.exe\r\nMD5 b7127b3281dbd5f1ae76ea500db1ce6a\r\nSHA1 6e7b8bdc554fe91eac7eef5b299158e6b2287c40\r\nSHA256 726fd095c55cdab5860f8252050ebd2f3c3d8eace480f8422e52b3d4773b0d1c\r\nSample without C2 decoys encryption\r\nTitle Description\r\nName Transfer slip.exe\r\nMD5 1b5393505847dcd181ebbc23def363ca\r\nSHA1 830edb007222442aa5c0883b5a2368f8da32acd1\r\nSHA256 27b2b539c061e496c1baa6ff071e6ce1042ae4d77d398fd954ae1a62f9ad3885\r\nSource: https://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/\r\nhttps://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"MITRE"
	],
	"references": [
		"https://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/"
	],
	"report_names": [
		"xloader-formbook-encryption-analysis-and-malware-decryption"
	],
	"threat_actors": [],
	"ts_created_at": 1775434564,
	"ts_updated_at": 1775791286,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5be8afd49a185b0b43dfe5c99506101f94e2131b.pdf",
		"text": "https://archive.orkl.eu/5be8afd49a185b0b43dfe5c99506101f94e2131b.txt",
		"img": "https://archive.orkl.eu/5be8afd49a185b0b43dfe5c99506101f94e2131b.jpg"
	}
}