Troubleshooting Suspicious Outbound Traffic from a SolarWinds Platform Server

4/20/2026 11:24 AM

4/20/2026 3:48 PM

When perimeter devices, proxies, or security tools flag a SolarWinds Platform server as a source of unexpected outbound traffic, it is critical to quickly determine whether the connections are legitimate SolarWinds activity, a misconfiguration, or caused by unrelated software running on the same Windows host. Learn about initial triage using firewall data, mapping connections to Windows processes, and verifying whether those processes belong to known SolarWinds services. Check SolarWinds Platform configuration and logs for references to the destination, optionally validate behavior with packet captures, and finally leverage SolarWinds products (NTA, NetPath, SAM, Log Analyzer/SEM) to profile and monitor the traffic.

This provides a repeatable method to distinguish SolarWinds Platform‑generated traffic from third‑party activity and to know when to engage SolarWinds Support with the right evidence.

Orion Platform

Your network/security team noticed outbound packets from SolarWinds Server to external IP's that may or may not be suspicious.

 

Scope / Applies To

• SolarWinds Platform (all recent supported versions)

• All SolarWinds Platform roles:

  • Primary polling engine

  • Additional polling engines (APEs)

  • Additional web servers (AWS)

• Windows Server OS hosting SolarWinds Platform

---

1. Initial Triage – Define “Suspicious” and Collect Evidence

Before making changes on the SolarWinds Platform server, clearly define what is “suspicious”:

• Destination IP / FQDN

  • Unknown internet IP ranges

  • Domains not used by your organization, vendors, or known integrations

• Ports & protocols (see SolarWinds Port Requirements for genuine ports)

  • Unusual outbound ports for a SolarWinds Platform server (for example, random high ports to the internet)

  • Non‑standard HTTPS destinations

• Volume & timing

  • Large, continuous upload/ download

  • Traffic occurring outside normal maintenance or polling windows

1.1 Collect baseline information

From your firewall / proxy / IDS logs, capture:

• Source IP: SolarWinds Platform server IP

• Destination IP / FQDN

• Destination port and protocol

• Start / end time

• Approximate bandwidth

This information will be used in later steps to map traffic to processes and SolarWinds Platform components.

---

2. Identify Which Windows Process Owns the Connections

The most important first step is to map the connection to a Windows process, then decide if that process is part of SolarWinds.

2.1 Use Resource Monitor (built‑in)

On the SolarWinds Platform server:

1. Open Resource Monitor:
   Start → type resmon → Enter.

2. Go to Network tab.

3. Under Processes with Network Activity, locate your SolarWinds Platform server’s process sending traffic:

   • Sort by Send (B/sec) or Receive (B/sec).

   • Note Process name, PID, and associated Remote Address / Port in Network Activity pane.

4. Verify if the remote address and port match the “suspicious” connection seen on the firewall.

2.2 Use netstat / PowerShell (CLI)

Run from an elevated PowerShell or CMD prompt:

# Active TCP connections with owning process ID
netstat -ano | findstr :443

# Or using PowerShell for better filtering
Get-NetTCPConnection |
  Where-Object { $_.RemotePort -eq 443 -and $_.State -eq 'Established' } |
  Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess

Then map the PID to a process:

Get-Process -Id <PID> | Select-Object Id,ProcessName,Path

Repeat for the specific remote IP/port combination found in your firewall logs.

2.3 Use TCPView (Sysinternals) – Optional

If allowed by your security policy:

1. Download and run TCPView (Sysinternals) on the SolarWinds Platform server.

2. Sort by Remote Address or Process.

3. Identify:

   • Process name / PID

   • Remote address / port

   • Connection state

---

3. Determine if the Process Is Part of the SolarWinds Platform

Compare the identified process to known SolarWinds Platform‑related services and executables.

3.1 Common SolarWinds Platform services and executables

Typical SolarWinds services (service name → process) include:

• SolarWinds Orion Module Engine → SolarWinds.BusinessLayerHost.exe

• SolarWinds Information Service → SWISService.exe or SolarWinds.InformationService.Service.exe

• SolarWinds Job Engine V2 → SWJobEngineSvc2.exe

• SolarWinds Collector Service → SolarWinds.Collector.Service.exe

• SolarWinds Alerting Service V2 → SWAlertingServiceV2.exe

• SolarWinds Syslog Service → SyslogService.exe

• SolarWinds Trap Service → TrapService.exe

