Podcast Detail

SANS Stormcast Monday, July 14th, 2025: Web Honeypot Log Volume; Browser Extension Malware; RDP Forensics

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

Podcast Logo
Web Honeypot Log Volume; Browser Extension Malware; RDP Forensics
00:00

DShield Honeypot Log Volume Increase
Within the last few months, there has been a dramatic increase in honeypot log volumes and how often these high volumes are seen. This has not just been from Jesse’s residential honeypot, which has historically seen higher log volumes, but from all of the honeypots that Jesse runs. 
https://isc.sans.edu/diary/DShield+Honeypot+Log+Volume+Increase/32100

Google and Microsoft Trusted Them. 2.3 Million Users Installed Them. They Were Malware.
Koi Security’s investigation of a single “verified” color picker exposed a coordinated campaign of 18 malicious extensions that infected a massive 2.3 million users across Chrome and Edge.
https://blog.koi.security/google-and-microsoft-trusted-them-2-3-million-users-installed-them-they-were-malware-fb4ed4f40ff5

RDP Forensics
Comprehensive overview of Windows RDP Forensics
https://medium.com/@mathias.fuchs/chasing-ghosts-over-rdp-lateral-movement-in-tiny-bitmaps-328d2babd8ec

Podcast Transcript

 Hello and welcome to the Tuesday, July 15th, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich and this episode brought to you by
 the sans.edu certificate program in cybersecurity
 leadership is recorded in Washington, D.C. Well, if you
 are running one of our honeypots and sending us logs,
 which I hope many of you are doing, you may have noticed a
 delay in imports of these logs over the weekend. This was in
 part caused by, well, an unintentional self-inflicted
 denial of service. We were playing with a new version of
 the honeypot and, well, myself and Jesse were running it and
 causing a lot of additional logs. But this also triggered
 Jesse to look a little bit at the log volume of his
 honeypots. He's running about half a dozen of them across
 time. And we have seen in the past where honeypots sort of
 on a particular day or so all of a sudden get a big surge in
 logs. This is often caused by one particular IP address,
 essentially running a vulnerability scan against a
 particular honeypot. Well, what Jesse saw was something a
 little bit different. Over the last couple of weeks, the log
 volume across all of his honeypots has increased
 substantially sort of by an order of magnitude. Actually,
 when he plotted it sort of as number of logs or events over
 time, the prior part of the graph pretty much looked like
 zero, like nothing was there. What is also interesting here
 is that this attack appears to be caused by IP addresses that
 only scan a very small number of URLs. And these URLs are
 related to the sonic wall vulnerability. Looks like
 there is some kind of botnet that infected these sonic wall
 systems and is now very aggressively scanning for
 additional vulnerable systems. I hope they sort of got what
 there is as far as vulnerable systems exists out there. But
 definitely double check your sonic walls. Make sure you're
 patched. Other than that, I don't think that this
 particular botnet at this point is causing much
 additional damage. As they probably have reached sort of
 saturation way long ago, like a few weeks ago or so. I would
 expect within a day or so that this botnet probably reached
 saturation. And yeah, definitely need to look at it
 globally. Haven't had a chance the last couple of weeks to do
 much as far as data analysis goes. But have to see if this
 is an effect that all of our sensors see or just a specific
 subset of our sensor. And Idan Daridman with Koi Security did
 publish a blog post describing a campaign of compromised
 browser extensions that they are calling Red Direction.
 What's interesting about this is not only that like the more
 popular extension was part of this campaign, a color picker,
 color changer extension was installed by 2.3 million
 users. But also that this extension has been around for
 quite a while. Now, it wasn't malicious for the entire time
 it existed. It started out as a well-respected, non
 -malicious extension, but the malicious part was only
 installed later. However, with users, of course,
 automatically updating extensions, they then also
 received the malicious version as it was published. This
 extension will essentially monitor your browsing habits,
 do reports back things like URLs and such that you may
 visit. And, well, also has the ability to redirect you to
 other sites and basically control your browser. The
 problem with extensions in general is that, yes, they do
 have access to the entire content, the entire DOM in
 your browser. In this particular case, it probably
 also wasn't suspicious if the extension asked for that
 permission, as you wanted it to interact with the webpage
 to change, select colors and the like. There was also like
 an emoji keyboard, I believe, that was vulnerable and a
 couple of other really benign extensions that worked
 perfectly fine, but then received this malicious
 update. As far as defenses against this, well, of course,
 if you are affected by any of these extensions, immediately
 uninstall it. Be aware of the possible damage that has
 happened by data being exfiltrated. But you really
 must control the number of extensions that you install,
 in particular if they do have wide access to your browser,
 which most of them have. And think about whether it's
 worthwhile having an extension that may change styles, fonts
 a little bit, and whether it's worth the risk of potentially
 affecting yourself with the latest spyware and malware.
 And then we have a great blog post by science instructor
 Matthias Fuchs, who is going over how to reconstruct RDP
 activity. RDP is one of the big ways how attackers these
 days are entering corporate networks. Sadly, it's still
 often exposed. Matthias is in detail going over different
 Windows event IDs that you may be seeing, and also down to
 how using the RDP cache, which contains little 4x64 pixel
 snippets of the screenshots during the RDP activity, how
 to reassemble them to basically get a better idea
 about what happened during a particular event like this. So
 great resource for any incident responders or
 forensic haters. Well, and this is it for today. So
 thanks for listening and talk to you again tomorrow. Bye.