SANS Stormcast Tuesday, March 31st, 2026: Honeypot Session Lifetime; Let’s Encrypt Tests Mass Revocation; F5 RCE Exploited

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/9872.mp3

previous

Honeypot Session Lifetime; Let’s Encrypt Tests Mass Revocation; F5 RCE Exploited

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 31st, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from Orlando,
 Florida. And this episode is brought to you by the SANS.edu
 Graduate Certificate Program in Purple Team Operations.
 Well, in Diaries today, Jesse is asking an interesting
 question. Well, first of all, when do Honeypot sessions
 disconnect? First of all, a couple statistics here. Most
 Honeypot sessions do last a very short time, a couple
 seconds. That's no surprise because we have a lot of
 attackers that will just connect, do a quick you name
 or a quick check like that and then disconnect again. Now,
 there are a couple of outliers. There are a couple
 of sessions that last like several minutes. Also, some
 sessions that do launch a large number of commands. Now,
 quite often, these sessions are basically just sort of
 using these commands to transfer some kind of binary
 or such. So they're not actually sort of distinct
 different commands, but really just repeats of the same
 command and then just adding more data to a particular
 binary. But what I find actually most interesting in
 Jesse's diary is, what's the last command that an attacker
 executes in the Honeypot? Because that command sometimes
 gives away why they're connected to a Honeypot or
 that they're connected to a Honeypot. So Jesse looked at
 some of these commands and indeed some of these commands
 have distinct different return values depending on whether or
 not they're running in a Honeypot or not. So, well,
 we'll probably have to fix up some of the responses here to
 keep them longer entertained in our Honeypots. And then we
 had an interesting experiment that Let's Encrypt is running.
 It's a test of their mass revocation policy. So over the
 years, it always has been a problem if certificate
 authorities had to revoke a large number of certificates.
 More recently, the certificate authority baseline
 requirements do require that certificate authorities, first
 of all, must have a plan in how to revoke large numbers of
 certificates. And then they also must test it
 occasionally. This test is what Let's Encrypt did now.
 And they took advantage of a new feature in their ACME
 protocol, the ARI feature or the ACME renewal information
 feature. The way this works is if you're running your script
 that basically checks if your certificates are still up to
 date and need to be renewed. Well, this script will also
 check in with the server authority and basically check
 using the ACME protocol and this particular renewal
 feature whether or not the certificate must be renewed
 ahead of time. And that's what they did here. Now they used
 the Let's Encrypt staging environment. That is, of
 course, used by users to test whether or not their
 certificate scripts and so properly work. So not the
 production environment. That way, they avoided any impact
 on actual customers that use these certificates in
 production. At this point, I haven't seen anything about
 any issues with that. Someone at CertKit, that's one of the
 clients that implements the ACME protocol, noted that
 their client dealt with this issue. But of course, the vast
 majority of ACME clients out there right now will not
 support the ARI feature. So probably that went unnoticed
 to these users. If it does support the ARI feature, it
 will request a new certificate and also basically tell the
 server authority which certificate replaces. So this
 certificate can then be revoked. And back in October,
 F5 released an advisory about a Big IP APM vulnerability,
 CVE 2025-53521.
 But back in October, they stated that this is a denial
 of service issue. And I don't think back then I bothered
 covering it for that reason. Well, they just re-released
 the respective advisory stating not only that this
 vulnerability is now being exploited, but also that it
 turns out to be a remote code execution vulnerability after
 all, giving it now a CVSS score of 9.8. Now, given that
 this particular advisory was originally released in
 October, there's a good chance that you already patched this
 vulnerability. But please double check, you may have
 assigned a lower priority because of the categorization
 as a denial of service. It is now an already exploited
 remote code execution vulnerability. Well, and this
 is it for today. So thanks for listening. Thanks for liking.
 Thanks for subscribing. And talk to you again tomorrow.
 Bye.