Abusing SolarWinds Network Performance Monitor for Post-Exploitation
Windows post-exploitation with SolarWinds NPM.
Background
During a pentest late last year I got access to a SolarWinds Network Performance Monitor (NPM) application via its web administration console. I got lucky, the admin had just started setting it up and he/she hadn’t gotten around to changing its default credentials.
I didn’t think much of the access at first, all I could see from the admin panel was a bunch of nodes/devices that the application was monitoring. But since I was all out of options that I could use to get a foothold on any of the in-scope servers, I decided to spend a little more time getting acquainted with NPM.
After burning a few hours going through NPM’s user guide I found a way to use my access to the web console to execute privileged commands on the underlying operating system – which is what this post is about.
SolarWinds NPM
SolarWinds NPM (Network Performance Monitor) is SolarWinds’ flagship tool for network monitoring and arguably one of the most popular monitoring solutions on the market today. NPM 12.1 is the most recent version of the tool at the time of writing. I can’t go through all of its features, but feel free to check them out yourself on SolarWinds’ website.
To put it as simply as I can; NPM monitors network devices and triggers alerts when something goes wrong. This post is about abusing NPM’s alerting features for post-exploitation activities.
NOTE: This post is purely about post-exploitation, so you’ll already need to have gained access to NPM’s web administration console for the information here to be of any use.
Abusing NPM Alerts
Like I said above, NPM monitors network devices and kicks off an alert when an event occurs. NPM comes with a few alerts pre-installed and it also allows administrators to configure custom alerts for specific events they would like monitored.
SolarWinds are kind enough to offer a free 30 day evaluation of the full product. I downloaded this and set it up in a virtual environment to demonstrate how alerts can be used to gain access to the SolarWinds server and pivot around a target network.
1. Login to NPM’s web console
First thing’s first, login to the web console. After installation, mine could be found at:
http://IP-ADDRESS:8787/Orion/Login.aspx
- Default credentials; username ‘admin’ with a blank password.
2. Alerts management
Next, we head to the alerts management page which you can get to by clicking on the ‘Alerts’ menu and then selecting ‘Manage Alerts’.
3. Create a new alert or duplicate and edit an existing one
You have 2 options here; you can choose to create a new alert or duplicate and edit an existing one.
I’ve found that duplicating and editing an existing one is a lot easier since you won’t have to waste any time configuring a new alert with options you won’t use. Just make sure you pick an alert to edit that’s likely to be assigned to a Windows host. If you can’t find one, just create a new one.
Alternatively, you can navigate directly to a monitored Windows host from the Nodes Summary tab and add a new alert from there.
NOTE: Don’t worry about messing around with NPM’s configuration if you’re doing this in a client’s production environment, you won’t have to save any of the alerts you create/edit.
4. Configure a new alert or jump straight to trigger actions
If you chose to create a new alert, you’ll have to configure a few requirements before getting to the ‘Trigger Actions’ menu which is where the real fun is.
If you chose to duplicate and edit an existing alert you can jump straight to the ‘Trigger Actions’ menu by clicking on it since the requirements have already been filled in for you.
5. Add a new trigger action
Trigger actions are simply what NPM should do when the event/condition in question occurs. This is where the abuse begins.
Network monitoring solutions used to be pretty simple programs; they monitored network devices and sent admins via email when an event occurred.
I’m pretty sure that the most popular kind of trigger action is still emailing an admin, but as network monitoring solutions have evolved, the trigger actions they offer to administrators have developed far beyond the traditional ‘email an admin’ alert.
Click on ‘Add Action’ to see what I mean.
Mo features, Mo problems.
Select the ‘Execute an External Program’ trigger action (you can see where this is going, can’t you?).
6. Configure trigger action
Once you’ve selected the trigger action, you’ll have to configure it. You’ll need some malicious commands to execute. What command to use is completely up to you, but since it’s a Windows box, you’ll probably want to use Powershell to get yourself a remote shell on the underlying OS.
I setup an Empire listener on my attacker box and generated a Powershell launcher to use as the trigger action command/program.
All you have to do now is paste your command into the ‘Network path to external program’ text area. It doesn’t seem to have any character limits, so the entire Powershell launcher string should fit comfortably.
The name of the action can be whatever you choose. Hit ‘Save’ once you’re done.
7. Simulate trigger action
This is why I said you don’t have to worry about messing around with a client’s NPM configuration in a live environment; you won’t actually have to save the alert and wait for an event to occur for your trigger action to be executed. NPM has a handy little simulation feature for all trigger actions so admins can test if their trigger actions work like they’re supposed to before committing them to NPM’s configuration.
We’re going to use this feature to execute our command on the server.
You can actually select multiple hosts to run the simulation on. I had only setup one host in my virtual lab, but a NPM server in a production environment is highly likely to have more targets to choose from.
Once you’re done choosing targets, just hit ‘Execute’.
8. Pop shells
The shells come in with NT AUTHORITY\SYSTEM rights. No better feeling, right?
At first, the SYSTEM level access surprised me until I realised that every single SolarWinds process on the NPM server runs as SYSTEM.
NOTE: NPM allows admins to create users and assign them very specific rights. I created a new user and stripped them of every right but managing alerts and repeated the steps above using their account. So long as a user has the ‘Alert Mgmt’ right, their access can be abused to gain SYSTEM level access on the NPM server.
Conclusion
I wouldn’t be surprised if there are a lot more ways to abuse NPM administration to get OS level access but I didn’t find anything online about this specific method so I figured I’d blog about it.
I’d be more than happy to hear about more techniques so feel free to reach out if you know of any. Happy hunting.
