{ "id": "b7af9a54-287d-4172-8e67-72286e73cc09", "created_at": "2026-04-06T00:21:10.440617Z", "updated_at": "2026-04-10T03:21:37.319909Z", "deleted_at": null, "sha1_hash": "c2131be1e6600b41cade25e90a86b456a0e6530a", "title": "Talking to Dridex (part 0) – inside the dropper", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 77004, "plain_text": "Talking to Dridex (part 0) – inside the dropper\r\nArchived: 2026-04-05 15:45:04 UTC\r\nIntro\r\nDridex mostly comes to us as spam which contains a .doc with some macros, responsible for\r\ndownloading a dropper. One can quickly analyze it using oledump.py and looking through vbscript,\r\nor naturally, just try to run it in a sandbox and obtain the dropped files.\r\nCFG extraction\r\nAfter unpacking the rather mundane packer, lets get into the juicy parts. We are presented with a\r\nsmall stage1 dropper, which looks rather basic.\r\nThe purpose of the dropper is to download the main binary from C\u0026C and inject it to explorer, plus\r\nsome generic initialization stuff.\r\nFirst lets take a look how to find C\u0026C addresses. In older samples there was a PE section called\r\n.sdata and it contained xored xml-document with all of the interesting data,\r\n\u0026lt;config botnet=\"301\"\u0026gt;\r\n\u0026lt;server_list\u0026gt;\r\n85.25.238.9:8843\r\n91.142.221.195:5445\r\n46.37.1.88:473\r\n\u0026lt;/server_list\u0026gt;\r\n\u0026lt;/config\u0026gt;\r\nAbout a week ago that changed. There is no more .sdata – data sits in plain sight somewhere in\r\nmemory, structured as follows:\r\nstruct cfg_t {\r\nint field_0;\r\nunsigned __int16 botnet;\r\nunsigned __int8 count;\r\nchar unknown;\r\nip_addr cnc[count];\r\n};\r\nhttps://www.cert.pl/en/news/single/talking-dridex-part-0-inside-the-dropper/\r\nPage 1 of 6\n\nstruct ip_addr {\r\nchar ipaddr[4];\r\n__int16 port;\r\n};\r\nUsing a yara signature like this:\r\n $new_get_cnc = { E8 [4] BE [4] 8D ?? 5B 83 C4 1C 0F [3] 08 0F [3] 09 0F [3] 0A 0F [3]\r\nwe can easily locate address where it is used and pull out that data.\r\nFirst encounter with C\u0026C\r\nOk, now we have to find code that calls those addresses. After going back-and-forth between\r\nreferences we stumble across this function:\r\nhttps://www.cert.pl/en/news/single/talking-dridex-part-0-inside-the-dropper/\r\nPage 2 of 6\n\nHere is a little digression, if you don’t know this already: Dridex uses encoded strings and a run-time api resolving to make our life harder. Fortunately nothing fancy, a simple xor:\ndef dridex_decode_name(addr,idx,delm=“\\x00“):\naddr += 8; tmp = ‘‘; j = 0\nxkey = GetManyBytes(addr,8)\nfor i in range(idx+1):\ntmp = ‘‘\nwhile not tmp.endswith(delm):\ntmp += chr(ord(xkey[j%8]) ^ Byte(addr+8+j))\nj+=1\nreturn tmp.strip(delm)\nBack to business. Despite what’s often reported, the first communication is not encrypted with xor\nas described in other articles, but with RC4. Keys are stored somewhere in binary encoded as any\nother string. They are different per botnet but otherwise don’t seem to change that often. For botnet\n220 the key is:\nub9sKhcvsePZXuFC4HRw8KjFSIVUxsdAJXFyVP3Acl7HYL9KQBzETBzFvk2FlxeHZFBljIPps21W\nArmed with C\u0026C addresses and key, we can create a message. Fortunately, the Dridex authors were\nkind enough not to use any fancy binary format, just plain xml (sometimes gziped but we got to that\npart later…) and the message looks something like this:\n\u003c![CDATA[]]\u003e where “unique” is a bot name, created as follows:\nhttps://www.cert.pl/en/news/single/talking-dridex-part-0-inside-the-dropper/\nPage 3 of 6\n\n“botnet” is a 2 bytes value hidden in config, and the name corresponds to a request we’d like to do.\r\nThe most basic request is `list` which obtains a list of nodes.\r\nAfter decrypting the response, using RC4 with the same key, we got something like this, base64-\r\nencoded string is copied without decoding and dealt with in the next stage.\r\n\u003croot\u003e\r\n\u003cmodule name=”list”\u003e\r\nApts4+yozUR8Nbcan9dOya6yFIq6mxfdnJjlydF+uAELwWrIEIcvQIkk1mPURXr25/IwtnDW9l4s36C1\r\n0iL0O6H3sJ1xhnUvcLN7ccjZU+RNySaj6YYSALvTBcGfNreUusy1ESLHKscAq4LJqzNy3UoB6fHLyJkU\r\nLKhVFpKnogyKQEt4lctDeIpAS3iKQwb3205JWYYEZMwTJQEzS9B29XQK6aa1VsPxFd31tsa7IPRFldSb\r\ndDgUVQmVq35rDX5nJNAfOYttztqNC8etW0oDIxrkEzMJedOrGIIvAnMUtdjDeIouPdceNNhiLzkGY3q6\r\ngQoV8pwkCQsSrwltmFOmbyW9l6Vx+XWBiD8wOROQS3iK\r\n\u003c/module\u003e\r\n\u003croot\u003e\r\nThe next command is `bot` and is responsible for downloading main dll\r\n1 \u003croot\u003e\u003cmodule name=”bot”\u003ebase64-string\u003c/module\u003e\u003c/root\u003e\r\nThere is no rocket science here, base64-encoded string is being decoded and loaded into memory,\r\nwhat is interesting in this case is how it is done.\r\nLoader\r\nhttps://www.cert.pl/en/news/single/talking-dridex-part-0-inside-the-dropper/\r\nPage 4 of 6\n\nIt is normal in the malware world to apply an extra layer of protection to files stored in the local\r\nsystem. For example Tinba additionally xors it’s configuration file with bot id. But a non-written\r\nrule of how most malware works, is that every code is passed through memory in clear text. As one\r\ncan guess this not the case here.\r\nIndeed, Dridex’es method of injecting into another process is quite nice. It consists of two stub\r\nloaders. The first is responsible of decoding real payload (again just xor), while the second is used\r\nas a simple pe-loader which makes it possible to run PE files without syscalls like LoadLibrary or\r\nCreateProcess.\r\nThis is clearly visible in any memory tracer,\r\n[37ceca4ac82d0ade9bac811217590ecd.bin – 3980][3952]called[pre] NtOpenProcess(1212) = 1276\r\n– C:\\WINDOWS\\Explorer.EXE\r\n…\r\n[37ceca4ac82d0ade9bac811217590ecd.bin – 3980][3952]called[pre]\r\nNtWriteVirtualMemory(Explorer.EXE,1fe0000,459264) src: 932e90\r\n…\r\n[37ceca4ac82d0ade9bac811217590ecd.bin – 3980][3952]called[pre]\r\nNtWriteVirtualMemory(Explorer.EXE,b20000,2552) src: 12f348\r\n…\r\n[37ceca4ac82d0ade9bac811217590ecd.bin – 3980][3952]called[pre]\r\nNtWriteVirtualMemory(Explorer.EXE,b209f8,2460) sr c: 415020\r\n…\r\n[37ceca4ac82d0ade9bac811217590ecd.bin – 3980][3952]called[post]\r\nNtAllocateVirtualMemoryx(SELF,1900000,12288,MEM_COMMIT|MEM_RESERVE, RWX — )\r\n[37ceca4ac82d0ade9bac811217590ecd.bin – 3980][3952]called[post]\r\nNtAllocateVirtualMemoryx(SELF,1910000,65536,MEM_COMMIT, RW- — )\r\nWhat is important with further analysis is that it relays quite heavily on loader metadata, which is\r\nsomehow modeled to resemble a legit PE – which obviously it is not, as it missed almost every PE\r\ncharacteristic besides the typical MZ-PE signature.\r\nhttps://www.cert.pl/en/news/single/talking-dridex-part-0-inside-the-dropper/\r\nPage 5 of 6\n\n0000000: 4d5a 0000 0000 0000 0000 0000 0000 0000  MZ…………..\r\n0000010: 0000 0000 0000 0000 0000 0000 0000 0000  …………….\r\n0000020: 0000 0000 0000 0000 0000 0000 0000 0000  …………….\r\n0000030: 0000 0000 0000 0000 0000 0000 4000 0000  …………@…\r\n0000040: 5045 0000 0000 0000 0000 0000 0000 0000  PE…………..\r\n0000050: 0000 0000 0000 0000 0000 0000 0000 0000  …………….\r\n0000060: 0000 0000 0000 0000 0000 0000 0000 0000  …………….\r\n0000070: 0000 0000 0000 0000 0000 0000 0000 0000  …………….\r\n0000080: 0000 0000 0000 0000 0000 0000 0000 0000  …………….\r\n0000090: 0000 0000 0000 0000 0000 0000 0000 0000  …………….\r\n00000a0: 0000 0000 0000 0000 0000 0000 0000 0000  …………….\r\nMain dll is obviously packed – however I leave that challenge to the reader as a homework, as this\r\nis the end of introduction. Cya in the next part!\r\nmak\r\nsample used,\r\n1 37ceca4ac82d0ade9bac811217590ecd\r\nSource: https://www.cert.pl/en/news/single/talking-dridex-part-0-inside-the-dropper/\r\nhttps://www.cert.pl/en/news/single/talking-dridex-part-0-inside-the-dropper/\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "ETDA" ], "references": [ "https://www.cert.pl/en/news/single/talking-dridex-part-0-inside-the-dropper/" ], "report_names": [ "talking-dridex-part-0-inside-the-dropper" ], "threat_actors": [], "ts_created_at": 1775434870, "ts_updated_at": 1775791297, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/c2131be1e6600b41cade25e90a86b456a0e6530a.pdf", "text": "https://archive.orkl.eu/c2131be1e6600b41cade25e90a86b456a0e6530a.txt", "img": "https://archive.orkl.eu/c2131be1e6600b41cade25e90a86b456a0e6530a.jpg" } }