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.
