Cortex XDR Whitelist Hides LSASS Dumps, Aruba 9.8 Unauth RCE

◆ DEEP DIVES

1. 01

   Cortex XDR Was Blind to Credential Theft + Aruba Switches Owned Without Credentials: Patch Now

   <h3>Two Defensive Pillars Broken Simultaneously</h3><p>Your EDR and your network infrastructure both have critical blind spots discovered this week. Together, they represent the most immediately actionable new intelligence since the Veeam 9.9 disclosures.</p><h4>Cortex XDR: Encrypted Rules Hiding a Global Bypass</h4><p>InfoGuard Labs <strong>decrypted AES-256-CBC-encrypted CLIPS rule files</strong> shipped with Cortex XDR agents 8.7 and 8.8 (content version 1790-16658) and found a hardcoded global whitelist. Any process with <code>:\Windows\ccmcache</code> in its command line is exempted from approximately <strong>50% of all BIOC detections</strong> — including LSASS dump prevention mapped to <strong>MITRE T1003/TA0006</strong>.</p><p>The exploitation is trivial: an attacker appends this path string to their command line and <strong>bypasses credential dumping detection, process injection monitoring, and other behavioral rules</strong>. The whitelist was removed in Agent 9.1 with content version 2160, but <em>individual rule-level exceptions remain exploitable</em> even in upgraded agents.</p><blockquote>If you ran Cortex XDR agents below 9.1, assume credential theft attempts went undetected. A retrospective hunt for T1003 activity is not optional — it's incident response.</blockquote><h4>HPE Aruba AOS-CX: No Credentials Needed</h4><p><strong>CVE-2026-23813 (CVSS 9.8)</strong> allows an unauthenticated remote attacker to reset the admin password on HPE Aruba AOS-CX network switches — the devices that form the backbone of your network segmentation. Four versions are affected (before 10.10.1180, 10.13.1161, 10.16.1030, 10.17.1001). Three additional high-severity command injection CVEs (CVE-2026-23814 through 23816) affect the same products.</p><p>No exploitation evidence exists yet, but <strong>pre-auth admin takeover on network switches is a CVSS 9.8 for a reason</strong>. If management interfaces are exposed beyond a dedicated out-of-band management network, you are one scan away from total network compromise.</p><h4>Chrome Zero-Days: March 27 CISA Deadline</h4><p>Two actively exploited Chrome zero-days round out the emergency patch list. <strong>CVE-2026-3909</strong> (OOB write in Skia) and <strong>CVE-2026-3910</strong> (arbitrary code execution in V8) are on the CISA KEV catalog with a <strong>March 27 compliance deadline</strong>. Google removed one zero-day's description from its advisory, indicating it will be fixed in a future release — monitor release notes.</p><table><thead><tr><th>CVE</th><th>Product</th><th>CVSS</th><th>Status</th><th>Deadline</th></tr></thead><tbody><tr><td><strong>CVE-2026-23813</strong></td><td>Aruba AOS-CX</td><td>9.8</td><td>Patch available, no known exploitation</td><td>Immediate</td></tr><tr><td><strong>CVE-2026-3909</strong></td><td>Chrome (Skia)</td><td>High</td><td>Actively exploited</td><td>March 27</td></tr><tr><td><strong>CVE-2026-3910</strong></td><td>Chrome (V8)</td><td>High</td><td>Actively exploited</td><td>March 27</td></tr></tbody></table>

   Action items

   • Upgrade all Cortex XDR agents to 9.1+ with content version ≥2160 and run retrospective hunt for T1003 LSASS access patterns and any 'ccmcache' command-line strings outside legitimate SCCM operations
   • Emergency patch all HPE Aruba AOS-CX switches to 10.10.1180, 10.13.1161, 10.16.1030, or 10.17.1001+ and verify management interfaces are restricted to OOB management networks
   • Push Chrome 146.0.7680.75+ to all managed endpoints via MDM/GPO and enforce mandatory restart policies before March 27 CISA deadline
   • Evaluate whether single-vendor EDR reliance is acceptable given the opacity of encrypted detection rules — consider layered detection or periodic independent rule audits

   Sources:GlassWorm is force-pushing malware into your Python repos right now — plus a CVSS 9.8 in your Aruba switches · Your Cortex XDR agents below 9.1 are blind to half your BIOC rules — and GlassWorm is in your dev toolchain

