APT28 Router Botnet Steals OAuth Tokens, Bypasses MFA

◆ DEEP DIVES

1. 01

   APT28's Router Botnet Stole OAuth Tokens from 200+ Organizations — Your MFA Was Irrelevant

   <h3>What Happened</h3><p>APT28 (Forest Blizzard / GRU Unit 26165) exploited <strong>known vulnerabilities in TP-Link and MikroTik routers</strong> to build an 18,000+ device botnet spanning 120+ countries. The compromised routers had their DNS settings hijacked to redirect authentication traffic through attacker infrastructure, creating adversary-in-the-middle interception of <strong>Outlook Web Access</strong> login flows. The operation harvested passwords, OAuth tokens, and cloud credentials from <strong>200+ victim organizations</strong>.</p><p>The critical defensive failure: <strong>OAuth token theft bypasses MFA entirely</strong>. Users completed legitimate Microsoft login flows, MFA challenges fired and were satisfied normally, and the attacker received a valid session token that required no further authentication. This isn't a vulnerability in MFA — it's MFA operating exactly as designed while the network layer beneath it was compromised.</p><h3>The Disruption — and What Remains</h3><p><strong>Operation Masquerade</strong> — a coordinated effort by FBI, DOJ, Microsoft, and Lumen Black Lotus Labs — used court-authorized commands to reset DNS settings on affected U.S. routers. Botnet communications have steadily declined. However, <strong>non-U.S. routers remain compromised</strong>, creating residual risk for any organization with international operations or remote workers abroad.</p><blockquote>If a user's traffic was routed through a compromised router, their M365 session tokens could have been captured without triggering any MFA challenge. Conditional Access policies that bind tokens to compliant devices are the backstop when network-layer trust is compromised.</blockquote><h3>Cross-Source Intelligence</h3><p>This campaign converges with the <strong>device code phishing industrialization</strong> reported earlier this week. Both exploit OAuth token mechanics to bypass MFA, but via different vectors — device code phishing via social engineering, APT28 via network-layer DNS hijacking. The common thread: <strong>token security, not password security, is now the critical control plane</strong>. Multiple sources confirm that Continuous Access Evaluation (CAE) and device-bound tokens are the only reliable mitigations against both vectors simultaneously.</p><h3>Separate Vector: UNC6783 Live-Chat Okta Phishing</h3><p>Concurrent with the APT28 campaign, UNC6783 (Raccoon) is actively <strong>extorting dozens of major companies</strong> by social engineering employees through live chat into visiting fake Okta login pages. This bypasses email-based phishing controls entirely — the vector is human conversation, not a malicious link in an email. <strong>Helpdesk teams are the target, not end users.</strong></p><hr><h3>Defense Playbook</h3><table><thead><tr><th>Action</th><th>Priority</th><th>Rationale</th></tr></thead><tbody><tr><td>Enable Continuous Access Evaluation (CAE) in Entra ID</td><td>Today</td><td>Near-real-time token revocation when risk signals change</td></tr><tr><td>Enforce device-bound Conditional Access — require compliant/managed devices for all M365 access</td><td>This week</td><td>Stolen tokens can't be replayed from unmanaged devices</td></tr><tr><td>Audit TP-Link and MikroTik routers across branches + remote workers</td><td>This week</td><td>Check DNS configs against known-good baselines</td></tr><tr><td>Hunt for impossible travel and token replay in Entra ID sign-in logs</td><td>This week</td><td>Identify accounts already compromised by AitM</td></tr><tr><td>Brief helpdesk teams on UNC6783 live-chat-to-fake-Okta TTP</td><td>This week</td><td>Email phishing controls don't cover this vector</td></tr><tr><td>Enforce FIDO2/WebAuthn for all privileged Okta accounts</td><td>This sprint</td><td>Phishing-resistant MFA blocks credential replay from fake login pages</td></tr></tbody></table>

   Action items

   • Enable Continuous Access Evaluation and enforce device-bound Conditional Access policies in Entra ID today
   • Hunt Entra ID sign-in logs for impossible travel, residential ISP ranges, and token replay anomalies within the next 48 hours
   • Audit DNS configurations on all TP-Link and MikroTik routers in your infrastructure and remote worker environments this week
   • Brief helpdesk and support teams on UNC6783 live-chat social engineering to fake Okta login pages this week

   Sources:CyberScoop · Risky.Biz · TLDR IT · TLDR InfoSec