• SolarWinds Platform Web site (IIS) → w3wp.exe (with application pool named SolarWindsOrionAppPool)

If the traffic is associated with one of these executables, it is likely SolarWinds Platform‑related. If it is associated with other processes (for example, chrome.exe, powershell.exe, 3rd‑party AV / backup agents, remote control tools), the traffic is likely third‑party.

3.2 Confirm service origin

For any suspect PID:

Get-CimInstance Win32_Service | Where-Object { $_.ProcessId -eq <PID> } |
  Select-Object Name,DisplayName,PathName,StartMode,State

• If Name / DisplayName clearly reference SolarWinds, treat it as a SolarWinds component.

• If it references another vendor (AV, backup, RMM tools), treat it as third‑party and follow your internal security procedures.

---

4. Check If the Destination Is Expected for the SolarWinds Platform

Once you know which process owns the connection, assess whether the destination is expected or misconfigured.

Typical legitimate outbound communications for the SolarWinds Platform include (non‑exhaustive):

• SQL Server hosting the SolarWinds Platform database (TCP 1433 or custom) – internal only.

• SolarWinds Platform Agents (TCP 5671/17778 depending on config) – usually inbound to the SolarWinds Platform, but may appear as traffic between polling engine and agent hosts.

• SMTP server for alert notifications (TCP 25/587/465 to internal or external mail relay).

• Syslog / Trap forwarding from the SolarWinds Platform server to other collectors or SIEM.

• Cloud / integration endpoints you explicitly configured:

  • Webhooks for alert actions

  • Cloud monitoring APIs

  • Service desk integrations

4.1 Correlate with configured SolarWinds Platform features

On the SolarWinds Platform Web Console:

1. Review Settings → All Settings for the following:

   • Alert actions (email, webhooks, scripts, external programs)

   • Syslog / Trap forwarding rules

   • Integration modules (Service Desk, Cloud Pollers, etc.)

2. Check if any configured actions or integrations reference the same destination IP/FQDN as the suspicious traffic.

3. If yes, the traffic may be legitimate but mis‑documented; adjust your internal runbooks.

4. If not, continue to deeper analysis.

---

5. Inspect SolarWinds Logs for Activity to the Destination

SolarWinds logs can often confirm whether SolarWinds Platform components are actively connecting to a given target.

5.1 Locate logs

By default, most SolarWinds Platform logs are in:

• C:\ProgramData\SolarWinds\Logs\

Key logs to inspect:

• Orion\BusinessLayerHost*.log

• Orion\OrionWeb*.log

• Orion\InformationService*.log

• NetFlow\NetFlowService*.log (if NTA installed)

• OLM\SyslogService*.log

• OLM\TrapService*.log

5.2 Search for the suspicious destination

Use Select-String from PowerShell to search for IP/FQDN:

$SearchTerm = "suspicious.example.com" # or IP
Get-ChildItem "C:\ProgramData\SolarWinds\Logs" -Recurse -Filter *.log |
  Select-String -Pattern $SearchTerm |
  Select-Object Path,LineNumber,Line

• If you see repeated references to the destination in SolarWinds logs, especially around the same timestamps as the firewall events, you can reasonably conclude that the SolarWinds Platform is initiating or using that destination.

• If there are no hits in SolarWinds Platform logs, and the owning process is not SolarWinds‑related, then the traffic is very likely third‑party.

---

6. Advanced Validation – Packet Capture (Optional)

If allowed by your security policy, perform a short, targeted packet capture on the SolarWinds Platform server to inspect payloads (e.g., for HTTP User-Agent, SNI, or application signatures).

6.1 Using pktmon (built‑in on modern Windows OS)

pktmon filter remove
pktmon filter add -t tcp -p 443
pktmon start --etw -m real-time

Or use Wireshark on the SolarWinds Platform server or on an intermediate device to:

• Confirm which process / port initiates the traffic.

• Inspect TLS Client Hello / SNI fields to identify the intended hostname.

• Inspect HTTP headers if traffic is unencrypted.

Only capture what is necessary and follow your company’s data handling policies.

---

7. Using SolarWinds Products to Triage Suspicious Outbound Traffic

Several SolarWinds modules can help you detect, profile, and monitor outbound traffic from the SolarWinds Platform server and validate root cause.

7.1 NetFlow Traffic Analyzer (NTA)

If you have NTA and your firewall/router exports flows:

• Ensure your perimeter device is sending NetFlow/sFlow/jFlow/IPFIX to the SolarWinds Platform.

