Skip to content

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)

Embargo ransomware EDR killer — White Cloud Security Trust Lockdown default-deny would help block the loader, EDR killer, and encryptor before they run


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)

  1. 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.
  2. 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.
  3. 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.

Embargo attack flow: MDeployer loader to MS4Killer EDR killer via vulnerable driver, then ransomware encryption


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.

Default-Allow security versus White Cloud Security Zero-Trust default-deny application control against the Embargo toolkit


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.

How White Cloud Security Trust Lockdown denies the Embargo loader, EDR killer, and encryptor before they run


  • 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

  1. ESET WeLiveSecurity — Embargo ransomware: Rock'n'Rust (WeLiveSecurity)
  2. ESET Newsroom — New ransomware group Embargo uses toolkit that disables security solutions (ESET Newsroom)
  3. BankInfoSecurity — Embargo Ransomware Disables Security Defenses (BankInfoSecurity)

Further Reading