{
	"id": "8bcf1490-b2de-4c26-8834-293377d3bdf3",
	"created_at": "2026-04-06T00:06:29.968714Z",
	"updated_at": "2026-04-10T03:20:18.267909Z",
	"deleted_at": null,
	"sha1_hash": "6f88edb123aadc88094791dfeb5dfa81145f7bb1",
	"title": "No Win32 Process Needed | Expanding the WMI Lateral Movement Arsenal",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2475638,
	"plain_text": "No Win32 Process Needed | Expanding the WMI Lateral\r\nMovement Arsenal\r\nBy Philip Tsukerman\r\nArchived: 2026-04-05 20:24:55 UTC\r\nLateral movement is a critical phase in any attack targeting more than a single computer in a network. Lateral\r\nmovement usually abuses existing mechanisms that allow remote code execution, assuming the attacker has the\r\nright credentials. While these mechanisms are usually used for legitimate reasons, many environments may\r\nmonitor them for illegitimate use. Executing code remotely using a vector seldom used in a specific environment\r\n(such as using the PSExec tool in a network where remote service creation is a very rare occasion) may be\r\ndetected as an anomaly and flagged as malicious.\r\nLateral movement techniques that abuse LOLBins are interesting. Read about how the Astaroth trojan uses them.\r\nA more sophisticated attacker would prefer to use remote execution techniques more likely to get masked by a\r\nconstant stream of similar-looking, yet benign behaviors or techniques that abuse an execution channel that’s less\r\nlikely to be monitored by defenders. For this reason, expanding the set of available lateral movement techniques\r\nallows attackers to shape the way they appear to defenders and evade detection.\r\nIn this blog we’ll look at new lateral movement techniques discovered by Cybereason that abuse WMI (Windows\r\nManagement Infrastructure). We’ll also look at one that’s already been publicly disclosed and elaborate on it.\r\nSince these techniques are relatively unknown, many security tools can’t flag them. However, Cybereason built a\r\ntool that’s a proof of concept for the techniques, showing what an attacker could potentially do with them. The\r\nPowerShell script can be found here.\r\nTo learn more about legitimate features that are being abused to carry out lateral movement, check out this blog\r\nthat talks about how attackers are using Distributed Component Object Model (DCOM).\r\nA brief background on WMI\r\nWMI is the implementation of the WBEM and CIM standards on the Windows OS, and allows users,\r\nadministrators and developers (as well as attackers) to enumerate, manipulate and interact with various managed\r\ncomponents in the OS. In practice, WMI provides an abstracted, unified object-oriented model, which contains\r\nclasses representing many discrete elements of a machine, without needing to directly interact (and study the\r\ndocumentation of) many unrelated APIs.\r\nhttps://www.cybereason.com/blog/wmi-lateral-movement-win32#blog-subscribe\r\nPage 1 of 12\n\nWMI contains classes representing elements such as the system registry, processes, threads and hardware\r\ncomponents.\r\nYou can enumerate the instances of components represented by a class by issuing WMI queries, which are written\r\nin WQL, an SQL like language, or through abstractions such as the PowerShell CIM/WMI cmdlets. It is also\r\npossible to invoke methods on classes and instances, and thus to manipulate the underlying managed components\r\nusing the WMI interface.\r\nAn important feature of WMI is the ability to interact with the WMI model of a remote machine, using either the\r\nDCOM or the WinRM protocol. This allows attackers to remotely manipulate WMI classes on a remote machine\r\nwithout needing to run any arbitrary code on it beforehand.\r\nThe Main Components of WMI\r\nWMI consists of three major components:\r\n1. The WMI service (winmgmt) acts as a mediator between clients and the WMI model itself, and is\r\nresponsible for handling all requests (method calls, queries, etc.) coming from client processes. While it\r\ncannot process most of these requests by itself, it is able to forward them to other components, and forward\r\ntheir responses back to the client.\r\n2. WMI providers are where the actual code implementing classes, instances and methods is implemented.\r\nProviders are mostly implemented as in-process COM objects.\r\n3. The WMI Repository is the central storage area for the model, containing things like class definitions and\r\ninstances of objects which require persistence (as opposed to instances that are dynamically generated by\r\nhttps://www.cybereason.com/blog/wmi-lateral-movement-win32#blog-subscribe\r\nPage 2 of 12\n\nproviders.\r\nTo put this in the context of the classic WMI lateral movement technique – when a client (either local or remote)\r\ntries to invoke the “Create” method of the “Win32_Process” – a request for this action is sent to the WMI service,\r\nwhich then consults the repository to determine that the responsible provider is called CIMWin32. The WMI\r\nservice then forwards the request to the provider, which creates a new process and returns the Win32_Process\r\ninstance representing the process to the service, which sends it back to the client. Check out this paper for more\r\ninformation on WMI in a security and forensic context.\r\nThis method of lateral movement is pretty well known and many products are starting to detect it. Since this\r\ntechnique is known, attackers will innovate and look to WMI for additional lateral movement techniques.\r\nAlternative Methods of WMI Lateral Movement\r\nClass Derivation\r\nWhile not strictly a new lateral movement method, this evasion technique removes the need for an attacker to\r\ninteract with the often monitored Win32_Process::Create method directly. An attacker may (remotely) create a\r\nclass that inherits from known-problematic classes such as Win32_Process, and call methods (or create instances)\r\nof the new class, without directly calling the suspicious one, like so:\r\nCreate a subclass of Win32_Process, Win32_NotEvilAtAll, which can be done remotely via WMI\r\nThe new class inherits all the methods of the parent\r\nCall the “Create” method of the newly defined class\r\nExcerpt from the Invoke-WmiLm script released with this article. We create a new subclass of Win32_Process on\r\nthe remote machine using the \"Derive\" and the \"Put\" methods, and call the Create method of the newly defined\r\nclass.\r\nAt first glance, looking at the events of the WMI-Activity ETW provider, it looks like we have evaded the direct\r\nuse of Win32_Process:\r\nhttps://www.cybereason.com/blog/wmi-lateral-movement-win32#blog-subscribe\r\nPage 3 of 12\n\nIndeed, all instances of event 11, which shows requests made to the WMI service, shows no trace of the\r\nWIn32_Process class, which is very promising, but a closer looks shows our evasion is not perfect:\r\nSo why does this still show \"Win32_Process::Create\"?\r\nWhile we have created a new class with the same \"Create\" method, we have not actually introduced any new code\r\nto the target machine. This means the method is executed in the context of the same provider. Event 12 of the\r\nWMI-Activity provider shows the communication between the WMI service and WMI providers, and shows the\r\nmethod execution request after the service has inferred which provider actually implements the requested method.\r\nA different approach to detection is WMI introspection. WMI provides a comprehensive eventing system, and\r\nexposes some extremely useful events to monitor itself. One such event describes all WMI method invocations on\r\nthe machine.\r\nAs can be seen in the above screenshot, the MSFT_WmiProvider_ExecMethodAsyncEvent_Pre describes not the\r\nmethod requested by the client, but again the actual method implemented by the provider, not being affected by\r\nthe evasion technique.\r\nWhile this technique seems not to work as well as one might hoped for obfuscating WMI method invocation, it\r\nworks much better when applied to WMI \"attacks\" that do not need to use a method, such as event subscription, as\r\nthe name of the derived class, and not the original, will show up in all events.\r\nAnother, less successful attempt to abuse the WMI class hierarchy for evasion we have attempted is \"Class\r\nCloning\". This method takes a target class, and defines a new one, sharing all members and hierarchy with the\r\nhttps://www.cybereason.com/blog/wmi-lateral-movement-win32#blog-subscribe\r\nPage 4 of 12\n\ntarget. Supposedly, this is more evasive, as our new class is not a subclass of the target, but it seems that the WMI\r\nservice is unable to locate the implementation of methods defined in the cloned class, rendering them broken.\r\nWMI-ifying Classic Techniques\r\nSticking an additional acronym on a technique doesn't do much by itself, but performing common lateral\r\nmovement tasks (such as replacing PSEXEC) using WMI changes the attackers behavior enough to evade network\r\nmonitoring solutions. Below are a few examples of such technique modifications:\r\nService Creation\r\nRemote service creation (often done with the PSEXEC tool, or a pass-the-hash enabled implementation), is\r\npossibly the most common method of lateral movement in Windows environments, and can be reimplemented\r\nusing WMI.\r\nThe \"Win32_Service\" class represents a single service on a machine, and exposes pretty much all of the\r\nfunctionality of the Windows service manager (or the sc.exe tool).\r\nA quick look at the methods of Win32_Service shows the class is able to easily manipulate services on the target\r\nmachine. This is enough to implement the create-start-stop-delete chain often used by attackers moving laterally\r\nusing services.\r\nWin32_Service is not the only WMI class capable of these operations, and the following classes may be used\r\ninterchangeably:\r\nWIn32_Service\r\nWin32_BaseService\r\nWin32_TerminalService\r\nWin32_SystemDriver\r\nWhen done using PSEXEC, sc.exe, or any other common implementation of remote service management tools,\r\ncommunication will be done via the MS-SCMR protocol over DCERPC. Even when this protocol is using the\r\nmaximum possible level of encryption, one may still easily determine which types of actions (service creation,\r\nservice start etc.) are performed using network traffic monitoring.\r\nhttps://www.cybereason.com/blog/wmi-lateral-movement-win32#blog-subscribe\r\nPage 5 of 12\n\nA wireshark capture of remote service creation using sc.exe\r\nOn the other hand, the same action using WMI looks completely different on the wire:\r\nThough still based on DCERPC, all WMI DCOM method calls are done through a single interface, and when\r\ncoupled with \"packet privacy\" level encryption, network monitoring solutions would only be able to know that\r\nsome WMI method was called. When performed via the WINRM protocol,WMI traffic looks looks like HTTP,\r\nand is again completely different than when done via the SVCCTL interface. This means WMI-ified techniques\r\neffectively evade any network traffic signatures made to detect the lateral movement methods they are based upon.\r\nOld-Style Scheduled Task Creation\r\nWMI also provides a way to interact with the old (at.exe) Windows task scheduling mechanism. This is done via\r\nthe WIn32_ScheduledJob class.\r\nhttps://www.cybereason.com/blog/wmi-lateral-movement-win32#blog-subscribe\r\nPage 6 of 12\n\nThis class allows for the creation, deletion, and enumeration (through the enumeration of class instances, and not\r\nusing a dedicated method) of scheduled jobs. Like the at.exe utility itself, the functionality of this class is\r\ndeprecated in Windows 8 and up. The inability to force the execution of a task may be easily overcome (just like\r\nwith the classic technique) by simply scheduling a task to run a few seconds after it is registered.\r\nNew-Style Scheduled Task Creation\r\nAnother mechanism often used for lateral movement, which may be accessed using WMI is the new Windows\r\ntask scheduler, often interacted with using the schtasks.exe utility. Scheduled tasks created this way are\r\nrepresented by the PS_ScheduledTask and related classes under the ScheduledTaskProv provider.\r\nThe PS_ScheduledTask class exposes methods allowing a client to create, delete, and run arbitrary scheduled tasks\r\nwith custom actions. In fact, The scheduled task cmdlets available on Windows 8 and up, use these WMI classes\r\nbehind the scenes, which means attackers abusing these commands might have been unknowingly (or maybe\r\nknowingly) evading various IDS detections. It should be noted that while the new task scheduler is available on\r\nWindows 7 and up, the ScheduledTaskProv provider is only available for Win8+ machines.\r\nAbusing The Windows Installer\r\nThe Windows Installer provider exposes a class called Win32_Product, which represents applications installed by\r\nthe Windows Installer (msiexec). This class can allow an attacker to run a malicious msi package on a target\r\nhttps://www.cybereason.com/blog/wmi-lateral-movement-win32#blog-subscribe\r\nPage 7 of 12\n\nmachine.\r\nThe \"Install\" method (and probably the \"Admin\" and \"Upgrade\" methods too) of Win32_Product allows the\r\ninstallation of an msi package from a path or a URL. Such packages containing malicious payloads can be crafted\r\nby Metasploit:\r\nWhile Metasploit allows for the packaging of executables as an msi file, the package format also allows for the\r\nembedding of vbscript and jscript payloads, making the msi a rather versatile payload container.\r\nLess successful forays into into abusing the Win32_Product included an attempt to replicate the \"msiexec /y\"\r\ncommand, which tries to register a dll file from the command line. This seems impossible to achieve using WMI.\r\nAnother failed experiment was an attempt to hijack uninstaller command line fields in the registry, and then run\r\nthose commands using the \"Uninstall\" method of WIn32_Product.\r\nChanging the UninstallString value to an arbitrary command line and invoking the \"Uninstall\" method does not\r\nseem to work\r\nMalicious WMI Provider Loading\r\nhttps://www.cybereason.com/blog/wmi-lateral-movement-win32#blog-subscribe\r\nPage 8 of 12\n\nAs mentioned above, WMI providers are where most class instances and methods are implemented. This means\r\none can achieve code execution by loading a custom provider. A recent talk by Alexander Leary has supplied a\r\nmethod to register a WMI provider on a remote machine, using only WMI functions, and without needing to run\r\nany command lines beforehand. One of the shortcomings of this technique is the need to actually implement and\r\ndeliver an actual (malicious) WMI provider dll to the machine. As we are not interested in our code successfully\r\nfunctioning as a WMI provider, but only in it getting loaded as one, we will describe the steps required to run any\r\narbitrary command line as a WMI provider:\r\nFirst, we shall create a COM object - WMI providers are mostly implemented as in-process COM objects, but as\r\nwe would like to run an arbitrary command line, we will write an out-of-process COM object registration as the\r\nbasis of our provider.\r\nNext, we would need to register the provider itself. To do this, all we need to do is to create an instance of the\r\n__Win32Provider class, which represents registered WMI providers, on the remote machine.\r\nThere are three fields of importance in the __Win32Provider instance we would like to create:\r\nName - A human-readable name for the provider, which will later allow us to reference it\r\nCLSID - The Class ID of our newly created COM object\r\nhttps://www.cybereason.com/blog/wmi-lateral-movement-win32#blog-subscribe\r\nPage 9 of 12\n\nHostingModel - This field denotes how the COM object itself should be loaded - \"NetworkServiceHost\"\r\nwill load the COM object as a library into a special host process under the \"Network Service\" user,\r\n\"LocalSystemHost\" will load it as a library in a host process under the system user, and \"SelfHost\" will try\r\nto load the provider as a stand-alone executable under the System user. As we would like to use an arbitrary\r\ncommand line, we would prefer to run our provider as an executable.\r\nNormally, a provider is loaded on demand, when one of the classes and methods it implements is called or queried\r\n(registration of method and instance providers is done via the __MethodProviderRegistration and\r\n__InstanceProviderRegistration classes), but our arbitrary executable obviously does not implement such things.\r\nFortunately, the \"MSFT_Providers\" class (which enumerates loaded WMI providers) has a method called \"Load\",\r\nwhich allows us to load any WMI provider, regardless of demand.\r\nIn addition, it seems that the first time the OS checks that our COM object actually implements a WMI provider is\r\nafter the command has run, allowing us to execute our obviously fake provider object. It should be noted that the\r\nregistration of a WMI provider with the SelfHost hosting model actually writes an alert to the event log,\r\ndescribing the creation of a sensitive provider (as it runs with System privileges). This log write can be evaded by\r\nusing the NetworkServiceHostOrSelfHost hosting model, which at first tries to load the provider as a library\r\n(which we may simply omit from the registration), and when this fails (as there is no library to load), tries to load\r\nthe provider as an executable, with the supplied command line, without writing to the event log.\r\nTo recap, we are able to load our malicious command line as a WMI provider using the following steps:\r\nCreate a new key under HKLM/SOFTWARE/Classes/CLSID/{SOMEGUID} (registry manipulation may\r\nbe done through the StdRegProv WMI provider)\r\nAdd a subkey of LocalServer32 with a \"(default)\" value of whatever command line you want to run (some\r\nnice powershell encoded command, for example)\r\nCreate a new instance of the __Win32Provider class, with our CLSID as the CLSID field, and\r\nNetworkServiceHostOrSelfHost as the HostingModel\r\nCall the Load method of the MSFT_Providers class with the name of our newly created provider\r\nRelax and enjoy our needlessly complicated (but probably undetected) authenticated remote execution\r\nhttps://www.cybereason.com/blog/wmi-lateral-movement-win32#blog-subscribe\r\nPage 10 of 12\n\nDetection and Conclusion\r\nWhile these techniques are relatively unknown and usually go undetected by most security products, Windows\r\nprovides enough information about the WMI function to implement detections for each of the techniques\r\ndiscussed above. Both the WMI-Activity ETW provider and the WMI eventing system provide deep visibility into\r\nall WMI method calls, instance creations and queries, which is just enough information to determine if any\r\nsensitive WMI functionality was invoked.\r\nWhile the techniques we discussed abuse legitimate, documented functionality, they occur infrequently enough to\r\nbe monitored on a per-action basis. We’d advice defenders to account for these techniques when trying to protect\r\ntheir organization from lateral movement and incorporate the multiple methods available to gain deeper visibility\r\ninto WMI and possibly stop these and many other techniques abusing this feature.\r\nLearn how to threat hunt from an expert. Check out our webinar on how to generate a hypothesis in a threat hunt.\r\nhttps://www.cybereason.com/blog/wmi-lateral-movement-win32#blog-subscribe\r\nPage 11 of 12\n\nAbout the Author\r\nPhilip Tsukerman\r\nPhilip Tsukerman is a researcher Cybereason Innovation Labs.\r\nSource: https://www.cybereason.com/blog/wmi-lateral-movement-win32#blog-subscribe\r\nhttps://www.cybereason.com/blog/wmi-lateral-movement-win32#blog-subscribe\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.cybereason.com/blog/wmi-lateral-movement-win32#blog-subscribe"
	],
	"report_names": [
		"wmi-lateral-movement-win32#blog-subscribe"
	],
	"threat_actors": [],
	"ts_created_at": 1775433989,
	"ts_updated_at": 1775791218,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6f88edb123aadc88094791dfeb5dfa81145f7bb1.pdf",
		"text": "https://archive.orkl.eu/6f88edb123aadc88094791dfeb5dfa81145f7bb1.txt",
		"img": "https://archive.orkl.eu/6f88edb123aadc88094791dfeb5dfa81145f7bb1.jpg"
	}
}