Subscribe
Share
Share
Embed
Threat Talks is your cybersecurity knowledge hub. Unpack the latest threats and explore industry trends with top experts as they break down the complexities of cyber threats.
We make complex cybersecurity topics accessible and engaging for everyone, from IT professionals to every day internet users by providing in-depth and first-hand experiences from leading cybersecurity professionals.
Join us for monthly deep dives into the dynamic world of cybersecurity, so you can stay informed, and stay secure!
We should all patch our software
all the time, and therefore it's
really good to have a patching server
in your environment, a WSUS
server, because that's the good guy,
he's going to help you.
He's going to make all your servers
be happy and updated and everything
until it turns to the dark side.
Welcome to Threat Talks.
My name is Lieuwe Jan Koning,
and here from headquarters
at ON2IT, we bring you the next episode.
And we're talking about a nasty
vulnerability in the WSUS server.
Let's get onto it.
Welcome to Threat Talks.
Let's delve deep into the dynamic world
of cybersecurity.
Let me introduce my two guests of today;
Rob Maas, friend of the show, and Luca Cipriano,
also a friend of the show, of course.
And the background of Rob is blue,
which gives away a little bit that he's
going to tell us how we are
going to avoid everything
that Luca is actually going
to make us afraid of.
Correct, gentlemen?
Correct. Yes, indeed.
So I said the WSUS server, because
I don't know how to pronounce it,
actually, Rob, do you know?
It's Windows Server Update Services.
That's as far as I can get.
Okay, so I'm not alone. Okay.
Could you explain what a WSUS server
is for and what it does?
So like what the name suggests
it’s an update server and it's used in
the network, for other Window
servers to get their updates from.
So instead of managing all
Windows servers individually
by getting new updates, you have this
central server or maybe you have multiple
where the server can request the updates
that are applicable to that server.
So it helps you a lot with keeping
servers up to date and patched.
Is this a remnant of the past in
which bandwidth was limited
and we had to be be careful about it?
Also. It also means that you can,
if you’re talking about Zero Trust
and protect surfaces, this also means
that your Windows servers don't need
any external access, in most cases,
to get updates. And they just
go to this update server.
Yeah.
And there's also, you can
also schedule updates here.
I mean you can, you can be in control.
Yeah, you can make groups of servers
and then decide what
updates they should get.
Which one maybe not, because
they might break something.
So you're really in control
of your updates
And which- You pilot servers first instead
of everything at the same time,
than have a CrowdStrike like incident where
your servers keep rebooting. Yeah. Okay.
Okay. Clear.
So and it's in the middle of
the environment, because
how does it work? Do I get updates pushed?
Do all- The servers need to connect
to the Windows update service.
And the Windows Update server, of course, needs
to have external access to retrieve the updates.
That’s... Yeah. So in terms of firewall, that server
has availability to connect to Microsoft
to get the updates locally cached,
and then all machines that run Windows,
[ ] all laptops, and domain controllers, etc.,
they should be able to connect to the...
Yeah. The Windows Update server.
And I'm afraid that Luca is going to tell us that
that web service that it runs, is actually broken.
Luca. Yes.
So there is a vulnerability in the server,
which leads to remote code execution.
Thing is the attacker does not
need to be authenticated.
So anybody that can reach the server
can exploit this vulnerability.
And, of course, you might ask, I mean,
it should not be open to internet, right?
But, apparently a lot of companies,
they have it exposed to the internet,
which, of course,
expanded the attack surface
for this attack.
But of course, an attack-
So that actually means that
without authentication, you
can simply send a packet to this server
that's exposed [ ] and then you’re...
Yes, that shouldn't be exposed
to internet, but it is in a lot of cases.
But even if it's not exposed...
If it's already inside...
[ ] exposed all your Windows machines.
So it's just one step extra, which we know
is not that difficult. No, exactly.
And as Rob also mentioned
before, this is something
that your host needs to communicate to,
to retrieve the updates.
So in general, this traffic
that you see, coming and going.
So it also-
It must be a very sophisticated attack then.
Well, yeah.
No, there are a couple of things here.
So, the first thing is, so the
attacker needs to send
a request, a SOAP request
for authentication, where
it needs to send the request
to get cookie function.
So the function that gets the cookie
and it adds it to the SOAP requests.
So it's an HTTP call with
a cookie attached to it.
That's what it looks like if you're
seeing the attack come in.
So and this can be exploited in two ways.
First of all, the encryption key
is hardcoded in the server.
So, I mean, it's a hardcoded key
so it's easy to encrypt,
but also you could slip in the payload
within a legitimate back-and-forward
during the authentication process.
The vulnerability stems from
the fact that this server used
an insecure dot net function to
deserialize the content of the
traffic, which is the binary
format dot deserialize.
Yeah. So check to see if I
understand what you're saying.
So the attacker sends an
encrypted payload like a
byte in some, in a header
of a regular web request. Yes.
It needs to be encrypted,
but with a key that is publicly available
because it's in the DLL or
whatever it is. Right.
So what you're saying
is it's easy to make it
once you know that secret. Yes.
And that's not all that hard. Yeah.
Then you send it to a certain endpoint,
API endpoint, on the server.
And then is going to do deserialize.
Yeah.
And that's where things break.
Exactly.
I really wonder how because,...
Yeah.
Deserialize doesn't seem like...
because what is deserialize?
So in general, serialization is
when you transform data
into byte stream and it's used
to be stored or transported
and the other way around,
when you deserialize, you transform
the byte streams and you
rebuild the object.
Yeah.
So this function gets an encrypted cookie,
that nobody understands,
not even computers. Yes.
And then the deserialization makes it
into this URL, this date timestamp,
this whatever. Exactly, in the format
that it should be, the object.
So what the attacker does,
it generates a payload,
chaining several gadgets. And basically,
when these get deserialized,
this function is insecure,
and the server treats
all the traffic as if it's okay,
like, and it will trust it.
And then this chain of gadgets will
lead to remote code execution
and... I don't understand this.
So you send date, it’s deserialized,
that is just decoding packets and
putting it somewhere in memory.
Right? How can you then...
Is this a buffer overflow?
No, it's not a buffer overflow, it’s just
like, that it is an insecure function.
And chaining these gadgets can
lead to unexpected behavior
and one of these is executing code
in the OS system. Rob.
Would firing the developer
be a solution here?
Because this really sounds like a very
basic thing that you need to implement.
I've no idea why it's there.
And also, I'm not working at Microsoft,
so I can only make educated
guesses. You cannot solve this for us.
I cannot solve this. No.
Okay. It surprises me.
It sounds like a really big flaw
in a very simple function to me.
We’ve seen many of those, of course,
but in a security product,
that worries me. That’s why I’m...
Indeed. Yeah.
But I mean, it's not the first or the
last time that we've seen this kind of..
Yeah, but with such a powerful server, it...
Okay. So, we have,
you send a BLOB that's
easy to construct.
Once you understand, that’s easy for people
to replicate and then remote execution.
So there's actual software of the attacker
running on the WSUS server?
Yes, indeed. Great.
So we have seen this exploit in the wild.
Yeah.
Well, but first I wanna have some more
comfort on, how we can handle this.
I want to certainly know how it actually
works, [ ]. Rob. What can we do here?
Because... On the deserialization, not much,
except that there is a patch available.
So you can patch your server,
that's one thing you can do.
You already have your patching server.
Yeah. You should patch your patching server.
The other thing is, look for
processes that should not be there.
If you have an EDR tool or XDR tool then
you can hopefully spot the abnormal behavior.
Also, if, these processes, they will be
started by one of the processes that
the Windows Update server runs.
So it will be a child process.
There's also something
you can look out for
because that should not be started
by those processes.
So you have a few things
that you can check on.
[ ] some endpoint protection solution.
I would definitely start there. Yeah.
And what about the network because Luca said,
hey, it’s publicly available from the internet.
Is there a use case for that? Why would ...
Your remote machines, maybe?
I would say not, because especially yeah,
there's no authentication involved.
So I would, even if you need to
patch remote machines,
then there are plenty of solutions
like SASE or VPNs
or nowadays, modern solutions
like WireGuard or Tailscale.
You have so many solutions
to securely connect
to your network and make it part of your,
let's say, internal network.
You don't have to expose this
to the internet.
Yeah, there’s very little things that you
should expose except for the VPN endpoint.
Right. And we've seen problems in those as well.
But that's a different episode.
We have recordings of that.
Yeah. Yeah. Indeed. Okay.
So from the internet it's really
definitely no good excuse to do so.
If you want to update
your remote machines,
if they're there for weeks, then
what you do is indeed do SASE
or VPN, as you said,
you should do that anyway.
Yeah.
Clear. And internal? I mean, is there a way,
because he says it's an API endpoint
that’s used, I mean... Internal it gets a bit harder
because these ports need to be open.
So the endpoint, at least a Windows
endpoint, so what you can do, for
example, is make sure that you have proper
network segments or protect surfaces.
And then if there are Windows servers in those,
then only allow these servers to communicate.
That will limit it a bit.
But if you are really a Microsoft house,
then you probably
will end up with a lot of Windows
machines that need to talk to that server.
So they will be there. What you can do,
but it will be limited, is
do it on application detection,
content inspection, then at least
if it does not comply with the standards
that at least you can detect something.
But I think, for this particular attack,
you must rely on the endpoint
unfortunately. Yeah. In this particular one we can
actually install the patch now, of course.
But if it's a very similar thing, then,
endpoint protection. Endpoint protection [ ].
Okay, Luca, you said, it's not just in theory,
this is actually being exploited.
What are ... who? And how?
Yeah. So, we have seen that
there was a report from ASEC
a company that was performing
an investigation
about this exploit, and they found out
that it was used to deploy
a well known backdoor,
which is called ShadowPad.
And it's a backdoor that is mostly
widely used by Chinese APTs.
So they managed to use this vulnerability
to get within the company.
Within the target I mean.
So the way they did it, they managed
to execute remote code,
and, what they have done,
they have used PowerCat.
PowerCat is a tool like NetCat.
Something that is used for remote
communication, which runs in PowerShell.
You can use it in PowerShell.
So it runs in memory.
They don't have to bring a binary
and they use the Invoke-Expression,
which is a function that is
a PowerShell command that
you can use to run something from remote,
for example, in this case, PowerCat, the PowerShell
script and load it directly in memory
without bringing the binary to the host.
But they just... So you do need
an extra binary to do this-
You don't need an extra binary,
they just run the remote code execution.
And with IX, they say, okay,
execute this, which is located at HTTP
wherever I host my malicious code.
Yeah, okay, so
they will download it,
but it's not on the disk.
It's not on disk, yes, it’s just in memory.
Just in memory.
Yeah.
So you're living of land tools to run it.
Yes.
And the script self of course is malicious.
Yeah. Okay. That's correct.
And that, of course, it gives
you already like a Reverse
Shell or anyway, some tools
that you can use, and from there,
they use the tool, then install
this Shadow Pad.
Is this required?
I mean, it’s common, good to understand,
that there's always multiple
steps involved in order to actually
get to the keys of the kingdom.
Right.
Could, I mean, if you can run
arbitrary code why don't they
execute these tools immediately then?
Well in general, of course, I mean-
Because now, I’m sure that Rob is going to say. Ha ha!
Now I got you!
Because I can actually detect
the download of the scripts.
Right. Yeah.
Right? Or...
Yeah, if you have a good EDR tool
because there's a memory,
we should be able to spot the execution
of PowerShell by one of the Windows Update
server processes. What is loaded in memory,
that's really up to the EDR tool to scan.
So you should have a proper-
But it's also traverses the network.
Yeah. The outgoing network connections
you can also of course block.
You should only allow connection
in this case to Microsoft Windows updates.
But if it is full open, which is
unfortunately quite common,
yeah, then the attacker might be
able to use the same port
because port filtering we often see.
But specific on full qualified
domain names, we do not see.
So probably the server has access
to go to the internet on port 443
to get the updates,
but they have not made it so specific
that it only can retrieve updates, but also
connect, for example, to Luca’s server.
So that would be a mitigation.
Make sure that the server,
of course, again, endpoint, but also
make sure that the server cannot
download the second stage. Correct.
But why is there a second stage then still?
Because well, if you can push arbitrary
code why don't they do that immediately?
Well of course in a lot of attacks we have
seen that happened also in the past.
I think we discussed it also, the Barracuda
like attackers or APTs in general.
They like to have multiple backdoors
that are in several places
just in case they get detected,
one can just slip out so,
I mentioned the Barracuda
because they managed to
put a backdoor that was in
the database that nobody saw,
so even after them restoring everything,
they could have access, anyway.
So in general, they look
for having more- Yeah.
Some kind of persistence step.
Yeah, some kind of persistence that makes sure that
you don't have to, also because after you patch it,
if I don't have like a backdoor then,
I mean, you close the door,
I can't enter anymore
because you patched your-
So longer term effort,
but in the short term
you could probably do
something nasty already. Yeah.
And this kind of backdoor,
especially, for example, this
one, they provide additional
functionalities that they might,
for example, help exfiltrate data in a
more stealthy way or they use different...
So I mean, where PowerCat
only does not have all that,
they use also different ways.
So also, one of the things
that they have done,
they have of course,
downloaded this backdoor,
and they used it with,
using DLL sideloading.
And these kind of attacks, often
they can also pass through EDR detection.
What is is DLL sideloading?
Yeah. So, basically, it means that, as an example,
I can bring within the system
an executable, that is
a legitimate executable.
I've done in the past a proof
of concept of with VLC.
So I bring, VLC the player,
that is just a normal player.
And then I craft a malicious DLL,
a malicious library,
which has the same functions
of the legitimate
libraries that VLC uses,
but plus, has malicious functions.
That's a kind of DLL proxy then.
Everybody uses the proxy
instead of the real thing.
Yes, exactly.
You use like a proxy.
So, my calls then are,
the legitimate calls are forwarded
to the legitimate DLL,
which maybe has another name,
but then the one
that should be the legitimate
is actually the malicious. And,
in this way, when the executable is run,
then the malware is loaded in memory.
And then you can use the commands.
That's what they also did.
Yeah. Sorry?
That's what they also did here.
Yeah. Indeed.
They used a DLL sideloading tool.
And this, unfortunately, sometimes
can also pass through EDR solutions.
Doesn't work, your EDR solution, Rob.
It depends on the EDR solution.
And also if the file is detected
when it's being downloaded.
So there are already a lot of ifs,
and again here, what's going
to be executed with this DLL
that should be caught by the EDR
because that should be
abnormal behavior for the system.
So maybe the loading goes well,
then you already have a step further.
But then still, what does it execute.
Might trigger the EDR.
And if it is something
that needs to go outside.
Then hopefully your
firewall will block it.
Okay.
And then?
And then, at that point, once the attackers are in,
of course- Yeah, they can do anything.
Yeah.
And also like, you are in a server
that normally communicates
with the hosts in your network
so the traffic can blend in.
And what we've seen also,
the attackers they use like,
living off the lands
in general to perform actions.
So they try to blend in with
legitimate traffic in general.
Yeah.
So what you're saying,
so then the WSUS server
is their stepping stone more or less,
we've already seen that
it's probably well connected within
the network, and they are admin there.
They can do whatever they like. Yeah.
Because it executes code as system.
So basically the system-
Do we know of any real world
harm that is done already?
Was this quite recent..
Yeah, I mean, this what I mentioned now with
PowerCat and the DLL sideloading and everything,
it is an actual investigation of
a company that got hacked.
Of course, there's no details of which
company it was, because... And also,
what the harm done was, but you can
imagine that this could be big.
And especially since the first step is
so easy to do and it's so impactful.
Well, yeah.
You also have like, several proof
of concepts in various GitLabs.
So if you want, tomorrow you can just
try and run it and it will work.
Okay.
Well Rob, that brings us to our final advice.
What do we need to do?
So everybody who has Windows,
which is almost everybody...
First, let's assume that
every step was successful.
And so, Luca gained access
to this Windows Update server,
then in a proper environment,
this Windows Update server is isolated.
It can retrieve a lot of connections
because the Windows systems
need to get their updates, but it should
not be allowed to go outside itself.
So for lateral movement,
you can make it really difficult
for in this case, Luca,
to see what else is in the network.
So that's one step.
So I think, if you look at a real world
scenario, make sure that the Windows
Update server is in its own segment,
network segment, or protect surface
If you follow the Zero Trust wording.
Make a very specific policy for inbound
access only for Windows servers,
if you have the chance. If you have
the chance, also do it application
based with content inspection.
And on the server itself,
run EDR or XDR, whatever you use,
and make sure that the outbound
connection of that server is only going
to Windows Update servers.
And not to everything on the internet.
And then, I think you already
have a quite okay setup.
And of course, nowadays patch the server
because there's- For this particular [ ].
We need to do it right now. Exactly. Yeah.
But to prevent the next similar
episode from happening. All the steps.
Everything that you just said. Yeah. Okay.
I will say also like, probably setting up some
alerting in SIEM, for example, for usage of
base64 encoded commands with PowerShell or
all this kind of things can also help you detect it.
Maybe the vulnerability is not known,
but something is happening
within your network
so you can maybe catch it.
Because in general, you should be
able to know who should run
some of the commands on
the server, using PowerShell.
And, just... Especially if the parent process is a
Windows Update server or related process.
Yeah.
But you trigger something.
Bit off topic for this one, maybe,
but why would we allow PowerShell
so many...? Isn't there a way around,
that you, not by default install it?
I mean I know that Windows
administrators [ ], of course. Yeah.
That is the problem, there’s always...
There's so many attacks these days
that we’ve seen that do this, right?
Yeah.
I mean- That use this. PowerShell is
pretty powerful, but in general, like,
well, you will need a way, a means to run commands,
even if it's command.exe instead of PowerShell.
There are things that you can use like Certutil,
you can use it with command.exe,
you don’t need PowerShell, you always
have living of the lands.
And of course you have network
administrator or system administrator
that will need to run commands so.
Yeah, they will be very miserable without it.
So what you're saying is, this living off the land
problem is really not going to go away.
I mean, it's using legitimate things that
are needed for nefarious purposes. Okay. Fair.
Thank you.
Well thank you. Gentlemen, thank you
very much for these insights.
We're going to patch tonight.
And to our viewers,
thank you as well, for tuning in
and if you like this, we'd love your
like, on YouTube, on your podcast app,
because it helps us spread
the word further.
While you're there, subscribe.
Because then next week you'll have
our next episode in your inbox as well.
Thank you. Bye bye.
Thank you for listening to Threat Talks,
a podcast by ON2IT cybersecurity and AMS-IX.
Did you like what you heard?
Do you want to learn more?
Follow Threat Talks to stay up to date
on the topic of cybersecurity.