Remote Weaponization of WSUS MITM
Network attacks (WPAD Injection, HTTP/WSUS MITM, SMB Relay etc.) are a very useful attack vector for adversaries trying to laterally spread, gather credentials or escalate privileges in a semi-targeted manner. This vector is used by known adversaries attempting to penetrate deep into networks, and numerous threat/malware reports have cited tools with functionality that allows attackers to perform these attacks in a remote fashion. Duqu 2.0 is a great example of where such attacks can be found in the wild and the reports of this actor make a great case study.
I became even more familiar with the techniques thanks to demos and stories from Jeff Dimmock (@bluscreenofjeff) and Andy Robbins (@_wald0), with whom I work everyday. After learning Responder, I toyed with broader capabilities such as , which combines a variety of tools into a weaponized platform for easy integration into your methodology. For those unfamiliar with these tools, please check out the following links:
In the case of the evil and wily APT actors in referenced Duqu 2.0 report, the actors used a module built specifically for their toolkit and did not require the use of public tools or external scripts. Unfortunately, for a long period of time, public MiTM/relay attack tools still required you to physically be on a local LAN (that I’m aware of anyways… I welcome your comments). In early 2015, Kevin Robertson (@kevin_robertson) released Inveigh, a PowerShell network attack tool that uses raw sockets to implement a limited subset of techniques including LLMNR spoofing, MDNS spoofing, and SMB relay. Inveigh opens the door for many interesting attack chains and allows us to better emulate threats using these vectors in a remote fashion. If you care why we emulate threats, go elsewhere… Raphael Mudge has some really great ideas and thoughts on the topic.
Let’s take a step back and learn the different components of a WSUS MITM attack first. Web Proxy Auto-Discovery (WPAD) is a protocol used by Microsoft Windows clients to automatically configure local proxy settings. Enterprises use the protocol to allow clients to automatically locate and use the proper proxy settings to egress the enterprise network. The discovery process and configuration is as follows:
- Did I get a proxy configuration during DHCP negation?
- If not, resolve “wpad.domain.com” and get the configuration from that server.
- If we did not get a result, broadcast using NetBIOS (NBT-NS) to resolve the name “WPAD”
- If a server has been found, request the resource from that server with the uri “/wpad.dat (http://<SERVER>/wpad.dat) which will contain the settings for the proxy
Due to the lack of verification during NBT-NS replies (step 3), any client in the broadcast domain or local subnet who observes the request could respond and claim to be the WPAD Server. The rogue WPAD server could then serve up a malicious configuration file to configure the target’s proxy settings. With the WPAD settings poisoned, any rogue host could masquerade as the proxy server and intercept all browsing traffic for tampering. This introduces a number of different vectors for lateral spread:
- HTTP MITM with an iframe (HTA, Exploit, Java Applet, etc.)
- HTTP Auth Prompt / Social Engineering
- WSUS Injection
- …and many many more
Windows Server Update Services (WSUS) is a system that allows for companies to manage and deploy updates or hotfixes from a centralized intranet location. At Blackhat USA 2015, a group of security researchers, Paul Stone () and Alex Chapman from Context, presented on the obvious problems with allowing enterprise updates to occur unencrypted over the network. They made the obvious point that without SSL, anyone can conduct a man-in-the-middle attack on the updates to serve a malicious update package. Oh by the way, HTTP is the default for WSUS. One problem: the update binary must be signed by Microsoft. One solution: PsExec from SysInternals allows an attacker to execute arbitrary Windows commands from a signed Windows binary. This attack was demoed at the conference and had me intrigued. Throughout the majority of the engagements I have been on, it is slight misconfigurations like these that have allowed our red team to get access to the key terrain we needed.
Please please please read their whitepaper for more research or check out their tool… I cannot do it justice in this short of a post. Also, for more research on why non-encrypted updates/software is bad, check out Josh Pitt’s (@midnite_runr) research or work on backdoor factory.
Putting It Together
Okay okay… All I have done at this point is regurgitate well-known vulnerabilities and attack strategies. The power is introduced when you put the tools together and weaponize it in a platform like Cobalt Strike enabling a MiTM attack outside the bounds of the local intranet. For this section, I will assume we have gained initial access from an external perspective to a domain joined host.
*DISCLAIMER: This is a demo, obviously there are a ton of constraints that could make an operator change the method or technique used. The point is, these seemingly advanced techniques are not limited to state-sponsored actors with custom tools, red teams can effectively emulate the adversaries and utilize these attacks.
1. Identify the Possibilities
The first step is to identify any WSUS misconfigurations. In most RATs, we can do this by querying the registry to determine the system’s WSUS settings. Next we can query the current proxy configuration of Internet Explorer. If the URL for WSUS is “HTTP://<SERVER>” and the browser is set to automatically configure the proxy, we can continue!
- HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings (Note: If the 5th byte is even, automatic detection of the proxy is likely set in internet explorer which enabled WPAD)
Once those are checked, we can use ARP to locate another host on the subnet we might want to target.
2. Network Bending Kung-fu
The obvious problem arose during exploitation of how we use our agent as the WSUS Proxy. Luckily with Cobalt Strike’s Beacon, we have reverse port forward capabilities. During the WPAD poison, we can point the victim’s browser at our “proxy” which is simply a reverse tunnel out of the network to our C2 server. Then, using the SOCKS forward tunnels, we can push the browsing traffic back into the environment to receive the action WSUS updates in addition to the tampered package.
Once the tunnels are ready, it is finally time for the attack. First, I to configure my malicious payload and start WSUSpectProxy. WSUSpectProxy takes in a custom payload defined in their payload.ini file (example shown below). Like the researchers recommend in their white paper, I use PsExec.exe with a command line parameter. In my case, I made the parameter launch powershell.exe to run “net user” and “net localgroup” to add a backdoor user “bob”.
Now it is time to launch Invoke-Inveigh with a number of flags to define the settings we wish the script to use:
- -IP <IP OF POISON VICTIM> : Set the IP to bind the raw socket to
- -NBNS Y : Set NBNS spoofing to be enabled
- -LLMNR Y : Set LLMNR spoofing to be enabled
- -HTTP Y : Turn on the HTTP server for serving up WPAD.dat files
- -SMB N : Do not do any sort of SMB relay kind of stuff
- -StatusOutput Y : Print status outputs
- -Tool 2 : Configure the settings to run this in a certain tool. The Empire setting works well for Cobalt Strike
- -SpooferIPsReply <TARGET IP> : IP of the target or CSV list of targets
- -WPADAuth Anonymous : Do not pop a creds box for the WPAD
- -WPADIp <ProxyHost> : IP of poison host where the rportfwd command is run
- -WPADPort 8080 : port of the rportfwd command
This command will perform a targeted WPAD poison of a host and serve up a WPAD.dat pointing the target browser at the port forward tunnel we have outbound. That port forward will go back to our C2 server on port 8080.
4. MITM Updates
Once the MITM condition is met, the update request is intercepted and my malicious package is passed to the client. Since the update is critical, it will likely get executed, adding a local user and allowing us to laterally spread.
DISCLAIMER: Adding a local user to a system might tip off IR but makes a good training objective and it makes the demo easier. I do recommend improving the tradecraft to launch a memory only agent (possibly using PowerShell)… but I will let you figure that out.
TADA! We now have access and can deploy a Beacon agent using the newly added user.
Fixing the Vulnerabilities
There are numerous flaws that allow for this attack chain to be successful and they should be fixed in any network. These issues have been identified for a long time but I continue to see a lack of awareness and controls surrounding the misconfigurations abused in this chain. In addition to controls to prevent the vulnerabilities, there are many ways that SOCs and CIRTs can detect malicious activity like this occurring on their network and with sophisticated attackers, a heavy focus on detection is healthy.
WPAD Controls / Fixes
To remediate the WPAD misconfiguration, DNS A or CNAME records should be added in the internal DNS server with the name “wpad” to prevent the host from getting to the step where it performs the MDNS/LLMNR broadcast. Further, it helps to uncheck the automatic settings via a GPO if that feature is not needed.
Any update packages or software should ALWAYS be deployed over secure connections (at least SSL). There are many projects that focus on backdooring software and applications in transit across networks… many bad guys used this technique to gain initial access and laterally spread. For WSUS specifically, I found this site helpful for configuration of a proper setup: https://technet.microsoft.com/en-us/library/hh852346.aspx#bkmk_3.5.ConfigSSL
Prevention controls are a bare minimum expectation but as an organization grows in maturity and works through the hierarchy of security controls, auditing and forensic capabilities are a must. As organizations shift to an assume breach mentality, they maintain their focus on prevention but also introduce the heavy demand of detection and response. There are a couple themes that can be abstracted from the attack chain above to alert on suspicious activity.
PowerShell v4 and v5 have introduced many features that the blue folks should appreciate. I mention them here specifically because I used Inveigh.ps1 in my attack chain but is not directly relevant to detection of the underlying techniques, only the weaponization vector. There is an article out that sums up most of the features that will be helpful. Anyone who is working on improving network detection should look for and introduce features to combat PowerShell attacks. PowerShell attacks are on the rise and are not going anywhere any time soon.
Event Log forwarding in a large enterprise can be difficult. The value earned from centralized collection and monitoring and collection of these logs cannot be understated and in my opinion, is totally worth it. In the case of this attack chain, it seems like the best log to add to collection is the c:\windows\windowsupdate.log file. If you are not collecting that, the System event log with a source of “WindowsUpdateClient” and ID of 17 or 19 will show you the names of the updates downloaded/installed. Comparing thees logs across the hosts will allow you to pick out edge events (rogue updates) which have only happened on selected hosts.
Collections of DNS logs would also be useful in this case. Assume that an organization suspects that they have properly remediated WPAD poisoning by disabling WPAD, if a rogue/new workstation is introduced to the environment without the controls or a current workstation has the control disabled, they would alert and observe failed resolutions for WPAD.
WMI Event Subscription
Our team is a huge proponent of WMI’s uses offensively and defensively. You might have seen Matt Graeber’s recent tweets such as this one where he provides WMI signatures that would provide alerts surrounding events worth monitoring. Jared Atkinson, ATD’s Hunt capability lead, has developed a tool called Uproot which is, in effect, an agent-less host-based IDS using that uses WMI event subscriptions.
In our case, it would be possible to create WMI event filters to fire during the value change inside of the network profile sub keys underneath “HKEY_USERS\<USER-GUID>\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad”. Further, you could signature on file creation or modification of the wpad.dat file which gets temporarily dropped into “<USER APP DATA>\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\”.
If you are interested, check out Uproot and WmiEvent and take this as a practice opportunity.
While I did not introduce any new tools in this post, my goal was to stitch together several awesome tools to show an interesting attack chain and encourage creative techniques. Further, I hoped to bring light to several misconfigurations I still commonly see in large enterprise environments.