CrowdStrike published a report on that same arithmetic this week. A China-nexus group, tracked by CrowdStrike as VAPOR PANDA, ran an agent framework called ARTEX against more than 200 organizations in 14 countries over 11 days in a campaign apparently steered by a human operator. Elsewhere: the supermarket fridge attacks are back for a second round, a TV-box botnet shipped from the factory, and two more crypto heists. Also, from last week: Brotli and PHP2Shell, both now confirmed exploited, and an agent-security piece from Anton Chuvakin. On the leadership side, a UK government report with one very useful word in it. Let’s dive in!

Subscribe now

🛡️ Right Now

VAPOR PANDA: One Operator, 200+ Targets

CrowdStrike says VAPOR PANDA, a China-nexus group it has tracked since 2021, ran the ARTEX framework against more than 200 organizations in at least 14 countries starting October 17. Targets include foreign ministries in Latin America, the Middle East, and Europe, plus defense, semiconductor, pharma, and nuclear organizations in the US and telecoms in a few other countries. The models behind it are mostly DeepSeek, plus a second commercial model CrowdStrike couldn’t identify. ARTEX is the same framework behind the South Korean bank case from Issue #69, but CrowdStrike says this is a different operator from the Storm-0940 activity Microsoft reported earlier this month. In short, it looks like the framework is spreading.

AI-enabled attacks are quickly becoming old news, so what I find interesting about this story isn’t “AI did the hacking” - it’s the “human orchestrator” part. People are using these frameworks to run intrusions in parallel, at scale, with requests reportedly firing as often as every 10 seconds. This is, basically, a gatling gun: same attacker skill, same exploitation and post-exploitation techniques, but far more output per attacker. I’ll say again that if you’re defense is built on the assumption that a skilled adversary has scarce time and resources, it’s past time to revisit that assumption.

More coverage on this story from CyberScoop here.

Fridges, Round Two

In Issue #69 I called the Danfoss refrigeration attack “kind of boring.” The sequel is just as boring, which is kind of the point. SecurityWeek and The Hacker News report that overnight on November 2, attackers altered Danfoss refrigeration controllers at more than 100 stores in Belgium, Sweden, Estonia, and Ireland.

We know from the first wave that Claroty published the Danfoss vulnerabilities in August, with fixes, and BleepingComputer counted more than 4,500 Danfoss devices reachable from the internet on Shodan. Danfoss has said most affected French systems were older products that no longer get updates, but it seems like whatever got fixed after round one wasn’t the exposure. If you run refrigeration, HVAC, or building controllers (or your facilities vendor does), time to pull a list of everything that’s reachable from the Internet.

Brotli: A Fix in the Repo for Eight Months (and Now It’s Exploited)

CVE-2026-111497 is an out-of-bounds write in Google’s Brotli decoder (open-source, lossless data compression algorithm). If you’re searching for info, this bug goes by HTTP2Shell, Broccoli2Shell, and Node2Shell - never good when they get a name, right? The fix was committed to the Brotli source all the way back on February 27.

Last week I’d planned to write “no exploitation reported yet, so we have a head start.” Well, that didn’t last long. The Canadian Cyber Centre’s alert says CISA added the CVE to its KEV catalog on October 27. Help Net Security reports that ELLIO recorded in-the-wild exploit traffic with a public exploit that gets a shell on vulnerable builds.

Exposure depends on whether the software decompresses Brotli data an attacker can send. Microsoft notes Brotli decompression isn’t enabled by default in .NET or ASP.NET Core. If you can’t patch yet, block Brotli-compressed requests at the proxy or firewall, or turn off Brotli decoding altogether.

Short Hits

Per Krebs and SecurityWeek, Google and partners took down a botnet of 1.3 million Android TV boxes that came preloaded with proxy and ad-fraud software from the OEM/ODM Videostrong. The takedown also cut access to more than 10 million other compromised IoT devices from healthcare devices to karaoke machines. Don’t ignore cheap embedded hardware that shows up on your guest wifi or in the break room!

Two big crypto losses in one news cycle this week: Dark Reading frames the Binance theft as one compromised endpoint expanding through weak segmentation. Meanwhile, The Record reports Mercado Bitcoin confirmed a breach, with blockchain security firms estimating $46 million or more moved off-platform.

🎯 On Leadership

A Model Is Not a Boundary

Anton Chuvakin and Usman Chaudhary have published part one of a three-part series on agent security. They characterize an agent as a model + harness, with an execution layer around it. The model is non-deterministic and treats untrusted text as instructions, so it can’t be asecurity boundary nor is a second “guard” model an effective control. More alignment tuning doesn’t get you there, but (1) controlling what the agent is able to do via the harness AND (2) securing the hardness itself is a good start.

We see in the CrowdStrike story that attackers have a harness too, in ARTEX, as a main agent coordinating planner and worker agents. This may be boring, but like all good security, it’s a focus on fundamentals: scoped credentials, a tool allowlist, logging, human oversight, and a way to shut it off (I keep saying this).

So pick one agent your org runs or is evaluating. Where’s the line between what the model decides and what the harness will refuse no matter what the model says?

“Tolerated” Is the Word to Steal

The UK’s NCSC warned of an “unprecedented rise” in attacks in its annual report, with a line that vulnerabilities tolerated for far too long are now exploitable at new scale. There’s also a separate warning that UK critical infrastructure will face AI-driven attacks by 2028.

“Tolerated” is the operative term: just this week, we’ve tolerated a software fix sitting in a repo for eight months before inevitable discovery and exploitation. Fridge controllers are still reachable three weeks after a highly publicized attack. Most programs have a list of known, accepted exposures, and maybe the signatures on that risk acceptance are coming too easily. What’s your feeling on an expiration date for broad risk acceptance?

🔗 Connecting the Dots

Ok, back to the top - gatling gun goes brrrrrrrrrrrr.

None of this week’s stories are about how sophisticated and scary attackers have become - these are all tolerated-risk stories. When one operator can run 200 intrusions in 11 days, your tolerated list is an attacker’s punch list knocked out in a day.

A few things to do:

• Today: find every copy of Brotli (Node.js, .NET, PowerShell, Envoy, Istio, Python packages), rebuild container images, and reject Content-Encoding: br where you can’t update yet. Confirm PHP is at 8.2.35, 8.3.36, 8.4.27, or 8.5.12, including copies bundled in vendor software.

• This week: list every internet-facing building and OT controller (refrigeration, HVAC, access control), yours or a vendor’s, and take the management interfaces off the internet or behind a VPN.

• This week: check whether any segment lets consumer or embedded devices (TVs, conference gear) reach the internet unrestricted.

• Next 30 days: run a tabletop on lateral movement from one compromised endpoint to your most critical asset. Not a generic IR tabletop.

• Longer term: add vendor-supplied device integrity to third-party risk criteria, and write down, for one AI agent, what the harness will refuse regardless of what the model says. If that list is empty, you have your answer.

Subscribe now

Most jars of pasta sauce have a little button on the lid to show that no one opened the jar after it left the factory. That “tamper-safe” button doesn’t tell you what went into the jar at the factory. But we trust it anyway, because nobody is going to lab-test their marinara.

Security has its own buttons: code signing, certificates from a trusted CA, etc., and a retainer with an insurance-approved DFIR firm, things that say, “we’re good, you can sleep at night” (at least on a few narrow concerns). This week, we woke up to these buttons popped down; the sauce is bad! Is this metaphor still working?

Other developments: ConnectWise lost the app identities behind its Cloud Backup product, a WordPress plugin and a backup utility distributed malware through their update channels. Also: PHP’s emergency patch for two critical RCEs that leaked before the fix, a Palo Alto bug that ransomware crews have picked up, and a reminder that an IR retainer is a contract, not necessarily a guarantee.

Subscribe now

🛡️ Right Now

eMudhra: Eight CA Keys, One of Them “4”

Researchers reported on October 17 that the private keys for eight intermediate CA certificates from India’s eMudhra were compromised: six for TLS and two for code signing. The Hacker News has a decent writeup, and Google’s Chrome post points to insufficient randomness in the key generation tooling.

Per CoinDesk, Scott Helme says the keys were tiny integers, one of them literally the number 4, and that he recovered all eight from public certificates in under a second (!). This is one of those “you can NOT mess this part up” mistakes, especially for a CA. eMudhra says the certificates came out of a key generation ceremony in April 2025, which is supposed to be the most scripted, witnessed, and audited event in a CA’s life. Random number generation is the first thing you’d test. So how do eight keys like that sit in public certificates for about eighteen months? And what else did those audits check?

Chrome and Mozilla blocked within hours, Apple and Microsoft followed over the next three days, and Chrome is removing the root. No misuse has been reported, and Chrome found no rogue certificates in Certificate Transparency logs. So browsers are theoretically ok, but scripts are a different story. Helme says curl, Python, Node, Go, and Java all accepted a forged certificate for Stripe’s API in his tests, and many clients never check revocation, so revoking these keys doesn’t help them. Go shipped fixes for 1.27 and 1.26 (nothing for 1.25 and older), certifi and Rust’s webpki-roots have updated, and Node was still pending when I looked. So how many of your service-to-service connections trust a root store with no CT check and no revocation check? And which of them are too old to get a fix?

To recap: no root cause identified yet, and eMudhra says none of the affected intermediates issued certificates to end users or websites (one was deployed in production).

PHP: Two Critical RCEs Leaked Before the Patch

This one doesn’t fit the jar metaphor (it was a stretch anyway), but it’s the most urgent, actionable item in this issue. Details of two critical remote code execution flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, leaked ahead of the coordinated release which happened on Wednesday as scheduled. PHP’s security team rates both 9.2 on CVSS v4.0 and moved an emergency release up to Wednesday at 14:00 UTC. watchTowr says the leak is real and that it reproduced one of the two. Huntress is calling the pair “php2shell,” which basically tells you what a web request might get an attacker.

Claims that the range reaches back to PHP 5 are unconfirmed, and it’s a fair bet end-of-life branches won’t get fixes. On exploitation, Huntress and watchTowr had seen none as of Tuesday, while Patchstack says it has confirmed multiple incidents. Everything old is new again: PHP sits under WordPress, Drupal, Joomla, Magento, and Laravel. So it’s not just servers, but control panels, vendor appliances, and bundled stacks.

Inventory first, then patch internet-facing systems if you haven’t already. For hunting, Huntress suggests alerting on PHP worker processes (php-fpm, php-cgi, apache2, httpd) spawning shells, interpreters, or download tools, and on recon commands like whoami and uname -a coming from a web server.

ConnectWise Cloud Backup: The Credential Was an App

ConnectWise disclosed a possible supply chain incident on October 16 involving “unauthorized access to application identities” tied to Cloud Backup (formerly SkyKick). It disabled the service the next day, later pulled SaaS Security and Cloud Management, and says it has revoked certificates and rotated credentials. The Record has more.

ConnectWise says it has no confirmed downstream customer compromise, and notes it can’t see inside customers’ Microsoft 365 tenants anyway. Huntress reports that sign-ins from one IP address touched more than 1,000 Entra tenants, and more than 300 succeeded. In two tenants, the attacker persisted by promoting the ConnectWise app to Global Administrator and adding credentials.

What was stolen here was an app secret, not account creds, and a backup app needs pretty broad access (Exchange, Teams, SharePoint, Graph) to function properly. If you use an MSP, ask them whether they use this product rather than waiting for a notification. Then look at the enterprise apps in your own Entra tenant: what do your backup and SaaS-management vendors hold, and who last reviewed it?

Two More Poisoned Update Channels

BleepingComputer (with The Hacker News and SecurityWeek) reports that Rank Math PRO v3.0.123, a popular WordPress SEO plugin, went out from rankmath.com and via auto-update between 20:02 UTC on October 15 and 07:12 UTC on October 16, with a hidden, self-restoring backdoor. If you can’t easily say which WordPress plugins and versions you run, that’s your first problem (or maybe it’s running WordPress, and the plugin thing is your second problem).

BleepingComputer also has the story on an attack involving Windows and iPhone backup software AOMEI, where attackers changed two config files in the promo and notification system, pointed it at a malicious ZIP, and changed the expected checksum so the download verified cleanly. Then they put the files back. The exposure windows were reportedly 10, 6, and 5 minutes, between May and July, and it’s only coming to light now.

Palo Alto PAN-OS: Old Bug, New Crews

CVE-2026-0257 is an authentication bypass in PAN-OS GlobalProtect portals and gateways. It isn’t new, but who is using it is. Unit 42’s updated brief ties exploitation to ransomware affiliates (Qilin and, per the update, Inc), and other outlets report Qilin affiliates using it for VPN access.

Short Hits

Siemens Software Center is being abused in ClickFix campaigns: a genuine signed Siemens executable, paired with a malicious DLL through sideloading. Detection logic that leans on “unsigned binary equals suspicious” misses this kind of thing. And Ahold Delhaize confirmed “malicious actions” that forced systems offline across most of its US and European brands. Details are sparse, but for retail, it’s a moment to reflect on recovery speed and customer communications.

🎯 On Leadership

Your IR Retainer Is Not a Reservation

Reuters reported this week on the uptick in breaches, driven by AI tooling. Rob Joyce added a point on X about incident response firms being overloaded by the volume (not mentioned in the reporting).

This sentiment lines up with something John Hubbard and I are updating in SANS LDR551 right now. Having a retainer is no guarantee of availability. Whether it gets you responders when everyone else is calling too depends on what it says and what the provider has in capacity. So this is a good time to pull the contract and call your provider. Questions I’d ask:

• What does the response time commit to: a call back, a scoping call, or someone working in your environment?

• Remote only, or can they get onsite? Does the clock differ when you activate versus when your insurer does?

• What happens to your commitment when the provider is in surge? Is there a priority tier, and are you in it?

• Do you get a named team, or whoever’s free?

I haven’t seen any data on Rob’s claim, but he isn’t one to catastrophize.

🔗 Connecting the Dots

A signed update, a CA’s certificate, a vendor’s credential, and a retainer each tell you one narrow thing: will we be ok? Who delivered this thing, who will vouch for it, who is allowed in, or who you can call. We keep reading all of them as “safe,” and this week the gap between the label and the contents got a lot of attention. The folks who make the safety “buttons” have had a bad few days.

A few things to do this week:

• Pull your IR retainer contract and call the provider about capacity and response times when it’s activated.

• Inventory every PHP install, including ones bundled inside vendor software and control panels.

• List the non-browser clients that talk to external APIs (scripts, Go and Node services, Java apps, curl in cron jobs) and check which root store and Go/Node/Python version each uses.

• Ask your MSP and RMM vendors whether they use ConnectWise Cloud Backup, and review the Entra enterprise apps your backup and SaaS-management vendors hold.

• Pull Rank Math PRO versions across your WordPress estate (anything installed or updated between 20:02 UTC October 15 and 07:12 UTC October 16 is compromised), and patch PAN-OS for CVE-2026-0257 now.

Subscribe now

This week we saw a version of that: a ransomware negotiator was arrested in connection with the group that stole FBI data. Elsewhere, a SonicWall bug did exactly what I said it would last issue, which is a good excuse to dig into a new report on how fast attackers are moving. And someone turned French supermarket freezers into ovens, a reminder of why management interfaces don’t belong on the internet, and our 1,000,000th reminder that security by obscurity doesn’t work in the AI era.

Subscribe now

🛡️ Right Now

SonicWall SMA 1000: Exploited Within Days

Last week, I mentioned SonicWall’s unauthenticated SSRF in SMA 1000 appliances (CVE-2026-102255) and said it wouldn’t be long before we started seeing active exploitation (not an earth-shattering prediction, but I’ll take a W where I can). The Hacker News and SecurityWeek have both reported exploitation attempts within days of disclosure.

Is “days” fast? Root Evidence’s Vulnpocalypse Report traced every CVE with confirmed exploitation in CISA KEV and VulnCheck KEV from January 2018 through mid-July 2026: 3,769 out of 253,912 published (1.5%). The report’s thesis is that AI has had the biggest impact for the people finding bugs, not the people using them. CVE volume is climbing, but the share adversaries actually exploit has stayed between 1.3% and 2.0% every year since 2021.

SonicWall makes a good test case of that assertion for two reasons. First, SonicWall shipped a patch before the disclosure. That makes this an n-day, and adversaries exploit n-days 81% of the time (3,058 of 3,769). True zero-days run about one in five, a ratio that has remained pretty steady since 2021.

Second, “how long do we have?” has two answers. The report’s median wait between patch and first exploitation was 116 days in 2026, up from 24 in 2018. But the median hides two groups: of the 391 n-days first exploited in 2026 so far, 33.5% were hit within 30 days of the patch, and 30.4% took more than a year. Of course, the SMA 1000 bug is in the first group.

The Root Evidence report puts SonicWall, Oracle, and D-Link at a 225 to 235 day median wait in 2026. SonicWall also appears among the vendors whose bugs were exploited the same day a patch shipped (n-days). So it’s safe to say that attackers move fast where tooling exists and the target is popular, and a pre-auth, internet-facing, CVSS 10 gateway is a very popular kind of target.

The report’s three-tier “count less, prioritize more” advice aligns to the problem with the SMA 1000 vuln and the like:

• Same-day: compensating controls have to exist before the advisory publishes.

• Within 30 days: you need an enforceable patching deadline.

• Everything slower: you need a prioritized selection process, because there’s too much coming out to tackle everything.

Danfoss Refrigeration Controllers: Cyberwar is Here, and It’s Kind of Boring

Overnight Sunday into Monday, attackers hit 150 to 200 Intermarché stores in France, plus Coopérative U and, reportedly, other chains. They remotely triggered the defrost cycle on Danfoss refrigeration controllers at a 50°C setpoint, spoiling the food stored inside. Still awaiting details on how the attackers got in, but there are mentions of “older Danfoss software versions”.

The incident comes right after Claroty Team82’s research on Danfoss AK-SM 800A system managers, presented back in August, where researchers found thousands of management interfaces reachable from the internet. A Censys scan counted 2,765 exposed AK-SM 800A devices. I don’t think there is evidence yet that the associated CVEs were used in France, but it does look like the pattern described above: the fix was out there long before the attack.

