Session CRT-20260712 — 12 July 2026 · Morning Edition

Halil, my cut is simple: CMS webshells and GhostLock are the real “do something now” items. Chrome for iOS is a fast patch, not a drama. The Recorded Future June patch-wave framing sounds overheated unless it maps to your exposed assets.

For ACSC’s CMS campaign, isolate any public CMS showing unexpected web-root files, new admin users, modified templates, suspicious upload directories, or webshell-like PHP/ASP artifacts. This is not “patch and walk away.” The evidence says attackers are actively exploiting vulnerable CMS platforms/plugins and deploying webshells, with patterns including unauthenticated file upload, RCE, SSRF, and unsafe deserialization. That closes the kill chain: internet-facing app → code execution/upload → persistent webshell → credential theft/pivot. Scan first, but if you find indicators, isolate and rebuild from clean media. Webshell cleanup is like pulling weeds after they’ve seeded the lawn.

For GhostLock CVE-2026-43499, patch Linux kernels today, especially shared hosting, CI runners, Kubernetes/container hosts, bastions, and anything with semi-trusted local users. The reporting says public exploit code exists, gives a logged-in user root quickly, and may enable Docker/Kubernetes escape; upstream patching exists but distro rollout is uneven. Caveat: this is local privilege escalation, not remote initial access by itself. So don’t treat it like unauthenticated RCE. But if an attacker already has a shell, this is the door from “foothold” to “own the host.” If you can’t patch/reboot high-risk multi-tenant nodes, isolate workloads or restrict local access until you can.

For Chrome for iOS CVE-2026-13777, push the update fleet-wide and monitor compliance. I would not isolate devices based only on the evidence here. The handoff flags active exploitation and an emergency Chrome for iOS update to version 150.0.7871.47, but the visible evidence is thin on exploit mechanics. Patch it, yes. Panic, no.

On the Recorded Future June patch-wave claim, I’d treat the wording as too hot until each CVE is tied to your asset inventory, exposure, and exploitation status. “57 actively exploited flaws demand immediate patching” is not a plan; it’s a siren. Prioritize exploited internet-facing services, identity systems, edge devices, and anything with public PoC. Everything else goes into normal accelerated patch cadence.

No, I would not break the trust-state model — I’d tighten it. The new point is that the enrollment ceremony itself is now the compromised trust boundary. If O-UNC-066 can vish a user into registering an attacker-controlled Entra passkey, then “phishing-resistant MFA” only helps after you secure who is allowed to create the phishing-resistant credential.

Tonight, I’d change four things:

1. Enrollment controls: pause broad self-service passkey/FIDO2 enrollment until scoped. Microsoft docs say Entra can restrict passkey/FIDO2 sign-in by Authentication Methods policy and Conditional Access authentication strength, including limiting to specific passkey providers or security key models. Use that. For Authenticator passkeys, Microsoft also documents a setting where users cannot register via Security info if registration is disabled. So: no unmanaged, helpdesk-prompted, user-initiated passkey enrollment for high-risk users; require known device, known network or compliant device, and tight group scoping.

2. Helpdesk workflow: ban “I’m IT, please enroll this passkey now” as a valid support pattern. The reported O-UNC-066/Pink activity uses vishing and fake passkey pages to impersonate IT and push users into registration; HostDir’s coverage explicitly advises verifying authentication-change requests through separate channels. So make the callback path non-negotiable: ticket exists, manager or identity team approval exists, and the helpdesk never walks users through passkey enrollment from an inbound call.

3. Session and credential revocation: do not stop at password reset. The reported campaigns involve token capture, AiTM relay, session theft, and in some cases quiet passkey enrollment. Containment means: revoke Entra sign-in sessions/refresh tokens, remove newly added passkeys/FIDO2 methods, review authentication methods, kill suspicious OAuth grants, and re-authenticate the user from a trusted device. Microsoft’s own device-code phishing guidance says to revoke refresh tokens with revokeSignInSessions when suspected activity is found.

