Session CRT-20260621 — 21 June 2026 · Morning Edition

C5 first: Microsoft’s fresh read is a Mastra npm supply-chain compromise tied to North Korea’s Sapphire Sleet/BlueNoroff. The delta is the scope — more than 140 @mastra packages were republished via a compromised maintainer account (ehindero), and Microsoft says the malicious path was a typosquatted dependency (easy-day-js) that triggers at install time. Confidence on attribution is moderate: the infrastructure/malware chain is solid, but the actor link is still vendor attribution, so I’d keep the G-number-free label as a North Korean-nexus supply-chain campaign unless more corroboration lands.

Behavior-wise, the malware is install-time, cross-platform, and credential-centric: it disables TLS verification, reaches out to C2, drops a second stage, and Microsoft says they observed PowerShell backdoor activity, persistence, Defender exclusions, and SYSTEM-level service abuse. For defenders, the practical IOC guidance is to hunt for compromised Mastra versions, unexpected easy-day-js/phantom dependencies, install-time script execution, odd .js artifacts in temp/home paths, and any TLS-bypass behavior during package install. The downstream risk is broader than Mastra: any org using AI/dev tooling with loose dependency controls has to treat package updates as a potential initial access path, especially where lockfiles, pinning, and provenance checks are weak.

I found some Handala and healthcare-breach material, but it’s a separate lane — worth a quick later segment, not now.

C15: the 24B corpus by itself is a real risk amplifier, but not proof of live abuse. Fortinet’s own analysis says the activity involves reused credentials from prior incidents plus brute-force against weak-password/no-MFA devices, and SpyCloud says they captured a live FortiGate session cookie that can be replayed to bypass auth. So the operator risk is credential stuffing plus session hijack, not magic zero-day nonsense. What would confirm active abuse? Fresh logins from impossible geography/device fingerprints, repeated auth failures followed by success, new VPN/session-cookie reuse, abnormal admin changes, and evidence of replayed cookies or config tampering. If you’ve got those, this is live abuse. If not, it’s still a hunt problem.

C3: CVE-2026-11911 is Simple File List <= 6.3.7. It’s unauthenticated arbitrary file deletion via path traversal in eeSFL_DeleteFile / eeSubFolder; the simplefilelist_edit_job AJAX action is exposed via wp_ajax_nopriv_, and is_admin() is bypassed on admin-ajax.php. The RCE pivot is simple: delete wp-config.php and you’ve usually got a site-kill / setup-reset path that can become code execution. Wordfence says it’s patched, and mitigation is blunt: update past 6.3.7 or remove the plugin now. Immediate checks: inventory for Simple File List, confirm version, look for delete events against unexpected paths, and hunt for admin-ajax.php hits to the plugin’s actions.

C19: this changes detection priority only a little. HexKiller, ThrottleBlood, and HavocKiller are all part of the Gentlemen EDR-killer ecosystem, and ESET says the group is unusually fast at operationalizing BYOVD PoCs within days. That means the priority is kernel-driver abuse and security-product tampering, not the individual killer brand names. Hunt driver installs, vulnerable signed drivers, service creation for odd .sys files, disabled EDR telemetry, and process-termination bursts against security tools. This is a BYOVD problem first. Treat it that way.

For C5, tell teams to treat the Mastra incident as a supply-chain compromise at install time: any dev workstation or CI/CD runner that did npm install or npm update in the exposure window should be considered exposed. Check for easy-day-js in lockfiles and artifacts, inspect build logs for unexpected postinstall activity, and hunt for the host artifacts Microsoft called out: $TMPDIR/.pkg_history, $TMPDIR/.pkg_logs, and unexpected .js files in temp or home directories. Containment is clean rebuilds, token/secret rotation, and rebuilding only from trusted, pinned dependencies.

For C15, the WordPress call is solid: Simple File List <= 6.3.7 is vulnerable to unauthenticated arbitrary file deletion via path traversal in eeSubFolder, and the published advisory says this can easily lead to RCE when the right file is deleted, such as wp-config.php. So the action is patch or remove that plugin immediately, then run file-integrity checks on WordPress core, config, and plugin directories.

For C3, the right framing is: Apple A12/A13 SecureROM is a real fleet risk, but it’s mainly a concern when your threat model includes physical access or DFU/USB-level abuse. For C7, Microsoft’s Gentlement guidance does support EDR in block mode, tamper protection, and hardening against tool eviction; that’s the practical control set to put in front of the SOC. For C19, I’d keep Bluetooth earbuds and AVideo Meet off the top line unless you have a specific exposed environment — they don’t change today’s action list.

Look, the Mastra incident is a classic npm trust-failure: a compromised maintainer account with publish rights across the @mastra scope was used to push poisoned releases, and those releases pulled in easy-day-js, a typosquat of dayjs, with install-time execution. The blast radius is wider than the direct packages: anything resolving those versions through a lockfile refresh, container rebuild, or fresh npm install in the exposure window is in scope.

The practical read is: treat this as install-time compromise on dev endpoints and CI runners, not just a bad dependency. Hunt package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, SBOMs, and artifact manifests for easy-day-js and affected @mastra/* versions; then check for the host artifacts Microsoft called out: $TMPDIR/.pkg_history, $TMPDIR/.pkg_logs, and unexpected .js files in temp or home directories. Also assume any npm token or secret present on an exposed machine may be burned and rotate it.

On the provenance side, SLSA only helps if you enforce it. If your pipeline accepted the compromised publishes without requiring verified attestations, that’s a broken control plane, not a package bug. My recommendation: pin versions by hash, rebuild from trusted sources, require provenance verification in CI, and add VEX/SBOM updates so downstream teams can tell whether they actually consumed the bad versions.