Scriptlet from remote URL
regsvr32 /i:<url> — the "Squiblydoo" technique. regsvr32 fetches a remote COM scriptlet and executes the script inside it, so code runs from a URL with…
What it detects
regsvr32 /i:<url> — the "Squiblydoo" technique. regsvr32 fetches a remote COM scriptlet and executes the script inside it, so code runs from a URL with no file ever written to disk and no unsigned binary ever loaded. Application control that trusts signed Microsoft binaries permits it.
The rule keys on the /i: + URL combination rather than on regsvr32 itself, because the technique is routinely run from a RENAMED copy of regsvr32 — a real capture in our benchmark corpus invokes it as jabber.exe, where any process-name rule fails. /i: followed by a URL is meaningless outside this technique.
MITRE ATT&CK mapping
- T1218.010System Binary Proxy Execution: Regsvr32· Defense Evasion
False positives and triage
No legitimate use observed. Registering a real COM object uses a local file path, not a URL, and does not need /i: at all in the common case.
To confirm: the URL is the payload location — resolve it and preserve it as evidence before it is taken down; raw-paste and file-sharing hosts are typical. Check for outbound connections to that host from the same process, and note the image name: if it is NOT regsvr32.exe, the operator renamed the binary to evade detection, which raises confidence rather than lowering it.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 90%. Source: rules/windows/scriptlet_from_remote_url.yaml, licensed under the Apache License 2.0.
id: windows.execution.scriptlet_from_remote_url
version: 1.0.0
status: stable
severity: critical
confidence: 0.9
platforms: [windows]
mitre_techniques: [T1218.010]
description: |
`regsvr32 /i:<url>` — the "Squiblydoo" technique. regsvr32 fetches a remote COM
scriptlet and executes the script inside it, so code runs from a URL with no file
ever written to disk and no unsigned binary ever loaded. Application control that
trusts signed Microsoft binaries permits it.
The rule keys on the `/i:` + URL combination rather than on regsvr32 itself,
because the technique is routinely run from a RENAMED copy of regsvr32 — a real
capture in our benchmark corpus invokes it as `jabber.exe`, where any process-name
rule fails. `/i:` followed by a URL is meaningless outside this technique.
match:
command_line_regex: '(?i)/i:\s*"?(https?|ftp)://'
correlation_keys: [hostname, user_name]
false_positive_guidance: |
No legitimate use observed. Registering a real COM object uses a local file path,
not a URL, and does not need `/i:` at all in the common case.
To confirm: the URL is the payload location — resolve it and preserve it as
evidence before it is taken down; raw-paste and file-sharing hosts are typical.
Check for outbound connections to that host from the same process, and note the
image name: if it is NOT regsvr32.exe, the operator renamed the binary to evade
detection, which raises confidence rather than lowering it.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.