WEBVTT
00:00:01.120 --> 00:00:02.560
Welcome back to the podcast.
00:00:03.600 --> 00:00:10.640
This week we're looking at Microsoft patching hundreds of vulnerabilities in the latest August patch Tuesday.
00:00:10.880 --> 00:00:17.679
We're also looking at an Active Directory authentication flaw returning from the dead.
00:00:18.399 --> 00:00:22.559
We're also looking at researchers apparently stealing pass keys.
00:00:22.879 --> 00:00:29.519
And finally, a poisoned AI package spreading through the software supply chain.
00:00:34.000 --> 00:00:36.079
Let me jump into story number one.
00:00:37.119 --> 00:00:43.520
421 Microsoft bugs in the latest Patch Tuesday.
00:00:43.840 --> 00:00:49.039
And there's been public attribution that Lazarus was already using one.
00:00:50.640 --> 00:00:59.679
So in the latest August Patch Tuesday, which has addressed 421 vulnerabilities, that in and of itself is historically very high.
00:01:00.000 --> 00:01:02.079
This just seems to be the new norm.
00:01:02.799 --> 00:01:04.400
The new norm lately.
00:01:05.280 --> 00:01:11.120
But the one that deserves attention is CVE 2026 68820.
00:01:11.920 --> 00:01:19.680
Because researchers say North Korea's Lazarus group has already been exploiting it as a zero game.
00:01:21.359 --> 00:01:24.640
Let's look at the technical details of what's going on here.
00:01:24.959 --> 00:01:33.840
The vulnerability sits in AFD.sys, the Windows ancillary function driver for WinSock.
00:01:34.640 --> 00:01:40.079
So if you've ever written network software on Windows, you've probably interacted with the WinSock.
00:01:40.719 --> 00:01:50.239
AFD.sys sits much lower down the stack inside the kernel, helping Windows manage socket operations.
00:01:51.359 --> 00:01:59.359
And this bug is a classic example of why concurrency and memory management are such dangerous neighbors.
00:02:00.239 --> 00:02:12.560
Checkpoint says multiple threads could cause two code paths inside afd.sys to manipulate the same socket related state without adequate synchronization.
00:02:13.120 --> 00:02:19.199
One path releases an object while another still assumes that object exists.
00:02:20.639 --> 00:02:25.919
That creates a well-known use after free vulnerability.
00:02:26.960 --> 00:02:32.159
So to sort of explain this, think of memory as a hotel room.
00:02:32.479 --> 00:02:37.199
One thread checks a guest out and tells the hotel room is available.
00:02:37.439 --> 00:02:43.120
Another employee still has paper saying the original guest occupies that room.
00:02:43.360 --> 00:02:49.599
The room gets reassigned, but the second employee continues operating on it as though nothing changed.
00:02:50.719 --> 00:02:58.159
So in software, attackers try to influence what gets placed into that newly freed memory.
00:02:58.400 --> 00:03:07.039
If they can successfully manipulate the corrupted object, they can sometimes turn a simple crash into arbitrary memory access.
00:03:08.319 --> 00:03:21.439
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.
00:03:22.400 --> 00:03:27.039
And system isn't merely another administrator account.
00:03:28.719 --> 00:03:37.120
At that point, malware is operating at a privilege level where many endpoint security assumptions start breaking down.
00:03:38.400 --> 00:03:44.080
Lazarus used that access to deploy a new version of FUD module.
00:03:45.039 --> 00:03:48.400
It's kernel focused rootkit technology.
00:03:49.199 --> 00:04:06.080
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.
00:04:07.680 --> 00:04:09.680
I think that's an important lesson.
00:04:10.960 --> 00:04:14.400
Privilege escalation isn't always the attacker's final objective.
00:04:15.360 --> 00:04:27.040
Sometimes system level access is simply the position they need to build the security tools that might detect everything that they do next.
00:04:28.319 --> 00:04:38.720
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.
00:04:40.879 --> 00:04:46.959
I think what's also interesting in this story is that the initial compromise was equally interesting.
00:04:48.560 --> 00:05:02.800
So what's happened here is that quote unquote Operation Dream Job used fake employment opportunities, uh impersonation websites, and even search engine optimization.
00:05:03.439 --> 00:05:09.040
Victims were directed towards a trojanized PDF viewer called Security PDF.
00:05:10.240 --> 00:05:15.519
This could be recognized attacker-crafted PDFs.
00:05:15.920 --> 00:05:20.879
Extract an embedded payload and execute the Trojan backdoor.
00:05:21.519 --> 00:05:33.680
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.
00:05:33.839 --> 00:05:38.319
That is defense in depth dismantled one layer at a time.
00:05:41.600 --> 00:05:43.759
Let's quickly move on to story two.
00:05:44.560 --> 00:05:46.879
Zero logon is back.
00:05:47.439 --> 00:05:48.079
Sort of.
00:05:48.240 --> 00:05:49.519
Kind of maybe.
00:05:50.720 --> 00:05:56.399
So this story takes us directly into Active Directory.
00:05:56.720 --> 00:06:04.160
Researchers have introduced an exploit called OneLogin, or should I say reintroduce.
00:06:04.800 --> 00:06:09.360
And this attack is against Microsoft's net logon authentication protocol.
00:06:09.600 --> 00:06:20.639
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.
00:06:21.759 --> 00:06:29.120
And for those playing at home, we'll know that that means that this Zero Day was first discovered six years ago in 2022.
00:06:30.000 --> 00:06:33.920
Not 2022, 2020, if you prefer proper English.
00:06:34.160 --> 00:06:35.279
So what's going on here?
00:06:35.600 --> 00:06:42.560
Netlogon helps establish secure channels between machines and domain controllers.
00:06:42.959 --> 00:06:49.600
A machine joined to Active Directory has a secret associated with its computer account.
00:06:50.399 --> 00:07:00.639
Netlogon uses cryptographic challenge response operations to prove that both sides possess the appropriate secret.
00:07:00.959 --> 00:07:08.800
The problem here is the way legacy NetLogon uses AES in CFB8 mode.
00:07:10.240 --> 00:07:15.120
So CFB stands for cipher feedback.
00:07:16.079 --> 00:07:27.839
Unlike simply encrypting independent blocks, feedback mode uses a previous cryptographic state when processing subsequent data.
00:07:28.879 --> 00:07:31.040
And here's what's really important to note.
00:07:31.279 --> 00:07:37.360
Critically, they depend on the initialization vector, or IV.
00:07:37.839 --> 00:07:41.759
An IV isn't supposed to provide secrecy by itself, right?
00:07:41.920 --> 00:07:49.279
But it prevents identical inputs under the same key from repeatedly producing predictable cryptographic behavior.
00:07:50.560 --> 00:07:58.240
Legacy NetLogon used AES CFB8 incorrectly, and this is the important part to note.
00:07:59.600 --> 00:08:08.720
Including a predictable all zero initialization state, Zero Logon exploited the consequences of that design.
00:08:08.959 --> 00:08:10.720
That's really important to note.
00:08:11.279 --> 00:08:18.720
So Microsoft patched Zero Logon in 2020 and later enforced NetLogon protections.
00:08:19.920 --> 00:08:31.759
But interestingly, the researchers behind this recent re-examination of one logon found that the underlying cryptographic design was never really eliminated.
00:08:33.200 --> 00:08:35.679
They've done some really interesting research here.
00:08:36.000 --> 00:08:38.399
They demonstrated two approaches.
00:08:39.679 --> 00:08:55.279
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.
00:08:56.320 --> 00:09:01.919
The second approach was also very interesting.
00:09:02.240 --> 00:09:07.840
This second approach uses a meet in the middle attack style approach.
00:09:08.080 --> 00:09:10.559
Note that I'm not saying man in the middle.
00:09:10.720 --> 00:09:17.840
I think most security researchers are fill familiar with a man in the middle, but are familiar with meat in the middle.
00:09:18.159 --> 00:09:33.200
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.
00:09:33.840 --> 00:09:40.320
If you didn't know, a meat in the middle attack is different from a normal man in the middle attack.
00:09:41.200 --> 00:09:58.960
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.
00:10:00.960 --> 00:10:03.200
So the bigger lesson here is architectural.
00:10:03.360 --> 00:10:12.960
According to the researchers, genuinely correcting the AES CFBA problem would require a backwards compatible change to net logon.
00:10:13.519 --> 00:10:20.080
Microsoft instead relies on secure RPC protections to prevent exploitation.
00:10:22.080 --> 00:10:36.960
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.
00:10:38.159 --> 00:10:40.639
Let's quickly move on to story three.
00:10:41.759 --> 00:10:48.240
A wonderfully named pass taquet tax is being reported.
00:10:49.440 --> 00:10:59.759
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.
00:11:06.480 --> 00:11:08.799
There's some important context here.
00:11:10.000 --> 00:11:13.120
They haven't broken the mathematics behind pass keys.
00:11:13.360 --> 00:11:14.159
Thank goodness.
00:11:14.320 --> 00:11:17.279
They've attacked the implementation around them.
00:11:17.440 --> 00:11:22.000
So a traditional passkey is a shared secret, as you well know.
00:11:24.399 --> 00:11:27.919
A traditional password, as you know, is a shared secret.
00:11:28.159 --> 00:11:33.679
You know it, and the server receives some representation of it, right?
00:11:34.159 --> 00:11:34.720
Passwords.
00:11:34.879 --> 00:11:38.559
A passkey, however, uses asymmetric cryptography.
00:11:38.879 --> 00:11:41.519
Your device holds a private key.
00:11:42.320 --> 00:11:46.000
The service holds the corresponding public key.
00:11:46.240 --> 00:11:52.399
When you authenticate, the server sends a fresh challenge and your authenticator signs in.
00:11:53.200 --> 00:11:57.600
There is no reusable password for phishing sites to steal.
00:11:58.480 --> 00:12:04.000
But synced pass keys introduce another problem.
00:12:04.960 --> 00:12:08.879
So how do you securely move credentials between your devices?
00:12:10.639 --> 00:12:26.559
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.
00:12:27.840 --> 00:12:40.799
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.
00:12:42.000 --> 00:12:46.399
Then there's silver pass to key attack.
00:12:46.960 --> 00:12:49.039
Here's where things get interesting.
00:12:49.440 --> 00:13:00.080
Researchers found that they could manipulate device re-enrollment and register an attacker controlled user verification key.
00:13:00.960 --> 00:13:10.240
The cloud authenticator could then accept attacker generated signatures as though the victim had completed biometric or pin verification.
00:13:11.039 --> 00:13:16.080
But the most interesting is golden pasta key.
00:13:18.879 --> 00:13:20.320
So what's going on here?
00:13:21.279 --> 00:13:33.519
Google's synced pass keys are protected using a thirty-two byte master secret called the security domain secret or SDS.
00:13:34.559 --> 00:13:44.960
Researchers have discovered circumstances where that secret became temporarily accessible inside Chrome's process memory during enrollment.
00:13:47.039 --> 00:13:57.200
Malware capable of dumping the process at the right point could recover the SDS and use it to decrypt synced passkey material.
00:13:58.159 --> 00:14:01.200
So that does sound kind of catastrophic.
00:14:02.159 --> 00:14:10.480
But here's why, you know, reporting out there, including Rs Technica, Story calls this largely a quote unquote nothing burger.
00:14:11.440 --> 00:14:15.519
The attacker already needs malware executing on your machine.
00:14:15.840 --> 00:14:19.679
So for the most part, you probably don't need to stress.
00:14:20.399 --> 00:14:36.480
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.
00:14:37.919 --> 00:14:46.159
So you know still remains that pass keys remain substantially better than reusable passwords.
00:14:47.919 --> 00:14:56.879
I think a key takeaway here is that this research to me is has a more subtle point.
00:14:57.919 --> 00:15:03.519
Phishing resistance is not the same thing as endpoint compromise resistance, right?
00:15:04.559 --> 00:15:26.159
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.
00:15:26.720 --> 00:15:34.879
Cryptographic cryptography can prove possession of a key, cannot automatically prove that the right human intended to use it.
00:15:37.360 --> 00:15:40.879
Let's quickly move on to our fourth and final story.
00:15:41.360 --> 00:15:47.759
A light LLM and the software supply chain cascading effect.
00:15:48.879 --> 00:15:56.799
We have one of the best examples this year of why software supply chain security is becoming infrastructure security.
00:15:58.399 --> 00:16:16.399
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.
00:16:17.759 --> 00:16:27.440
Lite LLM, if you didn't know, is especially valuable to attackers because it's commonly positioned between applications and multiple LLM providers.
00:16:28.240 --> 00:16:35.120
Meaning the environments running it can contain API keys, cloud credentials, and other sensitive infrastructure.
00:16:36.320 --> 00:16:38.799
But here's where things get really interesting.
00:16:40.960 --> 00:16:45.360
The interesting part is how the attackers apparently got there.
00:16:46.720 --> 00:16:53.679
Reporting is saying that the campaign had previously compromised Trivi, a popular security scanner.
00:16:54.000 --> 00:17:01.519
Attackers force pushed malicious commits across existing Trivia action version tags.
00:17:02.639 --> 00:17:14.640
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.
00:17:14.799 --> 00:17:29.200
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.
00:17:30.079 --> 00:17:45.119
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.
00:17:46.079 --> 00:17:58.079
That's why obviously high assurance CI pipelines increasingly pin dependencies to immutable commit hashes or verified artifacts, rather than trusting floating tags alone.
00:17:58.400 --> 00:18:05.839
The important point here is the Poison Trivic component reportedly harvested credentials from CI environments.
00:18:06.160 --> 00:18:16.079
Stolen access then helped the campaign move into other projects, eventually resulting in malicious light LLM packages being published.
00:18:16.400 --> 00:18:25.039
And version 1.82.8 contained a particularly nasty Python trick, a.ph file.
00:18:26.000 --> 00:18:32.720
Python processes.ph files when initializing its site environments.
00:18:33.119 --> 00:18:43.359
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.
00:18:43.519 --> 00:18:48.319
Just starting Python alone could be enough to activate it.
00:18:49.200 --> 00:18:57.440
The payload search for SSH keys, AWS, Azure, and GPC credentials, Kubernetes tokens, so on and so forth.
00:18:58.799 --> 00:19:02.720
What's interesting though is it then used hybrid encryption.
00:19:02.960 --> 00:19:12.160
AES256 for the stolen data and RSA 4096 to protect that AES key before exfiltration.
00:19:13.680 --> 00:19:17.759
That's a standard hybrid cryptography.
00:19:18.079 --> 00:19:25.440
Symmetric encryption is fast for large quantities of data, while asymmetric encryption involves the key distribution problem.
00:19:25.680 --> 00:19:34.400
CloudSec now says evidence associated with the wider campaign potentially maps to more than 2,500 organizations.
00:19:34.720 --> 00:19:43.119
Although importantly, that's reconstructed exposure, not proof that every listed organization was successfully compromised.
00:19:43.279 --> 00:19:45.440
And that's a real supply chain lesson.
00:19:46.079 --> 00:19:48.880
Your security boundary doesn't end at your source codes.
00:19:49.039 --> 00:19:56.720
You must always be looking at your package registries, build runners, GitHub actions, container images, so on and so forth.
00:19:58.000 --> 00:20:01.359
That concludes my final story for today.
00:20:13.440 --> 00:20:15.359
Enjoy interacting with people in the comments.
00:20:15.519 --> 00:20:20.880
Please leave a comment, leave a like, and I'll see you next time.
00:00:01.120 --> 00:00:02.560
Welcome back to the podcast.
00:00:03.600 --> 00:00:10.640
This week we're looking at Microsoft patching hundreds of vulnerabilities in the latest August patch Tuesday.
00:00:10.880 --> 00:00:17.679
We're also looking at an Active Directory authentication flaw returning from the dead.
00:00:18.399 --> 00:00:22.559
We're also looking at researchers apparently stealing pass keys.
00:00:22.879 --> 00:00:29.519
And finally, a poisoned AI package spreading through the software supply chain.
00:00:34.000 --> 00:00:36.079
Let me jump into story number one.
00:00:37.119 --> 00:00:43.520
421 Microsoft bugs in the latest Patch Tuesday.
00:00:43.840 --> 00:00:49.039
And there's been public attribution that Lazarus was already using one.
00:00:50.640 --> 00:00:59.679
So in the latest August Patch Tuesday, which has addressed 421 vulnerabilities, that in and of itself is historically very high.
00:01:00.000 --> 00:01:02.079
This just seems to be the new norm.
00:01:02.799 --> 00:01:04.400
The new norm lately.
00:01:05.280 --> 00:01:11.120
But the one that deserves attention is CVE 2026 68820.
00:01:11.920 --> 00:01:19.680
Because researchers say North Korea's Lazarus group has already been exploiting it as a zero game.
00:01:21.359 --> 00:01:24.640
Let's look at the technical details of what's going on here.
00:01:24.959 --> 00:01:33.840
The vulnerability sits in AFD.sys, the Windows ancillary function driver for WinSock.
00:01:34.640 --> 00:01:40.079
So if you've ever written network software on Windows, you've probably interacted with the WinSock.
00:01:40.719 --> 00:01:50.239
AFD.sys sits much lower down the stack inside the kernel, helping Windows manage socket operations.
00:01:51.359 --> 00:01:59.359
And this bug is a classic example of why concurrency and memory management are such dangerous neighbors.
00:02:00.239 --> 00:02:12.560
Checkpoint says multiple threads could cause two code paths inside afd.sys to manipulate the same socket related state without adequate synchronization.
00:02:13.120 --> 00:02:19.199
One path releases an object while another still assumes that object exists.
00:02:20.639 --> 00:02:25.919
That creates a well-known use after free vulnerability.
00:02:26.960 --> 00:02:32.159
So to sort of explain this, think of memory as a hotel room.
00:02:32.479 --> 00:02:37.199
One thread checks a guest out and tells the hotel room is available.
00:02:37.439 --> 00:02:43.120
Another employee still has paper saying the original guest occupies that room.
00:02:43.360 --> 00:02:49.599
The room gets reassigned, but the second employee continues operating on it as though nothing changed.
00:02:50.719 --> 00:02:58.159
So in software, attackers try to influence what gets placed into that newly freed memory.
00:02:58.400 --> 00:03:07.039
If they can successfully manipulate the corrupted object, they can sometimes turn a simple crash into arbitrary memory access.
00:03:08.319 --> 00:03:21.439
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.
00:03:22.400 --> 00:03:27.039
And system isn't merely another administrator account.
00:03:28.719 --> 00:03:37.120
At that point, malware is operating at a privilege level where many endpoint security assumptions start breaking down.
00:03:38.400 --> 00:03:44.080
Lazarus used that access to deploy a new version of FUD module.
00:03:45.039 --> 00:03:48.400
It's kernel focused rootkit technology.
00:03:49.199 --> 00:04:06.080
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.
00:04:07.680 --> 00:04:09.680
I think that's an important lesson.
00:04:10.960 --> 00:04:14.400
Privilege escalation isn't always the attacker's final objective.
00:04:15.360 --> 00:04:27.040
Sometimes system level access is simply the position they need to build the security tools that might detect everything that they do next.
00:04:28.319 --> 00:04:38.720
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.
00:04:40.879 --> 00:04:46.959
I think what's also interesting in this story is that the initial compromise was equally interesting.
00:04:48.560 --> 00:05:02.800
So what's happened here is that quote unquote Operation Dream Job used fake employment opportunities, uh impersonation websites, and even search engine optimization.
00:05:03.439 --> 00:05:09.040
Victims were directed towards a trojanized PDF viewer called Security PDF.
00:05:10.240 --> 00:05:15.519
This could be recognized attacker-crafted PDFs.
00:05:15.920 --> 00:05:20.879
Extract an embedded payload and execute the Trojan backdoor.
00:05:21.519 --> 00:05:33.680
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.
00:05:33.839 --> 00:05:38.319
That is defense in depth dismantled one layer at a time.
00:05:41.600 --> 00:05:43.759
Let's quickly move on to story two.
00:05:44.560 --> 00:05:46.879
Zero logon is back.
00:05:47.439 --> 00:05:48.079
Sort of.
00:05:48.240 --> 00:05:49.519
Kind of maybe.
00:05:50.720 --> 00:05:56.399
So this story takes us directly into Active Directory.
00:05:56.720 --> 00:06:04.160
Researchers have introduced an exploit called OneLogin, or should I say reintroduce.
00:06:04.800 --> 00:06:09.360
And this attack is against Microsoft's net logon authentication protocol.
00:06:09.600 --> 00:06:20.639
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.
00:06:21.759 --> 00:06:29.120
And for those playing at home, we'll know that that means that this Zero Day was first discovered six years ago in 2022.
00:06:30.000 --> 00:06:33.920
Not 2022, 2020, if you prefer proper English.
00:06:34.160 --> 00:06:35.279
So what's going on here?
00:06:35.600 --> 00:06:42.560
Netlogon helps establish secure channels between machines and domain controllers.
00:06:42.959 --> 00:06:49.600
A machine joined to Active Directory has a secret associated with its computer account.
00:06:50.399 --> 00:07:00.639
Netlogon uses cryptographic challenge response operations to prove that both sides possess the appropriate secret.
00:07:00.959 --> 00:07:08.800
The problem here is the way legacy NetLogon uses AES in CFB8 mode.
00:07:10.240 --> 00:07:15.120
So CFB stands for cipher feedback.
00:07:16.079 --> 00:07:27.839
Unlike simply encrypting independent blocks, feedback mode uses a previous cryptographic state when processing subsequent data.
00:07:28.879 --> 00:07:31.040
And here's what's really important to note.
00:07:31.279 --> 00:07:37.360
Critically, they depend on the initialization vector, or IV.
00:07:37.839 --> 00:07:41.759
An IV isn't supposed to provide secrecy by itself, right?
00:07:41.920 --> 00:07:49.279
But it prevents identical inputs under the same key from repeatedly producing predictable cryptographic behavior.
00:07:50.560 --> 00:07:58.240
Legacy NetLogon used AES CFB8 incorrectly, and this is the important part to note.
00:07:59.600 --> 00:08:08.720
Including a predictable all zero initialization state, Zero Logon exploited the consequences of that design.
00:08:08.959 --> 00:08:10.720
That's really important to note.
00:08:11.279 --> 00:08:18.720
So Microsoft patched Zero Logon in 2020 and later enforced NetLogon protections.
00:08:19.920 --> 00:08:31.759
But interestingly, the researchers behind this recent re-examination of one logon found that the underlying cryptographic design was never really eliminated.
00:08:33.200 --> 00:08:35.679
They've done some really interesting research here.
00:08:36.000 --> 00:08:38.399
They demonstrated two approaches.
00:08:39.679 --> 00:08:55.279
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.
00:08:56.320 --> 00:09:01.919
The second approach was also very interesting.
00:09:02.240 --> 00:09:07.840
This second approach uses a meet in the middle attack style approach.
00:09:08.080 --> 00:09:10.559
Note that I'm not saying man in the middle.
00:09:10.720 --> 00:09:17.840
I think most security researchers are fill familiar with a man in the middle, but are familiar with meat in the middle.
00:09:18.159 --> 00:09:33.200
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.
00:09:33.840 --> 00:09:40.320
If you didn't know, a meat in the middle attack is different from a normal man in the middle attack.
00:09:41.200 --> 00:09:58.960
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.
00:10:00.960 --> 00:10:03.200
So the bigger lesson here is architectural.
00:10:03.360 --> 00:10:12.960
According to the researchers, genuinely correcting the AES CFBA problem would require a backwards compatible change to net logon.
00:10:13.519 --> 00:10:20.080
Microsoft instead relies on secure RPC protections to prevent exploitation.
00:10:22.080 --> 00:10:36.960
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.
00:10:38.159 --> 00:10:40.639
Let's quickly move on to story three.
00:10:41.759 --> 00:10:48.240
A wonderfully named pass taquet tax is being reported.
00:10:49.440 --> 00:10:59.759
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.
00:11:06.480 --> 00:11:08.799
There's some important context here.
00:11:10.000 --> 00:11:13.120
They haven't broken the mathematics behind pass keys.
00:11:13.360 --> 00:11:14.159
Thank goodness.
00:11:14.320 --> 00:11:17.279
They've attacked the implementation around them.
00:11:17.440 --> 00:11:22.000
So a traditional passkey is a shared secret, as you well know.
00:11:24.399 --> 00:11:27.919
A traditional password, as you know, is a shared secret.
00:11:28.159 --> 00:11:33.679
You know it, and the server receives some representation of it, right?
00:11:34.159 --> 00:11:34.720
Passwords.
00:11:34.879 --> 00:11:38.559
A passkey, however, uses asymmetric cryptography.
00:11:38.879 --> 00:11:41.519
Your device holds a private key.
00:11:42.320 --> 00:11:46.000
The service holds the corresponding public key.
00:11:46.240 --> 00:11:52.399
When you authenticate, the server sends a fresh challenge and your authenticator signs in.
00:11:53.200 --> 00:11:57.600
There is no reusable password for phishing sites to steal.
00:11:58.480 --> 00:12:04.000
But synced pass keys introduce another problem.
00:12:04.960 --> 00:12:08.879
So how do you securely move credentials between your devices?
00:12:10.639 --> 00:12:26.559
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.
00:12:27.840 --> 00:12:40.799
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.
00:12:42.000 --> 00:12:46.399
Then there's silver pass to key attack.
00:12:46.960 --> 00:12:49.039
Here's where things get interesting.
00:12:49.440 --> 00:13:00.080
Researchers found that they could manipulate device re-enrollment and register an attacker controlled user verification key.
00:13:00.960 --> 00:13:10.240
The cloud authenticator could then accept attacker generated signatures as though the victim had completed biometric or pin verification.
00:13:11.039 --> 00:13:16.080
But the most interesting is golden pasta key.
00:13:18.879 --> 00:13:20.320
So what's going on here?
00:13:21.279 --> 00:13:33.519
Google's synced pass keys are protected using a thirty-two byte master secret called the security domain secret or SDS.
00:13:34.559 --> 00:13:44.960
Researchers have discovered circumstances where that secret became temporarily accessible inside Chrome's process memory during enrollment.
00:13:47.039 --> 00:13:57.200
Malware capable of dumping the process at the right point could recover the SDS and use it to decrypt synced passkey material.
00:13:58.159 --> 00:14:01.200
So that does sound kind of catastrophic.
00:14:02.159 --> 00:14:10.480
But here's why, you know, reporting out there, including Rs Technica, Story calls this largely a quote unquote nothing burger.
00:14:11.440 --> 00:14:15.519
The attacker already needs malware executing on your machine.
00:14:15.840 --> 00:14:19.679
So for the most part, you probably don't need to stress.
00:14:20.399 --> 00:14:36.480
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.
00:14:37.919 --> 00:14:46.159
So you know still remains that pass keys remain substantially better than reusable passwords.
00:14:47.919 --> 00:14:56.879
I think a key takeaway here is that this research to me is has a more subtle point.
00:14:57.919 --> 00:15:03.519
Phishing resistance is not the same thing as endpoint compromise resistance, right?
00:15:04.559 --> 00:15:26.159
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.
00:15:26.720 --> 00:15:34.879
Cryptographic cryptography can prove possession of a key, cannot automatically prove that the right human intended to use it.
00:15:37.360 --> 00:15:40.879
Let's quickly move on to our fourth and final story.
00:15:41.360 --> 00:15:47.759
A light LLM and the software supply chain cascading effect.
00:15:48.879 --> 00:15:56.799
We have one of the best examples this year of why software supply chain security is becoming infrastructure security.
00:15:58.399 --> 00:16:16.399
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.
00:16:17.759 --> 00:16:27.440
Lite LLM, if you didn't know, is especially valuable to attackers because it's commonly positioned between applications and multiple LLM providers.
00:16:28.240 --> 00:16:35.120
Meaning the environments running it can contain API keys, cloud credentials, and other sensitive infrastructure.
00:16:36.320 --> 00:16:38.799
But here's where things get really interesting.
00:16:40.960 --> 00:16:45.360
The interesting part is how the attackers apparently got there.
00:16:46.720 --> 00:16:53.679
Reporting is saying that the campaign had previously compromised Trivi, a popular security scanner.
00:16:54.000 --> 00:17:01.519
Attackers force pushed malicious commits across existing Trivia action version tags.
00:17:02.639 --> 00:17:14.640
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.
00:17:14.799 --> 00:17:29.200
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.
00:17:30.079 --> 00:17:45.119
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.
00:17:46.079 --> 00:17:58.079
That's why obviously high assurance CI pipelines increasingly pin dependencies to immutable commit hashes or verified artifacts, rather than trusting floating tags alone.
00:17:58.400 --> 00:18:05.839
The important point here is the Poison Trivic component reportedly harvested credentials from CI environments.
00:18:06.160 --> 00:18:16.079
Stolen access then helped the campaign move into other projects, eventually resulting in malicious light LLM packages being published.
00:18:16.400 --> 00:18:25.039
And version 1.82.8 contained a particularly nasty Python trick, a.ph file.
00:18:26.000 --> 00:18:32.720
Python processes.ph files when initializing its site environments.
00:18:33.119 --> 00:18:43.359
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.
00:18:43.519 --> 00:18:48.319
Just starting Python alone could be enough to activate it.
00:18:49.200 --> 00:18:57.440
The payload search for SSH keys, AWS, Azure, and GPC credentials, Kubernetes tokens, so on and so forth.
00:18:58.799 --> 00:19:02.720
What's interesting though is it then used hybrid encryption.
00:19:02.960 --> 00:19:12.160
AES256 for the stolen data and RSA 4096 to protect that AES key before exfiltration.
00:19:13.680 --> 00:19:17.759
That's a standard hybrid cryptography.
00:19:18.079 --> 00:19:25.440
Symmetric encryption is fast for large quantities of data, while asymmetric encryption involves the key distribution problem.
00:19:25.680 --> 00:19:34.400
CloudSec now says evidence associated with the wider campaign potentially maps to more than 2,500 organizations.
00:19:34.720 --> 00:19:43.119
Although importantly, that's reconstructed exposure, not proof that every listed organization was successfully compromised.
00:19:43.279 --> 00:19:45.440
And that's a real supply chain lesson.
00:19:46.079 --> 00:19:48.880
Your security boundary doesn't end at your source codes.
00:19:49.039 --> 00:19:56.720
You must always be looking at your package registries, build runners, GitHub actions, container images, so on and so forth.
00:19:58.000 --> 00:20:01.359
That concludes my final story for today.
00:20:13.440 --> 00:20:15.359
Enjoy interacting with people in the comments.
00:20:15.519 --> 00:20:20.880
Please leave a comment, leave a like, and I'll see you next time.