2. 02

   Dgraph CVSS 10.0 Has No Patch — And It Feeds Directly Into the K8s Token Theft Epidemic

   <h3>The Vulnerability</h3><p>Dgraph <strong>CVE-2026-34976</strong> scores a perfect CVSS 10.0 — and there is no patch. The <code>restoreTenant</code> administrative mutation was accidentally omitted from the authentication middleware mapping, leaving it <strong>completely unauthenticated across all versions through v25.3.0</strong>. This isn't a complex exploit chain; it's an open door.</p><p>Four exploitation paths have been documented:</p><ol><li><strong>Database overwriting</strong> — malicious backup file injection replaces your data</li><li><strong>Local file probing</strong> — error message information leakage reveals file system contents</li><li><strong>SSRF</strong> — reach internal services from the Dgraph instance</li><li><strong>Kubernetes service account token theft</strong> — reads <code>/var/run/secrets/kubernetes.io/serviceaccount/token</code></li></ol><blockquote>This vulnerability pattern — an endpoint accidentally excluded from auth middleware — is disturbingly common in microservice architectures. Use this as a trigger to audit your own middleware mapping completeness.</blockquote><h3>The K8s Convergence</h3><p>Unit 42 documents a <strong>282% year-over-year increase</strong> in Kubernetes service account token theft, with IT sector organizations accounting for 78% of observed activity. The Dgraph K8s exploitation path feeds directly into this industrialized playbook. Two distinct threat vectors now converge on identical post-exploitation workflows:</p><table><thead><tr><th>Vector</th><th>Actor</th><th>Entry</th><th>Post-Exploit</th></tr></thead><tbody><tr><td>CI/CD token abuse</td><td><strong>Lazarus (Slow Pisces)</strong></td><td>Overprivileged CI/CD service accounts</td><td>Extract K8s token → test RBAC → pivot to cloud</td></tr><tr><td>React2Shell + Dgraph</td><td>Opportunistic + nation-state</td><td>CVE-2025-55182 or CVE-2026-34976</td><td>Identical: enumerate → extract → pivot</td></tr></tbody></table><p>When <strong>both nation-state and commodity actors adopt identical TTPs</strong>, that attack path has become industrialized. The K8s service account token at <code>/var/run/secrets/kubernetes.io/serviceaccount/token</code> is now a standardized post-exploitation target — the equivalent of <code>lsass.exe</code> dumping in the Windows world.</p><hr><h3>The Disclosure Gap Problem</h3><p>A related vulnerability in <strong>OpenClaw (CVE-2026-33579, CVSS 8.1–9.8)</strong> highlights a systemic issue: patches dropped Sunday, but the CVE wasn't published until Tuesday — giving attackers a <strong>2-day reverse-engineering window</strong>. Compounding this, 63% of 135,000 internet-exposed OpenClaw instances run without authentication. Your patch monitoring cannot rely solely on CVE databases; you need vendor release note monitoring as a parallel signal.</p><hr><h3>Defense Playbook</h3><ol><li><strong>Dgraph (hours):</strong> Firewall all admin ports — 8080 HTTP, 9080 gRPC. There is no patch. Network isolation is your only mitigation. Audit your supply chain for vendor Dgraph usage.</li><li><strong>K8s tokens (days):</strong> Migrate all clusters to projected volume tokens with audience restrictions and TTLs under 1 hour. Disable <code>automountServiceAccountToken</code> on pods that don't need API access. Audit CI/CD service accounts for overprivileged RBAC bindings.</li><li><strong>Detection engineering:</strong> Alert on reads to <code>/var/run/secrets/kubernetes.io/serviceaccount/token</code> from non-standard processes. Monitor K8s API audit logs for token usage from unexpected source IPs.</li></ol>

   Action items

   • Firewall Dgraph admin ports (8080 HTTP, 9080 gRPC) immediately — there is no patch and exploitation is trivial
   • Migrate all Kubernetes clusters to projected volume tokens with <1hr TTL and disable automountServiceAccountToken on non-API pods this sprint
   • Implement vendor patch release monitoring independent of CVE databases this month

   Sources:TLDR InfoSec · Risky.Biz · CyberScoop

