How intelligence agencies defend against agentic AI

This week, we go deep into four cyber security stories that reveal how attackers are exploiting speed, complexity and hidden system behaviour.

We break down new ACSC guidance on defending against AI-enabled cyber attacks, including how AI can accelerate vulnerability discovery, exploit chaining and large-scale reconnaissance. Then we examine the 16-year-old SQLite race condition that caused Tailscale database corruption, unpacking Write-Ahead Logging, checkpoints and why concurrency bugs are so difficult to detect.

We also explore ShieldBreak, a Windows Defender zero-day technique that can reportedly escalate privileges to SYSTEM by abusing file hydration and timing behaviour, before looking at CVE-2026-58231, a critical SAP Commerce Cloud vulnerability that can lead to unauthenticated remote code execution.

Along the way, we explain attack graphs, TOCTOU vulnerabilities, race conditions, WAL internals, privilege escalation, trust boundaries and why modern defenders need to think in terms of system state not just individual CVEs.

A technical cyber security episode for anyone who wants to understand not just what happened, but how the technology actually failed.

Thanks for listening.

Follow the podcast for more cyber security news, malware analysis, threat intelligence, AI security, and real-world attacker tradecraft.

For contact or story tips, email: cyberinvestigationsau@gmail.com

Disclaimer: This podcast is for education and awareness only. Technical details are shared to help defenders improve detection, response, and security controls.

Transcript

SPEAKER_00 0:09

