SANS Stormcast Tuesday, March 3rd, 2026: Finding URLs in ZIPs in RTFs; Merkle Tree Certificates; Taming Agentic Browsers

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9832.mp3

previous

Finding URLs in ZIPs in RTFs; Merkle Tree Certificates; Taming Agentic Browsers

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Tuesday, March 3rd, 2026
 edition of the SANS Internet Storm Center's
 Stormcast. My name is Johannes Ullrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Graduate Certificate Program in Purple
 Team operations. When attackers are attempting to
 obfuscate what they're doing, they often take advantage of
 compound document formats. Where they're trying to sort
 of, you know, wrap one document into another document
 type and then of course it becomes more difficult to
 figure out the actual malicious part. Didier has a
 quick diary up on how to use his tools in order to analyze
 one particular type of these documents and that's a zip
 file inside an RTF. Yes, that's legal, that's perfectly
 fine and of course a particular type of zip file
 would be a Word document because these docx formats,
 well they're really just compressed zip files. So Didier
 is walking you here through a particular example and showing
 how to not only extract this sort of mess of convoluted
 documents but also then extract URLs for example which
 of course could lead you to then additional exploit
 attempts or malicious documents. One commenter
 pointed out that the document that Didier here happened to
 use in the blog post was actually also covered by
 Akamai a week or so ago because it was one of the
 documents attempting to exploit Microsoft
 vulnerability that was patched in February. So a relatively
 recent vulnerability was being exploited using this
 particular document. And well the voyage to finally end up
 with a quantum safe internet is continuing and the next
 challenge here is certificates. There are two
 interesting blog posts that are sort of related to each
 other one by Cloudflare, one by Google about how to solve
 this particular challenge. I'll link to the Cloudflare
 one. I like that a little bit better in its explanation but
 there's nothing really different so there's nothing
 wrong with the Google one if you have seen that one. It's a
 little bit arbitrary here to just pick Cloudflare. But
 either way, so what's the problem here? The problem is
 that if we are using quantum safe certificates, we also
 have to include well the certificate and then of course
 any signatures that were created using quantum safe
 algorithms. The problem here is that the certificates and
 signatures are about 20 times as big as normal certificates.
 So well what are we going to do about this? And what this
 would end up with is really like these client hello
 measures, certificate measures would basically span multiple
 packets that often kind of creates and issues with middle
 boxes and such. So have to somehow compress what's going
 on here. And the solution that they came up with here is
 Merkle tree certificates. Instead of actually sending
 the entire certificate as part of sort of the TLS handshake,
 we're just sending essentially proofs that these certificates
 exist and that's these Merkle tree certificates. Interesting
 solution, a little bit too complex to explain here as
 part of the podcast. That's why I'm going to link to these
 blog posts that have this in more detail how this all
 exactly works. Now the reason you have this from Cloudflare
 and from Google is that Google of course is going to
 implement that in Google Chrome. And Cloudflare is
 going to implement that in their proxy architecture.
 They're actually saying that already 50% of the connection
 that their proxy here are are taking advantage of some
 quantum safe encryption algorithms. But that's really
 just the traffic encryption that's not affecting the
 certificates. They're going to start implementing this about
 a year from now. So no rush here. Nothing that you have to
 do at this point. Similarly, like in the future versions of
 Google Chrome, Google Chrome will be able to support it as
 with any other sort of TLS change. They try to remain
 backwards compatible. So you still have the old fashioned
 certificates and such to go by. So really at this point
 nothing you have to do. But of course, as always, that's why
 they're going to roll it out slowly. There's always a
 chance that there is something breaking. Like for example,
 when they initially offered quantum safe algorithms in
 Google Chrome, they had some issues sort of with these
 multiple packets in the handshake and such of a TLS 1
 .3. They had some issues like this as well. And that's what
 they're looking for. And that's why they're sort of
 going to roll it out slowly to not break anything big right
 from the get-go. So the reason why quantum encryption and
 quantum signatures are so important for the certificates
 is also that, well, based on the current algorithms, if you
 have the public key in the certificate, you could derive
 the secret key. Now, one reason why you kind of want to
 start quantum cryptography early is this sort of, you
 know, store and decrypt threat where an attacker would store
 data. And then later, once quantum computing becomes
 available, decrypt the traffic. For the certificates,
 that threat is less of a problem because, well, the
 certificates are relatively short-lived on sort of that
 time scale we're talking about here. So, you know, these
 days, the longest certificate is about 13 months. So, with
 that, it's probably not going to happen that we have a
 quantum cryptography or quantum computing break
 certificates within the next year. That's why this is less
 of a problem. And we have more time implementing this than
 some of the other use cases of quantum safe cryptography. And
 Palo Alto did publish a blog with some details regarding a
 vulnerability that was recently patched in Chrome.
 And the problem here is, well, the new trend of agentic
 browsing and the Gemini panel that Google added to Chrome.
 So, the Gemini panel gives you access basically to Google's
 Gemini AI. And the problem here is that if a browser
 extension has access to that Gemini panel, which they
 usually have because it's really just a URL they're
 accessing here, well, they buy extension and also get access
 to anything that Gemini can do, which includes in this
 case accessing camera and a microphone. So, typically,
 when you're installing an extension in Google Chrome
 that wants to access the camera or the microphone, you
 get a warning. You wouldn't get this in this particular
 case because the extension itself never accesses the
 microphone or camera. It just does so via Gemini. And that
 was the vulnerability back then. Relatively easy to
 exploit. And I hope, well, as always, that you keep your
 browser up to date. But the reason I really mention this
 is because I think that's a little bit sort of a more
 generic issue with some of these AI tools that basically
 extend the capability of the browser and how these extended
 capabilities are then exposed to things like extensions.
 Well, and that's it for today. So, thanks for listening.
 Thanks for liking. Thanks for leaving comments about this
 podcast. And talk to you again tomorrow. Bye.