2. 02

   Your Ransomware Negotiator Worked for the Attacker: The ALPHV Collusion Indictment Breaks the IR Trust Model

   <h3>$75.25 Million in Ransom Payments — Steered by the Negotiator</h3><p>The DOJ unsealed charges against <strong>Angelo Martino</strong>, a ransomware negotiator at DigitalMint, for actively colluding with ALPHV BlackCat operators. Co-conspirators <strong>Kevin Tyler Martin</strong> (also DigitalMint) and <strong>Ryan Clifford Goldberg</strong> (IR manager at Cygnia Cybersecurity Services) have already pleaded guilty as of December 2025.</p><p>The attack model was devastatingly simple: Martino <strong>fed confidential client intelligence to ALPHV</strong> — information about DigitalMint's own clients — to help maximize ransom demands. He received a cut of payments. One ransom went directly to the trio; five others to ALPHV after Martino exploited his position as the <strong>trusted negotiator sitting between victim and attacker</strong>.</p><blockquote>This is not a theoretical insider threat scenario. A ransomware negotiator, hired to protect victims, was maximizing the ransom they paid — across 10 confirmed attacks.</blockquote><h4>Implications for Your IR Retainer</h4><p>Every organization with a ransomware negotiation or incident response retainer needs to reassess their trust model. The Martino case exposes three specific gaps:</p><ul><li><strong>Information compartmentalization</strong>: IR firms often get full-scope access to your environment, attack timeline, business impact, and insurance coverage. All of this is leverage for an attacker.</li><li><strong>Conflicts of interest</strong>: Negotiation firms that handle multiple simultaneous engagements create a concentration of victim intelligence that's valuable to threat actors.</li><li><strong>Vetting gaps</strong>: Background checks and contractual controls for IR retainers rarely match the rigor applied to permanent security hires.</li></ul><hr><h4>The Kratos Campaign: Trusted Services as Attack Infrastructure</h4><p>A separate but thematically linked finding: the <strong>Kratos PhaaS campaign</strong> chains through seven trusted services to harvest M365 credentials. The kill chain exploits trust at every hop — DKIM-validated JP Morgan emails pass SPF/DKIM/DMARC, Cisco Secure Email Gateway redirect links are whitelisted, Nylas tracking pixels are legitimate SaaS, and the landing page sits behind Cloudflare with anti-bot validation that defeats automated sandboxing.</p><p>Both the Martino indictment and the Kratos campaign demonstrate the same principle: <strong>the most effective attacks don't break trust boundaries — they weaponize them</strong>.</p>

   Action items

   • Review all incident response and ransomware negotiation retainer agreements for background check requirements, conflict-of-interest disclosures, and information compartmentalization protocols
   • Implement time-of-click URL analysis in email security to detect Cisco SEG redirect abuse and add Kratos PhaaS IOCs from the Outpost24 report to threat intel feeds
   • Establish a policy of engaging multiple independent firms for cross-validation during major ransomware incidents rather than relying on a single negotiator

   Sources:GlassWorm is force-pushing malware into your Python repos right now — plus a CVSS 9.8 in your Aruba switches · Your Cortex XDR agents below 9.1 are blind to half your BIOC rules — and GlassWorm is in your dev toolchain

3. 03

   Two Cryptographic Clocks Are Ticking: TLS Automation Deadline Is Live, PQC Migration Must Start Now

   <h3>200 Days Is Already Here — 47 Days Is Coming</h3><p>As of <strong>March 15, 2026</strong>, the CA/Browser Forum's 200-day maximum for TLS certificate validity is in effect. DigiCert moved to 199-day certificates on February 24; SSL.com followed on March 11. The compression trajectory is set and non-negotiable:</p><ul><li><strong>Now</strong>: 200-day maximum</li><li><strong>March 2027</strong>: 100-day maximum → <strong>3.5 renewals per certificate per year</strong></li><li><strong>March 2029</strong>: 47-day maximum → <strong>~8 renewals per certificate per year</strong></li></ul><p>For any organization with more than a few dozen certificates, this is an <strong>automation-or-outage inflection point</strong>. Manual renewal processes that work at 200 days will fail catastrophically at 100 days. The 200-day window is your transition period — use it to implement ACME-based automation before the 2027 deadline makes it mandatory.</p><hr><h3>PQC: The Other Cryptographic Deadline</h3><p>Multiple sources converge on the same warning: <strong>harvest-now-decrypt-later campaigns are actively collecting encrypted traffic</strong> today for future quantum decryption. Keyfactor CSO Chris Hickman estimates U.S. economic exposure exceeds <strong>$3 trillion</strong>.</p><p>What makes this more than a theoretical risk is the <strong>scope of the migration challenge</strong>. Post-quantum cryptography doesn't just mean upgrading TLS certificates. It requires reaching every cryptographic dependency — and that now includes <strong>authenticating thousands or millions of AI agent identities</strong>, a dependency most organizations haven't inventoried.</p><table><thead><tr><th>PQC Readiness Dimension</th><th>Current State (Most Orgs)</th><th>Migration Complexity</th></tr></thead><tbody><tr><td>TLS / Web PKI</td><td>Classical RSA/ECC</td><td>Medium — tooling exists</td></tr><tr><td>VPN / Site-to-Site</td><td>Classical IKEv2/IPsec</td><td>Medium — vendor dependent</td></tr><tr><td>AI / Machine Identities</td><td>Unmanaged / uninventoried</td><td>High — scale + visibility gaps</td></tr><tr><td>Supply Chain / Partners</td><td>No visibility</td><td>High — contractual + technical</td></tr></tbody></table><blockquote>Even if your organization migrates to PQC perfectly, data transiting partner networks using classical-only crypto remains harvestable. PQC is a supply chain problem, not just an internal one.</blockquote><p>The recommended approach is a <strong>hybrid model</strong>: bridging classical and NIST-standardized quantum-resistant algorithms during transition. Prioritize data flows that must remain confidential for 10+ years — IP, M&A activity, customer PII — for immediate hybrid PQC deployment.</p><p>The upside of TLS automation: infrastructure capable of automated certificate rotation can also <strong>rotate to post-quantum algorithms</strong> without manual intervention when the time comes. These two deadlines are converging, and solving one accelerates the other.</p>

   Action items

   • Complete a full certificate inventory across all environments by end of April, including AI agent and machine identities, and identify current maximum validity periods
   • Evaluate and select ACME-compatible CA and automation tooling with a target of 100% automation by Q4 2026 — well before the March 2027 100-day deadline
   • Implement hybrid PQC encryption on your highest-sensitivity data flows (IP, M&A, customer PII at rest and in transit) using NIST-standardized algorithms
   • Add PQC readiness assessment to vendor risk questionnaires and include cryptographic standards requirements in new contracts

   Sources:GlassWorm is force-pushing malware into your Python repos right now — plus a CVSS 9.8 in your Aruba switches · Your PQC migration clock is ticking: 'harvest now, decrypt later' attacks are active while your supply chain stays exposed

