Monitoring 'Trusted' Tools: 45 Days of Data on Living-Off-The-Land
Saw the write-up on Hacker News regarding Bitdefender's 45-day analysis of internal tooling. It reinforces a harsh reality: our biggest risk isn't some novel zero-day, it's the administrative utilities we blindly trust every day.
The report highlights how tools like PowerShell, WMIC, Certutil, and MSBuild are the modern attacker's toolkit. The challenge isn't detecting the software—it's detecting the intent. To an EDR, a certutil -urlcache command looks like a certificate import until you check the destination IP or the file hash.
We've started aggressively auditing Script Block Logging on our endpoints to catch obfuscated PowerShell. If you aren't logging this, you're essentially flying blind to pass-the-hash or encoded command attacks. Here is the registry setting we enforce via GPO to ensure we capture those blocks:
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name "EnableScriptBlockLogging" -Value 1
On the SIEM side, we are hunting for "impossible" admin combos. For example, seeing `msbuild.exe` (a developer tool) being spawned by `winword.exe` (a word processor) is a massive red flag.
How are you guys handling the noise from these trusted binaries? Are you moving to block specific LOLBins outright, or are you relying entirely on behavior analytics?
We tried blocking mshta.exe and certutil.exe entirely, and the helpdesk phones melted. It turns out a lot of legacy LOB apps use them for weird things. We moved to strict allow-listing instead. If a user needs certutil, they have to request a temporary exception via a specific ticket queue. It adds friction, but it killed the alert noise significantly. We also correlate the command line arguments—if it's not using a standard flag, it triggers a high-severity alert.
Exactly why I tell clients not to rely solely on antivirus signatures. If I can get an initial foothold via phishing, I don't need malware. I'll use your own regsvr32 to register a malicious COM object and execute a script. It's authorized code running in an authorized context. The only reliable defense I've seen in these audits is strict user privilege management. If the user account doesn't have admin rights, wmic can't do much damage anyway.
This is the "Living off the Land" (LoL) problem in a nutshell. We've started implementing PowerShell Constrained Language Mode for general users. It blocks access to the .NET framework and COM objects directly via PowerShell, stopping a lot of the execution chains. It breaks some things, so we had to create an AppLocker exception path for our actual IT admins who need full language mode. It's a pain to manage, but it contains the blast radius effectively.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access