Why did RansomHub matter in 2024?
Answer first: volume and affiliate quality. After ALPHV/BlackCat's apparent exit-scam in early 2024 and LockBit's takedown in Operation Cronos, many experienced affiliates needed a new home. RansomHub positioned itself as an affiliate-friendly RaaS, reportedly offering affiliates a 90/10 split with the affiliate collecting first, and absorbed a notable share of displaced operators. A joint CISA/FBI/HHS/MS-ISAC advisory (AA24-242A) formally described RansomHub's tactics and named it as responsible for attacks across more than 210 victims spanning critical infrastructure sectors as of that advisory's publication.
That advisory is the baseline source for almost every specific claim below. Where public incident reporting disagrees, I default to the CISA document.
What is the RansomHub kill chain in practice?
Per the joint advisory and subsequent vendor reporting from firms like Sophos and Trend Micro, a representative intrusion looks like:
- Initial access via phishing, valid credentials purchased from an access broker, or exploitation of known CVEs. Documented exploited CVEs include Citrix NetScaler (CVE-2023-3519), Fortinet FortiOS (CVE-2023-27997), and Apache ActiveMQ (CVE-2023-46604), among others.
- Reconnaissance using AngryIPScanner, Nmap, and native Windows utilities.
- Credential access via Mimikatz or LSASS dumping.
- Lateral movement using RDP, PsExec, AnyDesk, Atera, Splashtop, or other remote-management tools the victim already permits.
- Defense evasion including disabling or uninstalling EDR using a BYOVD (Bring Your Own Vulnerable Driver) tool. The tool most often associated with RansomHub affiliates is EDRKillShifter, first publicly described by Sophos in 2024.
- Exfiltration to cloud storage or attacker infrastructure, followed by encryption of on-disk data.
- Double extortion: a leak-site countdown while negotiating the decrypt.
The playbook is not novel. The operational tempo and affiliate skill were.
How does EDRKillShifter actually work?
EDRKillShifter is a loader that drops a legitimately signed but known-vulnerable driver to disk, loads it, and uses the driver's kernel primitives to terminate protected processes including EDR agents. This is classic BYOVD. Microsoft maintains a vulnerable driver blocklist, and recent Windows versions ship with it enforced by default for HVCI-enabled systems, but coverage in the field lags because:
- Many enterprise endpoints are not HVCI-enabled due to legacy driver conflicts.
- The blocklist is only as good as its latest update and the signing certificates it revokes.
- Attackers rotate which vulnerable driver they use.
If the attacker can load a kernel driver, they win the user-mode EDR fight. Your control point has to be earlier.
Why is this an "EDR bypass" story and not just another ransomware story?
Because 2024 was the year enterprise defenders had to admit that EDR alone is insufficient against tier-one affiliates. RansomHub's use of EDRKillShifter, combined with its affiliates' comfort abusing remote-management agents and valid accounts, meant that classic endpoint alerts often fired after encryption was already underway, or not at all.
The engineer's takeaway: EDR is necessary, not sufficient. You need complementary signal from identity, network, and logs that cannot be tampered with by a local admin.
What defensive controls actually work against this tradecraft?
- Enforce the Microsoft Vulnerable Driver Blocklist and verify enforcement via telemetry, not just policy. Systems running without HVCI should be inventoried as a risk, not assumed compliant.
- Application control on remote-management tooling. Atera, Splashtop, AnyDesk, and ScreenConnect should be allowlisted by host, not tolerated anywhere. This is among the highest-leverage controls because multiple RaaS affiliates depend on these.
- Restrict local-admin sprawl. EDRKillShifter and nearly every BYOVD tool requires local admin or SeLoadDriverPrivilege. Every endpoint user who does not need local admin is a closed door.
- Patch the usual-suspects edge gear. Citrix NetScaler, Fortinet VPNs, Ivanti ICS, and F5 BIG-IP have all been initial-access staples. Your MTTR on these CVEs should be measured in days.
- Harden PowerShell, WMI, and lateral-move vectors with AppLocker or WDAC policies and with script block logging piped to a SIEM.
- Segment backup infrastructure so that the domain admin who gets compromised in the crypto phase cannot reach your immutable backup tier. Offline or object-locked backups are table stakes.
How does initial access land, and what can you cut off cheaply?
Most RansomHub intrusions I have seen reported publicly begin with one of three things: a phished SSO credential without phishing-resistant MFA, a purchased access listing from an initial-access broker, or an unpatched edge device. Cheap wins:
- Phishing-resistant MFA on SSO and VPN. FIDO2 or device-bound passkeys.
- Automated credential-leak monitoring against your corporate domains so you can force rotate when credentials appear on forums.
- Aggressive patching SLAs on internet-exposed appliances with a specific carve-out for "CISA KEV list" that bypasses normal change windows.
None of these are new. All of them are still commonly underimplemented.
How should incident response change when you know you are facing RansomHub-class tradecraft?
- Assume EDR is compromised on the first suspect host. Pull telemetry from centrally-collected logs and network sensors, not the endpoint.
- Isolate at the identity layer first. Disable tokens and sessions for suspected compromised users in the IdP before you start powering off machines. Otherwise, the attacker re-auths via another host.
- Rotate remote-management tenant credentials immediately. If Atera or ConnectWise tooling was in use, assume the attacker holds those tenant-side keys and is watching for your response.
- Preserve backups under a separate credential domain. The single most common way ransomware events turn into payment decisions is because backups were reachable from the primary AD.
What is the long-term outlook?
Affiliate programs will churn. Brands will rebrand. The underlying tradecraft - access-broker purchases, EDR-killer tooling, remote-management abuse, double extortion - is the stable thing. Defenders should architect against the tradecraft, not the brand, because the next "RansomHub" will look structurally similar. Law-enforcement disruption helps at the margins but has not dented the affiliate economy durably enough to change 2026 posture.
What does the supply chain angle add to this threat?
Answer first: a lot, because RansomHub affiliates explicitly shop for access into vendors that hold many downstream customer relationships.
Public RansomHub victims have included IT services providers, software vendors, and managed service organizations with customer tenancies embedded in the victim's own systems. When one of these goes down, extortion leverage compounds: the ransom cost is not just the victim's data, it is the expected liability from every downstream customer exposure. Defenders at downstream organizations should pay attention to:
- Which MSPs hold privileged access into their environments and how the MSP's own security posture is verified.
- Whether vendor admin consoles connected into your SaaS estate inherit sufficient access to make ransomware-driven extortion of the vendor your problem too.
- Contractual breach-notification SLAs with vendors and MSPs, tested against real timelines rather than assumed.
What telemetry retention matters most for RansomHub-class response?
Endpoint and identity logs for at least 180 days, ideally longer for Tier 0 sources. Many RansomHub incidents showed staged activity over several weeks before the encryption step, which means 30-day retention is too short for reconstruction. Cloud log storage of compressed telemetry is inexpensive relative to the cost of forensic gaps. Build retention into the SIEM architecture and into the IR playbook so that "pull the last six months of auth events for the compromised account" is a two-minute exercise, not a two-day one.
How Safeguard.sh Helps
Safeguard.sh gives you the supply-chain side of this picture. We track which of your vendors are running the edge appliances that RansomHub-class affiliates have weaponized (Citrix, Fortinet, ActiveMQ, and the evolving list), correlate their patch posture against active campaigns, and flag exposure before your vendor tells you. We also model identity trust between you and your providers so that a compromise at an MSP or SaaS admin tenant becomes a near-real-time alert, not a post-incident forensic finding. When affiliates move, we move your visibility with them.