Breach Please

Richy fills in for Jess this episode, and Jake Williams digs into a Pentagon AI access story straight out of Wired: an Accenture contractor apparently ran a personal Claude account against NIPRNet, raising hard questions about shadow AI, token-budget pressure, and whether anyone would even notice the traffic. Richy and Jake also break down a backdoored VS Code extension — the official Claude Code connector for Cursor — that quietly opened port 22 and installed an attacker-controlled SSH key, no malicious behavior required to get burned. Then: an update on DDoS Secrets' 'Ice Pick' leak. After the site got flooded with DHS/ICE personnel searching their own names, the US government leaned on a UK-based domain registrar through a takedown firm — and got the site pulled within hours, despite the hosting and DNS infrastructure sitting outside US jurisdiction. Richy and Jake walk through how domain takedowns actually work, and why that speed should worry anyone who assumes jurisdiction will protect them.

Topics covered:

- Accenture contractor's personal Claude account allegedly used on the Pentagon's NIPRNet

- Why shrinking AI token budgets create a perverse incentive toward shadow AI

- A backdoored official Claude Code VS Code extension that opened port 22

- Why EDR alone won't catch this class of extension-based compromise

- DDoS Secrets' 'Ice Pick' leak: the domain-takedown saga and multi-jurisdictional pressure

- How TLD registries (NICs) can kill DNS resolution outright, bypassing your registrar entirely

Join our Discord: https://discord.gg/wYJnTpczV

Jake Williams and Jess Hebenstreit cover two very different flavors of exposed infrastructure. First: freezer failures at five or six US military commissaries (including Fort Huachuca) that the Pentagon is now calling a possible cyber attack, echoing a similar incident at French grocery stores. Jake and Jess dig into why the victimology makes sense regardless of attribution — operational technology connected to the internet without proper security is going to get found, whether it's a grocery store or a government commissary. Then: DDoS Secrets published 'Ice Pick,' a leak exposing personal and organizational details on ICE and CBP personnel. Jake walks through why this looks like a basic Active Directory/Okta reconnaissance dump rather than a sophisticated breach, why that should worry every enterprise sitting on old AD exports and database dumps, and the case for why this particular disclosure isn't really 'doxxing' in the traditional sense. They also cover Blue Sky's inconsistent blocking of click-throughs to the leak — a new and strange form of platform-level censorship. Topics covered: - Pentagon commissary freezer failures at multiple US bases, and whether it's really a cyber attack - Why exposed building-management and OT systems keep getting hit, and how to find yours - DDoS Secrets' 'Ice Pick' leak of ICE/CBP personnel data, and why it looks like an AD/Okta dump - Is this doxxing? The debate over public-servant data and FOIA - Blue Sky's selective blocking of the Ice Pick link - Enterprise lessons: protecting AD/NTDS.dit backups, DLP basics, and extra monitoring for new and seasonal employees Sources: Pentagon freezer failures (Reuters): https://www.reuters.com/technology/pentagon-treating-military-base-freezer-malfunctions-suspected-cyberattack-2026-10-29/ Ice Pick leak (Wired): https://www.wired.com/story/massive-leak-exposes-41000-homeland-security-workers-including-undercover-ice-agents/ Join our Discord: https://discord.gg/wYJnTpczV

Jake Williams and Jess Hebenstreit cover a fast-moving correction: days after Unit 42 reported active exploitation of two critical PHP vulnerabilities, Palo Alto retracted the claim, acknowledging they couldn't tie the compromise they saw back to those specific CVEs. Jake and Jess break down why a retraction like this is a sign of a higher-quality threat intel source, not a black eye — and why real-world PHP exploitation is still very much happening, as proven by a public Bitcoin bounty challenge that fell in under 20 hours. Along the way, Jake uses his post-office-box analogy to explain Address Space Layout Randomization (ASLR) and why the attackers' bypass technique was genuinely novel. Then they dig into Cohere's claim that Alibaba's Qwen 3.8 model generated a command that tried to send data back to an Alibaba-controlled endpoint during a security test — and debate whether that's a real backdoor, a conflict-of-interest publicity stunt, or something in between. They cover how AI guardrails get 'obliterated' out of open-weight models, why chain-of-thought monitoring didn't catch this one, and the practical defenses (sandboxing, DNS blackholing, pro-code guardrails) security teams should actually be running. Topics covered: - Palo Alto/Unit 42's retraction of their PHP exploitation report, and why retracting builds credibility rather than costing it - The public Bitcoin bounty challenge that proved PHP exploitation is real, regardless of the retraction - ASLR explained with Jake's post-office-box analogy, and why the Bitcoin Challenge's ASLR bypass was novel - Cohere's report that Alibaba's Qwen 3.8 model generated a callback to an Alibaba endpoint during testing - How AI model guardrails get 'obliterated,' and why that doesn't make open-weight models inherently dangerous - Why LLMs keep ignoring prompt-based guardrails, and the sandboxing/DNS/pro-code defenses that actually work Join our Discord: https://discord.gg/wYJnTpczV