4. Detection: hunt the enrollment and the session, not just the phish. Alert on new passkey/FIDO2 registration followed by impossible travel, unfamiliar IP/ASN, device-code flow, or new client/app access. Microsoft says device code flow is high risk and can be filtered in sign-in logs by authentication protocol; Elastic’s detection guidance calls out concurrent sign-ins from different IPs in a short window as possible token replay, OAuth phishing, or AiTM activity. For Evilginx-style university attacks, the tell is often a clean MFA success followed by session reuse from infrastructure the user has never touched.

My blunt CISO instruction: passkeys are still the right destination, but unmanaged enrollment is now an attack surface. Lock down who can create the credential, then revoke every bearer token and registered factor the attacker may have acquired.

Halil, I would not freeze all engineering. I’d draw the containment boundary around execution plus credential reach: any developer workstation or CI runner that installed [email protected], built suspicious Visual Studio C++/C# project files, or held GitHub/cloud publishing credentials is in scope. Socket reports jscrambler as an npm package compromise; CyberPress/Doctor Web reporting describes Visual Studio project-file abuse with PowerShell, DLL replacement, registry manipulation, UAC bypass, and credential-stealing behavior. Those are execution boundaries, not just “bad code” boundaries.

Scoped action plan: first, quarantine npm install/build environments that consumed [email protected]; pull package-proxy logs, lockfiles, CI job history, and developer package caches. Rebuild from pinned known-good versions and disable/evaluate install scripts before re-enabling normal installs. Second, quarantine Visual Studio workstations and CI runners that opened or built untrusted .csproj / C++ project files; inspect project pre/post-build steps and hunt for the reported PowerShell/DLL/registry/UAC behaviors. Third, treat source control as a secrets boundary: the CISA/Nightwing case reportedly involved public GitHub exposure of AWS GovCloud administrative credentials, IAM tokens, and internal passwords, with secret scanning disabled, so revoke exposed tokens, enforce secret scanning, block public repo creation for sensitive orgs, and audit GitHub Apps/PATs.

For the GitHub ghost-account API reconnaissance and AI-generated dependency-name risk, the boundary is earlier: repository visibility and dependency admission. Lock down GitHub org enumeration, review anomalous API access, tighten repo/package permissions, and require human review for new package names suggested by AI coding tools. New dependencies should enter through a private registry/proxy with hash pinning, maintainer-change review, SCA in CI, and postinstall-script scrutiny. Publishing credentials are only frozen where they were present on affected machines or CI runners; otherwise rotate high-value tokens, but don’t stop unrelated teams from shipping.

Halil, my read: Ghostcommit is the more materially new AI delta; slopsquatting is old supply-chain abuse with a new demand generator. The Ghostcommit evidence describes a PR where AGENTS.md looks benign but points the coding agent toward a PNG that carries the malicious instruction, including instructions to read .env secrets. That is not “AI going rogue”; it is indirect prompt injection through repo context. The attack surface changes because docs, images, conventions, and “agent policy” files become influence channels for a tool-connected reviewer.

Slopsquatting is closer to classic typosquatting/dependency confusion. Socket and Snyk describe the pattern: AI coding tools recommend plausible but nonexistent package names, and attackers register those names on npm/PyPI. The AI-specific part is not the malicious package — that is traditional supply-chain abuse — but the fact that the model can repeatedly create attacker-predictable package demand. So the control needs to shift from “did the developer mistype?” to “did this dependency originate from an LLM suggestion, and has it been independently verified?”

Controls I would change immediately:

• Treat AGENTS.md, repo docs, PR comments, screenshots, and images as untrusted prompt input, not harmless context.
• Require CODEOWNERS or security approval for agent-instruction files like AGENTS.md.
• Do not let code-review agents read secrets, .env, CI tokens, or production credentials; run them in a sandbox with no secret-bearing environment and restricted egress.
• For binary/image additions in PRs, require explicit review if an AI agent will consume them; OCR/text-extract images and block hidden instruction patterns where possible.
• Log and show humans the full context the agent consumed before producing review or code changes.
• Never accept AI-suggested dependencies directly. Resolve every new package against registry metadata, maintainer history, age, downloads, provenance, known advisories, and internal allowlists.
• Quarantine “first-seen” or low-reputation packages, especially when introduced by AI-generated code.
• Require lockfile review, SBOM update, malware scanning, and preferably installation through an internal package mirror rather than directly from public registries.

