{
	"id": "d13f0455-7362-4f92-8e5b-7439afb4fad5",
	"created_at": "2026-04-06T00:06:25.417105Z",
	"updated_at": "2026-04-10T03:20:55.734962Z",
	"deleted_at": null,
	"sha1_hash": "8fb1f47345a10fc5aa900d2b8a35d2f11f79b066",
	"title": "Abusing the COM Registry Structure (Part 2): Hijacking \u0026 Loading Techniques",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5248659,
	"plain_text": "Abusing the COM Registry Structure (Part 2): Hijacking \u0026\r\nLoading Techniques\r\nBy Rob Maslen (@rbmaslen)\r\nPublished: 2018-08-18 · Archived: 2026-04-05 15:46:48 UTC\r\nTL;DR\r\nThere are several ways that attackers can leverage COM hijacking to influence evasive loading and hidden\r\npersistence.  A few examples include CLSID (sub)key abandonment referencing, key overriding, and key\r\nlinking.\r\nThere are several programs and utilities that can invoke COM registry payloads including Rundll32.exe,\r\nXwizard.exe, Verclsid.exe, Mmc.exe, and the Task Scheduler.  In the traditional sense, any binary that\r\nresolves non-existent and/or unreferenced COM classes can be potentially influenced (e.g. hijacked) for\r\n“unintended” loading.\r\nHijacking COM server binaries introduces a few interesting use cases (e.g. MMC).  Attackers can leverage\r\nthe -Embedding switch to open GUI binaries in a hidden manner.\r\nDefensive considerations include implementing robust Application Whitelisting policies, monitoring for\r\nunsuspecting command line usage (e.g. “-Embedding”) with a deviation from the proper parent process\r\n(e.g. svchost.exe), and the creation of interesting Registry keys (e.g. “TreatAs”, “ScriptletUrl”, etc.).\r\nBackground\r\nNot long ago, I wrote a blog post about Abusing the COM Registry Structure: CLSID, LocalServer32, \u0026\r\nInprocServer32.  In that previous post, a few interesting techniques were discussed such as abandoned registry key\r\ndiscovery, COM hijacking, lateral movement, defensive evasion, application whitelisting bypass, and situational\r\npersistence.  In this follow-up post, we will take it a step further and focus on a few other hijack methods and\r\nevasive loading techniques.  Topics include:\r\nCOM Hijacking Techniques\r\nCLSID Loading Techniques for Evasion \u0026 Persistence\r\nCOM Server Misuse: Microsoft Management Console (MMC) Use Case\r\nDefensive Considerations\r\nLet’s jump in…\r\nIn order to load and execute a COM payload without registration, an attacker must influence the COM registry\r\nstructure.  A way to do this is through a technique called COM Hijacking.  One of the best definitions for COM\r\nHijacking comes from the Mitre ATT\u0026CK Framework:\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 1 of 17\n\n“The Microsoft Component Object Model (COM) is a system within Windows to enable interaction between\r\nsoftware components through the operating system.  Adversaries can use this system to insert malicious code that\r\ncan be executed in place of legitimate software through hijacking the COM references and relationships as a\r\nmeans for persistence. Hijacking a COM object requires a change in the Windows Registry to replace a reference\r\nto a legitimate system component which may cause that component to not work when executed. When that system\r\ncomponent is executed through normal system operation the adversary’s code will be executed instead.  An\r\nadversary is likely to hijack objects that are used frequently enough to maintain a consistent level of persistence,\r\nbut are unlikely to break noticeable functionality within the system as to avoid system instability that could lead to\r\ndetection.”\r\n– Component Object Model Hijacking (T1122), Mitre ATT\u0026CK\r\nLet’s highlight a few COM Hijacking techniques…\r\nCOM Key Abandonment\r\nInprocServer32 and LocalServer32 (along with InprocServer and LocalServer) key-values are the references\r\npoints for the COM servers (e.g. DLLs, CPLs, EXEs, and OCXs).  After an attacker discovers a (vulnerable)\r\nreference, the attacker can drop a payload in place of the abandoned referenced path to the Portable executable\r\n(PE) under the right conditions (e.g. writable path).  That PE payload will simply load if called by an invoker (e.g.\r\nLoader or by program in execution that references the COM key)  as it attempts to instantiate the (potentially\r\nfalse) COM object under the CLSID entry point.  Let’s briefly revisit the VMware vmnetbridge.dll example\r\nfrom our previous post.\r\nIn this example, the use case is driven by COM keys that were left over (unregistered) by the VMware\r\nWorkstation uninstaller application.  After unning a recon script, we discovered that a LocalServer32 key path to a\r\nDLL that was previously removed.  An attacker can simply replace the binary to hijack the COM node structure as\r\ndemonstrated in the following screenshots:\r\nFigure 1: Abandoned COM Key Registry Path (Click Image to Enlarge)\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 2 of 17\n\nFigure 2: Abandoned COM Key File Path\r\nFigure 3: Abandoned Key Hijacking via Binary Reference Replacement \r\nCOM Key Override (Search Order Hijacking)\r\nOverriding a COM object is likely a more practical method for influencing a COM structure payload.  By adding\r\nthe proper registry keys in the HKCU Registry hive, keys located in HKLM are overridden (and ‘added’ to\r\nHKCR) when referencing the target COM object.  In this “SqibblyDoo” example provided by Casey Smith\r\n(@subTee), the “scripting.dictionary” COM program identifier (ProgID) is hijacked with a different class\r\nidentifier (CLSID) after importing the following registry import file:\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 3 of 17\n\nFigure 4: Registry File Containing the “Scripting.Dictionary” COM Override Keys\r\nEffectively, any program or script that instantiates the “scripting.dictionary” COM program or attempts to load the\r\nhijacked class identifier will invoke the payload.\r\nCOM Key Linking (with TreatAs)\r\nAnother way to influence alternate COM payload loading is with the TreatAs key, which effectively serves as a\r\nshortcut (or link) to another (unregistered) CLSID key.  Many (native) Windows programs have dangling\r\nreferences to non-existent registry CLSID nodes (*Note: These dangling references can be identified with the\r\nProcMon tool from SysInternals).  Depending on the CLSID key and program load, a properly hijacked CLSID\r\nnode structure with a TreatAs reference serves as its own loading technique if and when that CLSID key is\r\nreferenced (such as at program or script launch).  In essence, an attacker can take advantage of this by:\r\n1. Hijacking a program’s a) unreferenced COM CLSID path or b) legitimate path with the TreatAs key.\r\n2. Then linking that CLSID key structure with the TreatAs key to another (hijacked) COM CLSID key\r\nstructure that contains the malicious loader. \r\nLet’s take a look at the following example provided by Matt Nelson (@enigma0x3) and Casey Smith (@subTee). \r\nThis registry import file example is a part of Matt and Casey’s excellent Windows Operating System Archaeology\r\nresearch and presentation:\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 4 of 17\n\nFigure 5:  Windows Operating System Archaeology “TreasAs” Registry File\r\nIn Figure 5, two major CLSID nodes are created (that will override CLSID values from HKLM if such values\r\nexist).  If the {3734FF83-6764-44B7-A1B9-55F56183CDB0} CLSID key (orange) is referenced at any point (e.g.\r\nprogram load or any other invocation/load method), the TreatAs key will ‘redirect’ (e.g. act as a linked shortcut) to\r\nthe {00000001-0000-0000-0000-0000FEEDACDC} CLSID key (green) and invoke the respective payload.  The\r\nhigh level basic flows would look something like this when called by an invoker/loader:\r\n1 – Direct CLSID Node Reference\r\n[Invoker] -\u003e [CLSID Entry Point (key)] -\u003e [COM Server] -\u003e [Payload (e.g. Scrobj.dll Scriptlet)]\r\n2 – CLSID Node Reference with a TreatAs Key Linking\r\n[Invoker] -\u003e [1st CLSID Entry Point (key)] -\u003e [TreatAs Key Reference] -\u003e [2nd CLSID Entry Point (key)] -\u003e\r\n[[COM Server] -\u003e [Payload (e.g. Scrobj.dll Scriptlet)]\r\n*Note: This is a good place to give a shoutout to Jason Lang (@curi0usJack) from TrustedSec on the topic of\r\nidentifying and leveraging these unreferenced COM paths.  Jason did a great job covering this topic in the\r\nTrustedSec Purple Team training course at BlackHat 2018.  Also, Check out the blog post Beyond good ol’ Run\r\nkey, Part 84 by Adam (@Hexacorn) for a primer on TreatAs Instantiation Hooking.\r\nCLSID Loading Techniques for Evasion \u0026 Persistence\r\nNow, Let’s discuss a few techniques for evasive COM loading….\r\nProgram Reference Loader(s)\r\nAs highlighted in earlier sections of this blog post, script and programs that attempt to instantiate or call the class\r\nand/or program identifiers of a hijacked COM node will (likely) load the alternate payload at some point during\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 5 of 17\n\nexecution.  The art of overriding or linking to a malicious COM node pretty much comes down to a few factors:\r\nSuccessfully identifying and hijacking a (missing) reference that won’t negatively impact program\r\nbehavior (e.g. crash when a program is called).\r\nAccepting the risk of unintended consequences and choosing a COM node that likely won’t (greatly)\r\nimpact a system or user’s experience (e.g. nothing sticks out that a program or machine is “behaving\r\nincorrectly”).\r\nAlternatively, attempting to “patch” a hijacked path to resolve “program flow” (Note: this concept is\r\ninteresting and beyond the scope of this post)\r\nFor example, when we hijack the “scripting.dictionary” COM node with Casey Smith’s “SquibblyDoo” payload\r\nthen run WinRM, we can see the (un)intended consequences of this behavior when “scripting.dictionary” is\r\ninstantiated –\r\nFigure 6: Hijacked COM Node Loading with WinRM\r\n*Note: Not every hijacked path will cause (visible) programmatic failure.  There are many seamless, hijack-able\r\npaths that do not negatively impact program flow.  Some of these paths also qualify as stealthy persistence\r\ntechniques.\r\nRundll32 Invoker\r\nAs described in the previous post, one method for invoking a payload via the CLSID key (or PROGID) is by\r\nleveraging the lesser-known -sta (single threaded apartment) switch in rundll32 as follows:\r\nrundll32.exe -sta {CLSID}\r\n- or -\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 6 of 17\n\nrundll32.exe -sta ProgID\r\nThe -sta switch is not very well documented, but it does have utility and is a vector for potential abuse.  In the\r\nfollowing example, we leverage this technique to demonstrate direct and linked (“TreatAs”) COM loading as\r\ndescribed in an earlier section:\r\nFigure 7: Direct Key and Linked (“TreatAs”) COM Node Loading\r\nWe can also call our hijacked COM node by the Program Identifier (ProgID) with rundll32:\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 7 of 17\n\nFigure 8: Rundll.exe -sta execution by ProgID\r\nIn the context of AutoRuns logon persistence, the rundll32 command will not evade filters, but it can be deceptive\r\nby masking the hidden registry payload:\r\nFigure 8: Rundll32 -sta Logon Entry\r\nTask Scheduler for Persistence\r\nA few years ago, Matt Nelson (@enigma0x3) wrote about Userland Persistence with Scheduled Tasks and COM\r\nHandler Hijacking.  In his post, Matt describes a process for identifying interesting Scheduled Tasks that have an\r\naction set to “Custom Handler.”  When reviewing the XML schema file of the Scheduled Task, the “action\r\ncontext” is actually a “COM handler” represented by a CLSID.  After hijacking the CLSID structure, an actor can\r\nsimply supply a payload.  When the Scheduled Task is run (e.g. at logon), the malicious payload is executed.\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 8 of 17\n\nFigure 9: Schedule Task Configuration \r\nUserland Persistence with Scheduled Tasks and COM Handler Hijacking –\r\nby Matt Nelson (@enigma0x3)\r\nVerclsid Invoker\r\nVerclsid.exe is “used to verify a COM object before it is instantiated by Windows Explorer” (Microsoft Docs),\r\nwhich is quite interesting in its own context.  Nick Tyrer (@NickTyrer) demonstrates the following Verclsid usage\r\nin this Github gist:\r\nverclsid.exe /S /C {CLSID}\r\nRunning the previous command with the proper CLSID invokes the following payload in this example:\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 9 of 17\n\nFigure 10: Verclsid Execution by CLSID\r\nXwizard Invoker\r\nXwizard is another interesting way to load a CLSID node as documented by Nick Tyrer.  @harr0ey demonstrates\r\nusage of the following command that does not pop an error message:\r\nxwizard.exe RunWizard /taero /u {CLSID}\r\n*Note: Verclsid.exe has been used in a phishing malware campaign as documented in this post (Red Canary).\r\nCOM Server Misuse\r\nThere are many built-in Windows binaries that have the capability to ‘double’ as COM/DCOM servers under the\r\napplicable context for the intended service (such as remote machine management).  After proper invocation and\r\ninstantiation,  a D/COM applications exposes its properties and methods when called with the -Embedding switch\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 10 of 17\n\n[*better validation needed*].  However, an interesting “side effect” is that (many) COM-enabled applications that\r\nhave GUI/visible window components (e.g. mmc.exe, mspaint.exe, winword.exe, iexplore.exe, etc.) will run in a\r\nserver mode without presenting the GUI components.  Let’s take a look at an example use case where this\r\n*might* have some utility –\r\nUse Case: Microsoft Management Console (MMC)\r\nThe MMC utility may be a Windows system administrator’s best friend due it its extensibility and functionality. \r\nThe MMC allows a (power) user to add multiple management ‘snap-ins’ to locally and remotely manage Windows\r\nsystems.  The utility also provides an attack surface for *potential* misuse and abuse.  Early last year, Matt\r\nNelson (@enigma0x3) discovered that MMC exposes a method that can be used to facilitate remote command\r\nexecution over the DCOM protocol.  In his Lateral Movement using the MMC20.Application COM Object blog\r\npost, Matt describes the technique in greater detail.\r\nThough not nearly as exciting as the remote command execution/lateral movement technique, MMC can be used\r\nto invoke CLSID payloads for evasive loading and Run Key persistence.  Let’s setup our MMC console file to\r\ndemonstrate this example…\r\nMMC – CLSID Web Address Link\r\nFirst, we need to setup a CLSID link and save our configuration as a console file (.msc).  We can setup our basic\r\npayload by opening the MMC and the “Add/Remove Snap-In” window.  For simplicity, select “the Link to Web\r\nAddress” snap-in to open the wizard, and input the hijacked/reference CLSID key for the “Path or URL” as shown\r\nin the following screenshot:\r\nFigure 11:  MMC Add Snap-In – Web Address Link (Click Image to Enlarge)\r\nNext, create a name for the snap-in and select ‘Finish’ as shown in the following screenshot:\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 11 of 17\n\nFigure 12:  MMC Add Snap-In – Add Friendly Name (Click Image to Enlarge)\r\nThis will create our “test” menu item under the “Console Root.”  By selecting the “test” menu item, the CLSID\r\nlink will invoke accordingly.\r\nFigure 13:  MMC Snap-In – CLSID payload Launch Upon Selection\r\nMMC – MSC File Load\r\nWith our payload configuration created and enabled, let’s save the console as ‘test.msc’. Ensure that the snap-in\r\nlabel is selected (e.g. test) to preserve the console state.  If this is not selected, our payload will not invoke when\r\nwe attempt to open the console file later on.\r\nFor good measure,  we can open up the console file within a text editor to verify that the configuration and CLSID\r\npointer value –\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 12 of 17\n\nFigure 14:  MMC XML configuration\r\nWith this saved console file, let’s launch the msc file from the command line and invoke the CLSID payload in a\r\nhidden manner with the -Embedding flag (*Note: case is important) –\r\nmmc.exe -Embedding c:\\path\\to\\test.msc\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 13 of 17\n\nFigure 15:  MMC Hidden Launch with the -Embedding switch\r\nA Quick MMC Persistence Demo\r\nFrom an AutoRuns persistence perspective, mmc.exe will evade default filters because it is a Windows signed\r\nbinary as demonstrated in the following screenshot:\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 14 of 17\n\nFigure 16: MMC AutoRuns Run Key – Applied Filters (Click on Image to Enlarge)\r\nRemoving the filters, we now see the entry:\r\nFigure 17: MMC AutoRuns Run Key – No Filters (Click on Image to Enlarge)\r\nAt logon, this is the resulting payload execution with our hijacked key and reference:\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 15 of 17\n\nFigure 18: MMC Run Key – Logon Execution\r\nAll things considered, mmc.exe may not be the most effective use case.  However, other COM binaries may have\r\ngreater utility when invoked in a similar manner.\r\nDefensive Considerations\r\nIn a perfect world, a properly configured application whitelisting (AWL) solution with code integrity\r\nprotection would likely prevent (many of) these payloads from executing.\r\nMonitor for interesting COM application usage and run key additions.   The Embedding switch may be an\r\ninteresting indicator, but it has legitimate use cases for DCOM remote management and local instantiation\r\nif used in such context.  Properly invoked/instantiated COM applications should spawn from the Service\r\nHost (svchost.exe).  Any other invocation from another parent process may warrant suspicion.\r\nMonitor process creation events for interesting command line orientation and use of the afformentioned\r\nCLSID invokers.\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 16 of 17\n\nEvaluate newly created registry keys.  In particular, take note of additions that include TreatAs and/or\r\nScriptletURL keys.\r\nOther Notable Research\r\nCOM In 60 Seconds (Minutes) by James Forshaw (@tiraniddo) provides an incredible breakdown of how\r\nCOM works (I’m still watching this video over and over).  If you are not familar with James’ work, I\r\nencourage you to get acquainted ASAP 🙂\r\nNew lateral movement techniques abuse DCOM technology by PhilipTsukerman (@PhilipTsukerman)\r\nprovide a nice introduction to COM in addition to a great overview of DCOM lateral movement\r\ntechniques.\r\nCOM and the PowerThief by provides great background information on COM interaction with Internet\r\nExplorer.  Also, check out Rob’s  PowerThIEf tool for abusing Internet Explorer (IE) running instances.\r\nConclusion\r\nThank you for taking the time to read this post.  Stay tuned for the final part of this series where we will discuss a\r\nfew more advanced techniques!\r\n~ @bohops\r\nSource: https://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nhttps://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/"
	],
	"report_names": [
		"abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775433985,
	"ts_updated_at": 1775791255,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8fb1f47345a10fc5aa900d2b8a35d2f11f79b066.pdf",
		"text": "https://archive.orkl.eu/8fb1f47345a10fc5aa900d2b8a35d2f11f79b066.txt",
		"img": "https://archive.orkl.eu/8fb1f47345a10fc5aa900d2b8a35d2f11f79b066.jpg"
	}
}