{ "id": "2f06b2f5-c6b4-4a40-974d-5a328b3e5b22", "created_at": "2026-04-06T00:16:47.889497Z", "updated_at": "2026-04-10T03:21:35.468175Z", "deleted_at": null, "sha1_hash": "a10305f922988feb8abef73bb42de4b38f0afe3a", "title": "A Technical Look At Dyreza | Malwarebytes Labs", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 566292, "plain_text": "A Technical Look At Dyreza | Malwarebytes Labs\r\nBy hasherezade\r\nPublished: 2015-11-03 · Archived: 2026-04-05 15:43:11 UTC\r\nIn a previous post we presented unpacking 2 payloads delivered in a spam campaign. A malicious duet – Upatre\r\n(malware downloader) and Dyreza (credential stealer). In this post we will take a look at the core of Dyreza – and\r\ntechniques that it uses.\r\nNote, that Dyreza is a complex piece of malware and various samples come with various techniques – however,\r\nthe main features remain common.\r\nAnalyzed samples\r\nff3d706015b7b142ee0a8f0ad7ea2911 – Dyreza executable- a persistent botnet agent, carring DLLs with\r\nthe core malicious activities\r\n5a0e393031eb2accc914c1c832993d0b – Dyreza DLL (32bit)\r\n91b62d1380b73baea53a50d02c88a5c6 – Dyreza DLL (64 bit)\r\nBehavioral analysis\r\nWhen Dyreza starts to infect the computer – it spreads like fire. Observing it in Process Explorer, we can see\r\nmany new processes appearing and disappearing. As we can notice, it deploys explorer, svchost, taskeng… All\r\nthis is done in order to obfuscate the flow of execution, in hopes of confusing analyst.\r\n2 copies of the malicious file are dropped – in C:Windows and %APPDATA% – under pseudo-random names,\r\nmatching the regex: [a-zA-Z]{15}.exe , i.e vfHNLkMCYaxBGFy.exe\r\nThat persistence is achieved by adding a new task in the task scheduler – it deploys the malicious sample after\r\nevery minute, to ensure that it keeps running.\r\nCode injected into other processes (svchost, explorer) communicates with the C\u0026C:\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/\r\nPage 1 of 12\n\nChecking on VirusTotal we can confirm, that contacted servers have been reported as malicious:\r\n141.8.226.14 -\u003e https://www.virustotal.com/en/ip-address/141.8.226.14/information/\r\n83.241.176.230 -\u003e https://www.virustotal.com/en/ip-address/83.241.176.230/information/\r\n197.231.198.234 -\u003e https://www.virustotal.com/en/ip-address/197.231.198.234/information/\r\nWhen we deploy any web browser, it directly injects the code into its process and deploys illegitimate\r\nconnections.It is the way to keep in touch with the C\u0026C, monitor user’s activity and steal credentials.\r\nWe can also see files created in a TEMP folder that are serving as a small database, where Dyreza stores\r\ninformation, before they are sent to the C\u0026C.\r\nInside the code\r\nMain executable\r\nDyreza doesn’t start on a machine that has less than 2 processors. This technique is used as a defense, preventing\r\nfile from running on VM. It is based on the observation that VM usually have only one processor – in contrast to\r\nmost physical machines used nowadays. It is implemented by checking appropriate field in PEB (Process\r\nEnvironment Block), that is pointed by FS:[30]. Infection continues only if the condition is satisfied.\r\nAt the beginning of execution, malware loads additional import table into a newly allocated memory page. Names\r\nof modules and functions are decrypted at runtime.\r\nIt checks, if it is deployed under debugger – using function LookupPrivilegeValue with argument\r\nSeDebugPrivilege – if it returns non-zero value, execution is terminated.\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/\r\nPage 2 of 12\n\nValid execution follows few alternative paths. Decision, by which path of to follow is made based on the initial\r\nconditions – like, executable path and arguments with which the program was run. When it is deployed for the\r\nfirst time (from a random location), it make its own copy into C:Windows and %APPDATA% and deploy the\r\ncopy as a new process. As an argument to a deployed copy (from C:Windows) it passes a path to the other copy.\r\nIf it is deployed from the valid path and the initial argument passed validation, it performs another check –\r\nverifying if it is deployed for the first time. It is achieved by creating a specific Global mutex (it’s name is a hash\r\nof Computer name and OS Version  – fetched by functions: GetComputerName, RtlGetVersion).\r\nIf this condition is also satisfied and mutex already exist, then it follows the main path, deploying the malicious\r\ncode. First, the encrypted data and the key are loaded from the executable’s resources.\r\nT1RY615NR – encrypted 32 bit code, UZGN53WMY – the key, YS45H26GT – encrypted 64bit code\r\nUnpacking:\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/\r\nPage 3 of 12\n\nThe unpacking algorithm is pretty simple – key_data contains values and data – list of indexes of the values in\r\nkey_data. We process the list of indexes and read the corresponding values:\r\n[code language=”python”] def decode(data, key_data): decoded = bytearray() for i in range(0, len(data)):\r\nval_index = data[i] decoded.append(key_data[val_index]) return decoded [/code]\r\nThis script decrypts dumped resources:\r\nhttps://github.com/hasherezade/malware_analysis/blob/master/dyreza/dyreza_decoder.py\r\nThe revealed content contains a shellcode to be injected and a a DLL with malicious functions (32 or 64 bit\r\nappropriately). The main sample chooses which one to unpack and deploy, by checking if it is running via\r\nWOW64 (emulation for 32 bit on 64 bit machine) – calling function IsWow64Process.\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/\r\nPage 4 of 12\n\nMalicious DLL (core)\r\nAt this stage, functionality of the malware becomes pretty clear. The DLL does not contain much obfuscation – it\r\nhas clear strings and a typical import table.\r\nWe can see the strings that are used for communication with the C\u0026C:\r\nBoth – 32 and 64 bit DLLs have analogical functionality. Only architecture-related elements and strings are\r\ndifferent.\r\nThe agent identifies the system:\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/\r\nPage 5 of 12\n\nand then – include this data in information sent to the C\u0026C:\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/\r\nPage 6 of 12\n\nSimilar procedure is present in the 64 bit version of the DLL, only the hardcoded string “_32bit” is substituted by\r\n“_64bit”:\r\nAlso, network settings are examined (to verify and inform the C\u0026C whether the client can establish back\r\nconnection – command : AUTOBACKCONN)\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/\r\nPage 7 of 12\n\nIt targets following browsers:\r\nBelow – attempt to send stolen account credentials:\r\nIn addition to monitoring browsers, it also collects general information about the computer (it’s hardware, users,\r\nprograms and services) – in form of a report:\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/\r\nPage 8 of 12\n\nThe malware not only steal information and sniff user’s browsing, but also tries to take a full control over the\r\nsystem – executes various shell commands – system shutdown,etc. Some examples below:\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/\r\nPage 9 of 12\n\nTrying to add a user with administrative privileges\r\nShutdown system on command (AUTOKILLOS)\r\nC\u0026Cs\r\nThis botnet is prepared with great care. Not only communication is encrypted, but also many countermeasures\r\nhave been taken in order to prevent detection.\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/\r\nPage 10 of 12\n\nFirst of all, the address of  the C\u0026C is randomly picked from a hard-coded pool.This pool is stored in one of the\r\nresources of Dyreza DLL (AES encrypted). Below, we can see how it gets decrypted, during execution of the\r\npayload:\r\n(A script for decrypting list of C\u0026Cs from dumped resources is available here:\r\nhttps://github.com/hasherezade/malware_analysis/blob/master/dyreza/dyrezadll_decoder.py)\r\nAlso, the certificate served by a particular C\u0026C changes on each connection. The infrastructure is built on the\r\nnetwork of compromised WiFi routers (most often: AirOS, MicroTik).\r\nThe server receives encrypted connection on port 443 (standard HTTPS) or 4443 (in case if standard HTTPS port\r\nof a particular router is occupied by a legitimate service).\r\nConclusion\r\nDyreza is an eclectic malware, developed by professionals. It is clear that they are constantly working on a quality\r\n– each new version carries some new ideas and improvements, making analysis harder.\r\nAppendix\r\nVery good Dyreza/Upatre tracker: https://techhelplist.com/maltlqr/ – by @Techhelplistcom (list of C\u0026Cs\r\nfrom the current sample: https://techhelplist.com/maltlqr/reports/01oct-20oct-status.txt )\r\nScripts used in this post: https://github.com/hasherezade/malware_analysis/tree/master/dyreza\r\nAbout the author\r\nUnpacks malware with as much joy as a kid unpacking candies.\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/\r\nPage 11 of 12\n\nSource: https://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/\r\nPage 12 of 12\n\nThe revealed appropriately). content contains The main sample a shellcode chooses to be injected which one to unpack and a a DLL with and deploy, malicious functions by checking if it (32 or 64 is running via bit\nWOW64 (emulation for 32 bit on 64 bit machine)-calling function IsWow64Process.\n Page 4 of 12", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "MITRE", "ETDA" ], "references": [ "https://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/" ], "report_names": [ "a-technical-look-at-dyreza" ], "threat_actors": [], "ts_created_at": 1775434607, "ts_updated_at": 1775791295, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/a10305f922988feb8abef73bb42de4b38f0afe3a.pdf", "text": "https://archive.orkl.eu/a10305f922988feb8abef73bb42de4b38f0afe3a.txt", "img": "https://archive.orkl.eu/a10305f922988feb8abef73bb42de4b38f0afe3a.jpg" } }