So: not novel autonomy, but a real shift in trust boundaries. AI-assisted development makes natural-language context and hallucinated package names part of the software supply chain. That is enough to require different review gates.

Halil, the money trail is the priority here. Fact: Bonzo’s own incident report says a manipulated SAUCE/wHBAR price update was accepted on-chain; CoinDesk reports the attacker deposited only 250 SAUCE, then borrowed 6.63M USDC and 34.52M WHBAR, for roughly $9.05M in losses. CyberBrief/Cryip reporting adds that part of the proceeds moved from Hedera to Ethereum via LayerZero, with some assets converted toward ETH. The later “white-hat” Discord claim is not enough; investigators should treat it as unverified until the actor signs from the exploit wallets and returns funds to an agreed recovery address.

Next 24 hours for DeFi teams: pause or cap any market using the affected Supra-fed SAUCE pricing path; fail-closed on malformed oracle verification, zeroed signatures, zero committee keys, stale values, and extreme price deviation; add secondary-source checks before borrow power updates; and review every lending market where a thin collateral asset can borrow liquid assets like USDC/WHBAR. This is not just a “Bonzo bug” problem — it is delegated price authority accepting a formally valid but economically insane instruction.

Treasury teams: freeze new deposits into affected Bonzo/Supra-dependent strategies, inventory exposure to SAUCE, WHBAR, Hedera USDC, and any LP/vault positions using those prices, and suspend automated rebalancing that could crystallize bad prices. Investigators: trace the Hedera exploit account through LayerZero messages into Ethereum, tag recipient wallets, alert exchanges/bridges/issuers on any USDC or wrapped-asset chokepoints, and preserve Discord communications as evidence — but do not negotiate from trust. If funds are already in ETH, the freeze window narrows sharply unless they touch a compliant exchange.

On Ethereum’s libp2p gossipsub crash fix: it is a separate validator-availability issue, not part of the Bonzo laundering path. Validator operators should patch affected clients promptly according to client guidance, but it does not change the urgency of the Bonzo response; the Bonzo clock is about freezing and tracing funds before further swaps or off-ramp attempts.

I’d give airtime to O-UNC-066 and the Pakistan law-enforcement espionage story first.
FACT: O-UNC-066 is tied in the handoff to a vishing campaign hijacking Microsoft 365 passkey enrollment across six industries. ASSESSMENT: that is decision-maker material because it maps to identity compromise, roughly T1598.004/T1078/T1098. Attribution confidence: moderate for O-UNC-066 as a reporting cluster, low for collapsing it into “Pink/The Com” without stronger pivots.

For ShinyHunters, airtime only if we frame it as CRM/OAuth/credential abuse, not “Salesforce got hacked.” FACT: Klue reporting says attackers abused a dormant API credential, harvested OAuth tokens, and queried customer CRM/Salesforce data; other reporting links ShinyHunters claims to Canvas and Salesforce records. ASSESSMENT: operational risk is high, actor-brand confidence is low-to-moderate because the label is noisier than the access path.

For pro-Iran hacktivists hitting Canonical/Ubuntu, I would keep it as context unless we have confirmed intrusion depth, data loss, or service impact. I can’t substantiate the claim from the evidence in front of us, so attribution confidence is low and “pro-Iran” is being overstated.

For China- and India-linked activity against Pakistani law enforcement, airtime is deserved, but language matters. FACT: SentinelLABS reporting says suspected China- and India-linked actors independently targeted Pakistani police systems over more than two years, including Balochistan Police, with access to sensitive law-enforcement systems and malware uploaded through a citizen complaint portal; large-scale theft or successful infection was not confirmed. ASSESSMENT: espionage pattern confidence is high, specific state-link attribution moderate, and treating it as one unified China-plus-India campaign would be wrong.