Today’s stories share a theme: attackers getting what they need not by breaking something, but by using something that was already trusted — a signed driver, a years-old credential nobody rotated, a vendor system nobody watched, a “recovery firm” email that sounds like help. Here’s what’s new since yesterday’s digest.
EDR watch: Check Point weaponizes Microsoft Defender’s own boot-time driver for kernel-level tampering
Check Point Research disclosed BTR Reforged, a technique that abuses BTR.sys — the Boot Time Removal driver bundled inside Microsoft Defender’s MpEngine.dll to clean up locked malware components — to perform arbitrary kernel-level file and registry operations on any Windows system from Windows 7 through Windows 11 25H2. No software vulnerability is exploited and no external driver is loaded: the technique repurposes a legitimately signed component that’s already present on every Windows machine running Defender. That matters because BTR.sys is a required Defender component, so Microsoft can’t add it to the Vulnerable Driver Blocklist or block it via WDAC without breaking Defender itself. Researcher Jiří Vinopal presented the findings as a main-stage briefing at Black Hat USA and DEF CON, publishing a proof-of-concept tool, BTR_CLI, on August 20. Exploitation requires an administrator account holding SeLoadDriverPrivilege — a real bar, but one that’s often already cleared once an attacker has local admin. Check Point Research · The Hacker News
This is a post-exploitation primitive, not an initial-access bug, but it’s a dangerous one for anyone relying on Defender for tamper resistance: an attacker who already has admin can use the AV’s own driver to delete or disable other security software at boot, no third-party LOLDriver required. If Defender is your primary or only endpoint control, this is worth flagging to whoever owns your endpoint hardening — and worth watching for unusual BTR_CLI-style command-line activity or unexpected driver service installs in your endpoint logs.
Cloud security watch: More than 9,300 leaked AWS access keys are still valid years after they were exposed
Researchers at Truffle Security tested AWS credentials found publicly exposed between August 2022 and August 2026 and confirmed 9,300+ are still active. Out of 10,616 keys with complete, testable credentials, 88% still authenticated as of August 10. Hugging Face was by far the largest exposure source, accounting for 8,482 leaked keys — mostly pasted into model repos, notebooks, and dataset configs. Among the subset tied to identifiable companies, 768 corporate keys carried enough privilege for full account takeover, including 526 AWS root keys and 242 IAM users with the AdministratorAccess policy attached. The median age of an exposed key was about five years, meaning most had simply never been rotated since the day they leaked. Truffle Security · BleepingComputer
The uncomfortable finding here isn’t the leaking — it’s that nobody noticed for years. If your organization uses Hugging Face, public GitHub repos, or any other public-facing code/notebook hosting, run a secret-scan against your own historical commits and shared assets rather than assuming an old leak was already caught; a key that’s been sitting exposed since 2022 and never rotated is functionally a standing backdoor.
Breach watch: Japanese cloud provider Sakura Internet discloses a breach affecting 1.36 million accounts
Sakura Internet disclosed that attackers accessed its internal sales management system — which stores customer contract, membership, and billing information — during an intrusion that began August 9. The breach came to light while the company was investigating a separate, previously disclosed compromise of its Sakura Rental Server service (announced August 17), which involved unauthorized logins to 583 accounts and malware installed on Sakura’s own systems. The sales-system exposure is far larger: up to 1,360,563 accounts potentially affected, with names, email addresses, contract details, and billing information in scope. Stored passwords are hashed and no credit card data was stored on the affected system; Sakura says it has not confirmed actual data exfiltration as of its latest update. BleepingComputer · SC Media
Two disclosures from the same vendor within a week — one confirmed customer-facing compromise and malware on the host, then a second and much larger dataset surfacing during that investigation — is a pattern worth remembering: an initial breach notice is often a floor, not a ceiling. If you or your customers use Sakura Internet services, treat account emails as exposed for phishing purposes even though passwords were hashed, and watch for credential-stuffing attempts using email addresses tied to this disclosure.
Also noted: A rogue ransomware affiliate poses as a data-recovery firm to re-extort victims before attacks go public
GuidePoint Security’s threat intelligence team assesses with moderate confidence that “Ransom Busters,” an outfit emailing ransomware victims and offering to recover encrypted files and delete stolen data for $20,000 to $60,000, is itself a ransomware affiliate — not a legitimate recovery service. The pitch: claiming to have infiltrated the original attackers’ infrastructure and offering to restore files and destroy the stolen copies, reaching out to CEOs or IT leaders before the breach becomes public. GuidePoint tied two such approaches to intrusions bearing identical fingerprints — SoftPerfect Network Scanner for reconnaissance, s5cmd for exfiltration to cloud storage, the Remotely remote-management tool, and a local backdoor account created with the password Numlock!123 in both environments — and links the activity to DragonForce, Settra, and Anubis ransomware incidents. The Register · BleepingComputer
If your incident response plan includes a step for “unsolicited recovery offers,” this is the reason it’s there: an early, too-good-to-be-true recovery pitch before an attack is public knowledge should be treated as a second extortion attempt, not a lifeline. Route any such contact through your incident response provider or law enforcement for verification before any payment or data exchange is considered.
Final thought
Four different flavors of the same problem today: a trusted signed driver repurposed for tampering, trusted-but-forgotten credentials still standing years after they leaked, a trusted vendor’s internal system quietly compromised for weeks before disclosure, and a trusted-sounding “recovery firm” that’s actually the attacker working an angle. None of these require a novel zero-day — they require someone assuming that “trusted” still means “safe.” If you want help figuring out where that assumption might be quietly wrong in your own environment, see our how-to guides or book a discovery call.