Hello and welcome to the Monday, July 21st, 2025
edition of the SANS Internet Storm Centers Stormcast. My
name is Johannes Ullrich, recording today from
Jacksonville, Florida. And this episode is brought to you
by the SANS.edu Master's Degree Program in Information
Security Engineering. The top news today is a new actively
exploited SharePoint vulnerability. Microsoft
published a special bulletin over the weekend to alert of
this vulnerability, but has not yet released a patch.
Microsoft's advice at this point is twofold. First of
all, deploy anti-malware on your SharePoint server. If
you're unable to do so, block access to the SharePoint
server, basically take down your SharePoint site. Neither
workaround is great. At this point, the attackers
exploiting this vulnerability have been deploying web
shells. Web shells are the preferred payload, of course,
for exploits like this. And Microsoft's anti-malware tools
will detect web shells currently deployed by the
group attacking vulnerable SharePoint servers. But it is
likely only a matter of time for the web shells to emerge
that will bypass current detection rules. If you are
operating a SharePoint server that is currently exposed to
the internet, assume compromise. There is no patch.
The vulnerability does not appear to be linked to a
particular configuration. Any currently deployed SharePoint
server should be considered vulnerable and given the
widespread exploitation of the vulnerability should be
considered compromise. The exploit targets the toolpane
.aspx script. First evidence of the vulnerability was made
public by researchers with code white last week. But
initially, no proof of concept, exploit or additional
details were released. The new vulnerability is a variant of
an older vulnerability patch that this July is part of
Patch Tuesday. And code white initially used the CVE numbers
associated with these older vulnerabilities. Microsoft
this weekend assigned this vulnerability a new CVE
number. It's a new distinct vulnerability, even though it
is somewhat a variation of these older vulnerabilities as
well. The root cause appears to be the use of specific
refer headers. Sign out.aspx which bypass authentication
and allows for code execution. With that also, the attacker
can get a hand of the keys being used to encrypt your
view state. And that then leads to an insecure
deserialization attack that then can be further exploited
by the attacker. Microsoft states that its SharePoint 365
service is not affected. The first hit against URL, that
particular page that we have seen in our Honeypots, was on
the 16th. It was one individual hit from actually
Microsoft IP. But let's say the Microsoft company could be
one of their cloud users or whatever playing with this. We
don't see a lot of exploit attempts against Honeypots at
this point. Because, well, after all, they're first
checking if you're actually running SharePoint, which we
are at this point not emulating. Maybe we'll do this
shortly. And in Diaries this weekend, Xavier came across an
interesting phishing email. This email claims to originate
from a voicemail system. But instead of including the
transcribed voicemail, something I've certainly seen
before, it included the actual audio file in the WAV format.
The message is very brief and claims that the recipient's
Veeam backup license has expired. Veeam, of course, is
the large backup system commonly used in particular if
you're dealing with virtualization and the like.
And, well, the recipient should call back and basically
get that resolved. It's a very short message. In the
particular case that Xavier has looked at, the victim had
nothing to do with Veeam. They didn't use Veeam. This does
not appear to be authentic from Veeam. Also, they're
basically just using it as a pretense to trick the victim
to call back to then do probably some kind of tech
support scam. And the art company Expel has identified
an interesting attack against Passkeys or FIDO2. This
attack, according to Expel, has already been exploited in
the wild in order to bypass Passkeys as a two-factor
authentication solution. When using a Passkey or FIDO2 as
second factor, the user is prompted to provide their
Passkey after initiating authentication with a username
and password. Now, to aid in usability, Passkey offers an
extension to the original FIDO2 spec where the user may
use a device other than the one they're just using to
connect to the website in order to complete the
authentication. And Passkey offers two methods in order
for the browser the user is using to connect to a
secondary device like, in many cases, a mobile phone. The
first case is Bluetooth low energy, not affected here, but
it's a particular issue. The second one is a QR code. And
then, essentially, the user is pointing their phone at the QR
code and completing the authentication to log in.
What's being abused here is that the attacker will
basically just classic phishing, ask for username and
password on a fake website. Then, the attacker will
basically turn around, present that information to the
victim's website, and take the QR code that comes back,
present it to the victim, and then ask the victim to
complete the authentication using this QR code using their
mobile phone. So, this way, the attacker is then
completely logged in. The solution here is don't allow
QR codes for these login scenarios. Only allow
Bluetooth low energy or basically force the user to
complete the authentication on the device they're currently
sitting in order to connect to the website. And that, of
course, may not be a great option in many cases. The
problem with or the reason why there are these QR codes in
the first place is that, you know, think about it. You're
sitting on some kind of work computer. You're trying to log
in to a website that's more personal. You don't want to
share this passkey with the work computer. So, the QR code
essentially allows you to complete authentication
without sending the actual passkey to the work computer.
And, of course, in particular, with sort of more tightened-up
configurations, you may not be able to use Bluetooth low
energy to connect to your work computer. And the QR code is
your only option. Another solution here that is being
recommended by XPEL is if you can't disable QR codes, you
could review your logs in order to look for any kind of
suspicious login attempts here that are using QR code. That,
of course, depends on the volume of the logs, whether or
not this is actually a realistic option. Well, and
that's it for today. So, thanks again for listening.
Thanks for everybody I saw at Science Fire last week. It was
a great event and had a lot of good sort of connections
there. Thanks for liking, subscribing, and, of course,
as always, for rating this podcast and giving it good
reviews. Thanks and talk to you again tomorrow. Bye.