There’s been a lot of hype around cyber-physical attacks, some of it justifiable, but this is the kind-of-boring-could-have-been-worse scenario for society writ large, compared to other possible supply chain attacks. If you run refrigeration, HVAC, or building controllers, yours or a facilities vendor’s, the first control is also rather boring: take those management interfaces off the internet!

Agents on the Offense: Early Anecdotes

Two stories this week put Claude-based agents in real attacks. The Hacker News reports CyberXero, a campaign against WordPress sites, e-commerce, and critical infrastructure in Ukraine that pairs Cobalt Strike with Claude Code for orchestration and has stolen more than 628,000 records. BleepingComputer covers a Chinese hacker who reportedly used the ARTEX AI pentest suite and Claude agents against South Korean banks. The Root Evidence data through July doesn’t show adversaries getting faster yet, but these stories indicate a larger trend in that direction.

🎯 On Leadership

The Vendor As Inside Man

SecurityWeek, BleepingComputer, and Krebs on Security all covered the arrest of Edward Dubrovsky, co-founder of a ransomware negotiation firm. He was picked up in Pennsylvania while at a conference, in connection with the FBI’s investigation into ShinyHunters stealing data on FBI agents.

Negotiation and IR vendors see your data, your options, and how badly the incident is impacting your business. Most vendor due diligence asks about technical capability, insurance, and references. Contracts rarely require vetting the vendor’s staff and subcontractors. If you have an IR or negotiation retainer, pull it and look for:

• Background checks and ongoing screening for the people who would work your incident.

• Subcontractor disclosure, including who gets access to your data and logs.

• What happens to your data and communications after the engagement ends.

• A duty to tell you when someone on your engagement is under investigation.

One arrest doesn’t indict an industry full of super trustworthy, professional people, and background checks are obviously an imperfect control for cases like this. But I’d still ask the questions, because they were fair before this week and many of us haven’t asked them. A possible opportunity to expand your insider threat program to include security vendors and contractors, if nothing else.

🔗 Connecting the Dots

None of the stories covered this week are new or exotic, and I was happy to take a break from the AI-of-it-all. These are trust and speed issues: who has access to your systems and data, and how fast can you move once the adversary has the same information you do? The SonicWall hotfix and the vendor contract are the things you can actually work on this week.

A few things to do:

• Today: confirm SonicWall SMA 1000 patch status across the estate, and check who can reach the appliance. While you’re at it, take a closer look at all of your edge infrastructure.

• This week: find every connected device and management interface that faces the internet (yours or a vendor’s), and assign a system owner to restrict access under deadline without impacting business processes.

• This week: pull your IR retainer and ransomware negotiation contracts. Ask who vets the vendor’s staff and subcontractors, what data access is required, and what happens to your data after the engagement is over.

• Next 30 days: sort last quarter’s exploited-in-the-wild CVEs by how fast you remediated them. How many did you close inside 30 days?

• Longer term: add insider-risk and chain-of-custody questions to your vendor due diligence criteria, alongside technical capability vetting.

Subscribe now

In 1696, William Kidd sailed from New York with a royal commission to hunt pirates and a letter of marque to take French ships - an endeavor backed by some of the most powerful men in England. Five years later, Kidd was hanged in London as a pirate. There’s some disagreement on whether this was because of his actions, or his backers needing someone to blame after the optics changed. If the question here is “who’s accountable?”, the answer was…whoever was easiest to hang?

This week, Anthropic formalized a tiered program giving vetted security teams access to its models with fewer guardrails, which is kind of a letter of marque. And Wikimedia published details on OpenAI-run agents that edited its wikis, tried to turn its tools into proxies, and hit its APIs with millions of requests, all without explicit approval. When an agent does something without authorization, who’s responsible for the outcome? Also: an Atlassian bug that spits out credentials, ClickFix changing costumes again, and the agent accountability question from a few angles, including what boards are actually paying for.

Subscribe now

🛡️ Right Now

Atlassian Pre-auth File Read Bug

Atlassian has disclosed CVE-2026-21589, a pre-auth arbitrary file read bug in Jira, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd, Crucible, and Fisheye. Cloud instances are already patched; Atlassian says there’s no evidence of exploitation, and points out that an attacker needs to know the exact path of the file they want. Probably a poor assumption that this will drive up costs for attackers with decent automation at their disposal, as discussed in last week’s issue.

If you’re running these on prem, time to restrict access, patch, and rotate any credentials used with them.

ClickFix Keeps Evolving

ClickFix is on its fourth or fifth costume change of the year. In one, reported by Flare, the pasted PowerShell command queries a DNS TXT record for its next instruction, so the actual payload never gets written to the clipboard. In the other, from Microsoft Threat Intelligence, the lure page pre-fetches the payload into browser cache disguised as a PNG, and the Run dialog command executes it from there. I gave a talk at Black Hat last month on how we detect this kind of thing very effectively at Push by focusing on the mechanic instead of the content, and we recently published an extensive breakdown of ClickFix-style attacks on the Push Security research blog. If your ClickFix analytics are written against specific strings or regex, you might want to revisit in light of these new obfuscation methods.

One More for the Patch List

SonicWall has shipped hotfixes for a max-severity, unauthenticated SSRF in SMA1000 appliances, CVE-2026-102255. No exploitation reported yet, but knowing how often SMA1000 bugs get picked up, I wouldn’t count on that lasting long.

🎯 On Leadership

Wikimedia Discovers Agent C&C

Via SecurityWeek: Wikimedia found agents run by OpenAI making edits on its wikis, trying to use its citation tool and Etherpad as proxies to fetch outside content, and generating millions of API requests and hundreds of thousands of Wikidata Query Service queries. Wikimedia’s bot policy requires approval before automated editing, but in Wikimedia’s words, “none of those approvals were sought.” This is the same issue we covered in the last issue around eval sandbox escapes. SecurityWeek also ties the report to thousands of edits on a German wiki going back to May - sooo, a pattern, visible across several organizations, for months.

Hot off a week of teaching SANS LDR551, it strikes me that these “incidents” aren’t breaches the way your IR plan might define one. When something like this happens, do you have a playbook? Who do you call? Is this a vendor issue, a legal issue, or an incident? What do you block, and what breaks if you block traffic to/from a frontier lab? Can your telemetry even tell an agent from a person with a script?

Anthropic Updates CVP

Anthropic has folded its Cyber Verification Program and Project Glasswing into a single three-tier program:

• Defense Access for SOC, IR, malware analysis, and vuln research, open to security teams, maintainers, and individual researchers.

• Red Team Access for organizations testing systems they own or are authorized to test, with real-time blocks still in place for things like ransomware deployment.

• Specialized Access, with minimal cyber restrictions, for a small number of organizations testing safety-critical infrastructure, vetted with the U.S. government.

Seems reasonable to me. Attackers are going to get this capability one way or another, and a tiered, vetted program beats pretending guardrails are going to stop anyone. But it is also, basically, a letter of marque. It shifts accountability onto the vetting and the credential. What happens when a Red Team Access account gets phished, or a vetted contractor points it at something out of scope?

Washington is having a more literal version of this debate. In August, a presidential memorandum cleared vetted private firms to run offensive operations against foreign criminal groups. The Pentagon’s new cyber strategy leans toward contractors for offense and tooling. Per POLITICO’s reporting, part of what’s driving these policy shifts is that private-sector AI models are getting better at finding and weaponizing flaws than human hackers. I’ll save the full cyber-privateering debate for another issue. The point here is that the government is wrestling with the same question as the AI labs, just with higher stakes (?): once you’ve signed the paper, who answers for the consequences?

Google PageBreak Finds Hundreds of Web App Flaws

Dark Reading covers PageBreak, an internal agent that found more than 500 XSS flaws in Google’s web apps. This design appears, at least on the surface, a bit more constrained than what we’ve seen elsewhere: the LLM proposes a finding, and then a set of non-AI, deterministic validators fire a real payload at a running environment to validate the finding before it gets escalated. Google claims a near-zero false-positive rate.

And Then, There’s the Money

In a Dark Reading interview, IANS’ Nick Kakolowski says most CISOs don’t expect AI to shrink their teams. The plan is to automate entry-level SOC work and move juniors up faster. I think the problem here is that a lot of budget increases are being eaten by vendors charging more for AI features they’ve bolted on. And boards, after a year of “invest in AI so we don’t fall behind!” have started asking whether they’re getting efficiency gains. Better late than never?

If your budget increase is paying an AI surcharge on tools you’ve already got, that budget isn’t going to identity hygiene, expanding monitoring coverage, or more people. Every agent story in this issue is basically an identity and monitoring problem: whose credential is that, can we see what it’s doing, and what do we shut off when it does the wrong thing? And while I appreciate the “automate the junior work” plan, junior analysts doing routine triage is how you end up with senior analysts. I’m not sure anyone has worked out what replaces that apprenticeship yet, and we don’t want to automate it away.

🔗 Connecting the Dots

Ok, back to Captain Kidd. Privateering ended because accountability breaks down once ships leave port. AI agents are leaving port (stay with me) with paperwork right now, and so, it seems, will some contractors. Nearly every story this week comes back to identity and visibility, and accountability: a config file leaking identity-system credentials, external agents nobody has approved to touch their stuff or use their infrastructure, and access tiers that are only as strong as the credential(s) used to get to them.

A few things to do this week:

- Inventory internet-facing Atlassian Data Center instances against CVE-2026-21589. Patch, then rotate anything stored in `crowd.properties` and database configs on exposed hosts.

- Find out who in your org is running AI agents (pentest, coding, SOC automation, a vendor’s new “autonomous” feature). Check whether each one has its own credential, a named owner, logging, and a way to revoke it. If the answer is “it uses Dave’s API key,” start there. Speaking of, I have some scripts to update.

- Add “a reputable third party’s agent is misbehaving against us” to your next tabletop. Decide ahead of time who you call and what you’re willing to block.

- Before you renew anything with a new AI line item, ask what verifies the AI’s output, and whether that money would do more in identity or detection coverage.

Subscribe now

Welcome to Issue #67 of Security Leadership Weekly.

In December 1942, Enrico Fermi’s team at the University of Chicago got ready to start the first self-sustaining nuclear chain reaction. Before they did, they built the way to stop it: control rods and, as the story goes, a man named Norman Hilberry standing by with an axe to cut the rope holding an emergency rod - a kill switch.

This week: a file-transfer vendor asked its customers to "throw the switch” based on a tip from federal authorities, an FBI breach and some serious drama, and an AI agent that may not have hacked anything (!). On the leadership side, two pieces on why AI doesn’t let you skip the parts of security that depend on knowing your own environment, and a short checklist to follow up on within the next week.

Subscribe now

🛡️ Right Now

Kiteworks Asks Customers to Shut Down

Last Friday, Kiteworks emailed self-managed customers and asked them to shut their systems down temporarily, after receiving word from the authorities that a threat actor might go after some customer systems. The company said it knew of no compromise and no unpatched vulns in the current release, and lifted the request on Sunday. Heise, the German news outlet that originally broke the story, heard that even systems not exposed to the internet were included in the customer notifications. File transfer services have long been favored targets, so I think at the very least it’s a defensible call - better that than saying nothing and putting unknowing customers at risk.

But it got me thinking: could I have done something like this as a customer CTO? File-transfer systems tend to be part of internal solutions for payroll processes, vendor management, regulatory submissions, and all sorts of other business processes. BC/DR plans usually cover what happens when a system like this fails, but not always a voluntary shutdown without a confirmed incident within a few hours. We might not ever find out what the tip was, but if nothing else, this sounds like a decent tabletop opportunity.

FBI and ShinyHunters Square Off

ShinyHunters says it took two to three terabytes of FBI employee data and wants the bureau to retract a May public warning about the group (an extortion demand for a press release correction, that’s new). In its own statement, the group framed the whole thing as payback: it called the FBI’s May FLASH report “false allegations” and “disinformation” and demanded a retraction before it would stand down. It also defaced the FBI’s jobs site and, per BleepingComputer, told reporters it used a new Oracle PeopleSoft zero-day to get in Monday night and pivot into FBI-managed AWS GovCloud infrastructure, none of which the FBI has confirmed. Since the original story broke, SH has seemingly backed off of their threats to disclose the data publicly.

Reuters ran the sample data against credit bureau records and a dark-web archive and found matches in at least nine or ten cases, including one that appeared to line up with FBI Director Kash Patel. The fuller sample Reuters reviewed included names, Social Security numbers, and assignments, some to counterespionage units. The FBI says it’s investigating unauthorized activity affecting FBIjobs.gov. The takeaway for the rest of us is that recruiting and HR systems make for great targets - when’s the last time you audited yours?

Breaking Out or Following Directions?

Australian Prime Minister Anthony Albanese has claimed an OpenAI agent gained unauthorized access to non-public files on a government health portal by working around blocks. Recorded Future News found that the portal’s own archived JavaScript pointed visitors at an unauthenticated guest endpoint, so the agent may have just done what the site told it to. Separately, non-profit research lab Transluce reported similar agent swarms using SQL injection, path traversal, and command injection on other sites while doing plain data retrieval. OpenAI says much of that overlaps with its ongoing review of misaligned model activity and expects it to take months.

Both things can be true. An agent following a site’s instructions isn’t a hack. An agent that reaches for SQL injection while fetching a table is definitely a problem, and (as discussed in the last issue of this newsletter) it falls to whoever built the agent. If you run agents, or let them touch your systems, decide now where their activity gets recorded and who can read it.

The Kill Switch

“Shut it down” seems to be a running theme these days. California's governor signed an executive order pushing a mandatory "kill switch" for frontier models with third-party validation. Congress has its own version under consideration. This follows the OpenAI HuggingFace incident, plus many other reported “breakouts,” plus a LOT of FUD from all directions.

A Nextgov commentary makes a great point: a kill switch is a last resort, not a control system, and it doesn't reach models running outside your jurisdiction or off someone else's open-source weights (read: easier said than done, and it’s not a panacea). More to the point, flipping it doesn't undo anything. Plus, as with the Kiteworks advisory, a mechanism to stop something often doesn’t include what to do once it’s shut down.

🎯 On Leadership

Anton Chuvakin is back in the newsletter (he keeps writing things I agree with). His question: can AI let a low-maturity SOC jump maturity levels? His answer is “only the boring half.” AI can produce the artifacts of a mature SOC in an afternoon: playbooks, parsers, baseline detections, dashboards. It can’t produce what a mature SOC has learned about itself in terms of capability and maturity growth. His test is fairly simple: does this element exist because someone had to spend time, or because someone had to learn something about us? He also notes that skipped stages used to fail loudly and now fail quietly, because the agent writes a plausible investigation around the gap. He mentions a CMM-type framing in this post, and this is why I really like Rob Van Os’ SOC-CMM, which measures both maturity (including process maturity, easy to jump by creating artifacts) and capability (gained through time and hard work).

What if we run this test on the Kiteworks issue? What depends on this system, and who signs off on turning it off? No agent is going to write this down, and it probably requires a human with experience and the ability to anticipate.

Phil Venables makes the companion point in Autonomic Defense, which we covered last week. Use AI to defend against AI, but not instead of a strong and rising baseline of controls. Speed alone won’t do it either. By Ashby’s Law, only variety can absorb variety, so a defense built on static playbooks, even automated ones, gets outmatched by attackers who can generate many paths.

🔗 Connecting the Dots

Back to the axe man. Fermi’s team had the kill switch, but they also knew what the reaction depended on, who was standing where, and what would happen when the rope was cut. Voluntary shutdowns, agent “breakout” investigations, and data breach response all get easier if you know what you have, what it touches, and who ultimately decides.

Things to try/consider this week:

• Pick your top three edge or file-transfer systems (managed file transfer, VPN, load balancers). For each, write down what depends on it, who can approve shutting it down, and how long it takes to bring back.

• Find out who holds your people data - does that list include Recruiting and HR platforms?

• Decide where AI agent activity logs before you need them!

Subscribe now

Welcome to Issue #66 of Security Leadership Weekly. This week: the (AI-powered!) intelligence failure that almost led to a kinetic strike, three more failed AI “sandboxes”, poor account hygiene, and why "nobody's going to bother checking that" is no longer a safe bet.

Subscribe now

🛡️ Right Now

AI Intel Almost Triggers Kinetic Attack

This week’s first story isn’t about cybersecurity, but it’s a real-world example of the AI risks we’re dealing with. Per CNN, a special operations command analyst asked an AI chatbot to synthesize open-source intelligence with secret signals intelligence concerning the cargo of a Chinese ship. The chatbot concluded the ship was carrying components of a nuclear weapons program; only, it wasn’t. The assessment got far enough that a boarding operation was prepared and aircraft were launched before the faulty intel got flagged. OSINT often includes rumor and hearsay, and it probably isn’t shocking in 2026 that an AI system was given such broad synthesis authority. The problem, of course, is that no one verified its output before acting on it. And this isn’t a one-off. The Pentagon’s own AI platform, GenAI.mil, just expanded on September 1 to include government versions of ChatGPT and Grok alongside Gemini; roughly 3 million military and civilian workers are now eligible to use it. Gen. Mark Hertling (Ret) had some interesting comments on this incident over at The Bulwark, which echo what a lot of us are saying about AI-powered attacks: these aren’t new problems, just old ones happening much faster and at scale.

More Breakouts, Shrinking Exploitation Windows, and AI On Both Sides of the Alert Queue

Meanwhile, in tech:

• Not to be left out, Google’s Gemini breached a real production system during a security evaluation run by Irregular, reportedly due to a “test domain mix-up.”

• Claude Opus 5 chained a bug in OpenAI’s help forum into a full takeover of OpenAI staff accounts during a separate evaluation run by Hacktron researchers. Risky Biz discussed this kind of scenario a while back, where the concern isn’t as much AI finding a silver bullet exploit as much as its ability to chain multiple primitives together that a human attacker may not have figured out yet.

