Chris Stegh / / Categories: Best Practices, Partner & Customer Updates, Security, azure sentinel

Detecting and Protecting Against Solorigate

This blog provides a summary of the Microsoft tools and guidance to detect and protect against the recent attacks embedded within SolarWinds monitoring agents.

Three major points are striking about this attack.

1) Attackers likely gained footholds in March, meaning they were in for ~270 days, well above the average "Mean Time to Identify" of ~191 days. The amount of data they were able to extract in that time is more than concerning.

2) This is another example of supply chain attacks, whereby the victim is indirectly attacked through a supplier's network/software. A similar concern is trending among Kubernetes container users, fearing adversaries may insert a backdoor into the kernel distribution and use it against many (many) users.

3) The stealthiness of the attack is noteworthy... the adversaries disguised their Command/Control protocols using Solarwinds’ actual traffic patterns/conventions. Intrusion detection systems look for anomalies, but there were none.

Now that the Indicators of Compromise are known, systems are able to ID the anomalous behavior.

Microsoft Defender Antivirus began blocking the known malicious SolarWinds binaries on 12/16. See Ensuring customers are protected from Solorigate - Microsoft Security

Azure Sentinel (SIEM) can hunt for existing compromises. See SolarWinds Post-Compromise Hunting with Azure Sentinel - Microsoft Tech Community. If you're ready to paste the KQL (Kusto Query Language) into your Sentinel, see

While there is no evidence of any breach in MSFT's environment, customers should still see the general "Recommended Defenses" at

Recommended Defenses include:

  1. Run up to date antivirus or EDR products that detect compromised SolarWinds libraries and potentially anomalous process behavior by these binaries. Consider disabling SolarWinds in your environment entirely until you are confident that you have a trustworthy build free of injected code. For more details consult SolarWinds’ Security Advisory.
  2. Block known C2 endpoints listed below in IOCs using your network infrastructure.
  3. Follow the best practices of your identity federation technology provider in securing your SAML token signing keys. Consider hardware security for your SAML token signing certificates if your identity federation technology provider supports it. Consult your identity federation technology provider for specifics. For Active Directory Federation Services, review Microsoft’s recommendations here: Best Practices for Securing ADFS
  4. Ensure that user accounts with administrative rights follow best practices, including use of privileged access workstations, JIT/JEA, and strong authentication. Reduce the number of users that are members of highly privileged Directory Roles, like Global Administrator, Application Administrator, and Cloud Application Administrator.
  5. Ensure that service accounts and service principals with administrative rights use high entropy secrets, like certificates, stored securely. Monitor for changes to secrets used for service accounts and service principals as part of your security monitoring program. Monitor for anomalous use of service accounts. Monitor your sign ins. Microsoft Azure AD indicates session anomalies, as does Microsoft Cloud App Security if in use.
  6. Reduce surface area by removing/disabling unused or unnecessary applications and service principals. Reduce permissions on active applications and service principals, especially application (AppOnly) permissions.
  7. See Secure your Azure AD identity infrastructure for more recommendations.

Work with our team of Cloud Computing Consultants who have done this so many times they know all of the “minefields” to prevent missteps.