{
	"id": "8455f662-7ae3-44af-96a4-c62e90b092d1",
	"created_at": "2026-04-06T00:22:33.226424Z",
	"updated_at": "2026-04-10T13:12:16.926683Z",
	"deleted_at": null,
	"sha1_hash": "1790923f8c7fb60651d8a74ce4cfbc21c17bac35",
	"title": "Introducing TrickBot, Dyreza's successor | Malwarebytes Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1053772,
	"plain_text": "Introducing TrickBot, Dyreza's successor | Malwarebytes Labs\r\nBy Malwarebytes Labs\r\nPublished: 2016-10-23 · Archived: 2026-04-05 18:28:58 UTC\r\nRecently, our analyst Jérôme Segura captured an interesting payload in the wild. It turned out to be a new bot that,\r\nat the moment of analysis, hadn’t been described yet. According to strings found inside the code, the authors\r\nnamed it TrickBot (or “TrickLoader”).\r\nMany links indicate that this bot is another product of the threat actors previously behind Dyreza, a credential-stealer. While TrickBot seems to be written from scratch, it contains many similar features and solutions to those\r\nwe encountered analyzing Dyreza.\r\nAnalyzed samples\r\nf26649fc31ede7594b18f8cd7cdbbc15 – initial sample, dropped by Rig EK\r\n3814abbcd8c8a41665260e4b41af26d4 – unpacked: intermediate payload (loader)\r\n f24384228fb49f9271762253b0733123 – unpacked: final payload (TrickBot) – 32bit \u003c-\r\nmain focus of this analysis\r\n10d72baf2c79b29bad1038e09c6ed107 – 64-bit loader\r\nbd79db0f9f8263a215e527d6627baf2f – unpacked: final payload (TrickBot) – 64bit\r\nTrickBot’s modules:\r\n533b0bdae7f4c8dcd57556a45e1a62c8 – systeminfo32.dll\r\nc5a0a3dba3c3046e446bd940c20b6092 -systeminfo64.dll\r\n90421f8531f963d81cf54245b72cde80 – injectDll32.dll\r\nc90f766020855047c3a8138842266c5a – the DLL injected in browsers (32bit)\r\n0b521fd97402c02366184ec413e888cc – injectDll64.dll\r\n5a7459fb0b49a8b28fae507730e2a924 – the DLL injected in browsers (64bit)\r\nAdditional payload:\r\n47d9e7c464927052ca0d22af7ad61f5d  – downloaded sample\r\ne80ac57a092ffcf2965613c8b3c537c0 – unpacked\r\nDistribution\r\nThe payload was spread via malvertising campaign, which dropped the Rig EK:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 1 of 18\n\nBehavioral analysis\r\nAfter being deployed, TrickBot copies itself into %APPDATA% and deletes the original sample. It doesn’t change\r\nthe initial name of the executable, however. (In the given example, the analyzed sample was named “trick.exe”.)\r\nFirst, we can see it dropping two additional files: client_id and group_tag. They are generated locally and used to\r\nidentify, appropriately, the individual bot and the campaign to which it belongs. The content of both files is not\r\nencrypted; it contains text in Unicode.\r\nAn example of the client_id consists of the name of the attacked machine, operating system version, and a\r\nrandomly-generated string:\r\nExample of the group_tag:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 2 of 18\n\nThen, in the same location, we can see config.conf appearing. This file is downloaded from the C\u0026C and stored in\r\nencrypted form.\r\nAfter some time, we can see another folder being created in %APPDATA% named Modules. The malware drops\r\nadditional modules downloaded from the C\u0026C, which are also stored encrypted. In a particular session, TrickBot\r\ndownloaded modules called injectDll32 and systeminfo32:\r\nThis particular module may also have a corresponding folder where its configuration is stored. The pattern of the\r\nnaming convention is [module name]_configs.\r\nWhen we observe the execution of the malware via monitoring tools, i.e. ProcessExplorer, we can find it\r\ndeploying two instances of svchost:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 3 of 18\n\nThe bot achieves persistence by adding itself as a task in Windows Task Scheduler. It doesn’t put any effort in\r\nhiding the task under a legitimate name, and instead just calls it “Bot.”\r\nIf the process is killed, it is automatically restarted by the Task Scheduler Engine:\r\nNetwork communication\r\nTrickBot connects to the several servers:\r\nFirst, it connects to a legitimate server myexternalip.com in order to fetch the IP visible from outside.\r\nThe interesting part is that it doesn’t try to disguise as a legitimate browser. Instead, it uses its own User Agent:\r\n“BotLoader” or “TrickLoader.”\r\nMost—but not all—of the communication with its main C\u0026C is SSL encrypted. Below, you can see an example of\r\none of the commands sent to the C\u0026C:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 4 of 18\n\nLooking at the URL of POST request, we notice the group_id and the client_id that are the same as in the files.\r\nAfter that, the command id follows. This format was typical for Dyreza.\r\nThe bot also downloads an additional payload (in the particular session it was:\r\n47d9e7c464927052ca0d22af7ad61f5d) without encrypting the traffic:\r\nC\u0026Cs are set up on hacked wireless routers, such as MikroTik. This way of setting up the infrastructure was also\r\npreviously used by Dyreza.\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 5 of 18\n\nIn this example of a used HTTPs certificate, we can see that the used data is fully random and not even trying to\r\nimitate legitimate-looking names:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 6 of 18\n\nInside the malware\r\nTrickBot is composed of several layers. As usual, the first layer is used for protection: It carries the\r\nencrypted payload and tries to hide it from AV software.\r\nLoader\r\nThe second layer is a main bot loader that chooses whether to deploy a 32-bit or 64-bit payload.\r\nNew PE files are stored in resources in encrypted form. However, the authors didn’t try to hide the\r\nfunctionality of particular elements, and looking at the names of the resources, we can easily guess\r\nwhat their purpose is:\r\nSelected modules are decrypted during execution.\r\nAt the beginning, the application fetches information about the victim’s operating system in order to choose the\r\nappropriate way to follow:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 7 of 18\n\nDepending on the environment, a suitable payload is picked from resources, decrypted by a simple algorithm, and\r\nvalidated:\r\nThe decrypting procedure is different than the one found in Dyreza, however, the general idea of organizing\r\ncontent (three encrypted modules in resources) is analogous.\r\ndef decode(data): decoded = bytearray() key = 0x3039 i = 0 for i in range(0, len(data\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 8 of 18\n\nSee full decoding script: https://github.com/hasherezade/malware_analysis/blob/master/trickbot/trick_decoder.py\r\nReturning to our malware analysis, next, the unpacked bot is mapped to the memory by a dedicated function and\r\ndeployed.\r\nThe 32-bit bot maps the new module inside its own memory (self-injection):\r\nand then redirects execution there:\r\nEntry point of the new module (TrickBot core):\r\nIn the case of 64-bit payload being chosen, first the additional executable—a 64bit PE loader—is unpacked and\r\nrun. Then it loads the core, malicious bot.\r\nIn contrast to Dyreza, whose main modules were DLLs, TrickBot uses EXEs.\r\nThe TrickBot internals\r\nThe bot is written in C++. It comes with two resources with descriptive names: CONFIG, which stores encrypted\r\nconfiguration, and KEY, which stores the Elliptic Curve key:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 9 of 18\n\nIn general, this malware is verbose: meaningful names can be found at every stage.\r\nThe name “TrickBot” also appears in the name of the global mutex (“Global\\TrickBot”) created by the application\r\nin order to ensure that it is run only once:\r\nAt first execution, TrickBot copies itself into a new location (in %APPDATA%) and deploys the new copy, giving\r\nas an argument path to the original one that needs to be deleted:\r\nAdding a task of running bot into the Task Scheduler:\r\nSetting the triggering event:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 10 of 18\n\nWe can find the date pointing to the beginning of 2016, which may confirm the observation that the bot is new,\r\nand was written this year.\r\nTrickBot’s commands\r\nTrickBot communicates with its C\u0026C and sends several commands in a format similar to the one used by Dyreza.\r\nBelow is list of format strings used by TrickBot commands:\r\nCompare that with Dyreza’s command format:\r\nTrickBot’s command IDs are hardcoded in the format strings. However, all of them are deployed from inside the\r\nsame function that gets the command ID as a parameter:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 11 of 18\n\nAfter filling the appropriate format string and sending it to the C\u0026C, the bot checks the HTTP response code. If\r\nthe returned code is different than 200 (OK), 403 (Forbidden), or 404 (Not found), then it tries again.\r\nHere’s a full list of implemented command IDs:\r\n0 1 5 10 14 23 25 63\r\nEach command has the same prefix – that is a group id of the campaign and bot’s individual id (the same data that\r\nare stored in dropped files). Format:\r\n/[group_id]/[client_id]/[command_id]/...\r\nSample url:\r\nhttps://193.9.28.24/tmt2/TESTMACHINE_W617601.653EB63213B91453D28A68C80FCA3AC4/5/sinj/\r\nMore notes about the protocol here.\r\nEncryption\r\nTrickBot uses alternatively two encryption algorithms: AES and ECC.\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 12 of 18\n\nThe downloaded modules and configuration are encrypted by AES in CBC mode. The AES key and initialization\r\nvector are derived from the data, by a custom, predefined algorithm. First, 32 bytes of input data is hashed, using\r\nSHA256. Then, the output of the hashing function is appended to the data buffer and hashed again. This step is\r\nrepeated until the full size of data in buffer become 4096. So, the hashing operation repeats 128 times. Below you\r\ncan see the responsible fragment of code:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 13 of 18\n\nFirst 32 byte long chunk of data is used as a initial value to derive AES key:\r\nAnd bytes from 16 to 48 are used as a initial value to derive AES initialization vector:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 14 of 18\n\nCompare with the content of CONFIG (mind the fact that the first DWORD is a size, and is not included in the\r\ndata):\r\nFull decoding script you can find here:\r\nhttps://github.com/hasherezade/malware_analysis/blob/master/trickbot/trick_config_decoder.py\r\nDecrypting hardcoded configuration using AES:\r\nIn case if particular input could not be decrypted via AES, the attempt is made to decrypt it via ECC:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 15 of 18\n\nTrick Bot’s configuration\r\nSimilarly to Dyreza, TrickBot uses configuration files, that are stored encrypted.\r\nTrick Bot’s executable comes with a hardcoded configuration, that, during execution is substituted by its fresh\r\nversion, downloaded from the C\u0026C and saved in the file config.conf. Below you can see the decrypted content of\r\nthe hardcoded one:\r\nhttps://gist.github.com/hasherezade/0c464f970018f509444243b67a0c5447#file-mcconf-xml\r\nCompare it with a downloaded one – version number got incremented, and some C\u0026Cs have changed:\r\nhttps://gist.github.com/hasherezade/0c464f970018f509444243b67a0c5447#file-mcconf2-xml\r\nNotice that names of the listed modules (systeminfo, injectDll) are corresponding to those, that we found in the\r\nfolder Modules during the behavioral analysis. It is due to the fact, that this configuration gives instructions to the\r\nbot, and orders it to download particular elements.\r\nSome of the requests result in downloading additional pieces of configuration. Example of the response, after\r\nbeing decrypted by the bot:\r\nhttps://gist.github.com/hasherezade/0c464f970018f509444243b67a0c5447#file-servconf-xml\r\nModules\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 16 of 18\n\nTrickBot is a persistent botnet agent – but its main power lies in the modules, that are DLLs dynamically fetched\r\nfrom the C\u0026C. During the analyzed session, the bot downloaded two modules.\r\ngetsysinfo – used for general system info gathering\r\ninjectDll – the banker module, injecting DLLs in target browsers in order to steal credentials\r\nList of the attacked browser is hardcoded in the injectDll32.dll:\r\nIt case of the Dyreza, this attack was performed directly from the main bot, rather than from the added DLL.\r\nDetails of the attacked target are given in an additional configuration file, stored in the folder:\r\nModulesinjectDll32_config.  Below we can see its decrypted form revealing the attacked online-banking systems:\r\nhttps://gist.github.com/hasherezade/0c464f970018f509444243b67a0c5447#file-dinj-xml\r\nThe instances of svchost.exe, observed during the behavioral analysis, are used to deploy particular modules.\r\nBelow – the module injectDll (marked sinj) in memory of svchost:\r\nand the module systeminfo (marked GetSystemInfo) in memory of the another instance of svchost:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 17 of 18\n\nConclusion\r\nTrick Bot have many similarities with Dyreza, that are visible at the code design level as well as the\r\ncommunication protocol level. However, comparing the code of both, shows, that it has been\r\nrewritten from scratch.\r\nSo far, Trick Bot does not have as many features as Dyreza bot. It may be possible, that the authors intentionally\r\ndecided to make the main executable lightweight, and focus on making it dynamically expendable using\r\ndownloaded modules. Another option is that it still not the final version.\r\nOne thing is sure – it is an interesting piece of work, written by professionals. Probability is very high, that it will\r\nbecome as popular as its predecessor.\r\nAppendix\r\nhttp://www.threatgeek.com/2016/10/trickbot-the-dyre-connection.html – analysis of the TrickBot at Threat Geek\r\nBlog\r\nThis was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest\r\nin InfoSec. She loves going in details about malware and sharing threat information with the community. Check\r\nher out on Twitter @hasherezade and her personal blog: https://hshrzd.wordpress.com.\r\nSource: https://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/\r\nPage 18 of 18\n\nThe decrypting content (three procedure is encrypted modules different than the in resources) one found in Dyreza, is analogous. however, the general idea of organizing \ndef decode(data): decoded = bytearray() key = 0x3039 i = 0 for i in range(0, len(data\n   Page 8 of 18   \n\n  https://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/   \nFirst 32 byte long chunk of data is used as a initial value to derive AES key:\nAnd bytes from 16 to 48 are used as a initial value to derive AES initialization vector:\n    Page 14 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/"
	],
	"report_names": [
		"trick-bot-dyrezas-successor"
	],
	"threat_actors": [],
	"ts_created_at": 1775434953,
	"ts_updated_at": 1775826736,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1790923f8c7fb60651d8a74ce4cfbc21c17bac35.pdf",
		"text": "https://archive.orkl.eu/1790923f8c7fb60651d8a74ce4cfbc21c17bac35.txt",
		"img": "https://archive.orkl.eu/1790923f8c7fb60651d8a74ce4cfbc21c17bac35.jpg"
	}
}