Session CRT-20260712 — 12 July 2026 · Afternoon Edition

Halil, quick mobile read: this is real patch work, but not the center of gravity for the whole room.

For iOS fleets, push Chrome for iOS 150.0.7871.47 today where Chrome is installed. The key differentiator is CVE-2026-13777 is described in the handoff as actively exploited, while CVE-2026-14066 is a navigation restriction bypass. Highest priority: managed iPhones/iPads used by executives, finance, legal, incident responders, and anyone exposed to targeted links or credential flows. Don’t message this as “all iPhones are burning”; message it as “Chrome for iOS needs same-day update on sensitive-user devices.”

For Samsung Galaxy fleets, don’t wait for a vague “July patch is out” assumption. The Samsung July package is reported as 57 fixes: 41 Android OS issues, 16 Samsung-specific SVEs, with coverage noted for Android 14, 15, and 16 devices. Reported affected Samsung components include KnoxGuardManager, SmartThingsKit, SamsungSEAgentService, Wallpaper Service, and SemClipboardService. Because rollout may lag by model/carrier, MDM teams should inventory patch level by device model and build, then quarantine or restrict access for lagging high-risk phones.

What not to let this distract from: the exploited edge and identity stories are still likely higher-impact operationally. The same source pack flags an ACSC warning on global exploitation of vulnerable CMS platforms, actively exploited Adobe ColdFusion CVE-2026-48282, and a Coinbase Cartel extortion/identity-phishing profile. So: patch mobile browsers and Samsung devices, yes — but don’t let that consume the team that should be closing exposed CMS/ColdFusion and tightening identity controls.

Halil, taking the AssuranceAmerica and Medtronic figures as confirmed inputs, these are no longer “watch items”; they require preserved breach records, regulator-ready scope tables, and customer/individual-notification execution. For any EU personal data involved, GDPR Article 33 requires supervisory-authority notification “without undue delay” and, where feasible, within 72 hours after becoming aware, unless the breach is unlikely to risk individuals’ rights and freedoms; Article 34-style individual notice becomes the question where risk is high. The important point: the clock runs from awareness, not from full forensic certainty.

For SEC-reporting entities, the board posture should be formal: management should document materiality analysis, legal holds, affected-data categories, credential-theft timeline, containment steps, and whether the incident has material impact or reasonably likely material impact. SEC Form 8-K Item 1.05 is due four business days after the registrant determines the cybersecurity incident is material. I would not treat the Under Armour 72M forum claim as confirmed breach scope: preserve evidence, monitor for credential stuffing and data validation, but do not notify on “72M affected” unless the dataset is authenticated, linked to Under Armour systems, and mapped to personal data/account records.

Practical instruction: AssuranceAmerica and Medtronic should run regulator, consumer, and board workstreams in parallel; Under Armour should run verification and containment first, with notification-ready drafts but no confirmed-number language. For DORA/NIS2/HIPAA or state-law specifics, I would need jurisdiction, entity status, and data-type confirmation before attaching exact clocks beyond the verified GDPR and SEC rules here.

Finance, comms, and fraud should make one decision today: likeness is not identity, and publisher branding is not provenance. The same control failure sits under cloned BBC/Guardian-style investment pages, fake Westpac CEO ads, and New Zealand executive-payment deepfake fraud: victims are being asked to trust a face, voice, headline, or familiar logo. FACT: our evidence includes cloned news-site investment scams using AI imagery and fake endorsements, Westpac/Kiwibank executive-themed fake trading-platform lures on Meta, and New Zealand executive-impersonation fraud reporting losses framed at up to NZ$2.2m per hit. UNKNOWN: I do not have verified data here on the specific generative model or tooling used.

My process decision would be blunt:

• Identity proof: no video, voice note, face image, “CEO appeared on a news page,” or social-media ad counts as proof. Sensitive actions require a pre-enrolled identity path: known corporate channel, MFA-backed account, verified device/session, or callback to a number already held in the system.
• Payment authorization: any new beneficiary, urgent transfer, account-detail change, or executive override requires dual approval plus an out-of-band callback. If the request arrives via voice/video, treat that as higher risk, not higher assurance.
• Public-brand impersonation monitoring: comms and fraud teams should run a standing takedown workflow for fake news pages, fake executive ads, and fraudulent trading-platform funnels. Westpac’s reported complaint was not just that scams existed, but that reported ads allegedly stayed live for weeks; that means escalation paths to platforms and regulators need owners, SLAs, evidence capture, and repeat-offender tracking.