Welcome back to the podcast. This week, ASD is warning that AI can compress the time between vulnerability discovery and exploitation. We're also going to be looking at Tailscale, which has spent six months hunting a race condition buried in SQLite for 16 years. We're also looking at the recent saga between Microsoft and Nightmare Eclipse. And finally, SAP has patched a maximum severity Commerce Cloud Vulnerability that attackers reportedly began probing within days. Let's jump into story number one. The Australian Signals Directorate's Australian Cyber Security Centre has released guidance for government critical infrastructure and large enterprises on AI-enabled attacks, and it has published a write-up as to how in which it believes large organizations should be defending against agentic AI-based attacks. They've stressed how the important point is that AI does not need to invent a science fiction cyberweapon. And that its immediate advantage is reducing the cost of existing offensive work, right? So if we think about vulnerability discovery as a search problem, an attacker has an enormous state space, right? Internet-facing hosts, software versions, API endpoints, source code, so on and so forth. Traditionally, humans narrow that search. AI can simultaneously paralyze parts of the process, right? So we can classify exposed services, reason about version-specific behavior, generate candidate test cases, inspect errors, mutate payloads, and feed results into the next round. The SESC write up warns that malicious actors may use AI discovered vulnerabilities, develop an exploit within hours, and target many victims simultaneously. And chain several lower severity weaknesses into a high severity outcome. So the write-up recommends daily identification of internet facing services. That is number one, rapid remediation of even lower severity vulnerabilities, segmentation, least privilege, and centralized log analysis with carefully scoped automated responses. What's very important, I think, here in the ACSE's write-up is the vulnerability chaining. This is now in the spotlight. Security teams often treat CVs independently. Vulnerability A is medium, vulnerability B is high, vulnerability C is low. Attackers care about paths, not isolation scores anymore, right? So imagine an attack graph. One node is internet access, another a service account, and another, a database admin. Individual flaws are edges. A medium authentication bypass plus a low information leak plus an overprivileged service account might create all the way to the database. AI makes searching those paths cheaper. The defensive response is to remove those useful edges, reduce internet exposure, automated patches, so your patches, your medium time to patch is significantly faster as segment systems and minimize privileges and analyze logs quickly. Let's quickly move on to story two. Now to tail scale, where the lesson is almost the opposite of the first story. This was a microscopic concurrency bug hiding in one of the world's most widely deployed databases. So let's sort of jump into the technical details as what's going on here. If you didn't know, SQLite supports writer headlogging, or WAL. Instead of immediately overriding pages in the main database file, a writer appends updated pages to a WAL file. Readers can keep using a consistent view while the writer works. So SQLite maintains a shared memory metadata called a WAL index, so readers can basically efficiently locate the newest page. Interestingly, eventually those pages must be copied back into the database. This is a checkpoint. The nasty part was a race during a WAL reset. So it looks like according to SQLite's technical write-up, the bug affecting UAL mode databases with at least two connections. One checkpoint completes, leaving the WAL eligible to reset, a second checkpoint begins. At almost the same time, another connection commits a transaction, resets the WAL, and starts writing new content at its beginning. Because of a race, the second checkpoint can miss that reset. So that's important technical detail here. It leaves the WAL index saying some pages have already been checkpointed when they have not. A later checkpoint skips them. So this transaction was committed and other structures may already reference those pages, but the pages never reach the main database. And this is the kicker. That creates corruption from inconsistent metadata about state. SQLite says the bug likely existed from version 3.7 in 2010 through to 3.51.2 and was fixed in 3.51.3 with backports for some older branches. Tailscale hit this because its control plane manually controlled checking point for frequent consistent backups. Across six months, it recorded 19 corruption incidents. This is a great investigation on their behalf. I think a takeaway for me is that TailScale logged every database changing SQL transaction so it could replay them against a clean backup, then found something that should have been impossible. A committed transaction could disappear from later state. I think this is great work by Tailscale and their researchers, and uh I think uh uh a lot of prop props should be given to that team. Let's quickly move on to story three. Now, if you haven't been keeping up with what is turning into a bit of a TV series, it's the ongoing saga between Nightmare Eclipse, who is an anonymous security researcher, or a group of security researchers, or something entirely different we don't actually know, and they're feud with Microsoft. If you didn't know, Nightmare Eclipse keeps dropping exploits one after another. And late last week, they went and did it again. This one has been reported as quote unquote Shield Break, a now released uh Windows Defender exploit. And it looks like it is a bypass of Microsoft's fix for CV 2026 5065, which was a patch to a previous exploit called Rogue Planet. And this new drop claims that the proof of concept works on Windows 11 25H2, including Canary Builds and Windows Server 2025. Now Microsoft has told public reporting outlets that it's still investigating this exploit drop. There's some interesting technical details that have been released by Nightmare Eclipse here. So let's look at what's actually happening here. This new exploit is a local privilege escalation, so an attacker already needs code execution as a lower privileged user. The goal is quote unquote anti-authority system, the security context used by many Windows services and one with extremely broad privileges. Sort of the irony of this is that the fascinating part is the apparent attack surface is, you guessed it, Windows Defender itself. Reporting by the register says Shieldbreak uses a user mode callback to change file contents while Defender performs a cloud file hydration scan through Windows Cloud Filter API. The Cloud Filter API lets Cloud Sync providers represent remote files as local placeholders. So when software reads a file that is not fully downloaded, Windows can trigger a fetch data callback, and the sync provider hydrates the placeholder. Microsoft documents transfer data as the operation used to perform that hydration. So I know we're getting into some technical details here, but bear with me. This is the good stuff. So now think about the security issue abstractly, right? A privileged service inspects attacker-influenced file state. If the attacker can change the state between what defender believes it is scanning and what defender later acts upon, you get a what's known as a time of check versus time of use style problem. This is a recurring operating system pattern. Some concluding thoughts on the whole Microsoft Nightmare Eclipse saga. Many people have been advocating for Nightmare Eclipse, in that the story goes that Nightmare Eclipse reported a vulnerability via approved avenues, but Microsoft didn't pay the bounty for it. But then other people say that the amount of exploits that this quote-unquote nightmare eclipse person has is one, fairly sophisticated, and two, this person or group seems to have a lot of them. Which might suggest that this isn't one person, this isn't a group, and their capability to have these highly advanced exploits is suggesting that it's larger than a group. No, I have no idea, but we'll see where this story pans out. I'll be sure to cover the whole thing, cause while it is definitely entertaining. Let's quickly move on to the fourth and final story of today. In SAP's August SAP that is, August security release, it included CV 2026-58231 in the SAP Commerce Cloud Data Hub Adapter. SAP rated it with a critical CVS score of 10 out of 10 and lists ComCloud 2211 and 2211 JDK21 as affected. If you're a SAP administrator, you may know what I'm referring to there. The CVE record says an unauthenticated attacker can abuse a default authentication client and send specifically crafted input to functions lacking sufficient validation, potentially producing arbitrary code execution and compromise of internal components. The published vector describes a network reachable, low complexity attack requiring no privileges and no user interaction. There are three security concepts hidden in that sentence, if you didn't pick it up, right? So authentication, the who you are, authorization, are you allowed to do this, and input validation. Is the data you supplied safe for the code path consuming it? So if we look at sort of the technical details here, what's really happening that if a default client gets an attacker through the first doorway, weak authorization lets them reach functionality they should not control. That's what's sort of happening here in the SAP exploit. And then finally, poor validation allows the attackers to reach a code generation or execution sync. The result can be RCE. That is a chain of trust boundary failures, not simply quote unquote bad input. A write-up on Hacker News reported that HoneyPots began seeing the exploitation attempts three days after SAP released the patch. Importantly, the same report said there was no public proof of concept and did not establish who was behind the attempts. So attempted exploitation should not automatically translate into confirmed successful compromise. That wraps up the stories for today. I'm looking forward to a new week in cybersecurity. We'll see what we get. As always, thank you very much for listening. Drop a like, drop a comment. See you next time.