4. 04

   OpenClaw RCE Hits 15K Instances While AI Agent Security Gets Its First Price Tag: $182M

   <h3>The Vulnerability, the Data, and the Market Signal</h3><p>Three converging data points quantify the AI agent security gap for the first time this week:</p><ol><li><strong>CVE-2026-25253</strong>: A confirmed RCE in OpenClaw affects an estimated <strong>15,200 externally exposed instances</strong>. AWS launched managed OpenClaw on Lightsail with Bedrock integration the same week — expanding the attack surface at the worst possible time.</li><li><strong>23% prompt injection success rate</strong>: Research against OpenAI's Operator agent shows nearly 1 in 4 prompt injection attacks succeed against a production agent with browser and filesystem access. This is against <em>one of the most well-resourced AI companies</em> — baseline success rates against less mature deployments are almost certainly higher.</li><li><strong>$182M in security funding</strong>: Kai raised $125M (Evolution Equity Partners) and Surf AI raised $57M (Accel) specifically for agentic AI security, confirming VCs see this as a large unsolved problem — which means your existing security stack doesn't cover it.</li></ol><h4>The Architectural Problem</h4><p>Jensen Huang stood on the GTC stage and <strong>publicly called out security vulnerabilities in OpenClaw</strong> while pitching Nvidia's NemoClaw as the enterprise alternative. China's cybersecurity agency separately declared OpenClaw <strong>"totally insecure."</strong> When a $4 trillion company's CEO and a nation-state's security agency agree something is broken, believe them.</p><p>The combination of RCE + supply chain risk + overly permissive agent permissions creates a <strong>triple-threat scenario</strong>: exploitation gives attackers not just code execution, but the agent's full operational scope — file system access, browser sessions, API credentials, and sub-agent delegation chains.</p><blockquote>Enterprise AI agent adoption is bottlenecked by permissioning, sandboxing, and regulatory caution — not model capability. The security gap is the constraint, and it's now priced at $182M by the VC market.</blockquote><h4>What's Different From This Week's Earlier Agent Coverage</h4><p>Previous briefings covered agent terminal access patterns and NemoClaw's launch. What's <strong>new today</strong> is the convergence of a specific RCE CVE with quantified prompt injection success rates and venture funding that confirms the gap is real, not theoretical. OpenClaw now has a known vulnerability, a quantified attack success rate, and a market valuation of its security deficiency — all in the same week.</p>

   Action items

   • Scan all environments for OpenClaw instances including shadow deployments, developer workstations, and CI/CD pipelines — patch or isolate any instance exposed to CVE-2026-25253 before the weekend
   • Establish an AI agent security policy gate: no agent deploys to production with browser, filesystem, or API access without a security review covering scoped credentials, prompt injection hardening, and data flow mapping
   • Evaluate Kai and Surf AI for POC if deploying agents at scale, and assess NemoClaw's OpenShell restrictions as a baseline containment framework
   • Block Solana RPC endpoints at the network perimeter for non-crypto environments to disrupt GlassWorm's blockchain-based C2 channel

   Sources:OpenClaw RCE (CVE-2026-25253) hits 15K instances — and AWS just put it on Lightsail · OpenClaw security flaws flagged by NVIDIA's CEO · Computer-using AI agents just hit proliferation phase · AI agents are getting system access faster than your security controls · Your Cortex XDR agents below 9.1 are blind to half your BIOC rules — and GlassWorm is in your dev toolchain