Podcast Detail

SANS Stormcast Wednesday Feb 26th: M365 Infostealer Botnet; Mixing OpenID Keys; Malicious Medical Image Apps

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

previous
next
Podcast Logo
M365 Infostealer Botnet; Mixing OpenID Keys; Malicious Medical Image Apps
00:00

Massive Botnet Targets M365 with Password Spraying
A large botnet is targeting service accounts in M365 with credentials stolen by infostealer malware.
https://securityscorecard.com/wp-content/uploads/2025/02/MassiveBotnet-Report_022125_03.pdf

Mixing up Public and Private Keys in OpenID
The complex OpenID specificiation and the flexibility it supports enables careless administrators to publich private keys instead or in addition to public keys
https://blog.hboeck.de/archives/909-Mixing-up-Public-and-Private-Keys-in-OpenID-Connect-deployments.html

Healthcare Malware Hunt Part 1:
Medial images are often encoded in the DICOM format, an image format unique to medical imaging. Patients looking for viewers for DICOM images are tricked into downloading malware.
https://www.forescout.com/blog/healthcare-malware-hunt-part-1-silver-fox-apt-targets-philips-dicom-viewers/

Podcast Transcript

 Hello and welcome to the Wednesday, February 26, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich and today I'm recording from
 Jacksonville, Florida. Security Scorecard published a
 write-up about Botnet. They have observed attacking
 Microsoft 365 accounts. And what's a little bit different
 here is that they're not sort of going after normal user
 accounts, but instead they're going after accounts used by
 automatic scripts. And with that, of course, you often
 don't have the ability to do things like two-factor
 authentication. In this particular case, they're
 attacking accounts that are using basic authentication,
 which means you typically have a static username and
 password, some kind of API key. And well, a recent NIST
 guidance, for example, specifically suggested to move
 away from API keys. And one of the big reasons behind that
 was that API keys tend to be difficult to rotate. If you do
 need to design some kind of API and web services access,
 the standard method these days is often OAuth. Now, OAuth is
 not really safe from some of these info stealer types. But
 in addition to that, you probably also want to make
 sure that development and production environment are
 cleanly separated because info stealers tend to infect
 developers and not so much in production environments. And
 as such, if an info stealer steals credentials from a
 developer, then, well, they can't be used against the
 production environment. It may also be worthwhile looking
 into like canary tokens here. That's a nice little trick
 that can help you identify some of these attacks. Now,
 security scorecard did publish a bunch of indicators of
 compromise here with the report, but we all know that
 they were out of date the moment they were put into that
 document. And sticking with authentication here for
 another story, there is a blog post by Hanno Böck looking
 into misconfigured OpenID setups. OpenID, well, I just
 mentioned OAuth and the two are related, is commonly used
 as a standard in order to support a single sign-on. And
 one interesting thing about OpenID is as part of the
 standard, there's a standard URL at which you can retrieve
 the configuration for an OpenID server. This
 configuration file does include public keys or well,
 it should include public keys in order to verify any
 assertions that were signed by this particular OpenID server.
 However, as Hanno found out, some misconfigured servers are
 also offering private keys. This is a little bit based on
 sort of the flexibility of OpenID. It can use symmetric
 as well as asymmetric signatures. Asymmetric
 signatures, you only get the public key. Well, symmetric
 ones, you get the key, which of course is public and
 private, and should not be leaked to the public. But yes,
 misconfigurations happen. And Hanno did take a look at the,
 I believe it was the 100,000 biggest files based on one of
 the standard top web server lists. Only found nine that
 were misconfigured, but still nine servers out of the 100
 ,000 most popular web servers. And of course, not all of them
 offer a single sign-on with OpenID were misconfigured and
 did leak private keys. Looks probably worse when you're
 looking at smaller setups that are not necessarily as
 prominent and as often probed as these top web servers. And
 definitely something that you do want to review in your own
 OpenID configuration. And if you were ever subjected to any
 medical imaging, you may have been given by your doctor or
 the lab CD or DVD with the image file. Well, that image
 file was likely in a format called DICOM. And DICOM is a
 standard medical image format. And then of course, you wanted
 to look at the images yourself. Well, I remember
 doing this myself a couple of years back, and the image
 viewers I found were kind of hokey. They didn't really look
 sort of like real software per se, a little bit sort of
 antiquated in their UI. And it looks like that Chinese threat
 actor now is taking advantage of that by offering back door
 image viewers for the DICOM format. ForScout has a little
 write up about this. But essentially, this group is
 publishing malicious DICOM viewers that unsuspecting
 users that like I did years ago, just search Google for a
 random, more or less DICOM viewer, maybe search some of
 the app stores, then end up with these malicious versions.
 Not sure what to tell you about how to fix this. I think
 your best bet is probably to stick with the official app
 stores for some of these applications, even though even
 those applications, like I said, the UI looks a little
 bit clumsy, not sort of as polished as you usually
 expected from commercial software, at least the
 software I ended up with. Hope I didn't end up with any back
 door software back then. Well, and this is it for today.
 Thanks for listening and talk to you again tomorrow. Bye.