Embargo Ransomware Brings Its Own EDR Killer — Default-Deny Blocks It First
A new Rust-based ransomware crew uses a custom loader and a "bring-your-own-vulnerable-driver" EDR killer to disable defenses before encrypting. Stopping unauthorized code from running short-circuits the whole playbook.
Date: October 23, 2024 Primary Source: ESET Research (WeLiveSecurity)

Executive Summary
- What: ESET documented tooling used by the Embargo ransomware group — a Rust loader (MDeployer) and a custom EDR killer (MS4Killer) — that disables security software before the ransomware encrypts.
- Who is affected: Windows and Linux environments; ESET observed U.S. companies among the targets, with the group running its own victim-communication infrastructure.
- Severity: High — a well-resourced crew that invests specifically in defeating endpoint defenses prior to encryption.
- Action required: Don't rely solely on the EDR that this toolkit is built to disable. Add a default-deny execution layer so the loader, EDR killer, vulnerable driver, and encryptor cannot run unless approved.
Overview
On October 23, 2024, ESET Research published an analysis of new tooling leading to deployment of Embargo ransomware. (WeLiveSecurity) Embargo is a relatively new group — first observed by ESET in mid-2024 — that writes its ransomware and supporting tools in Rust for cross-platform reach across Windows and Linux. (ESET Newsroom)
The notable part is not just the encryptor; it is the pre-encryption toolkit. ESET named two components: MDeployer, a loader that decrypts and runs the next stages, and MS4Killer, an endpoint-detection-and-response (EDR) killer that is custom-compiled per victim to terminate only the security products present in that environment. (WeLiveSecurity) Together they reflect a clear trend: ransomware crews increasingly treat "disable the defenses first" as a dedicated phase of the attack.
The defensive lesson is straightforward. A toolkit designed to disable detection is far less useful if the unauthorized executables that do the disabling are never allowed to run. That is the premise of White Cloud Security (WCS) Trust Lockdown.
Threat Summary
| Field | Detail |
|---|---|
| Threat actor | Embargo ransomware group |
| Public research | October 23, 2024 (ESET) |
| Tooling | MDeployer (loader), MS4Killer (EDR killer); Rust-based |
| Key technique | BYOVD (bring-your-own-vulnerable-driver) for kernel-level process termination; Safe Mode abuse |
| Affected platforms | Windows and Linux |
| Targeting | U.S. companies observed among victims |
| Exploited in the wild | Yes |
| Patch available | N/A — execution-control problem; keep vulnerable drivers patched/blocked |
Technical Analysis
How the Attack Works
Based on ESET's research, the pre-encryption chain works roughly as follows: (WeLiveSecurity)
- Loader stage (MDeployer). Decrypts and executes the EDR killer and the ransomware payload from encrypted cache files; can reboot the system into Safe Mode, where most protections are not active, and establishes a service to continue execution after reboot.
- Defense evasion (MS4Killer). Continuously scans for running processes and terminates targeted security products. It uses BYOVD — abusing a signed but vulnerable kernel driver to gain kernel-level code execution — and is custom-compiled for each victim to target only their specific security tools.
- Encryption. With defenses disabled, the Rust ransomware payload encrypts files.
Payload and Impact
By neutralizing endpoint defenses first, the group increases the odds that encryption completes before anyone can respond. The custom-per-victim EDR killer also makes signature-based blocking harder, because the binary differs between environments. The result is a faster, quieter path from intrusion to encryption — and a tougher cleanup.
Why Traditional Defenses Struggle
- The toolkit targets EDR itself. A defense designed to be turned off cannot be the only safeguard.
- BYOVD abuses signed drivers. The vulnerable driver is legitimately signed, so naive signature trust does not help.
- Per-victim compilation changes hashes, blunting signature- and reputation-based detection.
- Safe Mode strips away many protections at exactly the moment the attacker needs them gone.
How White Cloud Security Trust Lockdown Stops This
WCS Trust Lockdown enforces a default-deny, Zero-Trust App Firewall: nothing executes unless it has been explicitly Approved by application, publisher/certificate, handprint, and approved parent-child relationship.
| Attack step | How WCS would help |
|---|---|
| MDeployer loader executes | An unapproved loader would be denied before it can stage the next components |
| MS4Killer EDR killer runs | A custom, unapproved executable would be prevented from running, even if compiled uniquely per victim |
| BYOVD vulnerable driver loaded | An unapproved driver would be denied, helping contain the kernel-level technique the EDR killer depends on |
| Ransomware payload launches | The unknown encryptor would be blocked — no signature or family name required |
Because WCS identifies approved software by handprint (SHA-1, SHA-256, SHA-512, MD5, CRC32, and file length), a per-victim recompiled MS4Killer would still be denied rather than slipping past name- or hash-based checks. WCS also would give administrators visibility into blocked applications, surfacing the loader/killer attempts for review.
Scope, stated plainly: WCS would help block the unauthorized loader, EDR killer, and encryptor, and would contain the risk of unknown software introduced during the intrusion. It does not replace EDR, driver/OS patching, or backups — it complements them, and it is specifically valuable against a toolkit whose entire purpose is to disable EDR.
At White Cloud Security, we continue to track and report new hacking methods and tools — not just because of its immediate threat, but because patterns of reuse often expose the playbooks of these cybercriminal groups.
Recommended Mitigations
- Add a default-deny execution layer so loaders, EDR killers, and encryptors cannot run unless approved.
- Enable vulnerable-driver blocklists (e.g., Microsoft's recommended driver block rules) to hinder BYOVD.
- Restrict and monitor Safe Mode reboots and the creation of new auto-start services.
- Keep EDR tamper protection enabled and alert on security-process termination.
- Maintain tested, offline/immutable backups.
Indicators of Compromise
Source: ESET WeLiveSecurity. Treat IOCs as a complement to execution control, not a substitute. (WeLiveSecurity)
| Indicator | Type |
|---|---|
dtest.dll, fxc.exe, fdasvc.exe |
MDeployer loader file names |
praxisbackup.exe |
MS4Killer file name |
pay.exe, win32.exe |
Embargo ransomware file names |
SHA-1 A1B98B1FBF69AF79E5A3F27AA6256417488CC117 |
dtest.dll |
SHA-1 8A85C1399A0E404C8285A723C4214942A45BBFF9 |
pay.exe |
Key Takeaways
- Ransomware crews now budget for disabling defenses. Embargo ships a dedicated loader and EDR killer.
- A defense built to be turned off can't stand alone — pair EDR with default-deny execution control.
- Handprint identity denies per-victim recompiled tooling that defeats signatures.
- Block vulnerable drivers to undercut BYOVD, and keep tamper protection on.
References
- ESET WeLiveSecurity — Embargo ransomware: Rock'n'Rust (WeLiveSecurity)
- ESET Newsroom — New ransomware group Embargo uses toolkit that disables security solutions (ESET Newsroom)
- BankInfoSecurity — Embargo Ransomware Disables Security Defenses (BankInfoSecurity)