{
	"id": "3cb122ff-a89b-45dc-bda0-c2a4e1b6458b",
	"created_at": "2026-04-06T00:21:30.328857Z",
	"updated_at": "2026-04-10T03:20:54.620067Z",
	"deleted_at": null,
	"sha1_hash": "c328392db768cf4de98ea7eb8a4c2305857efd62",
	"title": "DirtyMoe: Introduction and general overview of modularized malware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 899353,
	"plain_text": "DirtyMoe: Introduction and general overview of modularized\r\nmalware\r\nBy Threat Research TeamThreat Research Team\r\nArchived: 2026-04-05 14:14:39 UTC\r\nAbstract\r\nThe rising price of the cryptocurrency has caused a skyrocketing trend of malware samples in the wild. DDoS\r\nattacks go hand in hand with the mining of cryptocurrencies to increase the attackers’ revenue/profitability.\r\nMoreover, the temptation grows if you have thousands of victims at your disposal.\r\nThis article presents the result of our recent research on the DirtyMoe malware. We noticed that the\r\nNuggetPhantom malware [1] had been the first version of DirtyMoe, and PurpleFox is its exploit kit [2]. We date\r\nthe first mention of the malware to 2016. The malware has followed a  fascinating evolution during the last few\r\nyears. The first samples were often unstable and produced obvious symptoms. Nonetheless, the current samples\r\nare at par with other malware in the use of anti-forensic, anti-tracking, and anti-debugging techniques nowadays.\r\nThe DirtyMoe malware uses a simple idea of how to be modularized, undetectable, and untrackable at the same\r\ntime. The aim of this malware is focused on Cryptojacking and DDoS attacks. DirtyMoe is run as a Windows\r\nservice under system-level privileges via EternalBlue and at least three other exploits. The particular functionality\r\nis controlled remotely by the malware authors who can reconfigure thousands of DirtyMoe instances to the\r\ndesired functionality within a few hours. DirtyMoe just downloads an encrypted payload, corresponding to the\r\nrequired functionality, and injects the payload into itself.\r\nDirtyMoe’s self-defense and hiding techniques can be found at local and network malware layers. The core of the\r\nDirtyMoe is the service that is protected by VMProtect. It extracts a Windows driver that utilizes various rootkit\r\ncapabilities such as service, registry entry, and driver hiding. Additionally, the driver can hide selected files on the\r\nsystem volume and can inject an arbitrary DLL into each newly created process in the system. The network\r\ncommunication with a mother server is not hard-coded and is not invoked directly. DirtyMoe makes a DNS\r\nrequest to one hard-coded domain using a set of hardcoded DNS servers. However,  the final IP address and port\r\nare derived using another sequence of DNS requests. So, blocking one final IP address does not neutralize the\r\nmalware, and we also cannot block DNS requests to DNS servers such as Google, Cloudflare, etc.\r\nThis is the first article of the DirtyMoe series. We present a high-level overview of the complex DirtyMoe’s\r\narchitecture in this article. The following articles will be focused on detailed aspects of the DirtyMoe architecture,\r\nsuch as the driver, services, modules, etc. In this article, We describe DirtyMoe’s kill chain, sophisticated network\r\ncommunication, self-protecting techniques, and significant symptoms. Further, we present statistical information\r\nabout the prevalence and location of the malware and C\u0026C servers. Finally, we discuss and summarize the\r\nrelationship between DirtyMoe and PurpleFox. Indicators of Compromise lists will be published in future posts\r\nfor each malware component.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-1/\r\nPage 1 of 12\n\n1. Kill Chain\r\nThe following Figures illustrate two views of DirtyMoe architecture. The first one is delivery and the second one\r\nis exploration including installation. Individual Kill Chain items are described in the following subsections.\r\nFigure 1. Kill Chain: Delivery\r\nFigure 2. Kill Chain: Exploitation and Installation\r\n1.2 Reconnaissance\r\nThrough port-scanning and open-database of vulnerabilities, the attackers find and target a large number of weak\r\ncomputers. PurpleFox is the commonly used exploit kit for DirtyMoe.\r\n1.3 Weaponization\r\nThe DirtyMoe authors apply several explicit techniques to gain admin privileges for a DirtyMoe deployment.\r\nOne of the favorite exploits is EternalBlue ( CVE-2017-0144 ), although this vulnerability is well known from\r\n2017. Avast still blocks around 20 million EternalBlue attack attempts every month. Unfortunately, a million\r\nmachines still operate with the vulnerable SMBv1 protocol and hence opening doors to malware include\r\nDirtyMoe via privilege escalation [3]. Recently, a new infection vector that cracks Windows machines through\r\nSMB password brute force is on the rise [2].\r\nAnother way to infect a victim machine with DirtyMoe is phishing emails containing URLs that can exploit\r\ntargets via Internet Explorer; for instance, the Scripting Engine Memory Corruption Vulnerability ( CVE-2020-\r\n0674 ). The vulnerability can inject and damage memory so that executed code is run in the current user context.\r\nSo, if the attacker is lucky enough to administrator user login, the code takes control over the affected machine\r\n[4]. It is wondering how many users frequently use Internet Explorer with this vulnerability.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-1/\r\nPage 2 of 12\n\nFurther, a wide range of infected files is a way to deploy DirtyMoe. Crack, Keygen, but even legit-looking\r\napplications could consist of malicious code that installs malware into victim machines as a part of their execution\r\nprocess. Customarily, the malware installation is done in the background and silently without user interaction or\r\nuser’s knowledge. Infected macros, self-extracting archive, and repacked installers of popular applications are the\r\ntypical groups.\r\nWe have given the most well-known examples above, but how to deploy malware is unlimited. All ways have one\r\nthing in common; it is Common Vulnerabilities and Exposures (CVE). Description of the exact method to install\r\nDirtyMoe is out of this article’s scope. However, we list a shortlist of used CVE for DirtyMoe as follows:\r\nCVE-2019-1458 , CVE-2015-1701 , CVE-2018-8120 : Win32k Elevation of Privilege Vulnerability\r\nCVE-2014-6332 : Windows OLE Automation Array Remote Code Execution Vulnerability\r\n1.4 Delivery\r\nWhen one of the exploits is successful and gains system privileges, DirtyMoe can be installed on a victim’s\r\nmachine. We observe that DirtyMoe utilizes Windows MSI Installer to deploy the malware. MSI Installer provides\r\nan easy way to install proper software across several platforms and versions of Windows. Each version requires a\r\ndifferent location of installed files and registry entries. The malware author can comfortably set up DirtyMoe\r\nconfigurations for the target system and platform.\r\n1.4.1 MSI Installer Package\r\nThe malware authors via MSI installer prepare a victim environment to a proper state. They focus on disabling\r\nanti-spyware and file protection features. Additionally, the MSI package uses one system feature which helps to\r\noverwrite system files for malware deployment.\r\nRegistry Manipulation\r\nThere are several registry manipulations during MSI installation. The most crucial registry entries are described in\r\nthe following overview:\r\nMicrosoft Defender Antivirus can be disabled by the DisableAntiSpyware registry key set to 1.\r\nHKCU\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware\r\nWindows File Protection (WFP) of critical Windows system files is disabled.\r\nHKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\SFCDisable\r\nHKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\SFCScan\r\nDisables SMB sharing due to the prevention of another malware infection\r\nHKLM\\SYSTEM\\CurrentControlSet\\Services\\NetBT\\Parameters\\SMBDeviceEnabled\r\nReplacing system files by the malware ones\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\AllowProtectedRenames\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\PendingFileRenameOperations\r\nSets the threshold to the maximum value to ensure that each service is run as a thread and the service is not\r\na normal process.\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control\\SvcHostSplitThresholdInKB\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-1/\r\nPage 3 of 12\n\nFile Manipulation\r\nThe MSI installer copies files to defined destinations if an appropriate condition is met, as the following table\r\nsummarizes.\r\nWindows Session Manager ( smss.exe ) copies the files during Windows startup according to registry value of\r\nPendingFileRenameOperations entry as follows:\r\nDelete (if exist) \\\\[WindowsFolder]\\\\AppPatch\\\\Acpsens.dll\r\nMove \\\\[SystemFolder]\\\\sens.dll to \\\\[WindowsFolder]\\\\AppPatch\\\\Acpsens.dll\r\nMove \\\\[WindowsFolder]\\\\winupdate[64,32].log to \\\\[SystemFolder]\\\\sens.dll\r\nDelete (if exist) \\\\[WindowsFolder]\\\\AppPatch\\\\Ke583427.xsl\r\nMove \\\\[WindowsFolder]\\\\sysupdate.log to \\\\[WindowsFolder]\\\\AppPatch\\\\Ke583427.xsl\r\n1.4.2 MSI Installation\r\nThe MSI installer can be run silently without the necessity of the user interaction. The installation requires the\r\nsystem restart to apply all changes, but the MSI installer supports delayed restart, and a user does not detect any\r\nsuspicious symptoms. The MSI installer prepares all necessary files and configurations to deploy the DirtyMoe\r\nmalware. After the system reboot, the system overwrites defined system files, and the malware is run. We will\r\ndescribe the detailed analysis of the MSI package in a separate article.\r\n1.5 Exploitation\r\nThe MSI package overwrites the system file sens.dll via the Windows Session Manager. Therefore, DirtyMoe\r\nabuses the Windows System Event Notification (SENS) to be started by the system. The infected SENS Service is\r\na mediator which deploys a DirtyMoe Service.\r\nIn the first phase, the abused service ensures that DirtyMoe will be loaded after the system reboot and restores the\r\nmisused Windows service to the original state. Secondly, the main DirtyMoe service is started, and a rootkit driver\r\nhides the DirtyMoe’s services, registry entries, and files.\r\n1.5.1 Infected SENS Service\r\nWindows runs the original SENS under NT AUTHORITY\\SYSTEM user. So, DirtyMoe gains system-level\r\nprivileges. DirtyMoe must complete three basic objectives on the first run of the infected SENS Service.\r\n1. Rootkit Driver Loading\r\nDirtyMoe runs in user mode, but the malware needs support from the kernel space. Most kernel actions try\r\nto hide or anti-track DirtyMoe activities. A driver binary is embedded in the DirtyMoe service that loads\r\nthe driver during DirtyMoe starts.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-1/\r\nPage 4 of 12\n\n2. DirtyMoe Service Registration\r\nThe infected SENS Service registers the DirtyMoe Service in the system as a regular Windows service.\r\nConsequently, the DirtyMoe malware can survive the system reboot. The DirtyMoe driver is activated at\r\nthis time; hence the newly created service is hidden too. DirtyMoe Service is the main executive unit that\r\nmaintains all malware activities.\r\n3. System Event Notification Service Recovery\r\nIf the DirtyMoe installation and service deployment is successful, the last step of the infected SENS\r\nService is to recover the original SENS service from the Acpsens.dll backup file; see File Manipulation.\r\n1.5.2 DirtyMoe Service\r\nDirtyMoe Service is registered in the system during the maware’s deployment. At the start, the service extracts\r\nand loads the DirtyMoe driver to protect itself. When the driver is loaded, the service cleans up all evidence about\r\nthe driver from the file system and registry.\r\nThe DirtyMoe malware is composed of two processes, namely DirtyMoe Core and DirtyMoe Executioner, created\r\nby DirtyMoe service that terminates itself if the processes are created and configured. DirtyMoe Service creates\r\nthe Core and Executioner process through several processes and threads that are terminated over time. Forensic\r\nand tracking methods are therefore more difficult. The DirtyMoe services, processes, and their details will be\r\ndescribed in the future article in detail.\r\n1.6 Installation\r\nAll we described above is only preparation for malicious execution. DirtyMoe Core is the maintenance process\r\nthat manages downloading, updating, encrypting, backuping, and protecting DirtyMoe malware. DirtyMoe Core is\r\nresponsible for the injection of malicious code into DirtyMoe Executioner that executes it. The injected code,\r\ncalled MOE Object or Module, is downloaded from a C\u0026C server. MOE Objects are encrypted PE files that\r\nDirtyMoe Core decrypts and injects into DirtyMoe Executioner.\r\nAdditionally, the initial payload that determines the introductory behavior of DirtyMoe Core is deployed by the\r\nMSI Installer as the sysupdate.log file. Therefore, DirtyMoe Core can update or change its own functionality by\r\npayload injection.\r\n1.7 Command and Control\r\nDirtyMoe Core and DirtyMoe Executioner provide an interface for the malware authors who can modularize\r\nDirtyMoe remotely and change the purpose and configuration via MOE Objects. DirtyMoe Core communicates\r\nwith the command and control (C\u0026C) server to obtain attacker commands. Accordingly, the whole complex\r\nhierarchy is highly modularized and is very flexible to configuration and control.\r\nThe insidiousness of the C\u0026C communication is that DirtyMoe does not use fixed IP addresses but implements a\r\nunique mechanism to obfuscate the final C\u0026C server address. So, it is impossible to block the C\u0026C server on a\r\nvictim’s machine since the server address is different for each C\u0026C communication. Moreover, the mechanism is\r\nbased on DNS requests which cannot be easily blocked because it would affect everyday communications.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-1/\r\nPage 5 of 12\n\n1.8 Actions on Objective\r\nRegarding DirtyMoe modularization, crypto-mining seems to be a continuous activity that uses victim machines\r\npermanently if malware authors do not need to make targeted attacks. So, crypto-mining is an activity at a time of\r\npeace. However, the NSFOCUS Threat Intelligence center discovered distributed denial-of-service (DDoS)\r\nattacks [1]. In general, DirtyMoe can deploy arbitrary malware into infected systems, such as information stealer,\r\nransomware, trojan, etc.\r\n2. Network Communication\r\nAs we announced, the network communication with the C\u0026C server is sophisticated. The IP address of the C\u0026C\r\nserver is not hardcoded because it is derived from DNS requests. There are three pieces of information hardcoded\r\nin the code.\r\n1. A list of public DNS servers such as Google, Cloudflare, etc.\r\n2. A hard-coded domain rpc[.]1qw[.]us is an entry point to get the final IP address of the C\u0026C server.\r\n3. Bulgarian constants1) that are used for a translation of IP addresses.\r\nA DNS request to the 1qw[.]us domain returns a list of live servers, but it is not the final C\u0026C server. DirtyMoe\r\nconverts the returned IP address to integer and subtracts the first Bulgarian constant (anything making the result\r\ncorrect) to calculate the final C\u0026C IP address. A C\u0026C port is also derived from the final IP address using the\r\nsecond Bulgarian’s constant to make things even worse.\r\nThe insidiousness of the translation is an application of DNS requests that cannot be easily blocked because users\r\nneed the IP translations. DirtyMoe sends requests to public DNS servers that resolve the 1qw[.]us domain\r\nrecursively. Therefore, user machines do not contact the malicious domain directly but via one of the hardcoded\r\ndomain name servers. Moreover, the list of returned IP addresses is different for each minute. \r\nWe record approx. 2,000 IP addresses to date. Many translated IP addresses lead to live web servers, mostly with\r\nChinese content. It is unclear whether the malware author owns the web servers or the web servers are just\r\ncompromised by DirtyMoe.\r\n3. Statistics\r\nAccording to our observation, the first significant occurrence of DirtyMoe was observed in 2017. The number of\r\nDirtyMoe hits was in the thousands between 2018 – 2020.\r\n3.1 DirtyMoe Hits\r\nThe increase of incidences has been higher in orders of magnitude this year, as the logarithmic scale of Figure 3\r\nindicates. On the other hand, it must be noted that we have improved our detection for DirtyMoe in 2020. We\r\nrecord approx. one hundred thousand infected and active machines to date. However, it is evident that DirtyMoe\r\nmalware is still active and on the rise. Therefore, we will have to watch out and stay sharp.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-1/\r\nPage 6 of 12\n\nFigure 3. Annual occurrences of DirtyMoe hits\r\nThe dominant county of DirtyMoe hits is Russia; specifically, 65 k of 245 k hits; see Figure 4. DirtyMoe leads in\r\nEurope and Asia, as Figure 5 illustrates. America also has a significant share of hits.\r\nFigure 4. Distribution of hits in point of the country view\r\nFigure 5. Distribution of hits in point of the continent view\r\n3.2 C\u0026C Servers\r\nWe observed the different distribution of countries and continents for C\u0026C servers (IP addresses) and sample hits.\r\nMost of the C\u0026C servers are located in China, as Figures 6 and 7 demonstrate. We can deduce that the location of\r\nthe malware source is in China. It is evident that the malware authors are a well-organized group that operates on\r\nall major continents.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-1/\r\nPage 7 of 12\n\nFigure 6. Distribution of C\u0026C servers in point of the country view\r\nFigure 7. Distribution of C\u0026C servers in point of the continent view\r\n3.3 VMProtect\r\nIn the last two years, DirtyMoe has used a volume ID of the victim’s machines as a name for the service DLL. The\r\nfirst versions of DirtyMoe applied a windows service name selected at random. It was dominant in 2018; see\r\nFigure 8.\r\nFigure 8. Distribution of cases using service names\r\nWe detected the first significant occurrence of VMProtect at the end of 2018. The obfuscation via VMprotect has\r\nbeen continuously observed since 2019. Before VMProtect, the malware authors relied on common obfuscation\r\nmethods that are still present in the VMProtected versions of DirtyMoe.\r\n4. Self Protecting Techniques\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-1/\r\nPage 8 of 12\n\nEvery good malware must implement a set of protection, anti-forensics, anti-tracking, and anti-debugging\r\ntechniques. DirtyMoe uses rootkit methods to hide system activities. Obfuscation is implemented via the\r\nVMProtect software and via its own encrypting/decrypting algorithm. Network communications are utilized by a\r\nmultilevel architecture so that no IP addresses of the mother servers are hardcoded. Last but not least is the\r\nprotection of DirtyMoe processes to each other.\r\n4.1 DirtyMoe Driver\r\n The DirtyMoe driver provides a wide scale of functionality; see the following shortlist:\r\nMinifilter: affection (hide, insert, modify) of a directory enumeration\r\nRegistry Hiding: can hide defined registry keys\r\nService Hiding: patches service.exe structures to hide a required service\r\nDriver Hiding: can hide itself in the system\r\nThe DirtyMoe driver is a broad topic that we will discuss in a future post.\r\n4.2 Obfuscation and VMProtect\r\nDirtyMoe code contains many malicious patterns that would be caught by most AV. The malware author used\r\nVMprotect to obfuscate the DirtyMoe Service DLL file. DirtyMoe Objects that download are encrypted with\r\nsymmetric ciphers using hardcoded keys. We have seen several MOE objects which contained, in essence, the\r\nsame PE files differing in PE headers only. Nevertheless, even these slight modifications were enough for the used\r\ncipher to produce completely different MOE objects. Therefore, static detections cannot be applied to MOE\r\nencrypted objects. Moreover, DirtyMoe does not dump a decrypted MOE object (PE file) into the file system but\r\ndirectly injects the MOE object into the memory.\r\nDirtyMoe stores its configuration in registry entry as follows: HKLM\\SOFTWARE\\Microsoft\\DirectPlay8\\Direct3D\r\nThe configuration values are also encrypted by the symmetric cipher and hardcoded key. Figure 9 demonstrates\r\nthe decryption method for the DirectPlay8\\Direct3D registry key. A detailed explanation of the method will be\r\npublished in a future post.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-1/\r\nPage 9 of 12\n\nFigure 9. Decryption method for the Direct3D registry value\r\n4.3 Anti-Forensic and Protections\r\nAs we mentioned in the Exploitation section, the forensic and tracking methods are more complicated since\r\nDirtyMoe workers are started over several processes and threads. The workers are initially run as svchost.exe ,\r\nbut the DirtyMoe driver changes the worker’s process names to fontdrvhost.exe . DirtyMoe has two worker\r\nprocesses (Core and Executioner) that are guarded to each other. So, if the first worker is killed, the second one\r\nstarts a new instance of the first one and vice versa.\r\n5. Symptoms and Deactivation\r\nAlthough DirtyMoe uses advanced protection and anti-forensics techniques, several symptoms indicate the\r\npresence of DirtyMoe.\r\n5.1 Registry\r\nThe marked indicator of DrityMoe existence is a registry key HKLM\\SOFTWARE\\Microsoft\\DirectPlay8\\Direct3D .\r\nThe DirtyMoe stores the configuration in this registry key.\r\nAdditionally, if the system registry contains duplicate keys in the path\r\nHKLM\\SYSTEM\\CurrentControlSet\\Services , it can point to unauthorized manipulation in the Windows kernel\r\nstructures. The DirtyMoe driver implements techniques to hide registry keys that can cause inconsistency in the\r\nregistry.\r\nThe MSI installer leaves the following flag if the installation is successful:\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\SoundResearch\\UpdaterLastTimeChecked[1-3]\r\n5.2 Files\r\nThe working directory of DirtyMoe is C:\\Windows\\AppPatch . The DirtyMoe malware backups the original SENS\r\nDLL file to the working directory under the Acpsens.dll file.\r\nRarely, the DirtyMoe worker fails during .moe file injection, and the C:\\Windows\\AppPatch\\Custom folder may\r\ncontain unprocessed MOE files.\r\nSometimes, DirtyMoe “forgot” to delete a temporary DLL file used for the malware deployment. The temporary\r\nservice is present in Windows services, and the service name pattern is ms\u003cfive-digit_random_number\u003eapp . So,\r\nthe System32 folder can contain the DLL file in the form: C:\\Windows\\System32\\ms\u003cfive-digit-random-number\u003eapp.dll\r\nThe MSI installer often creates a directory in C:\\Program Files folder with the name of the MSI product name:\r\nFONDQXIMSYHLISNDBCFPGGQDFFXNKBARIRJH or a similar format: [A-Z]{36}\r\n5.3 Processes\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-1/\r\nPage 10 of 12\n\nOn Windows 10, the DirtyMoe processes have no live parent process since the parent is killed due to anti-tracking.\r\nThe workers are based on svchost.exe . Nonetheless, the processes are visible as fontdrvhost.exe under\r\nSYSTEM users with the following command-line arguments:\r\nsvchost.exe -k LocalService\r\nsvchost.exe -k NetworkService\r\n5.4 Deactivation\r\nIt is necessary to stop or delete the DirtyMoe service named Ms\u003cvolume-id\u003eApp . Unfortunately, the DirtyMoe\r\ndriver hides the service even in the safe mode. So, the system should be started via any installation disk to avoid\r\nthe driver effect and then remove/rename the service DLL file located in C:\\Windows\\System32\\Ms\u003cvolume-id\u003eApp.dll .\r\nThen, the DirtyMoe service is not started, and the following action can be taken:\r\nRemove Ms\u003cvolume-id\u003eApp service\r\nDelete the service DLL file\r\nRemove the core payload and their backup files from C:\\Windows\\AppPatch\r\nKe\u003cfive-digit_random_number\u003e.xsl and Ac\u003cvolume-id\u003e.sdb\r\nRemove DirtyMoe Objects from C:\\Windows\\AppPatch\\Custom\r\n\u003cmd5\u003e.mos ; \u003cmd5\u003e.moe ; \u003cmd5\u003e.mow\r\n6. Discussion\r\nParts of the DirtyMoe malware have been seen throughout the last four years. Most notably, NSFOCUS\r\nTechnologies described these parts as Nugget Phantom [1]. However, DirtyMoe needs some exploit kit for its\r\ndeployment. We have clues that PurpleFox [5] and DirtyMoe are related together. The question is still whether\r\nPurpleFox and DirtyMoe are different malware groups or whether PurpleFox is being paid to distribute DirtyMoe.\r\nOtherwise, both malware families come from the same factory. Both have complex and sophisticated network\r\ninfrastructures. Hence, malware could be a work of the same group.\r\nThe DirtyMoe authors are probably from China. The DirtyMoe service and MOE Modules are written in Delphi.\r\nOn the other hand, the DirtyMoe driver is written in Microsoft Visual C++. However, the driver is composed of\r\nrootkit techniques that are freely accessible on the internet. The authors are not familiar with rootkit writing since\r\nthe drive code contains many bugs that have been copied from the internet. Moreover, Delphi malicious patterns\r\nwould be easily detectable, so the authors have been using VMProtect for the code obfuscation.\r\nThe incidence of PurpleFox and DirtyMoe has increased in the last year by order of magnitude, and expected\r\noccurrence indicates that DirtyMoe is and will be very active. Furthermore, the malware authors seem to be a\r\nlarge and organized group. Therefore, DirtyMoe should be closely monitored.\r\n7. Conclusion\r\nCryptojacking and DDoS attacks are still popular methods, and our findings indicate that DirtyMoe is still active\r\nand on the rise. DirtyMoe is a complex malware that has been designed as a modular system. PurpleFox is one of\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-1/\r\nPage 11 of 12\n\nthe most used exploit kits for DirtyMoe deployment. DirtyMoe can execute arbitrary functionality based on a\r\nloaded MOE object such as DDoS, etc., meaning that it can basically do anything. In the meantime, the malware\r\naims at crypto-mining. \r\nThe malware implements many self-defense and hiding techniques applied on local, network, and kernel layers.\r\nCommunication with C\u0026C servers is based on DNS requests and it uses a special mechanism translating DNS\r\nresults to a real IP address. Therefore, blocking of C\u0026C servers is not an easy task since C\u0026C addresses are\r\ndifferent each time and they are not hard-coded. \r\nBoth PurpleFox and DirtyMoe are still active malware and gaining strength. Attacks performed by PurpleFox\r\nhave significantly increased in 2020. Similarly, the number of DirtyMoe hits also increases since both malware are\r\nclearly linked together. We have registered approx. 100k infected computers to date.  In each case, DirtyMoe and\r\nPurple Fox are still active in the wild. Furthermore, one MOE object aims to worm into other machines, so\r\nPurpleFox and DirtyMoe will certainly increase their activity. Therefore, both should be closely monitored for the\r\ntime being.\r\nThis article summarizes the DirtyMoe malware in point of high-level overview. We described deploying,\r\ninstallation, purpose, communication, self-protecting, and statistics of DirtyMoe in general. The following articles\r\nof the DirtyMoe series will aim to give a detailed description of the MSI installer package, DirtyMoe driver,\r\nservices, MOE objects, and other interesting topics related to the whole DirtyMoe architecture.\r\nA group of elite researchers who like to stay under the radar.\r\nSources\r\nSource: https://decoded.avast.io/martinchlumecky/dirtymoe-1/\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-1/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://decoded.avast.io/martinchlumecky/dirtymoe-1/"
	],
	"report_names": [
		"dirtymoe-1"
	],
	"threat_actors": [],
	"ts_created_at": 1775434890,
	"ts_updated_at": 1775791254,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c328392db768cf4de98ea7eb8a4c2305857efd62.pdf",
		"text": "https://archive.orkl.eu/c328392db768cf4de98ea7eb8a4c2305857efd62.txt",
		"img": "https://archive.orkl.eu/c328392db768cf4de98ea7eb8a4c2305857efd62.jpg"
	}
}