{
	"id": "0a0cc38d-95b2-47b9-8792-eab48400edb4",
	"created_at": "2026-04-06T00:16:48.842403Z",
	"updated_at": "2026-04-10T03:36:37.171331Z",
	"deleted_at": null,
	"sha1_hash": "ca3df2cfe53e0b5de0bb2572d4313bc6680a05e6",
	"title": "Reverse Engineering Dridex and Automating IOC Extraction",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2740953,
	"plain_text": "Reverse Engineering Dridex and Automating IOC Extraction\r\nPublished: 2025-01-09 · Archived: 2026-04-05 14:12:23 UTC\r\nCYBER RESEARCH\r\nColby Dyess |September 18, 2020 | 5 minute read\r\nInsights from Appgate Labs\r\nDridex[1] is a major banking trojan that appeared somewhere around 2011, continually evolving ever since.\r\nThe APT (Advanced Persistence Threat) known as TA505\r\n[2]\r\n is associated to Dridex, as well as with other\r\ninfamous malware such as TrickBot and Locky ransomware.\r\nOnce installed, Dridex can download additional files to provide more functionality to the trojan. Simply put, there\r\nare four main components:\r\nIn the last few days, our team detected recent Dridex samples through our live hunting process and, after\r\nanalyzing them, we’ve decided to publish an analysis of the main features implemented by this threat that makes\r\ndetection and analysis difficult.\r\nTherefore, in this post, we will focus on the second layer (Loader), showing the technical details regarding:\r\n1. Unpacking;\r\n2. Dynamic API Calls;\r\n3. Encrypted Strings;\r\n4. C2 Network Communication.\r\nhttps://www.appgate.com/blog/reverse-engineering-dridex-and-automating-ioc-extraction\r\nPage 1 of 11\n\nIn addition, we are publishing a tool that statically extracts IOCs from the latest Dridex binaries, as we believe that\r\nthis can enable organizations to reduce analysis time spent during incidents or prevent the malware family\r\naltogether.\r\n1. Unpacking\r\nUnpacking is an important step because Dridex doesn’t write the unpacked payload to disk, instead, the custom\r\npacker loads it directly to memory and there it stays. First, to analyze and extract the IOCs, we must get the\r\nunpacked sample, and this is not a difficult task.\r\nYou can easily execute the packed sample and then run the amazing PE-sieve[3] tool, from hasherezade, which\r\nwill extract the payload from memory. However, if you are curious like us and wants to understand how it works,\r\nthe first step in the unpacking process is the allocation of an encrypted content into memory:\r\nEncrypted DLL in Memory.\r\nThis data is an encrypted small DLL that is responsible for unpacking the Dridex loader. Also, we noticed that the\r\nmagic bytes (MZ) for the MS-DOS header was not present, probably to avoid automatic filetype identifications.\r\nhttps://www.appgate.com/blog/reverse-engineering-dridex-and-automating-ioc-extraction\r\nPage 2 of 11\n\nDecrypted DLL in Memory.\r\nAfter the decryption process, the main executable transfers the execution to the allocated DLL, which unpacks the\r\nDridex Loader and then replaces the main executable code with the payload’s code.\r\nDridex Payload in Memory.\r\n2. Dynamic API Calls\r\nDridex doesn’t have an import table like regular PE files. Instead, all the API calls are dynamically resolved by the\r\nmalware using a custom technique to avoid detection by APIs and to make reverse engineering more difficult.\r\nTo resolve an API, it calls a “resolver” function passing two parameters, both custom hashes. The first one is a\r\nhash for the DLL name that contains the API, and the second one is the hash of the API name that Dridex needs to\r\nresolve.\r\nThe way the API is resolved isn’t trivial, but in summary, if the API wasn’t already resolved by the malware, it\r\nparses the DLL linked list, located in the process’ PEB (Process Environment Block), generating a CRC32 hash\r\nhttps://www.appgate.com/blog/reverse-engineering-dridex-and-automating-ioc-extraction\r\nPage 3 of 11\n\nfor each DLL and API name and compares that with the ones that was passed into the function. Aside from the\r\nCRC32 hash, the value is also “xored” with a custom key, making the values unique on each Dridex sample.\r\nDridex Searching for DLL Using Custom Hash.\r\nTherefore, in the example above, the first hash stands for “kernel32.dll”. Using this same logic, we created a small\r\nIDA script which resolves API calls automatically and inserts a comment where the function is called, so we can\r\neasily search where in the code certain DLLs or APIs are being used.\r\nBlock with Encrypted Strings.\r\nEach chunk contains one or more strings that are encrypted with RC4, where the key is the first 40 bytes (in little-endian format) of each block.\r\nhttps://www.appgate.com/blog/reverse-engineering-dridex-and-automating-ioc-extraction\r\nPage 4 of 11\n\nDecrypting Dridex Strings.\r\nAside from the encrypted strings, we also found plain text strings in this recent Loader that were not present in\r\nolder versions, which can be used for identification (Yara rule):\r\nbot\r\nvnc\r\nsocks\r\nuacme\r\nlist\r\ncve-2015-0057 (mod5)\r\nTrendMicro (mod9)\r\nNetChecker (mod10)\r\nrep: DllLoaded (dmod5)\r\nrep: DllStarted (dmod6)\r\nrep: NetGood (dmod7)\r\nrep: NetFail (dmod8)\r\nrep: NetPart (dmod9)\r\nrep: StartedInLo (dmod10)\r\nrep: StartedInHi (dmod11)\r\n4. C2 Network Communication\r\nThe loader is responsible for the initial C2 communication and for downloading additional files, such as the bot\r\nand the modules. Analyzing the function that does such communication, we could see that the command sent to\r\nthe C2 is passed as a parameter, and it’s the CRC32 hash of the command string.\r\nFunction for C2 Communication.\r\nCuriously though, that despite using the hashes of the commands in the communication, this specific sample has\r\nthe same commands in the strings, as mentioned above, such as the \"list\" that requests a list of IPs to connect or\r\nthe \"bot\" that is the command to download the next stage.\r\nBefore doing the request, the botnet ID and the C2 addresses are parsed.\r\nhttps://www.appgate.com/blog/reverse-engineering-dridex-and-automating-ioc-extraction\r\nPage 5 of 11\n\nDridex Parsing Command \u0026 Control IPs\r\nThis information is stored in the PE “.data” section, represented in bytes, along with the Dridex botnet ID.\r\nDridex C2 IPs.\r\nhttps://www.appgate.com/blog/reverse-engineering-dridex-and-automating-ioc-extraction\r\nPage 6 of 11\n\nOnce these addresses are parsed, Dridex then sends a POST request to one of the C2 addresses and, bypassing the\r\nSSL, we could see that the data is encrypted. If the server doesn’t respond as expected, Dridex continues to send\r\nthe same content to the other IPs.\r\nDridex POST Request to C2.\r\nAfter analyzing the function, we found that the malware uses the first 4 bytes as a checksum for the encrypted\r\nbytes, with CRC32 hash.\r\nEncrypted Network Data Checksum\r\nIf the checksum matches, the data can be decrypted correctly. The algorithm used by Dridex is RC4 and the\r\nencryption/decryption key is stored among Dridex decrypted strings.\r\nhttps://www.appgate.com/blog/reverse-engineering-dridex-and-automating-ioc-extraction\r\nPage 7 of 11\n\nDecrypted Network Data.\r\nThe image below illustrates some of the main fields used in the first POST request made by this Dridex sample.\r\nData Sent by Dridex to C2.\r\n5. Automating IOC Extraction\r\nAlong with this blog post, we are releasing a python script that automates the IOC extraction from the Dridex\r\nhttps://www.appgate.com/blog/reverse-engineering-dridex-and-automating-ioc-extraction\r\nPage 8 of 11\n\nloader. These are the main features implemented by our “Dridex Analysis Toolkit”:\r\nExtract Botnet ID;\r\nExtract C2 IP Addresses;\r\nDecrypt Strings;\r\nDecrypt Network Communication.\r\nFurthermore, since most Dridex payloads comes from memory dumps, the script also tries to unmap the PE file to\r\ndisk, so it can get the right offsets to parse, example:\r\nExtracting C2 Addresses from Dridex Payload Automatically.\r\nBy using the “-s” option, the script searches and decrypts the payload strings and prints any possible RC4 keys:\r\nhttps://www.appgate.com/blog/reverse-engineering-dridex-and-automating-ioc-extraction\r\nPage 9 of 11\n\nRC4 Keys Found by the Script.\r\nYou can then use these keys to decrypt any network communication by using the “-n” option:\r\nDecrypted Network Data.\r\nThe script also writes the output data into a folder:\r\nScript Output.\r\nConclusion\r\nIn this post we show the main technical characteristics that makes Dridex a difficult malware to detect and\r\nanalyze. By publishing this analysis and the automation script, our intention is to help analysts understand how\r\nkey parts of Dridex work and to help organizations detect and extract Dridex IOCs as early as possible, so that\r\nappropriate actions are taken faster.\r\nhttps://www.appgate.com/blog/reverse-engineering-dridex-and-automating-ioc-extraction\r\nPage 10 of 11\n\nIOCs\r\nPacked Dridex Loader\r\nd506f18f771ec417c27a6528c17f08ee9d180d40a0a9c6b6ef93b7a39304b96a\r\nUnpacked Dridex Loader\r\n756fa5527f4c564effbc69dd3b3d76e7196b869976eeae48c4b34f4ff25dfa5c\r\nC2 Addresses\r\n45.79.8[.]25:443\r\n185.201.9[.]197:9443\r\n217.160.78[.]166:4664\r\n108.175.9[.]22:33443\r\nBotnet ID\r\n12333\r\nRC4 Keys\r\nxrAuVcgsoW0BBPhAH5w5aQ1Q2UuZQidMhZYugaYvCPvgttsD9jQkM\r\nVTRBArv8sWNVqJ4WDs2rzCN2QMqXLb9fsEjtRZL6vW628p93i3iJe\r\n[1] https://malpedia.caad.fkie.fra...\r\n[2] https://malpedia.caad.fkie.fra...\r\n[3] https://github.com/hasherezade...\r\nSource: https://www.appgate.com/blog/reverse-engineering-dridex-and-automating-ioc-extraction\r\nhttps://www.appgate.com/blog/reverse-engineering-dridex-and-automating-ioc-extraction\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.appgate.com/blog/reverse-engineering-dridex-and-automating-ioc-extraction"
	],
	"report_names": [
		"reverse-engineering-dridex-and-automating-ioc-extraction"
	],
	"threat_actors": [
		{
			"id": "5e6b31a6-80e3-4e7d-8b0a-d94897ce9b59",
			"created_at": "2024-06-19T02:03:08.128175Z",
			"updated_at": "2026-04-10T02:00:03.636663Z",
			"deleted_at": null,
			"main_name": "GOLD TAHOE",
			"aliases": [
				"Cl0P Group Identity",
				"FIN11 ",
				"GRACEFUL SPIDER ",
				"SectorJ04 ",
				"Spandex Tempest ",
				"TA505 "
			],
			"source_name": "Secureworks:GOLD TAHOE",
			"tools": [
				"Clop",
				"Cobalt Strike",
				"FlawedAmmy",
				"Get2",
				"GraceWire",
				"Malichus",
				"SDBbot",
				"ServHelper",
				"TrueBot"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "75d4d6a9-b5d1-4087-a7a0-e4a9587c45f4",
			"created_at": "2022-10-25T15:50:23.5188Z",
			"updated_at": "2026-04-10T02:00:05.26565Z",
			"deleted_at": null,
			"main_name": "TA505",
			"aliases": [
				"TA505",
				"Hive0065",
				"Spandex Tempest",
				"CHIMBORAZO"
			],
			"source_name": "MITRE:TA505",
			"tools": [
				"AdFind",
				"Azorult",
				"FlawedAmmyy",
				"Mimikatz",
				"Dridex",
				"TrickBot",
				"Get2",
				"FlawedGrace",
				"Cobalt Strike",
				"ServHelper",
				"Amadey",
				"SDBbot",
				"PowerSploit"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "99cb4e5b-8071-4f9e-aa1d-45bfbb6197e3",
			"created_at": "2023-01-06T13:46:38.860754Z",
			"updated_at": "2026-04-10T02:00:03.125179Z",
			"deleted_at": null,
			"main_name": "TA505",
			"aliases": [
				"SectorJ04",
				"SectorJ04 Group",
				"ATK103",
				"GRACEFUL SPIDER",
				"GOLD TAHOE",
				"Dudear",
				"G0092",
				"Hive0065",
				"CHIMBORAZO",
				"Spandex Tempest"
			],
			"source_name": "MISPGALAXY:TA505",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "e447d393-c259-46e2-9932-19be2ba67149",
			"created_at": "2022-10-25T16:07:24.28282Z",
			"updated_at": "2026-04-10T02:00:04.921616Z",
			"deleted_at": null,
			"main_name": "TA505",
			"aliases": [
				"ATK 103",
				"Chimborazo",
				"G0092",
				"Gold Evergreen",
				"Gold Tahoe",
				"Graceful Spider",
				"Hive0065",
				"Operation Tovar",
				"Operation Trident Breach",
				"SectorJ04",
				"Spandex Tempest",
				"TA505",
				"TEMP.Warlock"
			],
			"source_name": "ETDA:TA505",
			"tools": [
				"Amadey",
				"AmmyyRAT",
				"AndroMut",
				"Azer",
				"Bart",
				"Bugat v5",
				"CryptFile2",
				"CryptoLocker",
				"CryptoMix",
				"CryptoShield",
				"Dridex",
				"Dudear",
				"EmailStealer",
				"FRIENDSPEAK",
				"Fake Globe",
				"Fareit",
				"FlawedAmmyy",
				"FlawedGrace",
				"FlowerPippi",
				"GOZ",
				"GameOver Zeus",
				"GazGolder",
				"Gelup",
				"Get2",
				"GetandGo",
				"GlobeImposter",
				"Gorhax",
				"GraceWire",
				"Gussdoor",
				"Jaff",
				"Kasidet",
				"Kegotip",
				"Kneber",
				"LOLBAS",
				"LOLBins",
				"Living off the Land",
				"Locky",
				"MINEBRIDGE",
				"MINEBRIDGE RAT",
				"MirrorBlast",
				"Neutrino Bot",
				"Neutrino Exploit Kit",
				"P2P Zeus",
				"Peer-to-Peer Zeus",
				"Philadelphia",
				"Philadephia Ransom",
				"Pony Loader",
				"Rakhni",
				"ReflectiveGnome",
				"Remote Manipulator System",
				"RockLoader",
				"RuRAT",
				"SDBbot",
				"ServHelper",
				"Shifu",
				"Siplog",
				"TeslaGun",
				"TiniMet",
				"TinyMet",
				"Trojan.Zbot",
				"Wsnpoem",
				"Zbot",
				"Zeta",
				"ZeuS",
				"Zeus"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434608,
	"ts_updated_at": 1775792197,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ca3df2cfe53e0b5de0bb2572d4313bc6680a05e6.pdf",
		"text": "https://archive.orkl.eu/ca3df2cfe53e0b5de0bb2572d4313bc6680a05e6.txt",
		"img": "https://archive.orkl.eu/ca3df2cfe53e0b5de0bb2572d4313bc6680a05e6.jpg"
	}
}