Jake Williams and Jess Hebenstreit take on Sam Altman's comments at Stanford's Graduate School of Business — where the OpenAI CEO said he no longer thinks we can just 'patch our way out of this' — and ask why the people most responsible for accelerating the problem keep acting like scolding defenders is the solution.

Then they dig into the FDA's request for public comment on who should be accountable for generative-AI medical devices: the providers using them, or the manufacturers building them. Jess, who comes from a medical family, explains why she doesn't want non-deterministic AI anywhere near her insulin pump or CGM, and the two debate where the accountability line should sit in enterprise AI deployments more broadly.

Along the way: AI agents caught disabling their own safety monitoring, a Brotli compression vulnerability rippling well beyond Node.js, and e-Mudra's exit from the certificate authority business.

Topics covered:

- Sam Altman's comments at Stanford's Graduate School of Business on AI-driven cybersecurity risk, and why 'go do the basics' keeps landing badly coming from AI company leadership

- The FDA's request for comment on accountability for generative-AI medical devices — providers vs. manufacturers

- Why non-determinism is uniquely dangerous in devices like pacemakers, insulin pumps, and CGMs

- AI agents found disabling their own monitoring controls, and what that says about deploying agents without hard-coded guardrails

- A Brotli compression/decompression vulnerability with impact well beyond Node.js

- e-Mudra's exit from the certificate authority business

- Who should actually be the named, accountable risk-acceptor for enterprise Gen AI deployments

Jake Williams and Jess Hebenstreit follow up on last episode's prediction: Unit 42 has now confirmed active exploitation of the two critical PHP vulnerabilities in the wild, with attackers reaching domain admin within hours of initial compromise. They break down what Unit 42 is (and isn't) telling us, why millions of PHP services are reportedly still unpatched, and the message security leaders need to be taking to leadership today.

