
SANS Internet StormCast
SANS Stormcast Monday, January 5th, 2026: MongoBleed/React2Shell Recap; Crypto Scams; DNS Stats; Old Fortinet Vulns
AI Summary
The episode recaps recent security news, highlighting ongoing activity of the React2Shell exploit and the need to patch and isolate MongoDB servers against the MongoBleed vulnerability. It warns about classic advance‑fee cryptocurrency scams promising large payouts, and shares a practical tip using tshark to measure DNS response times and improve performance by disabling costly reverse lookups. Finally, it underscores the persistence of old Fortinet firewall flaws (CVE‑2020‑12812) affecting thousands of devices, urging regular firmware updates and end‑of‑life tracking for network gear.
Episode Description
Cryptocurrency Scam Emails and Web Pages As We Enter 2026
https://isc.sans.edu/diary/Cryptocurrency%20Scam%20Emails%20and%20Web%20Pages%20As%20We%20Enter%202026/32594
https://isc.sans.edu/diary/Debugging+DNS+response+times+with+tshark/32592/
https://www.bleepingcomputer.com/news/security/over-10-000-fortinet-firewalls-exposed-to-ongoing-2fa-bypass-attacks/
Show Notes
Title: SANS Stormcast Monday, January 5th, 2026: MongoBleed/React2Shell Recap; Crypto Scams; DNS Stats; Old Fortinet Vulns
Handler on Duty: Guy Bruneau
Publication date: Monday, January 5th, 2026
Podcast Transcript
Hello and welcome to the Monday, January 5th, 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 Cyber Defense Operations.
Well, first podcast of the new year, so I want to do a quick recap here. First of all, React2Shell still hitting the news every so often here and there. Mostly various botnets and such adding it to their arsenal, so nothing really too terribly exciting. Secondly, MongoBleed. I did a special podcast last week just to sort of keep everybody in the loop on this one. Haven’t seen a ton of news about this, but definitely, you know, number one, if you’re running MongoDB, make sure that you’re patched. Secondly, you probably want to make sure that MongoDB is not directly exposed to the internet.
And well, in diaries, we had one this weekend from Brad, who wrote about a recent cryptocurrency scam that Brad observed. This one is your classic advance‑fee type scam. The attacker is sending spam messages claiming that the recipient has some pending cryptocurrency deposit waiting for them. The way this is sort of made plausible is that they say that the victim signed up for some kind of cryptocurrency mining and, well, their cryptocurrency that they mined is now basically ready to be withdrawn. They’re promising quite a substantial amount, sort of in the order of one‑plus Bitcoins. So like a hundred thousand dollars are being offered here. And then of course, the classic advanced‑fee scam kicks in where the victim is then being asked to deposit for some kind of withdrawal fee that of course is then lost. So very classic scam here. And of course, playing, of course, also on the greed of the victim here that the victim, even though they probably know that they don’t have anything waiting like this, are still attempting to withdraw the money because, well, after all.
And then I did a quick diary a couple days ago about debugging DNS with tshark. tshark, of course, there’s an amazing tool. It’s the command‑line equivalent of Wireshark or Wireshark without the GUI. The feature I used here is, well, first of all, tshark’s ability to create some basic DNS statistics, but then also for tshark to calculate the response time. So for each response you get, well, how long did it take since the request to actually detect this response? And with that, you can easily create statistics about, you know, which of your DNS servers is lagging.
What I found sort of interesting here is I use four different sort of public recursive resolvers to forward my queries to, and they performed pretty much exactly identical. I’m using Comcast – here’s my ISP. One of the DNS servers was Comcast DNS server, but you have the Quad‑1, 8, 9 DNS servers here as well. I assume they all have co‑located anycast instances with Comcast, which sort of leads to some of this effect, but it doesn’t look like any one of them, at least from my perspective, has any performance difference here.
Another thing that sort of helped me here, and actually that’s where I did fix at least part of the problem I had with DNS performance in my environment, was it gives you a breakdown by DNS query types. I had an NTP server that is part of the NTP pool, and it did reverse lookups for any connection coming into it, which of course reverse lookups – these pointer records tend to be slower, tend to often fail in timeout. And yes, they exceeded like all the other DNS record types that I had in my network. So just turning that off in the NTP server actually made a little bit of a difference here. So don’t forget about tshark. Great tool to do sort of some network analysis like this. Not always for security, but also sometimes just for performance. Of course, a lot of this, like what record types are being used and such, is quite an interesting and important security tool as well.
And in this podcast, I’ve often talked about vulnerabilities in security systems, firewalls, VPN endpoints, and the like. Well, one of the names that often comes up is 40Net. Shadow Server now looked at an older vulnerability in 40Net’s firewalls, CVE‑2020‑12812. This vulnerability is five years old and still there are a lot of unpatched devices out there – about 10 000 according to Shadow Server’s census of these devices. I think that’s a great reminder that it’s not just about new vulnerabilities that vendors often leave in these devices, but also about users really having to get a little bit better at patching and keeping up to date with their devices.
The thing I have recommended before is a calendar reminder to once a month, just check for firmware updates for your particular secure devices, particularly in a home or small‑business network setup. I think that’s useful where you often just have the one sort of gateway that you have to keep up to date and also attach a sticker to the device with an end‑of‑life date, if you know what that date will be. So, you know, by that date, I probably should have replaced this particular device because no more updates will be coming. And the same when you’re buying a new device – don’t try to buy a new device without the vendor telling you for how long they’re going to deliver security updates for this particular device.
Well, that’s it for today. A little bit of a slower start to the new year. Nothing really all that breaking and catastrophic. Luckily, MongoBleed, I guess, is a little exception here that kept a lot of people certainly busy. So keep that in mind. And with that, thanks for listening and talk to you again tomorrow, going back to our normal schedule starting this week.
Thank you.
Related links mentioned in the episode
-
Cryptocurrency scam diary: https://isc.sans.edu/diary/Cryptocurrency%20Scam%20Emails%20and%20Web%20Pages%20As%20We%20Enter%202026/32594/
-
DNS debugging diary (tshark): https://isc.sans.edu/diary/Debugging+DNS+response+times+with+tshark/32592/
-
Article on old Fortinet devices still vulnerable: https://www.bleepingcomputer.com/news/security/over-10-000-fortinet-firewalls-exposed-to-ongoing-2fa-bypass-attacks/
Comments
Want to join the conversation?
Loading comments...