SANS Stormcast Thursday, November 6th, 2025: Domain API Update; Teams Spoofing; VShell Report

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

previous

Domain API Update; Teams Spoofing; VShell Report

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, November 6, 2025
 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 Undergraduate Certificate Program in
 Cybersecurity Fundamentals. Today I made live some changes
 to our new domain API, this is an API that basically delivers
 newly registered domains for the last day. This particular
 API had a problem that has been going on for a while
 where it often, pretty much always, only returned a
 partial result. So basically the results were cut off.
 Well, fix that two different ways. First of all, if you
 just want all the domains, all the domain names, then the
 easiest solution is just download a static file that
 I'm offering now. That file is being updated once an hour and
 should download really quickly because, well, it's just
 static. It doesn't have to be created on the fly. Also with
 that, it doesn't run into the problems where you only get a
 partial result back. The second option is if you still
 want to use the API, you now have pagination where you can
 just download a part of the results. You can also do some
 filtering for keywords if you don't really want the entire
 list. But really the easiest way is just download a static
 file and then do whatever filtering you need or so at
 your end. That probably will be the simplest, fastest
 solution for this. This list also includes our sort of
 still experimental scoring system where we sort of try to
 assign anomaly scores to the domains. If you have any
 feedback on that, please let me know. And Checkpoint
 published an interesting blog post showing some
 vulnerabilities that Microsoft recently patched in its Teams
 platform. One of the ways Teams, of course, is often
 used is for communication internal to a company. And
 with that, users tend to have quite a bit of trust in the
 platform, unlike with email, that the sender is actually
 the person that is indicated as part of the platform. Well,
 apparently that wasn't always the case. The fundamental
 problem here appears to be that each user in Teams has a
 unique user ID and that user ID is validated and you cannot
 basically spoof a different user ID. But that user ID is
 really just about one of those UUIDs or a random string and
 it's not visible to the recipient. Instead, there is a
 display name that's assigned to a particular user that is
 then being displayed to the recipient. And that display
 name, well, can be altered by the user sending the message.
 The other interesting and probably not quite as severe
 problem was that it was possible to modify a message.
 So the edit flag would not be visible. That, of course,
 could then be used to, for example, fake a message first
 to a user or send a message to a user, then later edit it.
 And the user can't really prove that you said something
 else earlier. I'm not sure what kind of internal logs are
 available there, but probably not too many, given that most
 of this happens in Microsoft's cloud platform. So I think
 this comes down to sort of a little bit of awareness item
 here to be careful even in these internal platforms
 whether or not a message is legit. And I think there
 should always be a little bit of a sanity check if a message
 arrives that's out of character for the sending
 person. Then probably be suspicious and maybe try to
 verify the identity of the sender beyond what you're
 seeing on the screen. There are typically many things like
 lookalike characters and such that can be used to
 impersonate other users that don't necessarily require an
 outright vulnerability in the platform. And we do have an
 amazingly thorough report about VSHELL from Belgium
 security company Nviso. Nviso collected pretty much
 anything that's available there about VSHELL. I can't
 even summarize it here. As part of the podcast, this
 report is 40 pages of details what VSHELL exactly does, how
 it works, how to detect it, which is always something that
 I'm really interested in. They found something like 1500
 different VSHELL servers. VSHELL is one of those
 implants that attackers are leaving on infected systems to
 then gain remote control over these systems. It's more used
 by the more sophisticated attackers. It used to be
 publicly available and open source essentially, but in
 recent years it has become closed source and well, of
 course, as a result also a little bit more difficult than
 to analyze what it exactly does and how it works. So
 great paper here for any incident responders or such
 that really want to dive into this if you run into VSHELL as
 part of an incident. Well, and that's it for today. Thanks
 again for listening. Thanks for liking. Thanks for
 subscribing. Thanks for leaving good comments on your
 favorite podcast platform. That's it for today and talk
 to you again tomorrow. Bye.