Microsoft Under Attack: Zero-Days & Supply Chain Chaos

This week, we break down four cyber stories that all come back to one thing: trust.

Microsoft has patched 421 vulnerabilities, including a Windows kernel zero-day already exploited by North Korea’s Lazarus Group. Researchers have also found a new way to attack legacy Netlogon authentication, passkey security has come under scrutiny, and malicious LiteLLM releases have exposed just how dangerous software supply-chain compromises can become.

We go beyond the headlines to explain the technical concepts behind each attack, including use-after-free vulnerabilities, kernel privilege escalation, AES-CFB8 weaknesses, meet-in-the-middle attacks, WebAuthn and synced passkeys, CI/CD compromise, mutable Git tags, Python .pth persistence, and credential theft from cloud environments.

If you want to understand not just what happened, but how these attacks actually work and what defenders can learn from them, this episode is for you.

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

Welcome back to the podcast. This week we're looking at Microsoft patching hundreds of vulnerabilities in the latest August patch Tuesday. We're also looking at an Active Directory authentication flaw returning from the dead. We're also looking at researchers apparently stealing pass keys. And finally, a poisoned AI package spreading through the software supply chain. Let me jump into story number one. 421 Microsoft bugs in the latest Patch Tuesday. And there's been public attribution that Lazarus was already using one. So in the latest August Patch Tuesday, which has addressed 421 vulnerabilities, that in and of itself is historically very high. This just seems to be the new norm. The new norm lately. But the one that deserves attention is CVE 2026 68820. Because researchers say North Korea's Lazarus group has already been exploiting it as a zero game. Let's look at the technical details of what's going on here. The vulnerability sits in AFD.sys, the Windows ancillary function driver for WinSock. So if you've ever written network software on Windows, you've probably interacted with the WinSock. AFD.sys sits much lower down the stack inside the kernel, helping Windows manage socket operations. And this bug is a classic example of why concurrency and memory management are such dangerous neighbors. Checkpoint says multiple threads could cause two code paths inside afd.sys to manipulate the same socket related state without adequate synchronization. One path releases an object while another still assumes that object exists. That creates a well-known use after free vulnerability. So to sort of explain this, think of memory as a hotel room. One thread checks a guest out and tells the hotel room is available. Another employee still has paper saying the original guest occupies that room. The room gets reassigned, but the second employee continues operating on it as though nothing changed. So in software, attackers try to influence what gets placed into that newly freed memory. If they can successfully manipulate the corrupted object, they can sometimes turn a simple crash into arbitrary memory access. It looks here that according to Checkpoint, Lazarus turned this particular memory corruption into a kernel read and write primitive, and from there escalated privileges to system. And system isn't merely another administrator account. At that point, malware is operating at a privilege level where many endpoint security assumptions start breaking down. Lazarus used that access to deploy a new version of FUD module. It's kernel focused rootkit technology. Checkpoint research says FUD module can interfere with process thread registry and image notification callbacks, remove file system mini filters, interfere with ETW providers, and suppress other security telemetry. I think that's an important lesson. Privilege escalation isn't always the attacker's final objective. Sometimes system level access is simply the position they need to build the security tools that might detect everything that they do next. And I think this is something that the security industry is seeing more and more as APT attribution goes lower and lower down the stack. I think what's also interesting in this story is that the initial compromise was equally interesting. So what's happened here is that quote unquote Operation Dream Job used fake employment opportunities, uh impersonation websites, and even search engine optimization. Victims were directed towards a trojanized PDF viewer called Security PDF. This could be recognized attacker-crafted PDFs. Extract an embedded payload and execute the Trojan backdoor. So the attack chain goes from human trust to user space malware, to a Windows kernel zero day to system level privileges, and finally to security tool evasion. That is defense in depth dismantled one layer at a time. Let's quickly move on to story two. Zero logon is back. Sort of. Kind of maybe. So this story takes us directly into Active Directory. Researchers have introduced an exploit called OneLogin, or should I say reintroduce. And this attack is against Microsoft's net logon authentication protocol. And if you didn't know, what's interesting about this is that the underlying problem goes all the way back to an exploit called Zero Logon, CV 2020 4072. And for those playing at home, we'll know that that means that this Zero Day was first discovered six years ago in 2022. Not 2022, 2020, if you prefer proper English. So what's going on here? Netlogon helps establish secure channels between machines and domain controllers. A machine joined to Active Directory has a secret associated with its computer account. Netlogon uses cryptographic challenge response operations to prove that both sides possess the appropriate secret. The problem here is the way legacy NetLogon uses AES in CFB8 mode. So CFB stands for cipher feedback. Unlike simply encrypting independent blocks, feedback mode uses a previous cryptographic state when processing subsequent data. And here's what's really important to note. Critically, they depend on the initialization vector, or IV. An IV isn't supposed to provide secrecy by itself, right? But it prevents identical inputs under the same key from repeatedly producing predictable cryptographic behavior. Legacy NetLogon used AES CFB8 incorrectly, and this is the important part to note. Including a predictable all zero initialization state, Zero Logon exploited the consequences of that design. That's really important to note. So Microsoft patched Zero Logon in 2020 and later enforced NetLogon protections. But interestingly, the researchers behind this recent re-examination of one logon found that the underlying cryptographic design was never really eliminated. They've done some really interesting research here. They demonstrated two approaches. The first approach, one starts from compromised low privileged computer account and reduces the problem to roughly a 24-bit brute force search, achieving a t account takeover in about half an hour. The second approach was also very interesting. This second approach uses a meet in the middle attack style approach. Note that I'm not saying man in the middle. I think most security researchers are fill familiar with a man in the middle, but are familiar with meat in the middle. A meat in the middle style approach to compromise one logon uses this without requiring that initial account access, with the researchers reporting that it also takes about 30 minutes. If you didn't know, a meat in the middle attack is different from a normal man in the middle attack. Instead of intercepting network traffic, you're reducing cryptographic search complexity by computing possibilities from two directions and looking for a match and looking for a matching intermediate state. So the bigger lesson here is architectural. According to the researchers, genuinely correcting the AES CFBA problem would require a backwards compatible change to net logon. Microsoft instead relies on secure RPC protections to prevent exploitation. So the obvious takeaway here is that if your environment still enables a legacy vulnerable net logon secure channel behavior for old application devices, you've effectively preserved an old cryptographic weakness for compatibility. Let's quickly move on to story three. A wonderfully named pass taquet tax is being reported. You've seen the dramatic headlines claiming passkeys have been defeated, but I don't I don't think that's what we should be taking away here. There's some important context here. They haven't broken the mathematics behind pass keys. Thank goodness. They've attacked the implementation around them. So a traditional passkey is a shared secret, as you well know. A traditional password, as you know, is a shared secret. You know it, and the server receives some representation of it, right? Passwords. A passkey, however, uses asymmetric cryptography. Your device holds a private key. The service holds the corresponding public key. When you authenticate, the server sends a fresh challenge and your authenticator signs in. There is no reusable password for phishing sites to steal. But synced pass keys introduce another problem. So how do you securely move credentials between your devices? Unit forty-two examined Google Password Manager in Chrome on Windows systems with a TPM and demonstrated several attacks requiring malware to already be running on the victim's endpoint. In a basic pass to key attack, malware could use device identity material in Windows cryptographic APIs to make requests that appear to come from a trusted device. Then there's silver pass to key attack. Here's where things get interesting. Researchers found that they could manipulate device re-enrollment and register an attacker controlled user verification key. The cloud authenticator could then accept attacker generated signatures as though the victim had completed biometric or pin verification. But the most interesting is golden pasta key. So what's going on here? Google's synced pass keys are protected using a thirty-two byte master secret called the security domain secret or SDS. Researchers have discovered circumstances where that secret became temporarily accessible inside Chrome's process memory during enrollment. Malware capable of dumping the process at the right point could recover the SDS and use it to decrypt synced passkey material. So that does sound kind of catastrophic. But here's why, you know, reporting out there, including Rs Technica, Story calls this largely a quote unquote nothing burger. The attacker already needs malware executing on your machine. So for the most part, you probably don't need to stress. If an attacker has endpoint execution capable of reading browser state or process memory, they may already be able to steal session cookies, manipulate browser sessions, capture data, or perform other account takeover techniques. So you know still remains that pass keys remain substantially better than reusable passwords. I think a key takeaway here is that this research to me is has a more subtle point. Phishing resistance is not the same thing as endpoint compromise resistance, right? And relying on parties still need to correctly check web authentication properties such as user verified or UV flag, rather than assuming that because cryptographic signatures is valid, a human user must have approved it. Cryptographic cryptography can prove possession of a key, cannot automatically prove that the right human intended to use it. Let's quickly move on to our fourth and final story. A light LLM and the software supply chain cascading effect. We have one of the best examples this year of why software supply chain security is becoming infrastructure security. So what looks like is going on here is that malicious versions, in particular 1.82.7 and 1.82.8 of Lite LLM were published on PyPI in March. Lite LLM, if you didn't know, is especially valuable to attackers because it's commonly positioned between applications and multiple LLM providers. Meaning the environments running it can contain API keys, cloud credentials, and other sensitive infrastructure. But here's where things get really interesting. The interesting part is how the attackers apparently got there. Reporting is saying that the campaign had previously compromised Trivi, a popular security scanner. Attackers force pushed malicious commits across existing Trivia action version tags. And that's it's really important to note because that matters as a lot of organizations think pinning a GitHub action to something like a version tag gives them immutability. And as I'm reading this story, it's kind of giving me the sense, which is quite obvious to understand, but is a good reminder, a Git tag is a reference. If the repository owner or the attacker controlling the repository can move that tag to another commit, your pipeline can request the exact same version name tomorrow and execute completely different code. That's why obviously high assurance CI pipelines increasingly pin dependencies to immutable commit hashes or verified artifacts, rather than trusting floating tags alone. The important point here is the Poison Trivic component reportedly harvested credentials from CI environments. Stolen access then helped the campaign move into other projects, eventually resulting in malicious light LLM packages being published. And version 1.82.8 contained a particularly nasty Python trick, a .ph file. Python processes .ph files when initializing its site environments. So the malicious code didn't necessarily require an application developer to write, you know, quote unquote import light LLM, or pip install light LLM. Just starting Python alone could be enough to activate it. The payload search for SSH keys, AWS, Azure, and GPC credentials, Kubernetes tokens, so on and so forth. What's interesting though is it then used hybrid encryption. AES256 for the stolen data and RSA 4096 to protect that AES key before exfiltration. That's a standard hybrid cryptography. Symmetric encryption is fast for large quantities of data, while asymmetric encryption involves the key distribution problem. CloudSec now says evidence associated with the wider campaign potentially maps to more than 2,500 organizations. Although importantly, that's reconstructed exposure, not proof that every listed organization was successfully compromised. And that's a real supply chain lesson. Your security boundary doesn't end at your source codes. You must always be looking at your package registries, build runners, GitHub actions, container images, so on and so forth. That concludes my final story for today. Enjoy interacting with people in the comments. Please leave a comment, leave a like, and I'll see you next time.