SANS Stormcast Friday, May 23rd 2025: Backup Connectivity; Windows 2025 dMSA Abuse; Samlify Vulnerability

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

previous

Backup Connectivity; Windows 2025 dMSA Abuse; Samlify Vulnerability

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 Friday, May 23rd, 2025 edition
 of the SANS Internet Storm Center's Stormcast. My name is
 Johannes Ullrich and this episode brought to you by the
 SANS.org certificate program in Purple Team Operations and
 is recorded in Jacksonville, Florida. In Diaries today, I
 did a quick write-up on ensuring that you have
 resilient access to your home or small business network.
 That usually involves some kind of 5G satellite
 connectivity, which typically does not come with a publicly
 routable IP address. So you must set up some kind of
 tunnel to an external jump post. The one part I'm
 focusing on here is not what is of mechanics of setting it
 up. There are plenty of good guides there, but how to
 secure that somewhat. This is an old problem. For example,
 in the good old days when people still did war dialing
 and such, some of the console servers and such were exposed.
 We're often, well, not as well monitored as some of the
 regular firewalls, other perimeter devices. And similar
 things can happen here. If someone takes over that jump
 post, for example, they have often direct, no
 unauthenticated or weakly authenticated access to your
 network. And that's a little bit what this is about. I'm
 showing you a couple of scripts, for example, that
 make it a little bit easier to get alerts whenever someone
 logs in your jump post. Just considering that this may
 happen during network outages and that these systems,
 particularly, again, focusing on a small business here, a
 home network. You may not have sort of the central logging
 infrastructure necessarily to collect an alert on all of the
 logs from these systems. So please keep that in mind.
 Don't build any tunnels into your network that bypass
 security controls without mitigating this with security
 controls around that tunnel. Well, and yesterday actually,
 sadly, didn't make it into yesterday's podcast. Didn't
 see it at the time it was recorded. We had an
 interesting blog post by Akamai Yuval Gordon here with
 Akamai, who illustrates how a new feature in Windows Server
 2025 may be abused to essentially take over a
 domain. So for privilege escalation. The problem here
 is a new feature included in Windows Server 2025, and
 that's delegated managed service accounts or dMSA.
 Service accounts have been around in Windows for quite a
 while, but they always have a little bit clumsy kind of the
 management of them and such. So these delegated managed
 service accounts and other new features around service
 accounts are supposed to help with the management of these
 accounts. Well, the problem, of course, is you have a ton
 of existing service accounts around. So Microsoft was nice
 enough to include a migration feature that allows you to
 migrate an existing service account to a dMSA. Okay, so
 what's the problem here? Well, at first, this looks like a
 very reasonable feature. You basically migrate the account.
 And in migrating the account, the new account, of course,
 will still have access to all the privileges of the old
 account. And the way this happens sort of under the hood
 is that the new account has a pointer that tells you what
 the old account was. And then the operating system is smart
 enough to basically look at the old account and just take
 those permissions and include them with the new account
 whenever authentication is done. The problem with this is
 that, well, anybody can set up a new dMSA. So not a migrated
 one. You just send up a blank, new, fresh dMSA. Okay. And
 then after the account is created, you, of course, have
 access to the account's properties. And with that, you
 can then basically tell the operating system, hey, this
 account was actually created by migrating an existing
 service account. So you just set that pointer in this new
 attacker created account. And with that, you now have access
 to all the permissions of the old, of the, well, not old in
 this case, but the fake old account that we sort of point
 to. So essentially, you're able to steal permissions from
 any other service accounts. The problem here is that,
 first of all, the permission to create service account is
 usually not sort of something that's very tightly
 controlled. So you have a lot of users that are able to
 create these service accounts and that then there are really
 no additional controls around this. Also, there is, at least
 at this point, no patch from Microsoft. Microsoft only
 considers this a moderate issue. Usually, they consider
 approach escalation important, at least, an issue. There's
 already any controversy between Akama and Microsoft
 comes in. Microsoft basically says, well, you need already
 some elevated privileges, like the ability to create these
 accounts, which Akama says, well, isn't really anything
 that special. From a mitigation detection point of
 view, well, of course, you can remove and control that
 permission. So users can't just easily create service
 accounts. Akama also published PowerShell scripts to make it
 easier to find potential users and also added a couple of
 other sort of hints. How to, for example, see these
 migrations in your logs and how to better monitor these
 migrations, which, of course, is another way to sort of
 mitigate the risk here. It's an interesting vulnerability.
 And we'll have to see how Microsoft, in the end,
 addresses all of this. Like I said, at this point, that
 doesn't appear to be a patch plant. But over the last 24
 hours, there's been a lot been written and spoken about this
 vulnerability. So there's a good chance that Microsoft
 will actually change its mind. And then sticking with the
 theme of, well, bad authentication and access
 control here for another story, Samlify. That's a Node
 .js JavaScript library in order to implement. SAML has
 an interesting signature wrapping attack. What this
 really means is that you can create a SAML assertion and
 then just add additional data to it outside the signature
 designed block. And the recipient will just accept the
 entire message, the entire assertion, not just the part
 that's digitally signed. So this is something that sadly
 keeps coming up in signed XML implementations. And one more
 reason to mention it, definitely check for that and
 make sure you are updating Samlify if you're using this
 library. There are patches available for this
 vulnerability. Well, that's it for today. Just a reminder,
 SANSFIRE coming up. So please register. We have a bunch of
 stuff planned. Again, we do have like Honeypot giveaways
 and things like that. So hope to see you in DC. That's it
 for today and talk to you again on Monday. Bye.