Leveraging WSUS – Part One

Hey all,

After an extended hiatus, I’m back. I was waylaid with OSCE training, exam writing, and overall frustration, but I’m going to brag for a second to say I passed :). The material was a bit dated but I was happy with the overall course and still learned quite a bit; I have nothing but good things to say about the guys over at Offensive Security. Anyways, to the blog post.

While at a conference I was speaking with some colleagues about leveraging WSUS from an offensive standpoint. I was aware of WSUSpect but unaware of any type of attack that could leverage existing WSUS server access. While researching I came across WSUSpendu and was surprised that I hadn’t heard of it before. WSUSpendu is a powershell script that can deploy updates to update clients to get remote code execution. Two applications come to mind when employing this type of technique.

• Escalating to Domain Administrator
• Attacking Downstream WSUS Servers

How often have you seen a WSUS group policy pushed out to all systems including domain controllers via GPO? I see it quite often. If the domain controller happens to be an update client and you have WSUS server access, you’re domain administrator.

WSUSpendu can deploy updates, create and delete WSUS groups, assign computers to groups, and delete updates. To keep inline with the new hotness, I re-wrote WSUSpendu in C#.

Links

• Blackhat Slides
• WSUSpendu Powershell
• WSUSpendu C# (Thunder_Woosus)

How To Defend

The key to defending this technique is understanding it. Understanding the restrictions, what a malicious update looks like, the exposure of trusting a WSUS server for updates, and understanding security controls that can work in unison with those restrictions.

One restriction for example is, any files deployed from WSUS need to be digitally signed by a trusted authority like Microsoft. WSUSpendu recommended using psexec or bginfo with command-line arguments for remote code execution. This is a significant restriction if an attacker is trying to cross a security boundary. For part two, I’m going to play around with alternative payloads to mix it up a bit.

Enumerating Update Clients

Below is an example of enumerating update clients via the WSUS SQL database. Before running any enumeration commands against the SQL database, Thunder_Woosus will verify that WSUS is installed and pull some relevant information via the registry.

Deploying the Windows Update

Below is an example of deploying the update with Thunder_Woosus.

The parameters of the update are as follows. Changing them are straight forward, but I recommend verifying any changes in a testing lab before rolling it out in an engagement … the code is very very alpha phase.

Life is busy and I’ll only be able to work on this code on the weekends, but the hard-coded parts are very easy to fix. One hard-coded value is psexec.exe being located at c:\temp\psexec.exe and the WSUS content location c:\program files\update services\wsuscontent. This will all be ironed out in the next month or so but if you feel like fixing it up, please feel free to do so.

Here is what the update looks like in Windows Server Update Services.

And on the domain controller (int-dc) which is an update client, here is what the malicious update looks like.

And finally, once the update is manually or automatically installed psexec.exe with the command line arguments are run. As seen in the code snippet above, psexec.exe runs cmd.exe /c “c:\windows\system32\calc.exe”. Notice the current working directory, further proof it was executed via Windows Update.

This PoC is pretty crude; however, adversaries have had access to everything needed to further refine this attack. I haven’t PoC’d it yet, but I would imagine modifying an existing update to entice downstream servers to approve is possible. The best protection is understanding how this works.