• Prophet Security released its Q3 2026 threat report, in which the HuggingFace incident gets a brief mention; post-incident, forensic analysts used their own AI (a self-hosted open-weight model) to assist in the response, where frontier labs refused to process payloads used in the attack - the point being AI tooling is now “on both sides of the alert queue”.

• The Hacker News reports CrowdSec disclosed that an ex-employee’s GitHub access, never revoked after they left, enabled an attacker to copy roughly 170 private repos. The initial foothold was the TanStack npm supply-chain attack, which compromised the former employee’s laptop months earlier - a miss that might once have been resolved by a security audit before discovery by an attacker. Again, this isn’t an evolutionary leap so much as a shrinking exploitation window.

Many of these are run-of-the-mill failures in governance and security best practices. The Frontier Labs aren’t doing proper segmentation and instrumentation; we’re still falling down on account hygiene; and accounts aren’t being disabled as part of employee off-boarding. Exploiting these doesn’t require AI at all, but it sure makes the process much faster, easier, and more comprehensive.

Honorable Mention

Dark Reading has a maximum-severity Cisco Identity Services Engine authentication bypass (CVE-2026-76460, CVSS 10.0), and The Hacker News has a pre-auth RCE in Orkes Conductor already confirmed exploited (CVE-2026-58138). Both are pre-auth and should jump to the top of the remediation list.

🎯 On Leadership

Acting Independently Isn’t the Same As Owning What Happens

MIT Sloan Management Review and Boston Consulting Group surveyed their annual panel of 29 AI experts this quarter and came to the following conclusion: governance that treats agents as autonomous decision-makers will fail. More agents are acting without a human approving every step, but acting independently isn’t the same as owning what happens. Simon Chesterman, of the National University of Singapore, frames it as: “The more we speak as if agents ‘decide,’ the easier it becomes for firms and governments to launder responsibility through the machine: The model recommended, the agent acted, the human shrugged.” This is a fairly accurate, if non-nuanced, description of what could’ve happened with the Chinese ship above, if the chain had gone one step further.

Kara Swisher made the same point at the Atlantic Festival last week: “We have to stop thinking AI is going to kill humanity.” The danger, in her estimation, is the people building and deploying it. She compared AI to guns and nuclear weapons, where the technology was never the part that needed restraining (guns don’t kill people…).

The panel in the MIT/BCG survey made a recommendation that lines up with Swisher’s argument: build autonomy limits like scoped permissions, approval gates, and hard stops instead of a policy you’re trusting an agent or an operator to honor, and name a specific accountable human for every consequential agent decision before you deploy it. This should sound familiar to anyone who has worked in cybersecurity for any amount of time.

It also applies directly to your own program if you’re giving an AI agent latitude to contain an intrusion or auto-remediate an incident. “The AI made the call” won’t be any more acceptable an answer for your board or regulators than “the agent decided” was for the panel above. While you’re at it, check out Phil Venables’ latest post describing the difference between Automation, Autonomy, and Autonomic.

🔗 Connecting the Dots

Ok, back to the locks on my house (and my hypothetical under-the-mat key). Every incident above is essentially the same failure: a boundary that exists only in theory, without validation or evidence. What’s changed is why that used to be an acceptable risk given attacker limitations.

Last week’s piece by Anton Chuvakin on security fundamentals that rely on attacker laziness was onto something; the version we’re seeing in these stories is based on attacker time, not motivation. In the past, attackers didn’t skip your stale accounts and unmonitored assets because they didn’t want the trouble - they skipped them because checking every door on the street took more time than they had. AI-enabled attack tooling has compressed that timeline the same way it compressed vulnerability disclosure a few issues back - and on the defender’s side, an AI system that reaches production during a “test,” or one given latitude to act on an incident without a named human signing off on that latitude, reduces reaction time in the other direction. Speed is only an advantage if verification steps keep pace, and this week’s stories show what happens when they don’t.

Three things to do this week:

1. Pull your last six months of departures and confirm access was actually revoked, not just that the offboarding ticket closed; bonus points if that review includes agentic models and prompts to which the employee had access.

2. If you’re piloting agentic AI internally, get a ruling on two things: whether eval environments are actually isolated from production, and who is specifically accountable for agents able to contain or remediate an incident on their own.

3. And if your organization is feeding AI systems synthesis across any kind of sensitive boundary, be it classification, compliance, or financial, this week’s Pentagon story screams for verification gates before outputs inform a decision or an action.

Subscribe now

I’m sure I’m not the first person to use the classic “I Love Lucy” chocolate factory scene as a metaphor for security: Lucy and Ethel are wrapping chocolates on a conveyor belt that keeps speeding up. They keep pace for a while, then they can’t, and the chocolates start going in pockets, hats, mouths, etc. The process isn’t broken; it’s just happening too fast for them to keep up.

This month, the “belt” that is vulnerability disclosure has continued to speed up. Microsoft’s September Patch Tuesday shipped 974 CVEs (including a rather nasty PE vuln in Defender), the largest single batch on record. We’ve got less time, more volume, and a remediation process that’s still largely manual. This week: the Patch Tuesday breakdown, a metric that can’t measure “less time” anymore, and what this means for how you measure and prioritize. Spoiler: there’s no way to stuff these into our pockets and shirts.

Subscribe now

🛡️ Right Now

This month’s Patch Tuesday seems like a good, tactical starting point for a broader discussion of cyber defense measures. If you aren’t up to speed on this month’s releases, go check out coverage from Brian Krebs, Dark Reading, and CrowdStrike: 974 CVEs, 113 critical, 2 confirmed exploited, 58 more classified by MS as “likely targets”. We know AI is speeding up discovery, but the bottleneck continues to be remediation testing and patching. You can’t improve what you can’t measure, but what’s the right approach when generally accepted metrics in these areas don’t withstand innovation and/or don’t capture the real problems?

We just saw this play out at the Zero Day Clock project, which recently retired its headline “time to exploit” metric. Their analysis of roughly 3,500 CVE-exploit pairs found that median time from disclosure to exploitation dropped from 771 days in 2018 to about 4 hours in 2024. The metric saturates at zero when something gets exploited same-day or pre-disclosure, and basically becomes useless for discerning “attackers are getting faster” from “we’re measuring more old CVEs finally getting hit.” This past week alone, we had the MikroTik RouterOS SSH bypass, where patching didn’t adequately remove the attacker’s foothold, and an Adobe Commerce zero-day that backdoored fully patched stores for two months undetected.

These kinds of pre-disclosure situations are the scenarios the old zero-day clock metric can’t capture. If we want to apply the lesson here to our own metrics, we might start by recognizing the problems with the time-to-exploit metric:

1. Aging bias: recent CVEs look artificially fast because older ones haven’t been exploited yet

2. Saturation: the metric bottoms out at zero and can’t show further acceleration

3. Simultaneous movement: attackers shifting toward disclosure day and a growing backlog of old CVEs finally getting hit both show up as the same falling median, so a single/broad number can’t tell you which trend you’re actually looking at

So what is the ZDC project doing instead? Their new approach tracks four separate KEV catalogs side by side, layers in honeypot data (actual exploitation attempts), compares year over year within identical time windows instead of point-in-time snapshots, and publishes context/intel like real compromise events and exploitation start dates.

The takeaway for security leaders looking for better metrics is that a scorecard-oriented number that saturates at its best or worst case, i.e., 100% patch compliance or zero open findings, is a poor instrument. Sources that disagree should stay visible as a spread for context. And a metric built from what’s convenient to log (tickets closed, KEV entries) may not cover important qualitative measures (verified fixes, confirmed exploitation).

🎯 On Leadership

I really enjoyed Anton Chuvakin’s piece on “Survival of the Basics,” which also touches on security measurement and AI-driven innovation on the offensive side. Anton conducted an informal poll on X and LinkedIn on which security fundamentals still hold up against AI-assisted attackers. His article, based on the results and his own observations, concludes that things like patch cadence and phishing training never stopped attackers outright; they relied on attackers being lazy (or deciding a target wasn’t worth their time). I think this might generalize to the vast and varied criteria that make a target “worth” an attacker’s time; but if we subscribe to the concept broadly, AI has effectively removed the “attacker time is scarce” constraint.

So the controls that degrade first aren’t the weak ones, in a qualitative sense; they’re the ones that were relying on attackers not bothering, rather than actually preventing anything. If you’re measuring your control stack, which of those controls assume attacker scarcity, and which assume attacker capability? Food for thought, and for your next purple team exercise?

📖 Resources

Josh Wright just published his book, “Dynamic Incident Response: A Framework for Security Teams”. It’s available online, entirely free - 720 pages based on his years of experience, with contributions from other subject matter experts. The framework referenced here is the Dynamic Approach to Incident Response (DAIR), which organizes response around five waypoints (Prepare, Detect, Verify and Triage, Response Actions, and Debrief) and a Response Actions Loop of Scope, Contain, Eradicate, and Recover that responders re-enter as new evidence appears. DAIR is built on John Boyd's OODA loop and includes a crosswalk to NIST CSF 2.0 - a shift away from the more linear, serial “PICERL” model found in NIST guidance and elsewhere.

Can’t wait to dig into this one - you can check it out at https://dynamicincidentresponse.com/

🔗 Connecting the Dots

Back to the conveyor belt. Less time before exploitation, more volume demanding a response, and a triage process that isn’t getting much faster - with no single metric able to capture the nuance of all three parts in a single figure.

And, back to Patch Tuesday. If you aren’t already well down the remediation path (or even if you are), try this as a parallel exercise:

• Prioritize the exploitation-confirmed subset from this batch.

• Pull whatever document/policy/SOP for your vuln-management SLA and ask yourself if it still assumes days or weeks between disclosure and exploitation (MikroTik and Adobe Commerce indicate this would be a false assumption).

• Pose Anton Chuvakin’s audit question to your own team: which controls actually stop attackers, and which ones just rely on attackers not bothering?

Subscribe now

Welcome to Issue #64 of Security Leadership Weekly. This week: AI agents can recognize that an action is outside of the rules of engagement, but have no hard internal guardrails that will stop them from doing “off limits” things. There are lots of great recent examples of this, including the OpenAI “rogue agent” Hugging Face incident. Since the first step is discovery, I’m leaning on two new frameworks to help cut through the hype and prepare for actual agentic capability.

Also: a Chinese threat actor has turned Cisco routers into a spying platform that config audits wouldn't have caught, and the McKesson/ShinyHunters breach is playing out against the same pay-or-not-pay debate we keep having with no real policy answers.

Subscribe now

Right Now

Rogue AI Agents Are an Identity and Access Problem!

Details from OpenAI’s rogue-agent incident continue to come to light, with a new post-mortem from Model Evaluation and Threat Research (METR) and Redwood Research uncovering some interesting details. seems that OpenAI’s agents weren’t trying to steal answers to a test, but were actually trying to learn more about ExploitGym’s evaluation scoring method. Fast Company has a nice breakdown here, and you can find the full report published online here.

There’s been a lot of great coverage and commentary on this incident elsewhere, so I’m not going to run it back here. But it’s interesting that the agents involved in the attack identified the action as crossing a line (objectively wrong), but continued anyway for lack of any programmatic concept of “off limits”. The lesson is that any “control” built into these models isn’t really a control at all - the same way that a policy of which a human is well aware isn’t actually a control. For as fascinating a read as these reports are, the issue here is pretty mundane: a lack of basic controls around identity and access.

The timing is great for Lenny Zeltser to have published a Security Autonomy Matrix. It’s a helpful reference that scores AI actions like read, write, send, spend, and delete on an independence scale from manual (L0) to independent (L4). In this model, each autonomy grant requires four things: an accountable person, an execution gate, a note outlining residual risk, and a re-approval date. According to the matrix, the Hugging Face agent was operating with a L3/L4 write authority without a gate at a minimum.

Cisco IOS XR Routers as Covert Spying Infrastructure

Researchers at Sygnia have discovered an active GRE tunnel interface on a Cisco IOS XR router hidden from running configuration and history commands. The discovery points to a mass compromise campaign of Cisco routers by a Chinese Threat Actor dubbed “Fire Ant” involving custom malware that hides their command-and-control channels from network admins. We often tout the importance of verifying network configs as a security control, but in this case, an audit wouldn’t have turned up anything. If nothing else, it’s a great use case for network security monitoring.

McKesson Breached by ShinyHunters

ShinyHunters has claimed 284M records stolen and set a deadline for payment under threat of public leak. The response is still underway, and McKesson has filed a disclosure, but as usual, details are sparse at this stage. SH continues a prolific run that most recently included Jack Henry, ReliaQuest, Oracle PeopleSoft, and Canvas/Instructure in the Spring. It probably isn’t a stretch to assume some combination of the same playbook(s): social engineering/vishing as an entry vector, SaaS for persistence and lateral movement, etc. What’s interesting to me is that the pay-versus-not debate continues to rage in a public policy vacuum. It isn’t clear if McKesson will pay, but last week, Berlin city government (also the victim of an attack by the Rhysida gang) publicly said they won’t pay the ransom.

👤 On Leadership

Security Leaders Don’t Trust What They’re Buying (Yes It’s AI)

Came across an excerpt from an Onapsis survey-driven report on the state of AI and ERP security, claiming 70.6% of security leaders don’t trust AI applications to secure business-critical data. The report also says that 41.5% of respondents rely on their ERP vendors to provide AI security controls without independent verification. I always view these reports with healthy skepticism, but I can’t help thinking back to the massive spending on display on the Black Hat expo floor on “AI security”. I think this spend largely chases top-down AI mandates, and signing a PO is certainly easier than validating capability.

According to this report, security teams are also objecting to AI access grants at nearly double the rate of IT teams - we’re getting steamrolled. Whether you believe these numbers or at least find them directionally true (which I do), this is where Zeltser and Van Os’s shared vocabulary gets really useful. We might not be able to slow the procurement tide or even slow it down enough for in-depth testing, but we can have vendors account for the level of autonomy of their agent and where it sits on the SAMM scale. Before giving your stamp of approval on any tool or agent pitched as “AI-driven", require the vendor or internal sponsor to specify its actual autonomy level and accountable owner.

👤 People and Processes

SOC-CMM Publishes the SOC Automation Maturity Model

I’ve been a fan of Rob Van Os’ work on SOC-CMM for a while - we cover it in LDR551, and I was previously a certified SOC-CMM assessor. Rob just published a SOC Automation Maturity Model, a six-level reference framework to track the progression of SOC automation (with AI as a tool, but not the end goal). I like that he’s highlighted the gap between AI enablement and fully autonomous operations, which cuts through the vendor hype a bit. And the adoption guidance for this model aligns well with the other SOC-CMM artifacts: pick a target level and timeline, set priorities/pre-reqs/risks, and work toward that goal. A good pairing with Lenny Zeltser’s matrix, which focuses on autonomy by individual action/grant, whereas this is autonomy by maturity stage.

💡Connecting the Dots

Lenny Zeltser’s Security Autonomy Matrix and Rob Van Os’ new SOC Automation Maturity Model give us a shared vocabulary for autonomy grants over vendor marketing. Many orgs are buying AI security tools faster than we can verify those tools really work, so the takeaway is this: ask every vendor and internal sponsor to clearly describe agentic autonomy levels and accountable owners before you sign off, and start building out your controls from there.

Subscribe now

Subscribe now

🛡️Tactical Challenges

A little over a week ago, Microsoft published this report on Storm-2945, a Midnight Blizzard sub-cluster (the same SVR-linked crew behind SolarWinds), which has been hijacking hotel and conference Wi-Fi captive portals since May to run what they’re calling CaptiveCrunch. The initial attack vector is exploitation of the network gear serving the captive portal, followed by a redirect into device-code phishing against Entra ID or malware delivery via ClickFix. Once on the box, it’s a Go-based RAT (CornFlake) and PowerShell infostealer (ChocoShell) which target session cookies, saved passwords, and M365 SSO tokens.

This is what identity attacks look like in 2026: no exploit, no zero-day, nothing (necessarily) written to disk. And it’s a post-authentication attack, so phishing-resistant MFA doesn’t save you. We’ve researched these kinds of attacks a TON at my day job, and I posted a short video about this specific campaign on LinkedIn explaining how best to defend against them.

🤖 Emerging Threats

You Get a Passkey Attack, and YOU Get a Passkey Attack, and YOU Get a Passkey Attack!

Speaking of identity attacks, The Hacker News covered some interesting research last week around defeating passkey protections, which isn’t great news if you’re depending on passkeys to keep your users safe from phishing and other identity attacks. But not to worry; in every case, successful exploitation requires pre-existing access to/persistence on the endpoint, and/or an attack chain that has been disrupted by security updates released since disclosure.

At a high level, the attacks target how passkeys get synced/recovered/exposed by the underlying OS and cloud providers. So the implication is that if you’re using passkeys, but not hardening the surrounding infrastructure, you may still be at risk. One technique reused signed auth material exposed by Windows, another abused a cloud-synced passkey system via malware already resident on the victim’s machine (again, assumed access), and the third targeted the MFA flow itself.

This latter one is the most interesting to me. In a presentation at Black Hat on “Pass-the-Passkey,” SpectorOps researcher Michael Grafnetter shows that YubiKey signatures are stored in clear text and are readable by authenticated users. Microsoft is tracking this as CVE-2026-34348, which is technically a vuln in the Windows Event Logging Service. Exploiting it doesn’t require the attacker to extract the private key from a YubiKey - they just need to grab and reuse the generated signature retained by Windows.

No evidence of this one being exploited in the wild yet, but something to keep an eye out for - maybe also an opportunity to soften or rework language around passkeys “eliminating phishing risk” (which hopefully you aren’t using anyway). Also maybe ask your incident response team if device compromise is treated as a passkey-invalidating event.

You can check out the full rundown from The Hacker News here, which includes links to the research covered.

👤 People and Processes

AI and Security Decision Fatigue

Sam Sabin at Axios published a piece on executive decision fatigue despite expanding budgets and board support for “AI attacks”. While CISOs focus on defining AI governance strategies and figuring out which shiny new widgets they might need to identify risks posed by AI-enabled threats, frontier models continue to add new capabilities, and security debt in other areas continues to build. Some good insights here from people in the field, many of which boil down to “focus on the fundamentals” and tackling agent permissions, identity, logging, and accountability. Read the full piece here.

