SANS Stormcast Monday July 21st, 2025: Sharepoint Exploited; Veeam Fake Voicemail Phish; Passkey Phishing Attack

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

previous

Sharepoint Exploited; Veeam Fake Voicemail Phish; Passkey Phishing Attack

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 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.