Rogue AI Botnets and the Quantum Countdown

Microsoft has unleashed a record-breaking Patch Tuesday covering 622 vulnerabilities, a ransomware attack has disrupted production at a Coca-Cola dairy subsidiary, and a new botnet called NadMesh is targeting exposed AI platforms and automation tools.

In this episode, we break down the technical concepts behind each story, including vulnerability prioritisation, identity federation attacks, IT and operational technology dependencies, container escape techniques, insecure Model Context Protocol deployments, credential theft, persistence mechanisms and the growing harvest-now, decrypt-later threat.

We also examine new Australian Signals Directorate guidance on post-quantum cryptography and explain what organisations should be asking their vendors before the 2030 migration deadline.

This is a deep technical look at the hidden dependencies connecting patch management, ransomware resilience, AI infrastructure security and the coming cryptographic transition.

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:00

Welcome back to the podcast. This week, Microsoft has delivered a staggering Patch Tuesday covering hundreds of vulnerabilities. We'll dive into that in today's episode. We'll also look at a new botnet called NADMesh, which is systematically compromising exposed AI infrastructure. And finally, we'll look at the Australian Signals Directorate, which has released new questions that asks, are you ready for post-quantum cryptography? Let's jump into it. The first story, I think, is aptly called a Microsoft Patch Apocalypse. Microsoft's routine Patch Tuesday was a little different this time around because it addressed 622 vulnerabilities in Microsoft products. Patch Tuesday releases have been increasingly filled to the brim. I remember Patch Tuesday a couple weeks ago also full. Last Patch Tuesday, the largest on record. More than triple the previous record of 206. That figure does not include another 428 Chromium vulnerabilities affecting Microsoft Edge. Of Microsoft's vulnerabilities, 58 were classified as critical. Two were already being actively exploited, and one had been publicly disclosed. The raw number is extraordinary. However, it sort of got me thinking around how we go about framing vulnerabilities. Because vulnerability count alone is not a useful patching strategy. So, as my listeners probably already know, security teams need to distinguish between technical severity, exploitability, and businesses' exposure when it comes to vulnerability reporting, right? Such as from Microsoft's Patch Tuesday. So let's give a little bit of context to position ourselves here. CVSS primarily describes the potential technical impact of a vulnerability under particular conditions. It does not tell you how likely attackers are to exploit it against your organization. A medium-scoring vulnerability exposed to the internet and already being exploited may require faster action than a critical vulnerability buried inside an isolated lab system, right? So one actively exploited vulnerability, let's take for example CV 2026-56155 effects Active Directory Federation Services or ADFS. Microsoft attributed it to insufficient granular access control. An attacker already possessing local access could elevate privileges and potentially obtain admin controls. ADFS is especially sensitive because it acts as an identity federation layer. It translate authentication decisions into security tokens that applications trust, right? As Microsoft admins know. Compromising the federation service can therefore transform a local foothold into an identity attack instead of attacking every downstream application separately. The adversary attempts to compromise the system that tells those applications who is trusted. The second actively exploited vulnerability in Microsoft's latest round of Patz Tuesday, CV2026 56164. This affects SharePoint and involves missing authentication for critical functions. An attacker with network access could elevate their SharePoint permissions. Although its reportedly CVSS score was only 5.0, this active exploitation makes it rather urgent, I would say. So that 5.3 CVSS score can be somewhat misleading. This demonstrates an important theoretical distinction, which I think is worth noting. Severity is not the same as risk within your organization. Risk can be thought of as a combination of likelihood, impact, and exposure metrics. Once exploitation is observed in the wild, the likelihood component has been dramatically changed. The question is no longer whether someone could build an exploit. The question becomes whether your vulnerable asset can be reached before you patched it. Another interesting release from this latest round of Patch Tuesday was a copilot vulnerability, CV 2026-48561, reportedly involving improper input neutralization and RCE from a low-privileged Hyper-V guest. Another exchange vulnerability could permit JavaScript execution through a maliciously constructed email, while Microsoft Office received fixes for multiple memory safety issues, including heap buffer overflows and use after-free conditions. So let's just quickly backtrack on what we mean by use after free here. For any listeners that may not be aware, a use after-free occurs when software continues using a memory object after that object has already been released. If an attacker can influence what replaces the freed memory, they may redirect program execution. A heap buffer overflow works differently, the one we mentioned before. This is where the program writes beyond the allocated boundary of a heap object, potentially corrupting nearby control structures or pointers. I think the takeaway for defenders, the correct response is can't be, you know, patch everything immediately. At this scale, that may be impossible without causing outages. So I do think this the amount of patches coming out of just a single vendor is really making security teams rethink their patching strategy. You know, this could include prioritize noin known, if you prefer proper English, exploited vulnerabilities. Even if the CVSS is relatively minor on the scale. You need to be prioritizing internet-facing systems, identity infrastructure, and systems containing sensitive data. Right. You've heard that before, but hear that again. Researchers at a security company named XLab have documented a Go-based botnet called Nadmesh that combines scanning, exploitation, persistence, and credential theft into an autonomous attack platform. This one is kinda crazy. Let's jump into the technical details of it. NADMesh, it seems, deliberately searches for exposed AI and automation services, including Comfy UI, OLAMA, N8N, these increasingly more common AI-focused software systems. And it then uses Shodan generated intelligence to place discovered AI services into a high-priority scanning tool. Researchers identified more than 20 exploited vectors covering technologies, including MCP servers, Kubernetes, Docker, Redis, Elasticash, and Jenkins. I think this is quite interesting and fairly significant because AI systems are deployed like development tools, but connected like production systems. You know, a team may expose OLAMA, which is a system for hosting local models. A team might expose OLAMA on port uh 11434, Comfort UI on 8188, or N8N on 5678 for quid testing. Right? The application may have weak authentication because developers assume it to be obscure or temporary. But internet scanners do not care whether something was intended to be temporary. It's worth reminding ourselves of that. And NedMash reportedly scans common AI, container and infrastructure ports, fingerprints the service, attempts an appropriate exploitation technique, and reports successful findings back to its controller. Against an exposed Docker API, an attacker may create a privileged container, mount host directories, and escape the intended container boundary. Interestingly, against Kubernetes, the malware can attempt to create a pod with a host path volume, exposing files from the underlying node. Against an insecure Redis server, an attacker may change Redis configuration values and write attack-controlled content into a location used for persistence. Here's where things get even more technical. Once it's gotten to this stage, its highest priority vector reportedly targets MCP servers or model context protocols for those living under a rock through JSON RPC tools call, request invoking an execute underscore command capability. So did you just backtrack a little? MCP allows AI models or agents to call external tools using structured messaging. The model might query a database, read a file, execute to code or interact with a business system, right? And the reason I want to make that point is the security boundary is therefore not the language model itself. It is the collection of tools and credentials available to the model made available through the MCP service. All of a sudden your attack service is 10x. When an MCP server exposes a command execution tool without strong authentication and authorization, a remote attacker may not need to manipulate the model through prompt injection. They can attempt to call the dangerous tool directly. So they can get to you via the tool you're using indirectly. NedMash, it seems, also had some pretty strong durability features built in. Now this company that discovered this attack system XLab observed an SSH public key backdoor. Things are getting serious, folks. But so they observe this SSK SSH public key backdoor, malware stored in several temporary file systems, locations, and cron-based watchdog tasks capable of restoring removed components. It builds, use Go obfuscation, UPX packaging, and random padding so that individual samples receive different hashes, weakening basic signature-based detection. Most importantly, I think the botnet appears interested in what the compromised hosts can access. It can harvest AWS credentials from environment variables and configuration files, Kubernetes service account tokens, Docker credentials, AI model access, and details of callable MCP tools. A single compromised development server could therefore become an entry point into cloud accounts, container clusters, and internal data sources. Wow, that was a a lot to take in, folks, but I think the obvious lesson from this story is straightforward but important. Do not expose AI development interfaces directly to the internet. And I think that's becoming increasingly more difficult. AI infrastructure is still infrastructure. It requires the same identity, network, and logging controls as every other production platform. You need to be asking yourself, are you just saying yes to all AI infrastructure? Or do you need to be securing your AI infrastructure and workloads a little bit more? Let's quickly move on to the third and final story today. ASD's post-quantum questions for vendors. It looks like finally the Australian Signals Directorate has released guidance designed to help organizations assess whether their vendors are prepared for post-quantum cryptography. Future cryptographically relevant quantum computers could undermine commonly used asymmetric algorithms. A lot of people in the security industry know that this is coming, but haven't actually done much about it, right? The immediate concern is not that every encryption system will suddenly fail tomorrow, right? It is that the cryptographic migrations take years, while sensitive information captured today may remain valuable for decades. This creates the harvest now decrypt later threat model that security practic practitioners have probably heard about, where an adversary records encrypted traffic today, stores it, and attempts to decrypt it when more capable quantum systems become available. They're just saving everything for later. So ASD has recommended prioritizing information with long-lived confidentiality requirements. ASD has set out a set of vendor questions to follow the lattice phases. Lattice standing for locate cryptographic dependencies, assess risk, triage systems, implement new algorithms, and communicate and educate stakeholders. The first requirement is a cryptographic inventory, sometimes called a cryptographic bill of materials, right? You've heard of software bill of materials, same thing, but for crypto. It should identify your algorithms, protocols, library certificates, key sizes, and hardware dependencies across applications, OSs, firmware, and third-party components. Without that inventory, an organization cannot really know where or when it's RSA, Diffie-Hellman, or Elliptic Curve cryptography. You need to start documenting the type of cryptographic algorithms are in use for each application. NIST's principal standard include MLKEM for establishing shared secrets, MLDSA for digital signatures, and SLHDSA as a hash-based signature alternative. MLKEM is based on the difficulty of the module learning with errors problem rather than the integer factorization or discrete logarithm problems underlying much of the traditional public key infrastructure. But replacing an algorithm is not as simple as changing one configuration value. Post-quantum keys, signatures, and certificates may be substantially larger. This is something that organizations are going to need to more and more understand how they're going to deal with this. Now that these crypto algorithms and their corresponding key signatures and certs are much larger, that can affect network handshakes, certificate chains, hardware security modules, embedded devices, and protocols built around strict packet size assumptions. So it looks like ASD is therefore recommending that people should be asking vendors about production readiness, certificate and key management changes, firmware, upgradeability, and hardware replacement, and support arrangements and their ability to complete customer transitions before the end of 2030. ASD is sort of saying, if your vendor saying, you know, we're not really monitoring quantum developments, that's not good enough anymore. What ASD wants people in the security industry to say is you have answers to your identified affected products. You have made a stock take of the applications and their corresponding algorithms, cryptographic algorithms, and a set of time frames as to when you can make that transition. So that about wraps up today's podcast. Thank you very much for listening. Still a relatively new podcast. Please give a like, follow, comment. All that helps. See you next time.