Templates for Cybersecurity Executive Briefings by Lenny Zeltser

Prepping for a briefing? Lenny Zeltser has published four super helpful templates: a Cyber Threat Intelligence brief for distilling a full CTI report or synthesizing vendor/government reporting on an emerging threat; a Vulnerability Investigation brief for evaluating a “celebrity” vulnerability against your organization’s exposure; an Incident Response brief for use during an incident, after containment, or for incidents too small to warrant a full report; and a Cybersecurity Assessment brief for distilling findings after a pen test or vulnerability assessment.

All of these are built on principles from Lenny’s SANS course Cybersecurity Writing - and you can have them for free!

Risk As the Language of Vulnerability Management

This piece by Todd Tucker at the FAIR Institute caught my eye, having just listened to last week’s episode of The CISO Series Podcast, “Why Don’t You Tell Me Which Risk Metrics Sound Most Impressive",” which covered (among other things) vanity metrics presented by CISOs. The article centers on a CISO who came up through vulnerability management and knows the discipline cold, but who is struggling to turn CVSS scores, exploitability ratings, and other signals into an actionable conversation for her CFO and Board; basically, she needs a language overhaul more than a technical one.

The article claims that security’s biggest value driver is risk reduction, not cost reduction. Tucket also advocates decoupling FAIR-the-mindset from FAIR-the-quantification-program. FAIR doesn’t necessarily require a large team, Monte Carlo simulations, and dedicated analysts; the most valuable part of the exercise is the structured way of thinking and shared language.

For vuln management specifically, Tucker names two payoffs:

1. Justifying investment: instead of walking into a budget conversation with thousands of critical findings, you frame the few that matter as a loss scenario the business already worries about - even directional framing (”high likelihood of serious loss because we run end-of-life systems”) is better than a severity count.

2. Aligning priorities: the scenario framing translates a technical finding into a breach scenario leadership already has in mind, and forces the one question only the business can answer: how large the harm would actually be.

The piece gets pretty deep into the weeds on FAIR, so it may not fully connect if you aren’t using the framework. But I like it as a companion to Lenny’s presentation templates and the Axios piece on analysis paralysis. Tucker is talking here about language: risk expressed as probable frequency and magnitude of loss, which should inform a CISO’s analysis in light of emerging threats (say, AI-enabled attacks) as well as briefings to the CFO and Board. It’s not about more tools and data; it’s about a common vocabulary for deciding what’s worth action and investment.

💡Connecting the Dots

CaptiveCrunch and the passkey research covered in the last week+ are two sides of the same coin. These are more identity attack surface problems than they are authentication or account problems, and they require a different lens than just “how to implement stronger auth?” (although you should do that too).

The Axios piece on decision fatigue and Tucker’s article on FAIR-as-language make the point that more tools and more metrics won’t help anyone if the CISO can’t turn technical signals into a decision someone with budget authority can actually act on. CaptiveCrunch and Pass-the-Passkey are interesting for sure, but are also exactly the kind of “emerging threat” that’s easy to over-index on and miss the actual point for leadership - treat every session as potentially compromised (or compromisable), treat every network as hostile, and get your IR team thinking about what invalidates a passkey the same way they think about what invalidates a password. Fundamentals, language, and identity, allllllll the way down.

Subscribe now

Google Cloud published a piece on applying Site Reliability Engineering to cybersecurity earlier this year, and Phil Venables (who shows up in this newsletter more than anyone else because he’s usually right before the rest of us catch up) just posted his own version, Control Reliability Engineering. These pieces don’t reference each other, but they are in conversation.

Anyone who’s spent time in security operations knows that defense has a scaling problem, and SRE tools and methods may help. I want to cover this from three angles: what this looks like in practice, what it means for leading a team, and where the analogy doesn’t really hold up (all models are wrong, but some are useful - right?). The leadership part is the one most relevant to this newsletter, so that’s where I’m spending the most words.

Subscribe now

🛡️Tactical Challenges

Google’s version boils down to four habits:

• Eliminate toil (repetitive actions that add no enduring value)

• Alert on symptoms instead of causes

• Run blameless postmortems

• Roll out changes gradually and reversibly

None of this is new to anyone who’s read the SRE book. Google basically says you can’t grow a security team linearly to match the expanding size and scope of operations, so a new approach is needed. The Google Cloud post also points out that security teams have historically alerted on system-level signals (a failed login, a specific hash - things at the bottom of the pyramid of pain) that are either too noisy or too brittle. The SRE solution is to alert on symptoms that measurably degrade confidentiality, integrity, or availability, and automate everything else. If a 3 a.m. alert doesn’t require a human response, well then, it probably shouldn’t be an alert.

Venables goes a little further with his concept of Control Reliability Engineering (CRE). He observes that most breaches result from a control everyone believed was working but quietly failed, rather than attributing to attacker brilliance. There’s a great analogy in his piece for this: a radiation detector that reads zero could mean the environment is safe, or it could mean the sensor is dead, which is why real detectors carry a small harmless source so they never actually read zero. His suggested approach for CRE is essentially a working checklist:

• control ontology and cataloging

• controls-as-code

• control-specific SLIs/SLOs

• continuous control monitoring

• synthetic event injection

• control readiness reviews (an adaptation of SRE’s production readiness review)

• safe/canaried changes

• control incident management

• error budgets for controls

If we’re worried about control failures as much as we are attacks (and we should be), we can treat “control incidents” the same way we would a security incident. Most organizations only do root-cause analysis on the thing that was exploited, but CRE says if the control was broken and got lucky, that’s still a finding.

On the ground, this is already showing up in detection engineering as detection-as-code: version-controlled, peer-reviewed, tested detection analytics over ad hoc alert tuning. I don’t know that the SRE-CRE-secops alignment is this clean everywhere - controls don’t necessarily have success rates the same way a service has an uptime (see: patching SLAs and proving a negative), so CRE in practice may take some tweaking and judgment.

🤖 Emerging Threats

Tailoring for SecOps, and Chaos Engineering

The source text for most of this is Building Secure and Reliable Systems, Google’s free 2020 book pairing SRE and security engineers to argue that reliability and security were never actually separate disciplines. If you haven’t read it, it’s aged pretty well, and it’s free. Anton Chuvakin’s writing on autonomic security operations is also required reading to see what common-sense alignment between secops and SRE might look like.

Another resource worth checking out is Kelly Shortridge’s Security Chaos Engineering, which is conceptually aligned with CRE: deliberately injecting failure to find out what happens - the security equivalent of chaos engineering’s fault injection in production. Where CRE is more about measurement and drift detection, SCE is about experimentation; they’re compatible, but they answer different concerns. CRE tells you whether your control is still working; SCE tells you whether your system degrades gracefully when it isn’t.

SRE was built to manage stochastic failure - disk failure, connectivity losses, load spikes, etc. Security failure is caused by an adversary actively probing the edges of whatever control set you’ve deployed. An error budget tells you how much unreliability you’re willing to tolerate before you stop shipping features (kind of like a risk tolerance). Applied to security, “error budget” starts to sound like an acceptable rate of successful attacks, which is probably not something your leadership wants to hear. So the approach and tools are sound, but the message might need a little…translation.

👤 People and Processes

Blameless postmortems only work if your team believes you mean it

The Google Cloud and Phil Venables posts lean on this staple of SRE, which means treating every incident, including a control incident, as a chance to improve the system rather than assign fault. I teach this in LDR551. The practice is easy to describe and difficult to actually run. “Blamelessness” depends entirely on psychological safety, which is earned over time. If your team suspects that blameless only applies until something gets bad enough, they’ll just stop telling you about the near-misses.

Toil elimination is a retention strategy

Pitch toil elimination as a retention strategy. About 70% of SOC analysts report burnout that bleeds into their home life, and nearly every organization is watching alert volume climb faster than headcount. SRE’s contribution here is that any manual, repetitive operational task gets treated as a bug in the system’s design. You don’t solve analyst burnout by hiring more analysts to do the same repetitive work faster; you solve it by treating the repetitive work itself as the defect to be controlled and reduced.

Error budgets are a negotiating tool

Tired of the eternal, exhausting fight with the business over how much risk is acceptable given operational velocity? An error budget lets you codify that number in advance and get buy-in instead of relitigating it every release cycle.

Changes to your staffing plan

Controls-as-code and detection-as-code require people who can write and review code, not just tune a console. If you’re building a security program around these ideas, your next few hires look more like engineers than analysts, and your career-pathing conversations with your current team should reflect that shift now, before it’s a surprise a year from now.

💡Connecting the Dots

SRE-for-security is a management philosophy expressed using engineering words: measure continuously, treat failure as information rather than a verdict on a person or solution, negotiate risk tolerance once rather than every release/sprint/operational cycle. Don't buy this from anyone selling it to you as a product in a booth at Black Hat. Focus on the concepts: controls-as-code, continuous monitoring, blameless learning, error budgets as a negotiating tool.

Subscribe now

This week: the industry’s rush to instrument AI agents with standing access - sometimes purposely, sometimes unknowingly - is basically repeating every identity and trust mistake enterprise IT teams spent the last decade fixing, only faster, with less visibility, and in many cases with no one assigned to own the solution.

Subscribe now

🛡️Tactical Challenges

AI agents don’t have the controls that govern other privileged identity classes

Enterprises are granting AI agents access to databases, APIs, file stores, and other data. Unfortunately, the OAuth token model used to grant this access has no way to express which human (if any) an agent is acting for, what scope it’s authorized to use, or whether one agent invoking another should inherit or narrow that authority.

According to CrowdStrike, the MCP spec’s recommendation to use OAuth 2.1 for agent tokens doesn’t account for who a token actually represents when agents act autonomously. We know this gap is exploitable; see the recently reported AWS Kiro flaw, which allows rewriting of the IDE config via hidden text on a webpage. There are plenty of other examples like this out there, and CrowdStrike’s prompt injection taxonomy update reflects the growing volume and evolution of these techniques.

If your organization has deployed or is piloting AI agents, ask who owns the identity architecture for those agents - not who owns “AI governance,” but who is accountable for scoping, audit trails, and revocation when an agent is compromised or acts unpredictably. Don’t let “we have an AI governance policy” substitute for verifying agents can’t rewrite their own config or execute code from untrusted input, which is what happened to Kiro.

(Note: We wrote about OAuth sprawl on the Push Security blog, which is where I borrowed the graphic above)

Human challenges in AI-enabled SOCs

Cynthia Brumfield's CSO Online feature posits that AI's biggest strain on the SOC may be human rather than technical. Futurum's Fernando Montenegro describes analysts drowning in machine-generated reports and alerts that still require human judgment for validation; we’ve brought down the cost of generating more signal without addressing the analysis bottleneck. My SANS colleagues (and secops experts) Chris Crowley and John Hubbard share some insights in the piece, which basically concludes that mature SOCs will absorb the load while understaffed ones burn out. In short: "Buy engineers, not tokens.”

🤖 Emerging Threats

What "no AI guardrails” looks like in practice

A governance policy that says “agents must operate within approved scopes” means absolutely nothing if the underlying system has no approval step capable of blocking an agent from acting on hidden instructions. The gap between AI governance documentation and enforcement is where some recent incidents have occurred, and we can’t keep papering over it with policy language alone.

CrowdStrike’s framing - “AI governance without guardrails is theater” - is catchy and maybe a bit trite, but it’s also true given what happened at AWS: its Kiro IDE could rewrite its own configuration and execute attacker code from a webpage summary request, with no approval gate to intervene. A research paper published last week on third-party mobile agents powered by Vision-Language Models (VLMs) makes the same point from a different angle: screen-reading agents trusted invisible text as legitimate instruction, because nothing in the architecture distinguished “content to summarize” from “commands to execute” (covered by The Hacker News here).

CISOs, BISOs, and security managers out there - in your next AI governance policy review, ask for a live demonstration that an agent in your environment cannot act on instructions embedded in content it’s asked to process (e.g., a webpage, a document, a calendar invite). If no one can produce that demonstration, the policy is aspirational, not operational, and your board-level AI risk reporting should say so explicitly rather than citing policy adoption as evidence of control.

👤 People and Processes

A must-read for SOC teams and managers: FinOps for SecOps

This post by Usman Chaudhary and Nikita Jagadeesh argues that agentic SOCs are now operationally necessary, but that blind AI adoption creates financial risk.

Their proposed solution is a “FinOps for SecOps” framework that starts by plotting each SOC workload on a value-versus-compute-cost matrix:

• High-value/low-compute work (Tier 1 triage, detection engineering, investigation summaries) should be automated

• High-value/high-compute work (open-ended threat hunting, multi-source correlation) deserves selective, async investment

• Low-value work already handled well by the SIEM (dedup, ticket routing, IOC matching) shouldn’t be handed to agents at all

• Low-value/high-compute work (i.e. agents re-normalizing raw data on every query instead of leaning on the SIEM) is the “token trap” to avoid entirely

The second half of the piece lays out a six-step rollout:

1. Aggregate telemetry efficiently, using MCP servers to query external data instead of migrating everything

2. Throttle agent autonomy by priority/telemetry source/target before enterprise-wide deployment

3. Run a 2-4 week parallel POV against manual ops to prove ROI

4. Require verifiable/auditable reasoning rather than black-box confidence scores

5. Shift success metrics beyond MTTD/MTTR toward toil reduction and junior-analyst enablement

6. Deliberately preserve manual triage skills in new hires (via CTF labs) to avoid “rubber stamping” and skill atrophy as agents absorb top-tier work

I really like the focus on ongoing skill development and cost justification in this framework. CISOs should make agents justify their token spend rather than chase easy automation, and we already know the AI token gravy train is coming to an end.

🌎Notable News and Research This Week:

CVE-2026-50522, a critical SharePoint deserialization RCE (CVSS 9.8), is being actively exploited following a public PoC; patch confirmation should be on this week’s agenda if you run on-prem SharePoint!

Arctic Wolf Labs observed Qilin ransomware affiliates using a patched PAN-OS authentication bypass (CVE-2026-0257) for initial access across multiple June intrusions; a reminder that “patched” doesn’t mean “remediated” if scanning lags (womp womp).

HollowGraph malware is using a compromised Microsoft 365 account’s calendar as a two-way C2 dead-drop, another entry in the growing list of SaaS-native LOTL techniques that blend into normal traffic.

Spain’s AEPD fined 23andMe nearly $3 million for cybersecurity failings tied to the 2023 breach.

💡Actions for this Week

1. Confirm CVE-2026-50522 (SharePoint RCE, CVSS 9.8) is patched on all internet-facing instances and check for indicators of prior exploitation, given active PoC-driven attacks.

2. Ask whoever owns your AI agent pilots whether any deployed agent can execute instructions embedded in content it processes (webpages, documents, emails) without a human approval gate.

3. (Next 30 days): Inventory every AI agent in production or pilot with access to sensitive systems and document who owns token scoping, audit logging, and revocation for each.

4. (Next 30 days): Re-scan environments for the patched PAN-OS auth bypass (CVE-2026-0257) even if the patch is confirmed applied; Arctic Wolf’s Qilin findings suggest exploitation windows persisted post-patch.

5. (Longer term) Add a standing agenda item to your next AI governance review that requires a technical demonstration of enforcement, not just a policy citation, before governance maturity is reported to the board or auditors.

Subscribe now

If you’re struggling to balance daily operational tasks and project work, chances are you aren’t getting less busy - but some structural improvements will be necessary to reduce operational load on people trying to reduce your attack surface, comply with Federal mandates, and respond to ransomware attacks.

Subscribe now

🛡️Tactical Challenges

The Browser Extension Attack Surface Keeps Growing

Two disclosures this week highlight the risks that browser extensions can pose to enterprise networks, and maybe also that AI branding has become the most reliable social-engineering lever for getting them installed at scale.

Microsoft removed 119 Edge extensions this week linked to a campaign impacting up to 2.6 million users. These extensions weren’t obviously suspicious tools: ad blockers, VPNs, translators, and video downloaders. The malicious payloads were hidden inside ordinary image and font files using steganography, stayed dormant through multi-day evasion checks, and only deployed after clearing fingerprint validation to evade security review. When they did activate, the damage wasn’t limited to ad fraud; retrieved payloads included an RCE backdoor, Google credential and 2FA code theft, WordPress admin credential harvesting, and bulk cookie exfiltration for session hijacking. Microsoft links the operation to DarkSpectre, a Chinese actor previously connected to other extension campaigns.

Separately, Microsoft’s Defender research team disclosed a Chrome extension impersonating Perplexity AI that collected every search query (and every other input to the address bar) through an attacker-controlled intermediary before redirecting users to legitimate results. The extension shipped with server-side Node.js code that explicitly logged incoming requests with full headers, IPs, and user agents. The AI branding was an effective lure, since users tend to install AI productivity tools at unusually high rates with less scrutiny than other software.

Most enterprise security programs treat browser extension installs as a user-responsibility problem rather than a managed control, and most corporate third-party software review processes do not include extensions. We’re well past the time to start treating browser extension inventory the same way mature programs treat shadow IT: audit what’s deployed across managed endpoints, define a policy for what requires review before install, and make sure someone owns that process.

Japanese telco exposes 14.2 million managed email credentials

Japanese telco KDDI disclosed that attackers exploited a vulnerability in third-party software powering a managed email platform it operates for itself and several other Japanese ISPs, exposing up to 14.2 million email addresses and passwords. KDDI detected the unauthorized access on June 17 and says it contained the intrusion the same day, but the window was enough for credentials to be at risk across the full customer base of the shared platform.

The blast radius in this case is really something. Because KDDI operates this email infrastructure as a managed service for ISPs, including STNet, JCOM, Chubu Telecommunications, Nifty, and BIGLOBE, a single vulnerability in a shared third-party component compromised credentials across multiple providers and their respective customer bases simultaneously. It’s a good example of why third-party and managed service risk continues to punch above its weight in breach statistics: the attack surface isn’t just your own stack, it’s every customer of whoever manages your stack.

