Hello and welcome to the Thursday, July 31st, 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 Graduate Certificate Program in
Industrial Control Systems Security. And today on the
Internet Storm Center website, in our diary, you're trying
something a little bit different. Now, we had guest
diaries in the past from not our usual group of handlers,
but this time we actually tried a little bit of video.
And the reason behind this is that, well, last week we had
this huge breach in the Tea application. The breach
itself, I think, was a little bit stupid in a sense how
simple it was. But of course, it had a big impact for some
of the victims affected by the breach. However, when I'm
talking about breaches here also in the podcast, I don't
like to do it because I don't like the victim shaming, even
if some of them may deserve it. I usually try to focus on
what are the lessons we can all learn from a particular
breach so we don't end up in the same situation as the
victim here. And of course, one of the victims here was Tea
and they made really sort of a very crucial, simple mistake
with Firebase. A mistake that has been made many times
before, but has been sort of brought to everybody's
attention here in this latest breach. Brandon focuses on
that technical lesson here in his video. Essentially, how do
you secure Firebase if you have to use it at all? And how
do you make sure that you're not a victim of the same
simple exploit that was used here in this particular
attack? So definitely, if you are coding with Firebase, take
a look at the video. If you consider coding with Firebase,
maybe take a look at a video and rethink that decision. But
anyway, let me see how this works for you, what we should
change with content like this in the future, and if it's
overall useful to you. And then a quick follow-up to
yesterday's Apple patches. I noted yesterday that there was
no actually already exploited vulnerability in this set of
patches. Well, that at least is true according to Apple's
statements. However, Google patched one of these
vulnerabilities in Google Chrome. And this patch came
out about a week ago on July 15th. And Google did state
that it is already being exploited. Now, it's not a
surprise that Google Chrome sort of shares vulnerabilities
with Apple Safari. The simple reason behind it is that
Google Chrome or Chromium does use WebKit, which is the open
source HTML rendering library that Apple produces. So both
Safari and Chromium, Chrome, Brave, and Edge share all the
same parsing library. And with that, also some at least of
the same vulnerabilities. And CISA released update for its
report on Scattered Spider. Scattered Spider keeps making
the news with breaching some high-value targets. So always
interesting what kind of updates they have here. Now,
well, some of the updates here are really not that terribly
exciting. Like, for example, they used some new file
sharing site. I think it was Mega.nz actually to exfiltrate
files. Yes, that's bound to always change. But also their
social engineering part is seeing some changes. And
that's, I think, part of what Scattered Spider is really
sort of the most special about. They apparently have it
down to impersonate various people and not necessarily
with AI. So there's no real AI component necessarily here to
it. They're just good at it. They're just good in
pretending to be someone else. And the latest part here is
for the posted employees to convince IT and help desk
staff to provide sensitive information. It's often the
other way around where a random employee is getting a
call claiming to come from the help desk. But here's actually
the other way around, which is actually a little bit more
difficult for the help desk because they're used to
receiving calls from users that may be sitting in front
of broken computers. So authentication and such always
is a challenge there. Think through the procedures. How
are you dealing with these challenges? And implement some
strict procedures here. Also alert the help desk that, yes,
people will try social engineering. They will try to
claim it's an emergency and not to fall for these ruses
and also, you know, how to deal with a real emergency and
how to distinguish them how to properly escalate things
without revealing, for example, passwords, access
credentials or just simple procedures or reporting
relationships that then later could be used by the attacker
to further escalate access and, well, basically fool the
next employee. That's always part of the social engineering
where you as a victim here may not necessarily really give
them a lot of data or details, but it's enough to then
impersonate the next employee in the next phone call. And
that's sort of how they step up their privileges call by
call until they have access to the kingdom and launch the
actual attack. So good report here to read. Definitely given
sort of the urgency and the currency of these types of
attacks, definitely something that you should be aware of
and should stay up to date with. Also from the social
engineering point of view, not just from indicators of
compromise and such that are very ephemeral. I usually
don't even look at them that much in these reports. Well,
and that's it for today. So thanks for listening. Thanks
for liking, subscribing, and as always for leaving good
comments and good ratings in your favorite podcast
platform. Thanks and talk to you again tomorrow. Bye.