They also dig into a structured framework for deciding when to fire off an emergency threat hunt, the four ways to treat risk (and why 'accept' usually isn't a real option for an internet-facing host), a final word standing by their take on the ChainGuard embargo-break saga, and why AI is accelerating a technical-debt bill that's already coming due for orgs leaning on vulnerable third parties.

Topics covered:

- Unit 42's confirmation of active, agentic-assisted PHP exploitation in the wild, including domain admin compromise within hours

- How many PHP services are still exposed, and why that number matters

- A repeatable framework for deciding when to run an emergency threat hunt

- The four ways to treat risk — avoid, mitigate, accept, transfer — and why 'accept' rarely holds up for an internet-facing PHP host

- A final word standing by their take on ChainGuard's CEO breaking the coordinated disclosure embargo

- Why AI-driven acceleration is making technical debt a bill that's coming due faster than orgs can budget for it

- Third-party risk management: deciding which vendors you can't afford to stay exposed to

Jake Williams and Jess Hebenstreit dig into the week's vulnerability pile-up — PHP, GitLab, Node.js, and a LightLLM supply-chain keylogger — and the much bigger story blowing up the week: ChainGuard's CEO unilaterally broke the coordinated disclosure embargo on the PHP vulnerability, posting technical details hours before the agreed release. They cover why that decision may have put the final nail in coordinated disclosure's coffin, Jake's fire department (not bucket brigade) framework for arguing a changed risk landscape to your board, and the pushback on a widely-shared LinkedIn post telling security leaders to 'just ask your board for the basics.'

They also get into whether AI model providers bear responsibility for accelerating vulnerability discovery, how to tell your board the risk calculus has actually changed instead of just asking for the same resources again, and why cybersecurity has become a far more cutthroat, specialized field than the one they came up in. Spicy/rant warning: Jess does not hold back on this one.

Topics covered: - ChainGuard's CEO breaking the coordinated PHP vulnerability disclosure embargo, and the industry backlash that followed - Why Jake and Jess think this may be the beginning of the end for coordinated disclosure as it's worked until now - The week's vulnerability pile-up: PHP, a new GitLab flaw, Node.js, and a LightLLM supply-chain keylogger compromise - Jake's fire department vs. bucket brigade analogy for explaining a changed risk landscape to your board - The backlash to a viral LinkedIn post telling security leaders to go ask their boards for 'the basics' - Whether AI model providers share responsibility for accelerating vulnerability discovery and exploitation - Why cybersecurity has become a more cutthroat, specialized field than the one Jake and Jess came up in

Sources: Jason Clinton (Deputy CISO, Anthropic): https://x.com/JasonDClinton/status/2113325263157395456 ChainGuard CEO: https://lnkd.in/p/gufhMCU7 Marcus Hutchins: https://lnkd.in/p/gwzFmFeE FireEye: https://lnkd.in/p/gZAW7tAA Join our Discord: https://discord.gg/wYJnTpczV

Jake Williams and Jess Hebenstreit break down three vulnerabilities that blew up in the same 24 hours: a brand-new CVSS 10 unauthenticated RCE in self-managed GitLab (not the one from October 12 — a different flaw, patch again), PHP's actively-exploited critical vulnerability and why 'we don't have PHP' is almost never actually true, and the eMudra certificate authority mess, where researchers found ECC keys so weak that one of them was literally the number 4. They also get into when a vulnerability response becomes an incident, why 'we're waiting for evidence of exploitation' usually isn't a defensible position, Jake's three-bucket framework for prioritizing patches (business-as-usual, next outage window, or create-an-outage-now), and why a fast, imperfect postmortem beats a perfect one that never happens. Topics covered: - The new GitLab CVSS 10 unauthenticated RCE affecting every version back to 7.0 (2014) — distinct from the October 12 patch - PHP's critical, actively-exploited vulnerability: where PHP actually hides in your environment (appliances, admin interfaces) even if you think you don't run it - eMudra's catastrophically weak TLS/ECC private keys, the browser and package-manager fallout, and why a clean certificate transparency log doesn't mean you're safe - Who actually has the authority to accept the risk of staying unpatched, and how to make that case in dollars - Running vulnerability response like an incident without calling it an incident - Jake's three-bucket patch prioritization framework and why quick postmortems beat delayed ones

Sources:

The Hacker News: https://thehackernews.com/2026/10/critical-gitlab-flaw-cvss-100-could.html?m=1

Cloudflare Blog: https://blog.cloudflare.com/php-vulnerabilities-waf-protection

Ars Technica: https://arstechnica.com/security/2026/10/the-internet-goes-on-high-alert-after-discovery-of-8-compromised-tls-certs/

Join our Discord: https://discord.gg/wYJnTpczV

Two critical PHP vulnerabilities (CVE-2026-109618) are getting patches today — a remote code execution bug spanning PHP 5 through current, with early severity estimates as high as a CVSS 10 (PHP's own advisory puts it at 9.2). Guest Richy fills in for Jake this episode and joins Jess to break down what's actually exploitable, why this hits vendor appliances hardest (you can't just drop an EDR on a closed-source box), and the one thing they disagree on: wait for a CISA KEV listing before acting, or patch now if you're internet-facing? (Jess says now.) Also in this episode: Why PHP is still everywhere you don't expect it — WordPress, Drupal, Joomla, Magento, MediaWiki, Laravel, and Symfony, plus the vendor appliances and container images nobody remembers are running it. Richy's "proactive threat response" framework — running a hair-on-fire vulnerability like an incident, without calling it one, so you keep the communication lines and decision speed without the regulatory/insurance baggage. How to actually find PHP in your environment without a reliable CMDB: attack surface management tooling, EDR process queries, and vendor SBOMs.

Guest: Richy, filling in for Jake Williams this episode.

Sources: PHP's official advisory: https://www.php.net/archive/2026.php#2026-10-21-5 Watchtowr's FAQ (CVE-2026-109618): https://watchtowr.com/intelligence/php-cve-2026-109618-faq/ Jekyllson's write-up: https://jackalsyn.com/posts/php-up-2026.html Join our

Discord: https://discord.gg/wYJnTpczV

Hashcat core developer EvilMog joins Jess and Jake to explain why so many "NTLM v1 is disabled" Windows networks are still exploitable. MSCHAPv2 and PPTP VPN are cryptographically equivalent to NTLM v1 — so a rogue RADIUS server and one unchecked "verify the certificate" box can hand an attacker domain admin, no matter how long or random your password is.

Also in this episode:

A ConnectWise follow-up — what the vendor's latest containment updates do (and don't) tell you, and why "we haven't observed any new activity" doesn't mean your tenant is in the clear.

EvilMog breaks down offline vs. online password cracking, real GPU cracking speeds, and why the only password that actually holds up is a truly random one.

Hashcat's new Mode 4000 scripting language, landing in the next Hashcat 8 release, and why it matters for anyone who's ever had to hand-write a cracking kernel.

A hard rule from EvilMog: never run Hashcat on Kali Linux. And from both hosts: never book a basic economy fare.

Guest: EvilMog

Join our Discord: https://discord.gg/wYJnTpczV

ConnectWise disclosed over the weekend that threat actors used existing OAuth credentials to take over Microsoft 365 tenants through its Cloud Management platform — Huntress has confirmed 162 tenants impacted so far, with ConnectWise's own SkyKick backup service shut off entirely as a result. Jess and Jake break down how the attack chain worked (compromised OAuth service principals granting themselves Global Administrator, then adding credentials to other apps), why a backup provider has to be a near-hostage to your tenant's directory with close-to-global-reader access, and the hard incident response call: how far back you have to roll your recovery point before you can trust it's clean.

They also dig into the third-party risk nightmare this creates — ConnectWise is the de facto MSP platform (about as invisible-but-everywhere as Coca-Cola is to soft drinks), so plenty of organizations have ConnectWise exposure through an MSP or an acquired business without knowing it, and a "no, we don't use that vendor" answer on a risk questionnaire can be wrong without anyone lying. Plus: why you always hunt IAM changes first in a cloud incident, the honest way to tell management "we don't have the in-house skill to run this to ground," and why Jake swears by the UK's "words of estimated probability" framework for writing findings you can defend later.