🤖 Emerging Threats

Ransomware Syndicates’ Continued Evolution

Intel 471’s Garrett Carstens draws on analysis of Black Basta’s leaked internal chat logs to document how modern ransomware operations have adopted fully corporate structures: scheduled call teams running social engineering from 6 p.m. to 2 a.m. Moscow time, outsourced contractors for malware, spamming, and initial access, internal performance reviews tied to ransom payment distribution, and tiered pricing models calibrated to victim revenue. Black Basta collected at least $107 million from 520 victims across 39 industries before shutting down in 2025, operating, in Carstens’ framing, less like a criminal gang and more like a professional services firm specializing in extortion.

It’s fascinating how attackers have turned the negotiation phase into a precision instrument. Ransomware groups now conduct data audits to assess the sensitivity and market value of what they’ve stolen, then use that valuation to set and manipulate deadlines - compressing them to force panic, or extending them when a longer runway improves payout probability. Cyber insurance policies, when discovered during reconnaissance, function as a pricing signal. Attackers use coverage details to infer the victim’s financial capacity and likely ransom ceiling. To me, the takeaway isn’t just to prepare for ransomware; it’s to treat negotiations as a scenario to be rehearsed in advance, with intelligence informing how the other side of the table actually operates. Really great read from Intel471 (with coverage via Cyberscoop).

Device Code Phishing Twofer!

Device code phishing attacks have risen sharply in 2026, largely due to the proliferation of new attack kits and the addition of this technique to existing kits. If you missed it, my Push Security colleague (and VP of Research) Luke Jennings did an awesome, in-depth breakdown of how device code phishing has exploded in scope and sophistication this year. Detailed timelines, TTPs, recordings of actual attacks, and mitigation strategies abound. You can see the recording here.

…AND, ⁠Selena Larson⁠, Staff Threat Researcher and Lead, Intelligence Analysis and Strategy at ⁠Proofpoint⁠, joins host ⁠⁠Caleb Tolin⁠ ⁠to detail the specific mechanics of device code phishing campaigns, revealing how adversaries exploit legitimate communication structures to capture administrative and enterprise access. You can check that one out here.

👤 People and Processes

Security Isn’t the Only Thing Saving the Company from Itself

New from Phil Venables: Security teams often carry an implicit sense that they’re uniquely burdened with having to be the adults in the room - the ones pushing back while the business wants to move fast and skip the guardrails. Venables pushes back on this by discussing other organizational functions that face the same pressure: financial controllers holding the line on revenue recognition, safety supervisors refusing to skip inspections, environmental compliance officers absorbing pressure to ignore runoff spikes, and HR directors asked to bury whistleblowers in restructurings. The point isn’t that security isn’t important; it’s that the tension between control functions (like security) and operational velocity is a feature of organizational life, not a sign that your company uniquely doesn’t “get” security. I am HUGE fan of tearing down the “security is saving the company from itself by being smarter than users” narrative, so this post really spoke to me.

The more useful half of the piece applies sociologist Stewart Clegg’s “circuits of power” framework to explain why security programs succeed or fail. Clegg identifies three circuits:

• Episodic (direct face-to-face power)

• Dispositional (cultural norms and policies)

• Facilitative (infrastructure and systems that enforce behavior automatically)

Venables’ argument is that security teams burn out because they fight Episodic battles (e.g., an executive demanding an MFA exception) using Dispositional arguments (pointing at policy). The sustainable answer is to invest in Facilitative circuits: make the secure path the easiest path through automation and technical controls, so the argument never has to happen in the first place. It’s a framework that maps cleanly onto the maturity difference between security programs that rely on enforcement and programs that rely on design.

What the post-quantum executive order demands of CISOs

The new post-quantum cryptography executive order sets two hard deadlines for federal systems: key establishment transitions to PQC by December 31, 2030, and digital signatures by December 31, 2031. Ellen Boehm’s piece in CyberScoop makes the case that CISOs outside the federal government shouldn’t treat these as someone else’s problem. The immediate concern she raises isn’t the deadline itself, but that “Harvest Now, Decrypt Later” attacks are already underway, with nation-state adversaries collecting encrypted data today to hold until quantum capabilities can break it. Long-lived sensitive data like IP, health records, financial transactions, government communications, etc. may already be compromised in ways that won’t become visible for years.

The practical challenge Boehm identifies is less about cryptography than about visibility and program management. Most organizations don’t have an inventory of where cryptography actually lives across their environment - which algorithms, which systems, which third-party dependencies, which certificates and keys. Without that, risk assessment is guesswork. She frames the end goal as crypto-agility: not a one-time algorithm swap, but a managed, living view of the organization’s trust infrastructure that adapts as standards evolve. Do you know where your cryptographic risk lives? Do you have a funded migration plan that maps to the EO deadlines?

💡Connecting the Dots

In my security leadership course, we discuss ways to strike the right balance between operational fire fighting and improvement initiatives/project work. This is super important when there will always be tension between the two, and maybe never more than now. The through-line this week is that the gap between where attackers operate and where most security programs focus keeps widening, and it’s widening in multiple dimensions. While the tactical picture is shifting, the organizational picture is too: ransomware groups are running structured negotiation playbooks while most IR teams are still improvising; security leaders are fighting policy battles while the leverage is actually in system design; and post-quantum migration is already inside current planning horizons while most cryptographic inventories don't exist yet.

If you’ve been in security a while, you know that these problems have been visible for a while, but they’re now becoming unavoidable. The question isn’t whether to address them, it's whether your program has the organizational structure, visibility, and funded roadmap to actually move in the right direction.

Subscribe now

Meanwhile, the Klue breach gave us a live case study in how OAuth integrations can become vectors for lateral movement, and new research is reframing shadow AI less as a data leakage problem and more as an access control gap. On the people side, Carl Froggett's dual CISO/CIO role at Deep Instinct makes one wonder what the CISO function might look like in the future, as security becomes inseparable from technology strategy and business operations.

Subscribe now

🛡️Tactical Challenges

Shadow AI Is An Access Control Problem

The “first generation” response to shadow AI - DLP rules, domain blocks, usage policies - was designed to prevent employees from pasting sensitive data into ChatGPT. But the risk has moved beyond that use case now that employees are connecting AI tools directly to corporate systems via OAuth integrations, granting those tools access to email, calendars, code repositories, and CRM data. The real exposure here is what permissions an unsanctioned AI application holds after that OAuth handshake completes.

The Hacker News ran a vendor-sponsored piece by Token Security framing AI agents as identity and governance problems, noting that agents “access data, trigger workflows, deploy code, and interact with critical business systems, often with little oversight.” Separately, The Hacker News published an analysis arguing that shadow AI’s primary risk has shifted from data leakage to access control, specifically pointing to the gap between what AI integrations are authorized to do and what security teams can actually observe. The takeaway is basically that an AI tool connected to your Salesforce via OAuth looks identical to the Klue integration that compromised Huntress this week (see below).

Your DLP-era shadow AI controls are not sufficient for these kinds of risks. The question to put to your security engineering team is whether your existing OAuth review and app governance processes cover AI-category applications, or were those processes designed for conventional SaaS integrations. If you’ve got a shadow IT discovery tool, verify it enumerates AI applications with active OAuth grants, not just browser-based AI usage or domain-based discovery.

Webinar: Device Code Phishing in 2026

My Push Security colleague and VP of R&D, Luke Jennings, is delivering a research-focused session that goes behind the scenes of device code phishing - including live demos, real examples from kits and campaigns in the wild, and a practical look at what security teams can do about it.

At the start of 2026, device code phishing was still a niche technique associated with Russian state-linked campaigns. Six months later, we’re tracking 18x kits in the wild, a 37x spike in detections, and it feels like every PhaaS vendor in the AiTM space has added device code phishing to their platform. Strong passwords, MFA, even passkeys: it sidesteps the standard login process altogether by targeting the authorization layer. Once an attacker has a valid token, a single phished session can quickly escalate into broad access across an organization’s connected apps and services.

The session is on June 30 at 10:00 AM BST. You can register here.

🤖 Emerging Threats

FortiBleed Mass Compromise Hits 86,000+ Devices

The “FortiBleed” campaign, attributed by CISA to Russian-speaking threat actors, systematically extracted credentials from roughly half of all internet-accessible Fortinet firewalls and VPNs - 86,000+ devices. So the attack surface is basically every organization that left a Fortinet appliance internet-exposed without rotating credentials after prior Fortinet vulnerabilities were disclosed over the last two years.

CISA issued an urgent advisory last week urging Fortinet customers to take immediate action against the ongoing campaign. The CISA advisory and SecurityWeek’s coverage both frame this as an ongoing campaign rather than a point-in-time breach, though the precise exploitation vector hasn’t been disclosed publicly.

If your organization runs Fortinet firewalls or VPN concentrators (or inherits them through an acquisition or managed service provider), treat the credentials on those devices as compromised until proven otherwise.

The Klue Breach: A Case Study in OAuth Attacks

The Klue incident, in which attackers abused OAuth tokens to exfiltrate data from the Salesforce instances of Klue’s customers (including security vendors Huntress and Recorded Future), is the latest public case study of OAuth token abuse. Third-party SaaS integrations that hold persistent OAuth tokens to your core platforms are effectively trusted insiders, and most security teams have no visibility into what those tokens can reach. The Salesforce-to-Klue connection wasn’t a misconfiguration, but an authorized integration that became a lateral movement vector when Klue itself was compromised.

Salesforce confirmed it disabled the Klue Battlecards app integration after the June 11 incident, noting that customers will be unable to reconnect until further notice. SecurityWeek reported that the exfiltrated data came from Klue customers’ Salesforce instances, meaning the attacker’s access to Klue translated directly into access to customer data on a separate platform via OAuth token abuse. That Huntress and Recorded Future appear in the affected customer list underscores that this isn’t a hygiene failure by unsophisticated teams - it’s a problem with how OAuth-based integrations are architected and monitored.

This week, ask your IAM or security engineering team to enumerate every third-party application with active OAuth tokens in your Salesforce, Microsoft 365, Google Workspace, and other core SaaS platforms. Then, ask which of those apps hold tokens with write or export permissions, and when those tokens were last reviewed.

Five Eyes Cyber Security Agencies Statement

The cybersecurity agencies of all five Five Eyes nations - the U.S. (NSA/CISA), U.K., Australia, Canada, and New Zealand - issued a joint statement this week calling AI-driven cyber risk an immediate leadership crisis. The agencies warn that frontier AI models are anticipated to fundamentally transform both offensive and defensive cyber capabilities on a timeline of months, not years, and that AI is already lowering barriers for malicious actors, increasing attack speed and complexity, and shrinking the window between vulnerability discovery and exploitation. The statement is notable for its tone: this isn’t an advisory aimed at security teams. It’s addressed explicitly at boards and executives.

The practical guidance is deliberately unglamorous and probably not groundbreaking for defenders out there: reduce your attack surface, accelerate patching, address legacy systems, strengthen identity and access controls, and test your incident response plans before you need them. The agencies acknowledge none of this is new, but frame it as newly urgent. Cyber resilience, they argue, is no longer an IT issue; it is central to operational continuity and market trust, and leaders who delay will face growing and avoidable risk. The full statement and accompanying guidance document are worth sharing up your chain if you’re still working to get executive attention on security fundamentals.

👤 People and Processes

CISO Perspectives with Carl Froggett, CISO & CIO, Deep Instinct

An interesting entry in SecurityWeekly’s CISO Perspectives series, as Carl Froggett holds both the CISO and CIO titles simultaneously. He makes a strong case that both roles ultimately serve the same purpose - supporting the business - creating natural overlap. Combining both roles would be unmanageable at a company like Citi with 200,000+ employees, but it works well at Deep Instinct with fewer than 200. The lesson isn’t that every company should merge the roles; it’s that the roles share more DNA than org charts typically reflect.

Froggett’s combined role is a live experiment on whether the CISO, as a standalone function, makes long-term sense as security becomes inseparable from technology strategy, risk management, and business operations more broadly (something I sometimes wonder). His experience suggests the roles are more complementary than competitive, and that the main cost of merging them is the loss of an independent check; something that’s manageable with the right culture, but harder to engineer at scale. Worth watching how this plays out across the industry over the next few years.

💡Connecting the Dots

The throughline across this week's stories is that the security perimeter has been replaced by the authorization layer, and most organizations are underinvesting in visibility there. The Klue breach shows what happens when a trusted OAuth integration becomes a supply chain vector; the shadow AI piece argues that unsanctioned AI tools present the same risk profile as the Klue-to-Salesforce connection; and the Five Eyes statement, while diplomatically restrained in its recommendations, is essentially telling boards that attackers are moving faster than defenders can patch or govern.

Device code phishing follows the same logic: bypass the credential layer entirely by targeting the token post-authentication. The FortiBleed campaign is the outlier in this kind of post-auth mechanism, but not in theme: credentials on internet-exposed appliances were treated as durable trust anchors loooong after they should have been rotated. The practical question to carry into next week is whether your identity and access governance processes - OAuth reviews, token enumeration, app governance -were designed for the threat model you had three years ago or the one you have now.

Subscribe now

The security industry has its own Maginot Lines. Backup infrastructure to restore encrypted systems, DLP tools that monitor managed endpoints, PAM scoped to human identities, etc. Each one is a genuine (and, in many cases, still very necessary) capability, built to stop a threat that has since changed tactics.

This week’s issue is largely about that gap. The Maginot Line wasn’t a failure of investment; it was a failure of adaptation. Which of your defenses are guarding a border that the attacker has already stopped crossing?

Subscribe now

🛡️Tactical Challenges

Backups Out as Ransomware Defense?

Encryptionless extortion (data theft without encryption) is now a primary attack pattern, according to BlackFog’s 2026 state-of-ransomware report. If your ransomware response plan is organized around “restore from backup,” it probably doesn’t cover the actual leverage the attacker’s got: the data they’ve already exfil’ed.

BlackFog’s report (vendor report, so treat as directional) documents the shift toward exfiltration-only attacks as a deliberate response to improved enterprise backup practices. This tracks with TechCrunch’s mid-year breach roundup, which independently documents ShinyHunters running simultaneous multi-target extortion campaigns against Canvas/Instructure (275M records), Charter/Spectrum (40M), and others, with 30–60 day breach-to-disclosure windows that the group uses to run parallel extortion tracks across victims before any single company can respond. We’ve written extensively about SH’s preference for identity attacks and highly automated attack chains at my day job.

The SharkStriker June 2026 breach roundup also confirms active extortion campaigns by Qilin, Play, Abyss, Akira, LockBit, and INC_RANSOM - a crowded market that creates competitive pressure to exfiltrate rather than encrypt, since speed to leverage matters more than operational disruption. And finally, the ODNI 2026 Annual Threat Assessment adds a layer: nation-states are increasingly using these criminal ransomware groups as proxies, meaning some “financially motivated” extortion is serving intelligence collection objectives, not just monetization. I wrote about this blurring of the lines between criminal groups and nation-states in the last issue of this newsletter.

So, what to do? Ask your IR lead and legal team what the playbook is when an attacker has already exfiltrated sensitive data before you detect them. It isn’t time to re-write your procedures around backup restoration, but do add an explicit exfiltration-only response track. Also, review your data classification and DLP coverage to understand what an exfiltration-only attack would likely target (or where it would be most damaging), and whether you’d detect it before the 30-day window closes.

AI Agents Are a Fast-Growing Identity Governance Problem

Agents that autonomously file tickets, execute scripts, provision resources, and interact with production environments have created an identity problem that existing PAM, UEBA, and IAM tooling are not built to handle. The sprawl is happening because, in many cases, AI agents are granted access rights under identity models designed for humans. Most enterprises don’t have an accurate inventory of agents currently in production, which means they can’t scope the problem, let alone govern it.

The Cisco/Splunk 2026 CISO report says agentic AI has moved from experimental to operational in most enterprise security programs, and flags AI agents with over-provisioned service accounts as an identity risk that PAM and UEBA programs won’t catch. Bessemer Venture Partners’ analysis found that 48% of cybersecurity professionals identify agentic AI as the single most dangerous attack vector, which would seem to support the assertion that most enterprises lack an agent inventory. Though I’m not aware of any real-world breaches achieved through compromised AI agent identities, this is probably something to revisit against other vulnerability management/threat modeling priorities.

A concrete starting point is to enumerate AI agents currently in production, identify the service accounts they operate under, and assess whether those accounts are in PAM scope - maybe check OAuth permission grants? The longer-term question to answer is whether your identity governance program covers non-human identities at all.

🤖 Emerging Threats

AI Eats the World by Benedict Evans

Via Phil Venables, you do not want to sleep on this excellent presentation (content-wise, but also, that design!) by independent analyst Benedict Evans, covering capital, deployment, institutional/operational change, and an analysis of AI as a transformative tech compared to previous generations.

CCCS Publishes Threat Bulletin on FIFA-themed Attacks

The Canadian Centre for Cyber Security (CCCS) issued a formal FIFA 2026 threat bulletin flagging phishing, fake streaming apps carrying banking malware, and AI-generated credential harvesting pages targeting employees. The CCCS assesses a high risk of targeting in the travel and hospitality, event management, infrastructure owners and operators, and services and sponsors tied to the tournament. It isn’t unusual to see topical lures and increased targeting around events like this, but given the expanding scale and sophistication of phishing and other social engineering attacks, it’s definitely worth looking out for.

👤 People and Processes

CIRCIA’s 72-hour Clock is Running

I wrote about CISA's final Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) rule in the last issue - the final rule is now enforceable, covering 300,000+ critical infrastructure entities across 16 sectors with a 72-hour reporting requirement for covered incidents and a 24-hour window for ransomware payments. What will probably bite most orgs is making a legally defensible “covered incident” determination before the investigation is complete, while the response team is still scoping the incident.

NIS2 requires a 24-hour initial notification to EU national authorities, so if you’re operating in both jurisdictions, a single incident could trigger three or four distinct reporting workflows with different deadlines and different content requirements.

