Product · 5 MIN READ · JAKE GODGART · JUN 20, 2025 · TAGS: AI & automation
TL;DR
- This auto remediation series focuses on understanding the functionality of all of Expel’s auto remediations
- The “delete malicious file” response action enables the Expel SOC to permanently remove a confirmed malicious file—what we call a threat artifact—directly from an affected host, using the EDRs and security tools you already have
- You can find blogs on our other auto remediations as well: Kill process, contain host, block bad hash, delete registry key, disable user account, reset credentials, terminate session, disable access key, and remove malicious email
In incident response, containing or stopping an attack is only half the battle. When an attacker gets into your environment, they leave tools and artifacts behind. A script, a payload, a backdoor, a configuration file—these don’t just disappear when you kill the malicious process.
Leaving these threat artifacts behind is like letting a burglar leave their lockpicks and crowbar on your porch. The risk of re-infection is a real danger if a persistence mechanism finds and re-executes the file. These artifacts can also interfere with future forensic analysis or even fail a compliance audit.
This is where the delete malicious file action becomes essential. It’s the direct, no-nonsense way to clean a specific piece of the infection off the host and move from containment to true eradication.
Before we get into the auto remediation action, it’s important to understand how deleting a malicious file fits into the sequence of other critical host-based actions an analyst might take. Each has a specific purpose, scope, and strategic value. Here’s how they compare:
| Auto remediation | Primary goal | Scope | When to use it |
|---|---|---|---|
|
Contain host |
Stop lateral movement | A single host’s network connectivity | Use this to put a “bubble” around a compromised host. It prevents the attacker from spreading to other systems while you investigate. |
|
Kill process |
Stop active malicious behavior | A specific running process on a host | This is the emergency brake. Use it to immediately halt what a malicious program is doing (e.g., encrypting files, exfiltrating data). |
|
Block bad hash |
Prevent future execution, environment-wide | All hosts managed by the EDR | This is a preventative measure. You’re teaching your entire immune system (the EDR) to never let this known bad file run again, anywhere. |
|
Delete malicious file |
Permanently remove a threat artifact | A specific file on a host’s filesystem | This is the clean up step. After the immediate danger is over, you use this to remove the attacker’s tool from the host so it can’t be used again. |
How it works
Let’s walk through a more advanced, real-world scenario.
The initial detection
At 2:15am on a Monday, your EDR generates a high-severity alert on a user’s workstation. The alert is for “Execution of a Known Malicious Executable,” mapping to MITRE ATT&CK Technique T1204.002 (Malicious File). The process, (CredHarvest.exe) was immediately blocked by the EDR’s prevention policy before it could do significant damage—a great first step.
The analyst investigation
An Expel analyst sees the alert in Expel Workbench™ within minutes. The immediate threat is stopped, but the investigation is just beginning. The analyst asks: “How did it get there, and did it leave anything else behind?”
The analyst pivots to your EDR console and examines the parent process of CredHarvest.exe, only to find that it launched from a zip file the user downloaded from their personal webmail. Looking at other activity from that process, the analyst discovers that in the few seconds before it was blocked, the executable managed to write two other files to the user’s AppData\Local\Temp directory: a DLL file named authlib.dll and a configuration file named c.dat.
Analyzing the remnants
This is where human expertise comes in handy. The analyst extracts these two new files for analysis and finds:
- The authlib.dll file is a secondary payload. Its purpose is likely to establish persistence by being loaded by a legitimate application (a technique like DLL side-loading).
- The c.dat file contains a Base64-encoded string, which, when decoded, reveals a command-and-control (C2) IP address. This allows the attacker to update their instructions without having to recompile and redeliver the entire malware package.
These are the remnants—the breadcrumbs we need to sweep up. The analyst confirms these artifacts are tied directly to the banking trojan’s operation.
After checking that you’ve approved the delete malicious file auto remediation, our workflow kicks off to command the EDR to delete both authlib.dll and c.dat, ensuring the trojan is fully eradicated from the system.
When to expect Expel to use the delete malicious file auto remediation
Our SOC uses this action (with your approval) during the eradication phase of incident response. Expect to see it in these cases:
- Malware remnants cleanup: This is the most common use case. After a primary malware executable is killed or quarantined, we hunt for and delete the leftover malicious files it created—configuration files, temporary files, droppers, or secondary payloads.
- Confirmed malicious downloads: Deleting a file a user downloaded (from a phishing email or a drive-by download, for example) that’s been definitively identified as malware (often after being analyzed in a sandbox).
- Eradication of attacker tools: Removing specific tools an attacker deployed onto a compromised system. This includes not just explicitly malicious tools, but also legitimate administrative utilities an attacker might use to “live off the land,” like PsExec.exe or AdFind.exe, when found in a suspicious context.
- Web shell removal: When a WebShell (like a .php or .aspx file) is discovered on a web server, deleting the file is the most critical step to remove the attacker’s interactive access.
Ultimately, deleting these files ensures malicious code can’t be re-activated, leaving the endpoint in a cleaner, more secure state.
The delete malicious file auto remediation workflow
Here’s the step-by-step breakdown of how this works when we find a malicious file that needs to go.
1. Detection & identification
An EDR alert fires or an analyst uncovers a malicious file during an investigation. The full file path, name, and hash are logged in Workbench.
Example: Following a block bad hash action on CredHarvest.exe, our analyst discovers authlib.dll and c.dat in C:\Users\jdoe\AppData\Local\Temp\.
2. Validation & context
Our analyst rigorously confirms the file is malicious and, critically, that it’s safe to delete. This isn’t just a quick hash lookup. The checklist includes:
- Checking the file hash against multiple threat intelligence sources (like VirusTotal and our own).
- Reviewing the file’s properties: (Is it signed? Is the signer legitimate?)
- Analyzing its prevalence in your environment: Is this file on hundreds of machines as part of a legitimate application, or is it only on this one host?
- Verifying it’s not a critical operating system file or a known-good application file.
Example: The analyst verifies the hashes of the DLL and config file are directly associated with the banking trojan, serve no other purpose, and aren’t part of any legitimate software in your environment. They are confirmed as safe to remove.
3. Customer approval check
The analyst checks in Workbench to see if you’ve opted into the delete malicious file auto remediation. Your control is granular—you can approve this action for standard workstations, but require manual approval for critical servers. We check your preferences every time.
4. Execution
With the threat validated and the auto remediation customer-approved, the analyst initiates the command via Workbench. Our platform communicates via API with your EDR, which instructs the agent on the endpoint to delete the file.
Example: The analyst triggers the delete malicious file command for the two files via the EDR.
Real-world check: If a file is currently locked by a running process, the deletion might fail or be deferred until the next reboot. In these cases, the proper procedure is to kill the locking process first, then issue the delete command. Our analysts know how to handle this sequence of operations.
5. Confirmation
We watch for the confirmation from the EDR showing the files were successfully deleted, which is also logged in Workbench for a full audit trail. The job isn’t done, though. The analyst’s investigation continues to ensure the threat is fully scoped. Were credentials compromised before the trojan was blocked? Did it communicate with its C2 server? Deleting the file is one step in the larger process of ensuring your environment is secure.
How to set it up
If you’re already a customer, you can learn more (and configure this auto remediation) in Workbench. It usually just requires making sure your EDR integration is set up correctly, and defining the scope for the action.
We recommend a phased approach: start with manual approval, and once you’re comfortable, enable automation for lower-risk systems like standard user workstations. Get in touch with your Expel account expert, and they can walk you through it.
Not a customer yet? If you like the sound of no-nonsense, transparent remediation that uses the tools you already own, let’s talk.