So I would not spend today shopping for a “deepfake detector.” Use detectors as triage only. The durable control is procedural: no money moves and no customer trusts an investment offer solely because the media looks real. Comms should pre-publish canonical “we do not endorse investment schemes through social ads” messaging, fraud should maintain live impersonation watchlists, and finance should hard-block exception handling based on executive likeness.

Halil, the trust-chain failure here is clear: the attacker is not “beating MFA” cryptographically; they are getting the user to complete authentication and then stealing the post-auth trust artifact — session cookies in Evilginx-style AiTM, or valid OAuth tokens in Microsoft device-code phishing. That means the next 24 hours should not start with password resets. Start with trust-state destruction.

For the next 24 hours:

1. Revoke sessions and refresh tokens for exposed users

   • Kill active Microsoft 365 / Entra sessions.
   • Revoke refresh tokens, not just passwords.
   • Review third-party OAuth grants and suspicious enterprise app consent.
   • Evilginx-style attacks can capture authenticated sessions, and device-code phishing can result in valid tokens after the victim completes MFA.

2. Block or tightly restrict OAuth device-code flow

   • If device-code auth is not operationally required, disable it through Conditional Access.
   • If it is required, allow only managed devices, trusted networks, and specific low-risk app IDs.
   • The visible evidence describes device-code phishing where the victim authenticates on Microsoft’s legitimate page and the attacker receives a valid token after MFA.

3. Move high-risk populations to phishing-resistant authentication

   • Prioritize university staff with payroll, research, IdP admin, finance, and student-record access.
   • Use FIDO2/WebAuthn/passkeys or certificate-bound/device-bound auth where available.
   • SMS, OTP, and push approval are not enough against AiTM phishing because the attacker can proxy the login and capture the resulting session.

4. Hunt for token replay, not just failed logins

   • Look for impossible travel, new user agents, new autonomous systems, unfamiliar device IDs, OAuth grant anomalies, and session use after password reset.
   • Pay special attention to Microsoft 365 mailbox rules, forwarding, new inbox delegates, Teams/SharePoint access, and consented apps.

5. Tighten Conditional Access immediately

   • Require compliant or hybrid-joined devices for sensitive apps.
   • Block legacy authentication.
   • Require re-authentication for risky sign-ins.
   • Reduce session lifetime for high-risk roles.
   • Separate student access policy from staff/admin access policy; universities often over-flatten this trust boundary.

On AssuranceAmerica: I do not have enough visible database evidence here to independently verify the stolen-employee-credential details, so I would treat that as an identity-risk lead rather than a confirmed mechanism from my side. But if stolen employee credentials were involved, the same response applies: reset credentials only after revoking sessions, refresh tokens, cached access, and third-party OAuth grants.

The MFA comfort blanket CISOs should drop immediately is “we have MFA, so credential phishing is contained.” If the factor is push, SMS, OTP, or anything replayable through an AiTM proxy, it is not sufficient. The operational standard for privileged and sensitive access should be phishing-resistant auth plus aggressive session/token governance.

Halil, the governance change is simple: treat ransomware negotiators and breach coaches as privileged high-risk insiders, not just service providers. The DigitalMint case shows why: CyberScoop reports Angelo John Martino III was sentenced to 70 months after sharing victims’ negotiating positions and insurance policy limits with BlackCat/ALPHV affiliates. Organizations should require dual-control over all ransom communications, prohibit a negotiator from being the sole holder of attacker-channel access, segregate insurance-limit data from negotiation chat rooms, and make any disclosure of payment ceiling or “maximum tolerance” a board-approved exception.

Legally, vendor engagement letters should be tightened before the incident: named personnel only, conflict checks, sanctions-screening workflow, no subcontracting without written approval, immutable communications logging, and immediate termination/reporting rights for unauthorized side-channel contact. OFAC’s ransomware advisory says firms facilitating payments, including cyber insurance, DFIR, financial services, and payment processors, should maintain risk-based sanctions compliance programs and that reporting/cooperation with law enforcement are significant mitigating factors. The ICO/NCSC letter also makes clear that paying ransom does not reduce UK regulatory penalty exposure.

Evidence-handling posture: preserve negotiation transcripts, wallet/payment instructions, vendor access logs, insurance communications, board minutes, and breach-coach instructions under legal hold from day one. For public companies, the board should receive a clean record of who knew payment limits, who authorized negotiation parameters, whether the vendor had conflicts, and whether the incident may require cyber disclosure. The key control is “need-to-know ransom economics”: the fewer people and vendors who know the insurance ceiling, the less leverage you hand to the attacker.