AI Compliance Is Now a Browser Problem

AI regulations across the US, EU, and UK are converging on obligations related to how employees use AI tools. This blog post by Push Security’s Head of Legal, John Creaton, maps out five common obligation categories emerging across frameworks like the EU AI Act, DORA, NYDFS, and HIPAA:

• AI inventory and classification

• Employee literacy and guidance

• Data governance and exposure control

• AI-resistant authentication

• Third-party/supply chain risk

The common failure across all five obligation categories is basically the same: organizations have policies but can’t demonstrate enforcement, because their tooling operates at the wrong layer. Some key takeaways:

• Shadow AI is a compliance liability, not just a risk. You need a real-time inventory of AI apps, extensions, and OAuth integrations, not a spreadsheet.

• Policy isn’t enough; you need auditable evidence. Regulators want proof that employees received guidance at the point of AI interaction, not just in annual training.

• Browser-layer DLP closes a gap most platforms miss. Traditional DLP tools lack visibility into what users paste or upload directly into AI tools.

• Phishing-resistant MFA is becoming mandatory. Multiple frameworks now explicitly require it, and AI is making phishing attacks more convincing and harder to detect through traditional means.

Of course, the browser is an excellent place to gain this kind of visibility and evidence which happens to be where Push operates :). But if you’re concerned about regulatory responsibilities related to AI, this is a great summary by a true expert.

💡Connecting the Dots

Three of this week’s stories are about a control that works, deployed against a threat that has moved on. Backups don’t stop exfiltration-only ransomware, PAM and UEBA weren’t built for non-human identities, and browser-blind DLP misses what employees paste into AI tools. In each case, the investment was sound, but attackers are starting to change the route.

CIRCIA’s 72-hour clock, 30-day breach-to-disclosure windows, and AI agents operating at machine speed all compress the window between something happening and you needing to have already responded. Adaptation matters, but so does the speed at which you adapt.

Some questions for your next team discussion: Do you have an exfiltration-only response track? An agent identity inventory? Auditable evidence of AI policy enforcement — not just the policy itself? If the answer to any of those is no, you’re defending a border the attacker stopped crossing a while ago.

Subscribe now

Welcome to Issue #57 of Security Leadership Weekly! This week's content has less to do with CVEs, MITRE ATT&CK techniques, or attack campaigns (though there’s still some of that). Being a CISO right now means making consequential decisions in domains where process, policies, or frameworks may not yet exist - where nation-states borrow criminal playbooks to confuse attribution, regulatory deadlines arrive before compliance frameworks mature, and where the supply chain you're responsible for securing extends into code repositories you've never audited and/or don’t control. The technical problems are really hard. The leadership problems, such as governing in ambiguity, framing risk for audiences who want certainty, and building institutional readiness for scenarios that haven't happened yet, may be harder. This week, we’ve got a bit of both.

Subscribe now

🛡️Tactical Challenges

Nation-State Actors Are Blurring the Line Between Criminal and State Operations

Two threat intelligence reports this week describe how nation-states are increasingly using criminal ransomware and hacktivist groups as operational proxies, with similar goals: persistent access to critical infrastructure, intelligence collection, and disruption. If your threat model still differentiates between “financially motivated cybercrime” and“nation-state APT,” you’re using distinctions that are dissolving quickly.

Waterfall’s 2026 threat report tracks a drop in cyber incidents with physical consequences (25% in 2025), but a 100% increase in nation-state and hacktivist attacks, with MuddyWater’s use of the Qilin ransomware ecosystem as an example of state actors operating through criminal infrastructure. CYFIRMA’s weekly intelligence report flags China-linked group UAT-7290 targeting U.S. and allied telecom providers through edge device vulnerabilities - access that serves intelligence collection, not ransomware monetization. Both are vendor-produced/unverified reports, but the pattern is well-documented public reporting on Russian and Iranian proxies using similar structures.

For most security leaders, the practical implication isn’t that you need to change up your defensive controls, but rather to change how you frame risk to boards and triage incident investigations. A ransomware intrusion that doesn’t proceed to encryption, or that targets operational technology networks rather than data, should trigger an APT hypothesis alongside the criminal one. Ask your threat intelligence function (or your IR retainer) whether your current escalation criteria would detect a nation-state actor using criminal tooling.

The AI-Driven SOC Revisited, by Rob Van Os

If you’re an operations leader who isn’t familiar with Rob’s SOC-CMM model, it’s worth your time to get up to speed. Rob just dropped this article on LinkedIn describing a new operating model for an AI-driven SOC, with the following key principles:

• The operational relevance of zero-days is increasing due to faster exploitation cycles

• SOCs are still dealing with ever-increasing event flows

• The bottleneck for many SOCs is the number of alerts that can be processed

• AIs are being embedded in SOC tooling, but value realization is still uneven and often limited to efficiency gains

I value Rob’s practical approach to these models and, to that end, his basic assertion that SOC functions aren’t fundamentally changing. A great addition to the SOC-CMM library of resources, especially if you’re incorporating AI capabilities into your SOC functions.

🤖 Emerging Threats

Attackers Target Developer Credentials In CI/CD Pipelines (and other things we already knew)

Multiple independent supply chain campaigns landed this week, with a common goal of harvesting cloud credentials, GitHub tokens, and deployment secrets from build systems. Most security leaders are aware, on some level, that secrets are often scattered throughout developer environments; attackers know this too, and have realized that these environments are less well-defended than the identity perimeter that most security programs have invested in hardening.

According to Unit 42, the “Mini Shai-Hulud” campaign embedded malware in four SAP npm packages with roughly 570,000 weekly downloads, explicitly targeting enterprise CI/CD pipelines for cloud credentials and deployment secrets. Separately, TechCrunch reports that a single compromised developer account was used to push over 630 malicious package versions across 317 packages in approximately 20 minutes; a manual review process just isn’t going to work at this scale.

And the list goes on, including the TanStack compromise targeting OpenAI employees’ devices and the Laravel-Lang/PHP campaign, which added more than 700 compromised package versions.

This week, ask your AppSec or DevSecOps lead two questions:

1. Do you have integrity verification (checksums, signed packages, lockfile enforcement) on every package your CI/CD pipelines pull at build time (not just production dependencies, but dev and build tooling as well)?

2. Are the credentials your build systems use scoped to least privilege and rotated on a schedule shorter than your MTTD?

If either answer is unclear, prioritize clarity and filling the gaps. Also, be sure to check out this Wired piece on TeamPCP’s mass software supply chain exploitation by Andy Greenberg and Lily Hay Newman (behind a pay wall).

👤 People and Processes

Most Security Programs Aren’t Ready for CIRCIA

CISA's final Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) rule - 72-hour incident reporting for about 300,000 entities across 16 critical infrastructure sectors, 24-hour reporting for ransomware payments - is expected to be finalized soon after the current lapse in Federal funding for CISA is resolved. The hard problem isn't the notification itself; it's making a confident, defensible determination within 72 hours that an incident is "covered" under CIRCIA's definition - most organizations still treat breach disclosure as an ad hoc task during incident response. Institutionalizing these disclosures will require documented triage criteria, logs sufficient to reconstruct a timeline, and pre-cleared legal counsel.

At the same time, the SEC is elevating cybersecurity above cryptocurrency on its 2026 examination priority list, which means the appetite for regulatory enforcement (read: fines) is increasing even as implementation timelines slip. The bottom line is that time is running short for organizations to build out these compliance programs.

Two things most IR teams don't have documented:

1. A sector-specific determination checklist defining what qualifies as a covered cyber incident under your CIRCIA designation

2. A logging architecture sufficient to establish the incident onset independently

If you're in critical infrastructure and haven't done a CIRCIA readiness gap assessment, assign it to your GRC function as a Q3 priority. The rule can be implemented at any time, and the ramp-up period will likely be short.

🎙️Media Roundup

AI-Driven Hunting in Browser Telemetry with Jacques Louw

James Wilson of the Risky Bulletin Podcast chats with Push Security Co-Founder and Chief Research Officer, Jacques Louw, about how we’ve integrated AI agents into our threat detection platform, our careful approach to introducing agentic capabilities over time, and how it has helped our threat research team scale analysis and detection engineering functions. Great conversation on striking the right balance between human expertise and automation, with examples!

Ethics in Cybersecurity with Ed Skoudis and Paul J. Maurer

⁠Paul J. Maurer⁠ and ⁠Ed Skoudis⁠ joined the ⁠Caveat⁠ podcast with ⁠Ben Yelin⁠ this week to talk about their new book, "The Code of Honor: Embracing Ethics in Cybersecurity." The book lays out a code of ethics for cybersecurity, providing a decision framework that transcends cyber law. This is immensely useful since technology trends move so quickly that policy just can’t keep up (Ed mentions AI as an example). Ed’s perspective, based on decades of experience as a practitioner and instructor, and Paul’s legal expertise, make for an interesting episode and a must-read; I will definitely be checking this one out. You can hear the N2K Cyberwire episode here.

Holding the Line: Episode One | Why the Hell Would Anyone Want to Be a CISO

Great first episode of a web series from Nagomi Security and Hacker Valley Media, featuring interviews with experienced CISOs. This one covers the evolution of the role (and what it looks like today), mental health and burnout, and primary motivations of a CISO.

💡Connecting the Dots

The CISO role has always required translating technical complexity into business decisions, but the complexity keeps expanding faster than the frameworks designed to contain it. This week's content, from Rob Van Os's AI-enabled SOC operating model to the CIRCIA readiness gap to Ed Skoudis and Paul Maurer's ethics framework, reflects efforts to build those frameworks in real time. If you're a security leader feeling the weight of that ambiguity, you're not alone, and the field is producing better tools, models, and conversations to help carry it.

Subscribe now

Subscribe now

🛡️Tactical Challenges

Device-code Phishing Is An Authentication Architecture Problem

Device-code phishing works not because users are fooled into clicking a malicious link, but because they are directed to a legitimate Microsoft login page and complete MFA successfully. The attack exploits an OAuth 2.0 flow that was designed for devices without browsers (like apps on your new smartTV), and it bypasses MFA precisely because MFA is working exactly as intended. Security leaders who think their MFA deployment closes this gap are wrong: they’ve hardened the IdP layer while leaving the authorization grant layer exposed.

The Tycoon2FA phishing kit was disrupted by an international law enforcement operation back in March, then rebuilt on new infrastructure, and was back at normal operational tempo within weeks - now with device-code phishing capability added. According to eSentire, the attack routes victims through a four-layer obfuscated delivery chain before completing the authorization flow.

Based on our research at Push Security, we’ve reported a 37x increase in device-code phishing this year across at least ten PhaaS platforms, and Proofpoint has independently documented a similar surge.

What to ask your identity team this week: Do our conditional access policies restrict or block the OAuth device authorization grant flow in our Microsoft 365 tenant? If not, what is the business justification for leaving it enabled?

Many orgs haven’t turned on conditional access controls to block or constrain device-code flows, because a lot of phishing training still focuses on credential harvesting or because they’re using business applications that leverage device code auth. If your tenant allows device code authorization, a technically average attacker can get a persistent foothold that survives a password reset.

Governing the Machines: How to Detect and Respond to Compromised Agent Identities in Microsoft Entra

In a May 2026 SANS Cloud Security presentation, my SANS colleague Maxim Deweerdt walked through the architecture underpinning Microsoft’s Agent Identity framework - where agents are now treated as first-class Entra identities with their own tokens, Conditional Access evaluation, and lifecycle governance - and what that means when things go wrong.

The framework introduces a four-layer hierarchy:

• An Agent Identity Blueprint (the factory that mints agents)

• A Blueprint Principal (the installer)

• The Agent Identity itself (the runtime credential that calls APIs)

• An optional Agent User (a linked user object for mailbox and Teams access).

The blueprint is basically the blast radius: a compromised or misconfigured blueprint instantly affects every agent identity it spawned. Microsoft’s Identity Protection now surfaces agent-specific detections like unfamiliar resource access, sign-in spikes, and failed access attempts, though these remain offline rather than real-time. Response options include confirming compromise via the Risky Agents report, applying a Conditional Access block, disabling the Agent User, or deprovisioning via Microsoft Graph, each with distinct tradeoffs between speed and business impact.

CA policies cannot yet target individual Agent Users or block them based on risk signals, leaving only a coarse all-or-nothing block option. Max’s seven-step SOC readiness checklist provides a concrete path to get ahead of this emerging identity attack surface before risky agent alerts start landing in their queues. Really great presentation worth checking out if you’re an Entra shop managing AI identities.

🤖 Emerging Threats

The CISA GitHub Leak Is a CI/CD Hygiene Story, and Your Organization Probably Has the Same Problem

A contractor for CISA (people I may or may not have worked with previously, but I digress) deliberately disabled GitHub’s built-in secret scanning, stored AWS GovCloud administrative credentials and plaintext passwords in a public repository, and used it as a personal sync scratchpad across environments. Plenty of room for criticism here, but from a governance standpoint, it’s the predictable result of giving developers and contractors the ability to opt out of secrets management controls. When secrets controls are bypassable, CI/CD tooling creates persistent credential sprawl, and the problem is exacerbated by contractor environments that sit outside the security controls applied to full-time staff. I thought CMMC was supposed to solve this? Jk. Kind of.

Krebs on Security reported that the public GitHub repository named “Private-CISA” contained AWS GovCloud administrative keys (in a file literally named “importantAWStokens”), a CSV of plaintext usernames and passwords for dozens of internal CISA systems, and internal deployment code for CISA’s DevSecOps environment. The researcher who discovered it, Guillaume Valadon of GitGuardian, noted that the account owner had explicitly disabled GitHub’s default secrets-detection feature; so this wasn’t an accidental misconfiguration, it was an active opt-out. We don’t yet know how long the credentials were exposed, whether anyone other than the researchers accessed them before discovery, and whether any GovCloud services were actually compromised or merely at risk.

The audit question for your team is: can your developers and contractors disable or bypass your secrets scanning controls, and does your organization know when that happens? GitHub’s push protection can be bypassed at the repository level if administrators allow it; the default is protective, but the override is usually easy. In the next 30 days, have your security engineering team verify that secrets scanning is enforced at the organization level across your GitHub (and GitLab, Bitbucket, Azure DevOps) estate, with contractor and third-party repositories explicitly in scope. The CISA incident also exposes a contractor oversight gap that belongs on a board risk agenda: do your third-party developers operate under the same credential and secrets management controls as internal staff, and how would you know if they didn’t?

“The Gentlemen” Ransomware Group Exposed: Inside a Major RaaS Operation

A detailed intelligence analysis published by Ransom-ISAC this week offers a look inside The Gentlemen, a Russian-speaking ransomware-as-a-service (RaaS) group that emerged in mid-2025 and has since claimed over 400 victims globally. The report is based on 3,366 internal chat messages leaked in early May 2026 after the group’s hosting provider was compromised, revealing the operation’s full attack lifecycle:

1. Initial access via Fortinet VPN exploitation (primarily CVE-2024-55591),

2. Lateral movement using NetExec and credential dumping tools

3. Data exfiltration via rclone

4. Double-extortion negotiations conducted through qTox.

Analysts identified nine core operators, a custom C2 framework called G-BOT, and the repurposing of the legitimate DFIR tool Velociraptor as a command-and-control platform (which we’ve seen before). Notably, the group actively integrated commercial LLMs like ChatGPT and Claude for negotiation drafting, while also experimenting with locally-hosted uncensored AI models for triage of stolen data. Strong infrastructure and personnel links to the defunct Black Basta group, including a shared Matrix server and recurring operator handles across multiple leak corpora, support a moderate-to-high level of confidence that The Gentlemen represent a direct successor lineage. Security leaders should prioritize patching internet-exposed Fortinet devices if you aren’t already, monitor for SOCKS5 proxy traffic on non-standard ports as a lateral movement indicator, and note that the group has actively tracked its own victim rankings.

👤 People and Processes

Your Board Deck Is Your Board Agenda, Whether You Like It or Not

Dave Kellogg published a post this week that’s required reading for any CISO who has ever walked out of a board meeting frustrated. His argument is simple and a little uncomfortable: the board deck isn’t a document you present, it’s the de facto agenda of the meeting. Whatever’s in the slides will get discussed. Whatever isn’t, won’t. As he puts it, the meeting flows where the slides take it, like a raft in a river. Which means that if you built a 40-slide operations review and wanted a strategic conversation, you’re not getting one - you’re getting the ops review you showed up with.

Most CISO board decks are built the same way every quarter: open last quarter’s deck, update the numbers, swap in the new incidents and the new threat intel, and add the initiative you want funded. The structure never changes because nobody explicitly decided what this meeting should actually be. Kellogg identifies at least seven different types of board segments - ops review, discussion, proposal, presentation, update, working session - each one requiring a different slide approach. A discussion segment should have almost nothing on the slides: a little context, a few well-framed questions, and then deliberate blank space that signals the value is in the conversation, not the deck. A proposal needs a clear situation-recommendation-ask structure and should not surprise anyone who got a pre-meeting call. The discipline isn’t complicated; it just requires deciding, segment by segment, what kind of conversation you’re actually trying to have. Most of us skip that step entirely and then wonder why the board keeps spending forty minutes on patch metrics when we wanted to talk about AI risk.

💡Connecting the Dots

The device code phishing story and the CISA GitHub leak look unrelated on the surface, but they’re the same problem at different layers. In both cases, an organization assumed a control was providing coverage that it wasn’t. This pattern has shown up in this newsletter more than any other: in #45 (”Your attack surface is working correctly”), in #48 (”Ambition Without Capacity Isn’t a Strategy”), in the Stryker MDM wipe in #49 where compromised admin credentials turned a patch management console into a mass-wipe tool.

The consistent lesson isn’t that the controls are bad, it’s that controls not scoped to actual adversary behavior create a false floor that’s worse than no floor at all. At least a missing control shows up as a gap in an audit.

