I hope all is well, it’s been a while! This post is going to discuss application propagation and introduce BADministration, a tool a colleague (@DarknessCherry) and I are currently putting together. More specifically, we’re going to be looking at how one could leverage SolarWinds Orion server from an offensive standpoint. Before going further, one thing I would like to make clear – this is not a Solarwinds issue or vulnerability. This post instead discusses features and architecture issues, similar to spanning a trusted domain to a less-trusted network.
Application propagation, improper application segmentation, or whatever you call it, is the act of reusing management applications across differing trust zones. This is especially relevant to OT environments as we often see IT management applications reused or propagated to the OT systems. The consequences of this type of spanning is if an attacker lands on that IT management server they most likely have privileged access to all its clients, including the OT systems. Breaching the IT/OT boundary or escaping the OT DMZ in this fashion is far too easy.
A perfect example of leveraging an administration application to attack clients is WSUSpendu, a powershell script which can deploy Windows updates to clients via WSUS. This type of attack is exacerbated if the WSUS server serves updates to more trusted networks, video example here – ijwrtpost.
BADministration – https://github.com/ThunderGunExpress/BADministration
How to Defend
To put it simply, when dealing with a critical trust boundary like the IT/OT, segment applications similar to how networks or domains are segmented. Attackers are looking to management applications which have server —control—> client relationships throughout the environment to find slip-ups by defenders. If those management applications serve clients which are a higher trust than the server, you have an issue. For example, if your domain controller has the keys to the kingdom and it’s a client of the NMS server, by extension the NMS server probably has access to the keys to the kingdom as well.
I find the IT/OT relationship is an interesting one. IT security budget often exceeds the OT security budget but OT is the more critical environment, which makes this recommendation weird – assign trust level 0 to the IT network. From an OT perspective, be wary of any delegated administration or authentication, not because their security is shit (it’s often real good), but instead because it’s out of your control. Also, the IT environment and most of its servers are often one or two hops away from the internet, a non-requirement for OT environments.
In my travels I often see one critical OT architectural flaw time and time again: the OT DMZ serves as a semi-trusted intermediary / management zone. The intermediary part is good; however, having management applications with critical OT clients is not. Unfortunately, deep diving this issue is out-of-scope for this post but for now, I’m going to toss out the idea of an Admin OT network which has one-way communications into the DMZ and Critical Control environments (old news to some, I’m sure). When configured correctly this type of configuration can be extremely potent, but the devil is in the details … post for another day.
Current Solarwinds Modules
The modules below leverage the Solarwinds API
- solarwinds-enum – Enumerates all Solarwinds clients
- solarwinds-listalerts – Lists Solarwinds alerts
- solarwinds-alertremove – Removes the malicious alert used in the syscmd module
- solarwinds-syscmd – Executes system commands on the NMS server
- BADministration_SWDump.exe – Standalone memory scraper which (hopefully) retrieves Solarwinds WMI credentials
In this video we’re going to steal Ingrid-DMZ’s credentials, who also happens to be an NMS Administrator. With those credentials, we’ll interface with Solarwinds via the API and proceed to enumerate clients, WMI accounts, and alerts. We’ll gain a SYSTEM session on the Solarwinds server by delivering a malicious alert, then we practice GOOD TRADECRAFT by cleaning up that alert after execution. With SYSTEM access to the NMS server we complete the attack chain by scraping memory and getting access to domain administrator credentials used for WMI polling.
I don’t want to be that 1337-hax0r guy showing you how I pwned all ur systems with a single thought … but I really think this is a cool video which emphasizes the risks of application propagation. Note, this module isn’t included in BADministration and you should probably never do this in an engagement, it’s unnecessary.