• In the NTA UI:

  1. Go to NetFlow → Top Talkers / Conversation views.

  2. Filter by Source IP = SolarWinds Platform server IP.

  3. Identify:

     • Remote endpoints (IP/FQDN)

     • Ports and protocols

     • Traffic volume and time pattern

Use this to:

• Confirm whether the SolarWinds Platform server is truly the source of volume flagged by your firewall.

• Identify whether the conversations are short (control API calls) or long‑running (possible data exfiltration or backup traffic).

7.2 NetPath (NPM)

If you have NetPath (NPM feature):

1. Create a NetPath Service with:

   • Source: SolarWinds Platform server (or another relevant node)

   • Destination: suspicious FQDN or IP (if reachable)

2. Review:

   • Path taken (hops)

   • Latency and potential network middleboxes

3. Use NetPath to:

   • Confirm whether the destination is reachable and how the traffic leaves your network.

   • Identify whether security devices in the path are affecting or shaping the traffic.

7.3 Server & Application Monitor (SAM)

With SAM, you can monitor process‑level resource usage on the SolarWinds Platform server:

• Apply a Windows Server template or a Windows Process Monitor template to the SolarWinds Platform node.

• Track:

  • Specific process CPU and memory

  • Network I/O counters, if enabled

• Use PerfStack to correlate:

  • Spikes in process network usage

  • With specific alerts, jobs, or user activity in the SolarWinds Platform.

This helps verify whether a specific SolarWinds service or third‑party process is responsible for the outbound spikes.

7.4 Log Analyzer (LA) / Security Event Manager (SEM)

If you have Log Analyzer or SEM:

• Forward Windows Security / Application logs and Syslog from the SolarWinds Platform server.

• Create filters or rules for:

  • New outbound connections to unusual destinations

  • Process creation events for unknown executables

• Use these to correlate process start events with new network flows.

---

8. Decision Matrix – Is It SolarWinds Platform or Third‑Party?

Use the table below as a quick decision guide:

Question	If YES →	If NO →
Does the connection’s PID belong to a known SolarWinds Platform service / IIS app pool?	Likely SolarWinds‑generated traffic. Verify logs and configuration tied to that service.	Proceed to check if process is third‑party.
Does the destination match any configured SolarWinds Platform alert actions, integrations, or forwarding rules?	Expected but possibly undocumented traffic. Ensure change records and security approvals exist.	More likely non‑SolarWinds Platform or misconfigured.
Do SolarWinds Platform logs reference the destination IP/FQDN in the same timeframe?	Confirms SolarWinds Platform involvement. Analyze feature / module responsible.	Strong indication traffic is not from SolarWinds Platform.
Does NTA show SolarWinds Platform server as a significant “top talker” to that destination?	Confirms SolarWinds Platform IP as source. Map to processes and SolarWinds Platform features.	Suspect firewall interpretation or NAT mapping.
Is the owning process clearly a 3rd‑party agent/tool?	Treat as third‑party; follow security playbook.	Continue deeper analysis / packet capture.

---

9. When to Engage SolarWinds Support

If, after following the above steps, you still suspect that outbound traffic might be related to the SolarWinds Platform but cannot identify the root cause:

Collect the following before opening a SolarWinds Support case:

• Precise timestamps and firewall / proxy logs for the suspicious flows.

• Process and PID mapping output:

  • Get-NetTCPConnection / netstat excerpts

  • Get-Process / Get-CimInstance Win32_Service output for the suspect PID

• Short packet capture (if permitted) showing:

  • Initial handshake (Client Hello / SNI)

  • Any clear text HTTP headers or protocol identifiers

• Full SolarWinds Platform diagnostics:

  • Run SolarWinds Platform Diagnostics on the affected server and upload the resulting archive.

Provide all of the above with a clear description of:

• What your security tools flagged

• Why you believe the SolarWinds Platform may be involved

• What you have already ruled out

This will significantly speed up verification of whether the traffic is truly generated by SolarWinds components or not.

---

Summary

• Always start by mapping network connections to Windows processes, then decide whether those processes are SolarWinds or third‑party.

• Use SolarWinds Platform configuration and logs to validate whether a given destination is expected.

• Leverage NTA, NetPath, SAM, and logging tools (LA/SEM) to get visibility into flows and process behavior.

• Escalate to SolarWinds Support with detailed evidence if you cannot conclusively determine the source within your own environment.