Regsvr32.exe registers and unregisters object linking and embedding controls, including DLLs, on Windows. The binary may be signed by Microsoft and is used all the time for normal operations. MITRE ATT&CK tracks its abuse as T1218.010, Regsvr32, in the Stealth tactic. The platform is Windows.
How attackers use it
MITRE gives three reasons adversaries like it.
First, normal use is common. Malicious runs may avoid triggering security tools that do not monitor regsvr32.exe or the modules it loads, because of allow lists or false positives from Windows using it legitimately.
Second, it can bypass application control. It has functionality to load COM scriptlets that run DLLs under user permissions. Since Regsvr32.exe is network and proxy aware, scripts can be loaded by passing a URL to a file on an external web server. This variant makes no changes to the registry, because the COM object is not actually registered, only executed. It is often called Squiblydoo, and MITRE says it has been used in campaigns targeting governments.
Third, Regsvr32.exe can also register a COM object used to establish persistence through Component Object Model Hijacking.
Why defenders miss it
Think about what your telemetry sees. A signed Microsoft binary starts, makes a web request, and runs something. If your rules treat regsvr32 as noise, none of that stands out. The registry stays clean in the URL form, so tools that wait for a registration event never fire.
How to detect it
The MITRE strategy focuses on regsvr32 executions that differ from normal administrative or system use. It lists these observations:
- Regsvr32 loading scriptlets or DLLs from unusual paths, especially temporary directories or remote URLs
- Command line arguments using the install or uninstall switches with suspicious file references
- Network connections started by regsvr32.exe
- Unsigned or untrusted DLLs loaded shortly after regsvr32 starts
The correlated sequence is process creation of regsvr32.exe, then the module load of a DLL or scriptlet engine, then optional outbound network traffic.
In terms of data:
- Process creation with command lines (Sysmon event ID 1 or Security event 4688).
- Network connections by regsvr32.exe (Sysmon event ID 3). Most legitimate runs have none.
- Image loads (Sysmon event ID 7), to catch script engines or unsigned DLLs.
- Registry writes to COM class keys (Sysmon event ID 13), for the persistence variant.
Tuning
Build a short list of what your software installers register and where they run from. A run from Program Files during an install is expected. A run with a web address, or with a path under a temp folder or a user profile, is not. Flag the second group.
How to reduce the risk
MITRE lists exploit protection and execution prevention steps for this technique.
- Use Attack Surface Reduction features to block regsvr32.exe from being used to bypass application control.
- Use application control such as Windows Defender Application Control, AppLocker or Software Restriction Policies to identify and block potentially malicious software run through regsvr32.
Because regsvr32 is needed for some legitimate installs, you may not be able to block it outright. In that case, constrain how it behaves. Block egress from regsvr32.exe at the host firewall, and restrict where DLLs and scriptlets may be loaded from.
Check your own environment
- Can regsvr32.exe reach the internet from your workstations today?
- Do you log command lines for every process creation?
- Does your application control treat regsvr32 as an unconditional allow?
- Do you have alerts on COM class registry changes in user writable hives?
This read-only PowerShell command lists recent process creation events that mention regsvr32, if command line auditing is on:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 500 | Where-Object { $_.Message -match 'regsvr32' } | Select-Object TimeCreated, Message
This one shows whether process creation auditing is enabled (cmd.exe):
auditpol /get /subcategory:"Process Creation"
What good looks like
For regsvr32, a good setup is one where you know the normal pattern. Installers run it from known paths, almost never with a network connection, and almost never with a URL. Anything else produces an alert with the process tree attached. Application control restricts which modules can load, the host firewall stops its egress, and logs from all of this land in one place where an analyst can read the chain in a few minutes.
Quick check
Why does the Squiblydoo variant leave no registry changes?
The COM object is not registered. The scriptlet is only executed, so there is nothing to write to the registry.
Which regsvr32 behavior is the strongest network signal?
Any outbound connection started by regsvr32.exe, since normal runs generally do not need one.
What can you do if you cannot block regsvr32.exe?
Limit what it can do: block its egress traffic, enforce application control on the modules it loads, and alert on runs from unusual paths or with remote references.
Sources
- MITRE ATT&CK, T1218.010: https://attack.mitre.org/techniques/T1218/010
