Product · 5 MIN READ · JAKE GODGART AND CLAIRE HOGAN · JUN 12, 2025 · TAGS: AI & automation
TL;DR
- This auto remediation series focuses on understanding the functionality of all of Expel’s auto remediations
- The “block bad hash” response action enables the Expel SOC to block potentially malicious processes and files based on their hash values
- You can find blogs on these auto remediations as well (post-publication): Kill process, contain host, delete malicious file, delete registry key, disable user account, reset credentials, terminate session, disable access key, and remove malicious email
A common tactic for cyber adversaries is to reuse malware or components they know have worked before. If they can get a malicious file onto one machine, they’ll often try to use it elsewhere (or just try again later) if their initial attempt is cleaned up.
This is where response actions like block bad hash come in. It’s about drawing a clear line in the sand: “This specific file is bad. Don’t let it run. Anywhere.” It prevents known threats from executing, stops malware spread or re-infection, and gives everyone—your team and ours—breathing room and a more secure footing to investigate the bigger picture without worrying about the specific file causing more trouble.
Our analysts can trigger our block bad hash workflow using the EDRs and security tools you already have, like Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne, and others we plug into. Nearly all these modern EDR platforms support blocking files based on their cryptographic hashes (MD5, SHA1, or, most commonly, SHA256) via public API.
Blocking bad hashes (which may be referred to by different vendor technologies as application blocking, banning hashes, blacklisting hashes, or indicator-based file blocking) prevents further propagation of an attack by blocking potentially malicious processes and files by their hash values.
How it works
Picture this: A user falls for a fake captcha, prompting them to run commands on their system. This command initiates the download of totally_legit_invoice.msi, an obfuscated JavaScript file that, once executed, leverages the Latrodectus loader to establish a foothold to prepare for malicious activity. Maybe your EDR catches it right away, or maybe we spot it during an investigation after it makes some suspicious network calls.
Once our SOC analysts have validated this activity as a threat, they’ll create an incident and apply a block bad hash remediation via Expel Workbench™. If you’ve given us the green light to auto-remediate, the block bad hash action will kick off automatically using your team’s EDR to prevent the specific totally_legit_invoice.msi from executing anywhere else in your environment.
Typically, this is triggered when we see indicators like:
- High-confidence alerts from your EDR identifying known malware by its hash.
- Malicious files discovered by our analysts during an investigation or threat hunt (like a dropper, payload, or tool used by an attacker).
- Threat intelligence indicating a specific file hash is part of an active campaign targeting your industry.
Blocking a bad hash is like putting a known criminal’s mugshot and fingerprints on a No Entry list at every door and checkpoint in your entire organization. It’ll be automatically stopped at any entry by your security—no ifs, ands, or buts.
When to expect Expel to use the block bad hash auto remediation
Here are some common situations where our analysts will use this response action:
- Responding to known malware variants (ransomware, infostealers, RATs) identified by their hash.
- Preventing the execution of malicious droppers or payloads delivered via phishing or downloaded from sketchy sites.
- Blocking known hacker tools identified on an endpoint.
- Stopping the spread of a malicious file laterally within your network.
- As a containment step during an active incident, to neutralize a specific malicious file quickly across all systems.
- Proactively blocking hashes identified from reliable threat intelligence feeds before they hit you.
When it happens, you’ll see it in Workbench. For instance, you’ll notice on your incident an alert when a bad hash is successfully blocked, shown below.
The path to termination: the block bad hash auto remediation workflow
Here’s the play-by-play for how block bad hash works, with the example of an attacker trying to deploy a known malware tool.
1. Detection
Something trips an alarm. Maybe your EDR flags EvilTool.exe on a workstation, or our analyst uncovers it during an investigation into suspicious PowerShell activity. The alert and the associated file hash land in Workbench.
Example: Microsoft Defender for Endpoint detects a file with SHA256 hash e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 (a known variant of Mimikatz) attempting to run.
2. Validation & context
Our SOC analyst grabs the alert. They confirm the file is indeed malicious by checking its reputation against multiple threat intel sources (like VirusTotal and our own intel), its observed behavior, and its possible role in your environment. While automation and AI can take on the brunt of the low-value work, we still use humans to confirm it’s truly bad and safe to block.
Example: The analyst verifies the hash is widely recognized as malicious, associated with credential theft, and not a component of any legitimate software used in your environment.
3. Customer approval check
The analyst wants to take action. They’ll use Workbench to check if you’ve opted into the block bad hash auto remediation action. After all, it’s your environment, your rules. You can decide the automated response actions you’re comfortable with us taking on your behalf. Maybe you want all confirmed malware hashes blocked automatically, or maybe only for certain types of threats or on specific endpoint groups.
Example: Your organization has pre-configured the block bad hash auto remediation action for any file identified as confirmed malware by Expel analysts.
4. Execution
Threat confirmed, permission checked. Our SOC analyst hits the button in Workbench to unleash the block bad hash auto remediation workflow. Workbench talks to your EDR, instructing it to add the malicious hash to its prevention list. This command is then pushed out by the EDR. If it’s a clear-cut case, this happens fast—think seconds to minutes for the rule to propagate.
Example: The analyst triggers the block bad hash command for SHA256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 via CrowdStrike Falcon through Workbench.
5. Confirmation
We watch to make sure the EDR accepts the command and the hash is now on the blocked list. Everything is logged in Workbench (and in your EDR console, too) so you see exactly what happened, when, and why. Full transparency. Any future attempt to execute the file on any protected endpoint should now be blocked automatically by your EDR (until the hash is unblocked either by API or within the EDR tool).
Example: The EDR confirms the hash is blocked. The analyst documents the action in Workbench and continues investigating the initial alert to see how EvilTool.exe got there, and what it did before it was blocked.
How to set it up
If you’re an Expel customer, you can easily learn more about the block bad hash auto-remediation and set it up for your environment in Workbench. It usually involves ensuring your EDR integration is set up correctly, and defining your desired scope and parameters for this action. Reach out to your Expel account expert and they can walk you through it.
Not an Expel customer yet, but like the sound of no-nonsense auto remediation, leveraging the tools you already own? Let’s talk. We’ll show you how we make your existing security stack work harder for you, cutting down on response times and making your life easier.
We’ll be back to break down more of Expel’s auto remediations. Stay tuned.
