On December 8, FireEye reported that it had been compromised in a sophisticated supply chain attack: more specifically through the SolarWinds Orion IT monitoring and management software. The attackers leveraged business software updates in order to distribute a malware named SUNBURST, and then used this foothold in the organization to contact their Command & Control (C&C) infrastructure, move laterally using different legitimate credentials, and steal data from the network.
Fortunately, there is already a hotfix released in order to patch the affected systems. Network admins in every company need to quickly identify these servers, isolate them from network, and patch them. Perhaps you work on a team that has purposefully built solutions by combining different tools to manage and secure your infrastructure. Defense in depth, anyone? Have you ever installed a “free trial” on a device or spun up a virtual machine (VM) for quick testing and then forgotten about it? Or did a previous network administrator ever deploy a server without really documenting or letting leaders know it exists in the network? You cannot patch what you don’t know exists in your network.
For further research about the attack, you can consult this article.
Discovering SolarWinds Orion servers and other NMS within your network
Cisco® Secure Network Analytics (formerly Stealthwatch) and its software-as-a-service (SaaS) version, Secure Cloud Analytics (formerly Stealthwatch Cloud) can help you uncover rogue or forgotten servers in your network that, if left unmonitored, could leave an open doorway for attackers. SolarWinds Orion servers, like many Network Management Stations (NMS), monitor the health and performance of the network in real time, using a combination of tools and protocols. The most common approach is to do SNMP polling from the NMS to all infrastructure devices in your network. It is typical to see SNMP notification from these infrastructure devices sent to the NMS servers. It’s this behavior that we are going to target when looking for them on the network.
In Secure Network Analytics, you can perform a Top Host search in order to find all the servers that have been using SNMP during the last 30 days.
“You cannot patch what you don’t know exists in your network.”
In Secure Cloud Analytics, you can look for the following indicators on your network, related to SolarWinds Orion servers:
- The “New SNMP Sweep” alert will have fired if a server has been attempting to reach a large number of hosts using SNMP.
- The “IP scanner” observation triggers when a device is seen on the network scanning a large number of entities.
Once you have identified the devices using SNMP polling in your network, you can investigate all the servers related to them, as they are potentially SolarWinds Orion servers.
Detecting malicious behaviors
If you were able to find any compromised servers in the network using the above methods, it’s imperative that you patch them with the designated hotfix. After that, the next logical step is to assess if any malicious or suspicious activity has already been taking place in your network. There are a variety of common patterns that have been spotted in SUNBURST variants. If you were monitoring your network with Secure Network Analytics or Secure Cloud Analytics before the attack started, there should have been some signs of suspicious activity that would have surfaced in the form of alerts.
Both products are capable of detecting a range of suspicious activities that are commonly seen in an advanced cyber attack with the purpose of stealing data, such as C&C connections, lateral movement, and data exfiltration. As a result, you will be able to detect other global campaigns, even before they make it to the news, and the IoCs are shared.
These are the alerts you should pay special attention to, in relation to the SolarWinds Orion compromise. You can search for them in your deployment in the last few months:
Alerts in Secure Network Analytics:
- “Exfiltration” alerts, such as “Suspect Data Loss” will trigger if there is an abnormal amount of data being transferred from an inside host to the outside. The ultimate goal in many instances of the SUNBURST attack has been the appropriation of highly valuable data.
- The “High SMB Peers” alert will be a sign of a compromised host, as once the attacker has gained access to the network with legitimate but stolen credentials, it will try to move to other hosts.
Alerts and Observations in Secure Cloud Analytics:
In your portal, review your alert priorities page to ensure you have the desired alerts enabled and appropriately prioritized. The alerts and observations below can help you identify a variety of tactics used by advanced attackers during this campaign.
- The “Abnormal User” alert will detect users’ abnormal activity like a user session that was created on an endpoint that does not normally see sessions with this user. This alert uses the Session Opened observation and requires an integration with either AWS, Sumo Logic, or Active Directory.
- “Domain Generation Algorithm Successful Lookup” is an alert that will be seen when a device succeeded in resolving an algorithmically generated domain (for example, rgkte-hdvj.cc) to an IP address. As Talos explains in its analysis, “The backdoor identifies its command and control (C2) server using a domain-generated algorithm (DGA) to construct and resolve a subdomain of avsvmcloud[.]com.”
“Potential Data Exfiltration” will trigger an alert when a device downloaded data from an internal device that it doesn’t communicate with regularly. Shortly after that, the device uploaded a similar amount of data to an external device.
Additional proactive actions for further protection
Now that you have searched for and identified potentially compromised servers and had a look at detections that alert on malicious behavior in the network that might be associated with the attack, you can go ahead and define a set of actions that will further protect your organization, and also allow for automated response.
It is always recommended to actively segment your network. As a network administrator, you know better than anyone who should be talking with who. In order to do this, you can use Custom Security Events (CSE) in Secure Network Analytics to allow communications from your SolarWinds servers only to legitimate peers. Additionally, you can define an Identity Services Engine (ISE) Adaptive Network Control (ANC) policy in order to quarantine servers that are communicating with peers who are not allowed. You will also be able to leverage the Internal Communications Watchlist in Secure Cloud Analytics in order to detect lateral movement.
In this article, we have identified how to look for compromised SolarWinds Orion servers that might be installed in the network but not documented. We have also reviewed which signs of compromise in the form of alerts you can look for in both Secure Network Analytics and Secure Cloud Analytics as well as ways of responding to this threat and proactively protecting your network further, in the event of other cyber attacks. In order to get a more step-by-step guidance, you can read the full “how to” article.