SANS Stormcast Thursday, April 9th, 2026: Honeypot Fingerprinting; Microsoft Locks Developer Accounts; ActiveMQ Vuln;

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

previous

Honeypot Fingerprinting; Microsoft Locks Developer Accounts; ActiveMQ Vuln;

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 Thursday, April 9th, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida. And just as a reminder that there
 will be no Friday podcasts due to my travel schedule. And
 this episode is brought to you by the SANS.edu Graduate
 Certificate Program in Industrial Control System
 Security. Well in Diaries Today I wrote a little bit
 about how attackers are attempting to fingerprint
 honeypots. In particular, the honeypots we are using like
 the little Python script we use to emulate web
 applications and Cowrie, of course, that is being used to
 emulate Telnet and SSH. Well, those kind of honeypots are
 often considered medium interaction honeypots, meaning
 that they try to emulate particular vulnerable or non
 -vulnerable devices, but are of course far from perfect.
 And that makes it relatively straightforward to fingerprint
 them and making sure that a particular device is a
 honeypot. Now, one trick that this particular attacker,
 researchers, whoever it was, did employ was to use username
 -password combinations that would definitely not show up
 in a normal system. So, for example, well the username was
 admin and the password then definitely not valid. Krets or
 usernames like honeypot and honeypotter. The idea behind
 this is that, for example, Cowrie that we are using to
 emulate Telnet and SSH, well it will sort of randomly
 accept username and password combinations. So, it will not
 just accept very specific ones, but ever so often it
 will let a basic attacker in, no matter what username and
 password they are using, to see what commands they may be
 executing. And that's what they're looking for if they're
 able to actually log in with a username like honeypotter.
 Well, they assume then that they are connected to a
 honeypot, which is a fairly fair assumption. Are we
 working on making it a little bit harder to fingerprint
 honeypots? Yes, we always sort of log into this and may
 actually be adding some features to sort of, you know,
 not allow logins from specific usernames or passwords. But,
 not really a high priority because like I said, it's
 always possible to fingerprint these honeypots. And we are
 not really sort of after the zero days or the targeted
 attacks, but really more after attacks that are just scanning
 the internet. And some concerns were raised today by
 three different security related Microsoft developers
 accounts being suspended. What we had here was WireGuard,
 Veracrypt, WinScribe. These are the three accounts that
 are apparently affected. There may be others, but these are
 the ones where I sort of found notice about. And pretty much
 the same happened to all three where they are no longer able
 to publish updates to their respective applications. Now,
 WireGuard and WindScribe are both VPN applications,
 Veracrypt, disk encryption applications. All of these are
 well respected projects that have been going on for quite a
 few years. So it's not really clear what's happening here,
 but of course, these particular projects are sort
 of privacy related. And as a result, there's of course
 always some concern that various regulations and such
 in countries that do no longer allow VPNs or end-to-end
 encryption may be targeting projects like this. The most
 likely reason that I found for this particular issue is that
 starting in April, well, we are in April and we have patch
 Tuesday, next Tuesday. So starting next Tuesday,
 Microsoft is actually changing some policies around signing
 drivers and also bootloaders, which affects in particular
 code like Veracrypt. If you are using basically a fully
 encrypted disk with Veracrypt, then you need a special
 Veracrypt bootloader to decrypt the disk as you are
 booting the system. Well, so far, there were some co
 -signed, dual-signed solutions that were offered. They're
 going away in April. Now, I have no idea why they would
 lock the accounts in response to this. These projects
 definitely have to basically struggle with how they're
 going to respond to these changes in policy. In
 particular, Veracrypt pointed out that if you're using their
 product to encrypt the entire disk, so you need to use the
 Veracrypt bootloader, well, then your system will stop
 booting in June when actually this will go in full effect.
 And with their account suspended, they will not be
 able to actually push any updates for you. So this at
 this point just affects Windows. Of course, we had in
 the past often that particular VPN software was often removed
 from country-specific application stores. That
 affected pretty much all of the big sort of app stores
 like Apple, Android and Microsoft. But this appears to
 be global and affect the developers' accounts
 themselves. At this point, I haven't seen any official
 statement from Microsoft and hope they're bringing some
 light behind what's actually happening here and why these
 accounts were suspended. If you're using NFDS products,
 they should be working, but be aware of that Veracrypt caveat
 here and keep watching it for any updates. Any other
 versions like Linux and macOS are not affected at this time.
 This is just Microsoft and with that Windows problem.
 Well, I mentioned already this week a couple times the use of
 AI in order to find vulnerabilities. We've got now
 a nice write-up by Horizon 3 showing how they used Cloud in
 order to find a remote code execution vulnerability in
 Apache ActiveMQ. Now, first of all, Apache ActiveMQ is quite
 popular. So if you're running it, definitely make sure that
 you're up to date, that you have this issue fixed. It is a
 remote code execution vulnerability, but requires
 authentication if you run a relatively recent version of
 ActiveMQ. There have been some older versions and we're
 talking like 2024. That's when at least the CVE came out for
 it that exposed the Jolokia API, which is causing the
 vulnerability here to be exposed without
 authentication. So for these old versions, it's an
 unauthenticated remote code execution vulnerability. So
 get it patched and if you are sort of into bug hunting and
 such, definitely a good write -up in how they use the clot
 here to actually figure out how this particular
 vulnerability works. Well, and that's it for today. So thanks
 for listening. Thanks for liking. Thanks for
 subscribing. And talk to you again on Monday. Bye.