3. 03

   Five Critical CVEs Under Active Exploitation — Storm-1175 Is Burning Through Zero-Days at Ransomware Speed

   <h3>Storm-1175: The Zero-Day Ransomware Machine</h3><p><strong>Storm-1175</strong> (Chinese cybercrime) is deploying Meduza ransomware via simultaneous exploitation of zero-days in <strong>GoAnywhere MFT (CVE-2025-10035)</strong> and <strong>SmarterMail (CVE-2025-52691)</strong>, plus rapidly weaponizing 14 additional CVEs post-disclosure. Their operational tempo is measured in hours from initial access to encryption. If either product is in your environment unpatched, assume compromise and investigate — don't just patch.</p><h3>The Active Exploitation Cluster</h3><p>Five critical-severity vulnerabilities are under active exploitation or have freshly published exploitation paths this week, independent of the Mythos/Glasswing disclosure cycle:</p><table><thead><tr><th>CVE</th><th>Product</th><th>CVSS</th><th>Status</th><th>Patch</th><th>Your Priority</th></tr></thead><tbody><tr><td>CVE-2025-59528</td><td><strong>Flowise</strong></td><td>10.0</td><td>Active exploitation</td><td>Yes (Sept 2025)</td><td>Emergency — discover shadow instances</td></tr><tr><td>CVE-2025-10035</td><td><strong>GoAnywhere MFT</strong></td><td>Critical (0-day)</td><td>Exploited by Storm-1175</td><td>Check vendor</td><td>Emergency patch or assume breach</td></tr><tr><td>CVE-2025-52691</td><td><strong>SmarterMail</strong></td><td>Critical (0-day)</td><td>Exploited by Storm-1175</td><td>Check vendor</td><td>Emergency patch or assume breach</td></tr><tr><td>CVE-2026-34197</td><td><strong>Apache ActiveMQ</strong></td><td>High</td><td>Write-up published</td><td>Yes</td><td>Patch all instances urgently</td></tr><tr><td>CVE-2026-34980/34990</td><td><strong>CUPS 2.4.16</strong></td><td>High (chain)</td><td>Write-up published</td><td>Yes</td><td>Patch; restrict port 631</td></tr></tbody></table><h3>Why Flowise Demands Special Attention</h3><p>Flowise CVE-2025-59528 is a <strong>CVSS 10.0 unauthenticated RCE</strong> on AI agent infrastructure that entered active exploitation this week — despite being patched last September. The exposure is <strong>shadow IT</strong>: Flowise is commonly deployed by developers as a low-code AI workflow tool outside security team visibility. Scan your entire environment — cloud, dev/test, shadow IT — and assume you have instances you don't know about.</p><blockquote>Six months of exposure at maximum severity means you should assume compromise and investigate, not just patch.</blockquote><h3>The ActiveMQ Discovery Signal</h3><p>CVE-2026-34197 in Apache ActiveMQ is an authenticated RCE affecting <strong>every version released in the past 13 years</strong>. The discovery context is significant: it was found by AI (Claude) in approximately <strong>10 minutes</strong>. This is a concrete, production example of AI-accelerated vulnerability discovery generating real CVEs in real infrastructure. Inventory all ActiveMQ instances — including those embedded in larger application stacks — and patch.</p><p>The CUPS chain (CVE-2026-34980 + CVE-2026-34990) follows the same pattern: unauthenticated RCE as <code>lp</code> escalating to arbitrary root file overwrite, <strong>also discovered by automated AI agents</strong>. Print services remain one of the most neglected attack surfaces in enterprise environments.</p><hr><h3>Defense Playbook</h3><ol><li><strong>Emergency discovery scan for Flowise</strong> across all environments — AI tools are deployed outside IT governance more than any other software category</li><li><strong>Verify GoAnywhere MFT and SmarterMail patch status</strong> — if unpatched, initiate compromise assessment immediately</li><li><strong>Patch ActiveMQ</strong> across all instances including embedded deployments; restrict management interfaces to internal networks</li><li><strong>Audit CUPS exposure</strong> across Linux/Unix fleet; restrict port 631 to management networks; disable CUPS where printing isn't required</li></ol>

   Action items

   • Run emergency discovery scan for Flowise instances across all environments including cloud, dev/test, and shadow IT within 24 hours
   • Verify GoAnywhere MFT and SmarterMail patch status within 24 hours; if unpatched, initiate compromise assessment
   • Inventory and patch all Apache ActiveMQ instances including those embedded in application stacks this sprint
   • Audit CUPS exposure fleet-wide and restrict port 631 to management networks this sprint

   Sources:Risky.Biz · TLDR InfoSec · AI Breakfast · CyberScoop