SANS Stormcast Thursday, January 15th, 2026: Luma Streal Repeat Infection; ServiceNow Broken Auth; Starlink/GPS Jamming

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

previous

Luma Streal Repeat Infection; ServiceNow Broken Auth; Starlink/GPS Jamming

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Mistake for ISC sticker

Starlink jamming portion
“Space Station”

Posted by 3000060128 on Thu Jan 15 2026, 03:44

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Thursday, January 15, 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
 Incident Response. In Diaries today we got a malware write
 -up by Brad. Brad is writing about a recent version of Luma
 Steeler. Luma Steeler as the name implies is an info
 stealer. Now in this particular case it will
 exfiltrate your data and then it will download an additional
 URL from Pastebin with instructions on what to do
 next. At this point the odd new behavior here of this
 variety of Luma Steeler is that it adds a scheduled task
 to keep repeatedly doing this. But then whenever it downloads
 the next binary or whatever it's going to load on your
 system well it adds another scheduled task. So these
 scheduled tasks keep piling up. Apparently they are
 scheduled every 30 minutes and Brad observed systems running
 up to 30 or so off these scheduled tasks meaning every
 minute at that point a new variety of malware is being
 downloaded and executed which of course should make the
 infection more noisy. But note that all of this happens after
 the bulk of the data exfiltration already happened.
 So at this point I think the attacker is less worried about
 being discovered and probably is more attempting to scrape
 any kind of additional information from the system
 that was initially missed. It's also possible that
 they're then sort of handing on the system to some other
 group that installs whatever malware they prefer,
 ransomware or whatever. And we have yet another interesting
 agentic AI vulnerability. In this case it's again
 ServiceNow. They have been in the news in the past with some
 vulnerabilities in their integrations. But this is
 really not so much an AI problem. It's really sort of
 one of your very basic authentication issues and
 particular the reuse of credentials. So the way the
 main part of the vulnerability here works, a lot of parts to
 it, but this is sort of the root cause of this issue is
 that the ServiceNow as part of its virtual agent did ship all
 virtual agents, basically all integrations, all customers
 that used it, got the same credentials. And this fixed
 credential was really all that was needed in order to
 authenticate. Now once of course an attacker knows that
 credential, well they're able to authenticate then as any
 user that has this particular application enabled. And since
 it was one of those default applications and also a very
 logic application to enable for ServiceNow. After all,
 it's sort of a help desk application. So having an
 automatic help desk agent makes a lot of sense here.
 Well, that basically then opened a lot of installations
 to this vulnerability. Now there are a couple more parts
 to it, how to exact and exploit it once you get
 access, once you sort of learn all of the UIDs and such being
 required in order to exploit this flaw. But still remember,
 even though it's AI, we are still dealing with very basic
 simple authentication vulnerabilities in this case.
 This last week there were a lot of news stories about
 Starlink terminals in Iran getting jammed and it wasn't
 really clear how this worked. Now thanks to a blog post by
 Noriman Garib, we now have some evidence as to what was
 going on there. What Noriman did is look at some debug logs
 from affected Starlink terminals and the common
 denominator was problems with GPS, which also makes some
 sense. Starlink terminals need to know their location in
 order to be able to direct themselves at the correct
 satellites in the sky. So they have similar to what GPS does
 too, they have tables as to which satellite is in what
 location at what time and then they calculate the angle to
 direct the antenna at a particular time based on their
 own location. Now the problem here was that apparently GPS
 was jammed and that's nothing really new. That has happened
 a lot in the last few years. The Starlink signal itself
 apparently wasn't actually here affected. It was just
 that the space station, not knowing where it exactly is,
 wasn't able to accurately point to the right satellites.
 Now there is actually sort of a failover mode here in these
 Starlink terminals if they recognize that GPS isn't
 working correctly. This failover mode was engaged in
 these cases but apparently without GPS just using
 Starlink satellite signals to position itself. Well that
 apparently wasn't accurate enough. So there's a potential
 fix here for the problem by improving the location via
 Starlink's own satellites. Of course the vast number of
 these satellites may make them more difficult than to
 interfere with and that was actually a proposal that was
 pointed out by SpaceX and Starlink in the past that they
 could use their satellites as an alternative to GPS. Well
 and that's it for today. Thanks for listening. Thanks
 for liking and subscribing to this podcast. Remember we also
 still have the contest going on if you find any mistakes in
 this podcast or have any other comments. You qualify for a
 free sticker and that's it for today. Talk to you again
 tomorrow. Bye.