The Entra Agent Identity piece is the same story in preview. Maxim’s presentation makes clear that Microsoft is building the governance architecture for AI agents in Entra in real time, but CA policies can’t yet target individual agents based on risk - meaning your coarsest control option is an all-or-nothing block. As I noted in issue #53 when covering CSA’s shadow AI research, 82% of organizations discovered an AI agent that security and IT didn’t know about; and that was before organizations started formally provisioning Entra identities for agents. The governance frameworks are arriving, but the attack surface is already here.

The Gentlemen leak deserves a second read for anyone who’s been tracking the AI-in-security-operations conversation. In my AI Commoditization essay, I argued that AI models are becoming interchangeable infrastructure - that the model isn’t the moat. The Gentlemen are running that thesis from the offensive side: ChatGPT and Claude for negotiation drafts, locally-hosted uncensored models for data triage, switching between them based on what each job requires. This also connects directly back to #27, where Velociraptor first appeared as an attacker tool. Bottom line: legitimate tools don’t stay legitimate tools when there’s an active criminal economy for them.

Subscribe now

Subscribe now

🛡️Tactical Challenges

Instructure/Canvas Breach: What We Know

Instructure, the edtech company behind the widely used Canvas learning management system, was breached by the ShinyHunters extortion group, which claimed to have stolen more than 3.6 TB of data (usernames, email addresses, course names, enrollment information, user messages). The attack affected over 30 million educators and students across more than 8,000 institutions worldwide - right in the middle of final exams.

ShinyHunters exploited cross-site scripting (XSS) vulnerabilities in Instructure’s Free-for-Teacher environment to obtain authenticated admin sessions and perform privileged actions. This was actually a return visit by SH; Instructure first detected unauthorized activity on April 29, and then on May 7, the attackers returned through the same unpatched vulnerability to deface Canvas login portals with extortion messages. A previous breach in September 2025, also claimed by ShinyHunters, had already compromised Instructure’s Salesforce instance, so it seems like the company has some questions to answer about their remediation practices and third-party risk posture.

This week, within the deadline SH had originally given for negotiations, Instructure announced it had “reached an agreement” with ShinyHunters - which sounds an awful lot like “we paid the ransom”. As part of the agreement, Instructure said the stolen data was returned (???) and it received digital confirmation of destruction in the form of “shred logs,” with ShinyHunters stating that no Instructure customers would be further extorted. Of course, there is no reliable way to verify data has actually been deleted or that the exposure has been fully remediated.

Key unanswered questions remain: Instructure has not disclosed the terms or financial value of the agreement, has not confirmed the full scope of affected users, and has not explained why the same Free-for-Teacher vulnerability was re-exploited a week after the initial breach. Security teams should also be alerting their communities to the elevated risk of follow-on spear-phishing campaigns leveraging real institutional context, like course names, advisor relationships, and sensitive private messages, which were captured in Canvas and now may be in criminal hands.

AI-Generated Zero-Day Exploit Used in Active Criminal Campaign

Google’s Threat Intelligence Group (GTIG) has identified what it describes as the first confirmed case of a threat actor using an AI-generated zero-day exploit in an active attack. According to GTIG, the exploit was developed by a prominent cybercrime group and was specifically designed to bypass two-factor authentication. This finding comes from a combination of Mandiant incident response engagements and GTIG’s proactive research, and it turns AI-assisted exploit development from a popular AI talking point into observed tradecraft.

What strikes me about this story isn’t that AI suddenly makes exploit development trivial (it doesn’t), but that it lowers the barrier to producing working exploits for groups that previously lacked the technical depth to develop them in-house. Your detection and patch velocity timelines should account for an abbreviated adversarial development cycle. The specific 2FA bypass targeting also reinforces a consistent pattern in which attackers invest engineering effort in defeating or bypassing authentication controls because they know that’s where defenses have hardened.

This research backs up GTIG’s February report on AI augmenting adversarial workflows, which is worth revisiting in light of this disclosure.

🤖 Emerging Threats

Fake OpenAI Model Repository Delivered Rust-Based Infostealer to 244K+ Downloaders

A malicious Hugging Face repository impersonating OpenAI’s legitimate “Privacy Filter” model reached the platform’s trending list and accumulated over 244,000 downloads before being disabled. According to HiddenLayer’s research team, the fake repo (Open-OSS/privacy-filter) shipped a loader.py file that, when executed, silently fetched and executed a Rust-based infostealer that harvested Discord tokens, cryptocurrency wallets, browser credentials, and system metadata. Hugging Face has disabled the repository, but the timeline of how long it remained live and whether affected users were directly notified is not publicly confirmed.

The 244,000 download figure probably doesn’t mean that many infections; views, stars, and clones are often conflated in these reports, and the infostealer required deliberate execution of a batch or Python script. But the problem here is that these ML model repositories have no meaningful supply-chain vetting equivalent to what package managers like PyPI or npm have built over years.

If your developers or data science teams are pulling models from Hugging Face as part of their workflow, they are doing so in an environment where typosquatting a trending model is trivial, and detection is reactive if it exists at all. The question to ask your teams this week is whether Hugging Face model pulls go through any review gate, or whether they land directly on developer or training infrastructure. More coverage of this story on The Hacker News.

Shared Claude Chats weaponized to target macOS users

This BleepingComputer report documents an active malvertising campaign (discovered by Berk Albayrak, a security engineer at Trendyol Group) that’s essentially a new evolution of the InstallFix campaign my colleagues at Push Security discovered back in March. Where InstallFix cloned legitimate install pages and swapped out the curl command, this campaign takes a more insidious approach: attackers are hosting malicious instructions inside Claude's own shared chat feature, so the Google Ads pointing to those chats show claude.ai as the verified destination URL (a genuine domain, not a lookalike).

The weaponized shared chats present themselves as official "Claude Code on Mac" installation guides attributed to Apple Support, directing users to open Terminal and paste a command that triggers an infostealer infection - the same ClickFix-style terminal-paste social engineering at the core of InstallFix, but delivered through a trusted AI platform rather than a cloned website. One variant performs geographic profiling first, checking for Russian or CIS-region keyboard inputs before proceeding; the other, a MacSync infostealer, skips profiling and goes straight to harvesting browser credentials, session cookies, and macOS Keychain contents.

South Staffordshire Water Fined Following Ransomware Attack

South Staffordshire Water, a UK utility supplying drinking water to 1.6 million people, was fined £963,900 ($1.3 million) by the UK's Information Commissioner's Office after the Cl0p ransomware group spent nearly two years inside its network undetected. The group gained initial access in September 2020 via a malicious email attachment and wasn’t discovered until July 2022, when an IT performance slowdown triggered an internal investigation. By then, the attacker had escalated to full domain administrator privileges and exfiltrated data on 633,887 customers and employees, including bank account numbers, National Insurance numbers, and disability information, ultimately publishing it on the dark web.

The ICO's investigation found a cascade of basic security failures:

• As of December 2021, an outsourced SOC was monitoring just 5% of the company's IT environment

• No internal or external vulnerability scans were conducted during the entire period of compromise

• Some devices were still running Windows Server 2003

• Two domain controllers remained unpatched against ZeroLogon, a critical privilege escalation vulnerability published in August 2020 (which the attacker successfully exploited).

The regulator's message was blunt: "Waiting for performance issues or a ransom note to discover a breach is not acceptable - proactive security is a legal requirement, not an optional extra." The case lands as UK water suppliers face a record pace of cyberattacks and Parliament prepares to take up the Cyber Security and Resilience Bill, which would expand mandatory reporting requirements for critical infrastructure operators.

👤 People and Processes

Cloudflare’s AI-driven layoff of 1,100 employees

Cloudflare announced a 20% workforce reduction (approx. 1,100 employees) despite reporting its strongest quarter ever, with $639.8 million in revenue representing 34% year-over-year growth. CEO Matthew Prince framed the cuts not as cost-saving measures but as a structural response to AI-driven productivity gains, citing a 600% increase in internal AI usage over just three months and claiming some employees have become up to 100 times more productive. The company's entire R&D team is now using AI coding tools with autonomous agents reviewing all deployed code, and AI is being used across HR, finance, and marketing as well. Prince argued that this efficiency surge reduces the need for support roles, though he maintained that Cloudflare will continue hiring and expects to have more employees in 2027 than at any point in 2026 - a claim that reflects a broader and increasingly familiar pattern in tech, where AI productivity gains are being used to justify headcount reductions even amid strong financial performance.

A few interesting notes on this one, aside from the fact that it sucks when “healthy” companies do mass layoffs:

• The company’s stock took a pretty big hit following the earnings release and layoff announcement - 23% on Friday.

• A new Gartner study of 350 global business executives found that many companies have reduced their workforce regardless of whether AI was actually generating returns; Gartner analyst Helen Poitevin says, "Workforce reductions may create budget room, but they do not create return. Organizations that improve ROI are not those that eliminate the need for people, but those that amplify them.

• An Nvidia exec made the following point about dubious cost efficiencies: "For my team, the cost of compute is far beyond the costs of the employees," said Bryan Catanzaro, VP of applied deep learning at Nvidia. An AI and finance professor quoted in the same piece attributed this to hardware and energy raising operating costs for providers, creating a short-term mismatch, where AI use has remained less efficient than human labor.

💡Connecting the Dots

This week's incidents share a common theme: attackers aren't breaking down doors, they're walking through ones you've propped open. Shared Claude chats and Google Ads abuse the trust you extend to verified domains and AI platforms. The Hugging Face fake model repository exploits the absence of supply-chain vetting in ML tooling that your developers treat as routine infrastructure.

The perimeter isn't where the action is anymore; the action is in your delivery channels, your model repositories, your shared productivity tools, and the monitoring gaps you may be paying someone else to cover.

This week’s to-do list:

1. Ask your development and data science teams to identify any Hugging Face repositories they pull into development or training pipelines, and confirm whether those pulls go through any integrity verification step (hash check, organizational review, or allowlist).

2. The South Staffordshire Water ICO finding is a useful forcing function for a board conversation about detection coverage. Pull your current mean-time-to-detect metrics and compare them against a two-year dwell scenario: would you have found it?

Subscribe now

Subscribe now

🛡️Tactical Challenges

cPanel Ransomware Attack Via Authentication Bypass Exploit

CVE-2026-41940, a CVSS 9.8 authentication bypass in cPanel and WHM, has been under active exploitation since at least late February, and has now been weaponized at scale by the “Sorry” ransomware group. Shadowserver has tracked at least 44,000 compromised cPanel IP addresses; Rapid7 researchers have confirmed that successful exploitation grants full control over the host system, its configurations, databases, and all websites it manages. The Sorry ransomware deploys a Go-based Linux encryptor using ChaCha20 with RSA-2048 key protection, meaning no decryption path exists without the threat actor’s private key. Multiple major hosting providers, including Namecheap, InMotion, KnownHost, and HostPapa, have emergency-firewalled their own customers off cPanel interfaces to slow the bleeding.

cPanel sits at the base of an enormous amount of shared and managed hosting infrastructure, which means the blast radius isn’t just the organizations running cPanel; it extends to every tenant, customer, and downstream site on those servers (read: supply chain attack on the hosting side). If your organization relies on managed hosting providers or if you oversee web properties running on shared infrastructure, confirm patch status and check whether your provider has applied the vendor-supplied detection tool. The broader pattern is familiar and worth flagging for your teams: zero-day exploitation with a months-long head start before public disclosure, followed by commodity ransomware operators piling in once the flaw goes public.

Note: this mass-hosting compromise mirrors the Cordial/Snarky Spider SaaS extortion story below, though it uses different attack infrastructure. It’s basically the same dynamic of attackers moving faster than most organizations’ patch and detection cycles.

Also Worth Tracking:

Via The Hacker News: Cordial Spider and Snarky Spider are running SaaS-only extortion campaigns using vishing to direct targets to SSO-themed AiTM pages. Detection is hard in these SaaS-based LOTL attacks because there’s no endpoint to examine, and because the attackers suppress device-registration notifications via inbox rules before pivoting to high-privilege accounts. Tough to establish baselines when you don’t see what’s happening.

Via BleepingComputer: Microsoft Defender falsely flagged two DigiCert root certificates as Trojan:Win32/Cerdigent.A!dha, and removed them from the Windows trust store on affected systems. A fixed signature update is now available, but the incident intersects with a DigiCert breach in which attackers compromised a support analyst’s device and obtained initialization codes for a limited number of code-signing certificates, some of which were used to sign malware.

🤖 Emerging Threats

Linux Kernel “Copy Fail” Exploit Hits Cloud and Kubernetes at Scale

CVE-2026-31431, dubbed “Copy Fail,” is a logic flaw in the Linux kernel’s AF_ALG cryptographic subsystem that allows any unprivileged local user to achieve full root access. A working PoC was published by researchers at Theori and Xint, and Go and Rust versions have already appeared in open-source repositories. The exploit works by corrupting the kernel’s in-memory page cache of readable files, including setuid binaries like /usr/bin/su, without touching disk.

This is a good example of how various factors come together to bump up the urgency of remediation: a nine-year-old vuln, a working public exploit that doesn’t require race conditions or memory address guessing, in-memory-only execution that produces no disk artifacts, and default exposure in Kubernetes. Obviously patching is a priority, but a bigger question is whether you can detect in-memory privilege escalation that doesn’t touch disk, and whether your Kubernetes pod security policies restrict AF_ALG access. Microsoft notes that exploitation has so far been primarily PoC-stage, but with multiple reimplementations in the wild and a CISA KEV designation, the window before opportunistic threat actors operationalize this is narrowing. If you’re running multi-tenant cloud workloads or shared CI/CD pipelines, you should treat this as a priority this week.

MFA Still Won’t Save You: ConsentFix v3 Reduces Friction

Via Bill Toulas at BleepingComputer: ConsentFix v3 is the latest iteration of a post-authentication, in-browser attack. The original ConsentFix was discovered by my colleagues at Push Security back in December as a ClickFix-style OAuth phishing attack that tricks victims into completing a legitimate Microsoft login flow, then pasting a localhost URL containing an OAuth authorization code back into an attacker-controlled page - effectively handing over account access without requiring a password or MFA bypass. v2 smoothed out the copy-paste friction with drag-and-drop, and now, v3 removes the manual backend steps entirely. When the victim interacts with the phishing page, the captured authorization code is automatically shipped to a Pipedream webhook and immediately exchanged for tokens, with post-exploitation handled through Specter Portal.

If you read our research on ConsentFix v1, you already know that Azure CLI is implicitly trusted in Entra ID as a first-party Microsoft app. It can’t be blocked or deleted by tenant administrators, requires no admin approval for permission grants, and can request scopes that third-party apps can’t - so standard app consent controls don’t apply. Phishing-resistant MFA doesn’t apply either, because the victim is completing a real authentication flow. The attack produces some detectable patterns: OAuth authorization code exchanges from unexpected IPs, token usage inconsistent with normal user behavior, and serverless platform endpoints like Pipedream appearing in OAuth redirect flows. If you’re not already monitoring browser telemetry, this is a good week to start.

Push Security Threat Briefing: May 2026

Push Security's May 2026 threat briefing is out on LinkedIn! This month's edition covers the Vercel OAuth breach and shadow AI integrations in general, a 37.5x spike in device code phishing (!), the rise of fully automated vishing platforms like ATHR, the structural limits of extension risk scoring, and a detailed rundown of the ongoing ShinyHunters/SLH SSO-to-SaaS campaign - including fresh victims across ADT, McGraw-Hill, Rockstar Games, Medtronic, and the European Commission. If identity-based attacks and browser-native threats are on your radar (and they should be), give it a look.

👤 People and Processes

Five Eyes on Agentic AI

The NSA, CISA, Australia’s ASD ACSC, and their counterparts in Canada, New Zealand, and the UK jointly released guidance this week on the secure adoption of agentic AI systems. The document was published the same week as the CSA’s shadow AI agent research (covered in the last issue), and begs the question of whether private industry has any hope of keeping pace with AI deployment.

The guidance warns that strong governance, explicit accountability, rigorous monitoring, and human oversight are “not optional safeguards but essential prerequisites,” and recommends that organizations assume agentic AI systems may behave unexpectedly. They further recommend prioritizing resilience, reversibility, and risk containment over efficiency gains. Of the risk categories cited, privilege takes the top spot; specifically, privileges assigned to agents directly determine the level of risk they can introduce, and poor privilege management exposes organizations to scope creep, identity spoofing, and agent impersonation. Also flagged: LLM-based agents that may change their behavior when evaluations are underway and may even bypass system-level instructions to achieve their objectives - a risk that’s easy to underestimate when most governance focuses on what agents are authorized to do rather than whether they’ll actually stay within those lanes.

The takeaway is that agencies recommend never granting agentic AI broad or unrestricted access to sensitive data or critical systems, and limiting its use to low-risk, non-sensitive tasks until security practices and evaluation methods mature. That’s a conservative bar that most current deployments (especially in the private sector) don’t meet. If your organization is moving faster than that, this document is a useful checklist for identifying gaps in your governance model.

CTI Isn’t Intelligence, And That’s Fine

Joe Slowik, via his Stranded on Pylos blog, has written one of the more thought-provoking pieces on threat intelligence I’ve read in a while. The field of cyber threat intelligence has saddled itself with terms and definitions borrowed from formal intelligence community (IC) tradecraft; structured analytic techniques, analysis of competing hypotheses, multi-phase production cycles, etc., which are largely mismatched to the timescales of detection and response. The tension stems from the fact that the formal IC model optimizes for rigor, but the operational security environment optimizes for speed.

The alternative framing Slowik proposes is indications and warning (I&W): a military concept where the further along the intelligence refinement process you move, the greater the likelihood that the resulting product arrives after its moment of maximum efficacy - basically, a point of diminishing returns. Under an I&W model, file triage, log analysis, and infrastructure tracking become more critical than executing a well-structured ACH (for example), because the decision maker needs actionable input now - not a finished product next week.

We cover a lot of these concepts in LDR551, including structured analytic techniques and ACH, so this one really gave me pause. But Joe is on point as usual. Structured analysis remains useful for training and process alignment, but it may not always be applicable in time-sensitive detection and response. Ask yourself: who is your intelligence actually serving, at what timescale, and is the production model matched to those needs? If your analysts are executing structured reporting cycles optimized for strategic briefings while your detection engineering team is waiting on IOCs, something is misaligned.

IR Professionals Sentenced for Ransomware Attacks

Ryan Goldberg (Sygnia) and Kevin Martin (DigitalMint) each received four-year sentences this week after pleading guilty to conspiracy charges for deploying ALPHV/BlackCat ransomware against clients they were ostensibly helping. A third co-conspirator, Angelo Martino, also a ransomware negotiator at DigitalMint, went even further: he was simultaneously negotiating ransoms on behalf of five victims while feeding those victims’ insurance policy limits and confidential operational details to the ransomware gangs. Martino coordinated payouts reaching $26 million and faces sentencing in July. The group earned $1.2 million from one successfully extorted company; law enforcement seized roughly $10 million in assets from Martino and tracked Goldberg across ten countries before arrest.

DigitalMint’s post-incident controls - cloud-audited negotiation platforms, founder oversight of all negotiations, DHS registration of negotiators - are reasonable minimums, but they came after the fact. Time to check in with your external IR and negotiation partners on access controls, audit logging, and conflict-of-interest disclosures.

💡Connecting the Dots

We’re in the middle of another evolution that echoes what we saw most recently in the ransomware ecosystem, toward scale, speed, and the systematic removal of cost from the offensive side of the equation. ConsentFix v3 is a great example: each iteration has eliminated one more step requiring human effort. ATHR replaces human callers with AI voice agents so that vishing scales without headcount. And when cPanel and Copy Fail went public, commodity operators were at scale within days.

Takedowns impose costs and are worth doing, but they don’t necessarily change the underlying economics. Joe Slowik's piece on CTI essentially presents the defender’s side of this argument: formal analytic tradecraft adds friction and time costs to the process at exactly the moment attackers have eliminated friction from theirs. The organizations best positioned to respond to this environment aren't the ones with the most rigorous processes or the longest list of controls; they're the ones who have matched their operational tempo to the threat.

Subscribe now

Subscribe now

🛡️Tactical Challenges

You Can’t Govern What You Can’t See

The CSA’s new research puts a number to a problem that security leaders have been sensing for a while: 68% of organizations say they have high visibility into their AI agents and autonomous workflows, yet 82% discovered at least one AI agent or workflow in the past year that security or IT did not previously know about. The gap between these is where the risk lives, and it’s a particularly uncomfortable gap given how AI agents work: unlike static infrastructure, agents can evolve through updates or prompt changes, expand their scope through integrations, interact dynamically with other systems, and operate without continuous human oversight if not kept on a short leash.

What makes this harder to solve is that shadow AI agents aren’t emerging from rogue corners of the enterprise. The most common discovery locations were internal automation and scripting environments, LLM platforms including custom tools and plugins, SaaS tools with built-in automation, and developer-created workflows.

The CSA’s recommendation isn’t to lock these environments down - it’s to make them governable: treat agent creation as a governance event, extend lifecycle management expectations beyond traditional software procurement, and design control models that assume decentralization rather than relying on a single review board or approval process. I’d add real-time monitoring for OAuth consents to weed out overly permissive grants to AI agents (something we’re doing at my day job). Either way, the time to focus on this is now - not after the first incident where an agent has gone rogue.

Robinhood Abused for Phishing Delivery

Via Lawrence Adams at BleepingComputer: Attackers have exploited a flaw in Robinhood’s account creation process that allowed them to inject arbitrary HTML into the device metadata field of official onboarding emails - content that Robinhood didn’t sanitize before rendering, causing the injected phishing message to appear as a legitimate security alert inside an email sent from Robinhood’s own systems. Using in-app notifications as phishing delivery mechanisms isn’t new; it’s a great way to get phishing messages past SPF, DKIM, and DMARC authentication checks and to add legitimacy to the lures.

Robinhood confirmed that affected customers were notified, the campaign was taken down, and account creation flows were strengthened. They noted that no account takeover was possible through the email itself, but this is less about Robinhood specifically and more about a mass delivery vector.

The Grace Period Is Over

Via Derek B. Johnson at CyberScoop: For years, organizations watched comprehensive privacy laws pass and largely concluded they had time. But in 2025, U.S. states issued $3.45 billion in privacy-related fines - more than the previous five years combined. The increase was driven by stronger enforcement of laws such as California’s CCPA, new interstate partnerships, and a sharper focus on how AI and automated decision-making affect personal data.

Regulators have moved from guidance to enforcement, and many organizations that “weren’t paying attention” were caught having let their privacy programs atrophy during the gap between legislation and meaningful penalties. Ten states now coordinate enforcement across state lines through the Consortium of Privacy Regulators, and federal preemption legislation (which would override stronger state laws like California’s) remains politically contested enough that organizations would be unwise to bet on it as a compliance strategy.

The timing on this is pretty pointed. In the past two weeks alone, ShinyHunters has claimed responsibility for a wave of high-profile data exposures. Victims include Udemy, Carnival Cruises, and Pitney Bowes. McGraw-Hill (15 million rows), Amtrak (2.3 million rows), and Carnival (7.5 million rows) also appear in recently verified disclosures. In a $3.45 billion enforcement year, with ten states actively coordinating, the question isn’t whether a breach will attract scrutiny; it’s whether your privacy program was mature enough to demonstrate reasonable care before it happened.

🤖 Emerging Threats

AI Prompt Injections in the Wild

This post on prompt injection in the wild by the Google Threat Intelligence Team is a cool case study of a detection challenge at scale. The team swept the Common Crawl Foundation (2-3 billion public web pages per snapshot) for indirect prompt injection patterns. Most of what they found was low-sophistication stuff like pranks, SEO manipulation, and benign experiments. Scanning for content like “ignore previous instructions” or “if you are an AI” returned mostly false positives like blogs, research papers, etc. Their fix was a coarse-to-fine pipeline: pattern matching, then LLM classification for intent and context, then human review.

This maps almost exactly to how we approach detection engineering at my day job. Browser session data is incredibly noisy; credential reuse, OAuth grants, extension behavior...the benign and the malicious are often indistinguishable until you add context. What customers don’t always see is the amount of work that goes into getting this right - the iteration, the tuning, the deliberate tradeoffs our team makes to surface high-confidence detections instead of handing analysts a firehose of noise.

👤 People and Processes

ATT&CK v19: The Framework Gets Sharper Where It Matters Most

The headline change in ATT&CK v19 is one many of us have been waiting on for a while: the Defense Evasion tactic has been split in two. The new structure separates Stealth - covering things like living-off-the-land binaries and masquerading - from Defense Impairment, which covers adversaries actively breaking your defenses. Think killing EDRs, tampering with logging pipelines, and/or subverting trust controls. It’s an important distinction because the two require completely different defensive responses, and lumping them together was obscuring that nuance.

If your team maintains ATT&CK-mapped detection content, time to do some homework! T1562 and several sub-techniques have been revoked and restructured under new IDs, and MITRE has published crosswalk files in JSON and CSV to help teams remap existing content. Check those before assuming your current mappings still hold.

Beyond the structural changes, v19 reflects where the threat landscape is actually moving. New techniques cover AI-enabled adversary behavior, like how threat actors are querying public AI services for target research and using AI to generate written and audio-visual content for operations. It also consolidates Social Engineering parent techniques like impersonation and email spoofing under a single behavior category with unified detection logic. The CTI additions are equally notable: MITRE has documented a PRC state-directed cluster using Claude Code to autonomously execute most of a multi-stage espionage campaign, and added LAMEHUG, described as the first malware documented to query a large language model in live operations.

Two quick hits on team design and communication this week…

The Case Against Team Meetings

Ever joked about the “expense” of a meeting based on the cost of the attendees’ time? On his blog, Alexandre Dulaunoy argues that when a team depends on a weekly meeting to learn what everyone has been doing, the meeting itself is a symptom: it signals that communication is already failing. The format compounds the problem by turning information-sharing into performance; one person speaks while everyone else waits for their turn, mentally checked out. The author makes a point worth sitting with: a one-hour meeting with ten people isn’t a one-hour meeting, it’s a ten-hour cost for the team.

The alternative is structure: Dulaunoy’s team relies on a handful of chat channels: a global room, an informal one, and project-specific rooms, with the expectation that updates are shared in context when they happen, not batched up for a calendar slot. This is very similar to how we work at my day job (except for the part about eliminating meetings!), and it maps cleanly onto how high-performing SOC and incident response teams already operate - decisions and developments are surfaced asynchronously in writing, with meetings reserved for live coordination that genuinely can’t wait. The takeaway isn’t “eliminate all meetings,” but to stop treating the status call as a default and start treating it as a failure mode.

The Team That Runs Itself

And now a counter-argument, via Aytekin Tank at FastCompany: Tank, CEO of Jotform, argues that successful teams don’t need more management, but that leaders still have to build the communication patterns that make autonomy possible. His own model is instructive: 20-minute weekly check-ins with each team, focused on what they’re working on and where he can add input, with no micromanagement in between. Delegation works best when ownership is clearly defined - when accountability is built into the workflow, not added on top of it.

The piece also makes a case for visibility as a cultural practice rather than a management tool. Jotform holds weekly Demo Days where all 20-plus teams share successes, setbacks, and teachable moments with the whole company; a ritual the author frames not just as a sharing mechanism, but as a trust-building one. Thinking about this for security teams as an opportunity to discuss near-misses, incidents, and detection wins. The takeaway from this and Dulaunoy’s blog is that best-run teams aren’t the ones that report the most; they’re the ones that communicate the most purposefully.

💡Connecting the Dots

Most of the challenges we covered this week are more the result of management and operational drift than recklessness. The ATT&CK v19 update and the Google prompt injection research point in the same “cost of adequacy” direction from the practitioner side: the work of maintaining good detection isn't dramatic, it's iterative and ongoing. The team management pieces this week make the same point about communication. The best-run teams aren't the ones doing the most; they're the ones doing the most purposefully.

Subscribe now

In related news, a Microsoft Deputy CISO published a timely counterpoint on credential elimination and platform engineering as structural defenses against exactly this pattern. Insurance carriers, apparently reaching their own conclusions, are quietly repricing or excluding the AI-shaped version of the same problem.

But before we dive in, a brief announcement: as part of Push Security’s State of Browser Attacks Series, I’ll be appearing with Troy Hunt for a discussion of identity attacks, attack trends, and well, pretty much anything Troy wants to talk about. You can register here and watch it live on April 30th at 11:00 AM EST!

If you missed the first episode of the series with Luke Jennings and John Hammond, you missed out on a great discussion and a live walkthrough of some really cool attack techniques. The good news is that you can watch the full recording here.

Subscribe now

🛡️Tactical Challenges

Microsoft On Making Opportunistic Cyberattacks Harder by Design

Ilya Grebnov, Microsoft’s Deputy CISO for Dynamics 365 and Power Platform, published this blog post on an argument I’ve made plenty of times in this newsletter (and daily in my day job): most attackers don’t break into your network, they log in with stolen credentials, and the most reliable fix isn’t better password hygiene; it’s removing credentials from the system entirely. The practical playbook he lays out centers on managed identities and federated token patterns that authenticate workloads just-in-time without a stored secret that can be compromised and reused. Worth a read, since this is basically Microsoft’s own internal security team describing how they protect 450+ services across one of the largest Azure footprints in existence.

The second half of the piece essentially describes platform engineering as a security control. Opportunistic attackers thrive on inconsistency, and the prescription described here is paved paths, policy-as-code, and enforced defaults that make the secure choice the easy choice. The Vercel breach covered later in this issue underlines this point: that attack succeeded because an over-permissioned OAuth token in a third-party app served as a bridge into Vercel’s environment. The Entra Agent ID note - treating AI agents as first-class identities with a named human sponsor - may be a small but telling signal of where identity governance is heading. Lots of great info here, though in my experience these best practices tend to break down and/or achieve less than full coverage in complex, heterogenous environments - leaving exactly the attack surface Grebnov describes here.

Insurance Providers Back Away From AI Coverage

Via CSO Online: Insurance carriers appear to be pulling back on coverage for AI-related outputs due to their unpredictability. Dozens of carriers are now declining to write policies for AI-generated output claims in cybersecurity and errors and omissions coverage, while others are hiking premiums to account for the increased risk. This kind of makes sense, since carriers can’t trace the reasoning behind an agentic decision and therefore can’t underwrite it. CSO’s article points out that in November 2025, AIG, Great American, and W.R. Berkley filed regulatory requests to exclude AI liabilities, but the trend has ramped up to include active policy exclusions.

If you’re a CISO, expect more pointed questions from your underwriters: What AI policies do you have? What models are you running? How are you validating outputs? Don’t assume your existing E&O or cyber policies cover your AI deployment, as AI exclusions often extend beyond the insured’s own AI use to any third-party AI systems incorporated into their workflows (read: SaaS capabilities or third-party apps in your SaaS).

🤖 Emerging Threats

Vercel Breached via Third-Party App

Via Matt Kapko at CyberScoop: The Vercel breach is a clean case study in how infostealers become the opening move in something much bigger. It started in February, when a Context.ai employee searched for Roblox game exploits and downloaded Lumma Stealer - a textbook infostealer deployment vector. From there, the stolen credentials gave the attacker access to Context.ai’s AWS environment and OAuth tokens, including one tied to a Vercel employee’s Google Workspace account.

Annnd that was it - that token granted full access. The employee had authorized the AI Office Suite app and given it broad permissions. The attacker then used that foothold to access Vercel environments and harvest environment variables, ultimately reaching customer credentials. ShinyHunters, or a group claiming the name to inflate notoriety, is attempting to sell the haul, which they claim includes access keys, source code, and databases.

So just to recap: this wasn’t a Vercel vulnerability, it wasn’t a phishing email sent to a Vercel employee, and it wasn’t a misconfigured Vercel system; this was an over-permissioned OAuth token granted to a third-party SaaS app that got popped at a completely different company. Vercel noted the Context.ai OAuth app was the subject of a broader compromise, potentially affecting hundreds of users across many organizations.

The infostealer-to-OAuth-to-lateral-movement chain is the kind of attack that generates no endpoint alert, leaves no malware signature in your environment, and bypasses MFA, because the attacker is using a legitimately issued token. Vercel’s CEO described the attackers as “highly sophisticated” and suspected the operation was “significantly accelerated by AI.” Whether that is born out by the evidence or not, the velocity and depth of the pivot across three separate organizations in a matter of weeks is the real headline.

👤 People and Processes

A Leadership Framework for Cutting Through Complexity

Tanveer Naseer’s Leadership Newsletter covers a common leadership challenge, which is that the more complicated things become, the more pressure there is on leaders to just “do something” that indicates progress - whether it’s the right thing(s) or not. Naseer describes a three-part simplification framework that requires answering three questions:

1. What should we stop doing?

2. What should we keep doing?

3. What should we be doing differently?

The first question gets to something we cover in LDR551 (referencing Cal Newport’s book Deep Work and John Doerr’s Measure What Matters): reducing shallow work - tasks that can be performed in a distracted state that add no enduring value. Things like sitting in on meetings, drive-by assignments, PowerPoint presentations, etc., may be necessary, but they’re mostly shallow work. If we can cut down on this stuff, we can focus instead on deep work - tasks which we might not be able to knock out immediately, but by completing them, everything gets better and easier. Another way of thinking about it, as described in Doerr’s book, is to separate tasks that are urgent from tasks that are strategically important. Reducing false positives and devising more effective threat mitigations would be two examples of deep work that are of high strategic importance (but probably low urgency, in that they aren’t immediate).

Maritime Transportation Security Act (MTSA) Takes Effect

Via Robert Lemos at DarkReading: The Coast Guard’s new maritime cybersecurity rules, first introduced in 2002 but expanded in 2025, are now in effect. The policy requires appointing dedicated cybersecurity officers, conducting formal assessments, and submitting cybersecurity plans for Coast Guard approval, while mandating that anyone with access to IT or OT systems complete cybersecurity training. Specifically, every US-flagged vessel, facility, or outer continental shelf (OCS) facility must designate a cybersecurity officer (CySO) to take responsibility for the cybersecurity of IT and OT infrastructure. The approach should look familiar to anyone who has formalized a cybersecurity function at the corporate level: formalize the roles, document the posture, and make training non-optional.

Given the focus on maritime security, this seems like timely guidance - the Strait of Hormuz has been effectively blocked since late February 2026 (wait, now it isn’t; no, yeah it is), with the IRGC asserting control over one of the world’s most critical maritime chokepoints. And since March, Iranian-affiliated actors have disrupted PLCs across U.S. critical infrastructure sectors, including water, energy, and government services. All of this to say that the maritime sector, now operating under elevated geopolitical stress and newly formalized cyber obligations, is exactly the kind of environment where governance frameworks go from a paperwork exercise to operational necessity.

💡Connecting the Dots

The Vercel breach is the clearest illustration of a pattern running through this entire issue - the entire attack lived in the SaaS and identity layer. Grebnov’s Microsoft post is essentially a structural prescription for this exact problem: eliminate secrets, shrink public surfaces, enforce identity-scoped access (easier said than done!). The big hairy problem here is that those controls tend to degrade at the edges of complex, heterogeneous environments, and most enterprises aren’t running a unified platform they control. They’re running dozens of SaaS apps, connected by OAuth tokens and API keys, that no one has fully inventoried. That gap is precisely where the Vercel-style attack finds its footing.

The insurance story closes the loop from the risk management side. Carriers can’t underwrite what they can’t trace, and the same opacity problem that makes AI outputs uninsurable applies to the SaaS identity layer: who authorized that token, what did it have access to, when did it expire? Most organizations can’t answer those questions with confidence. The maritime piece earns its place for similar reasons: the MTSA governance framework isn’t novel, but with Iranian-affiliated actors actively disrupting U.S. critical infrastructure OT systems and the Strait of Hormuz in active crisis, the distance between compliance-as-paperwork and compliance-as-operational-readiness has collapsed.

Subscribe now