News

Microsoft Offers Security Advice After 'Solorigate' Attacks

• By Kurt Mackie
• 01/05/2021

Microsoft last month described security measures for IT pros to consider in the wake of the SolarWinds Orion-based software attack.

Attacks using SolarWinds' Orion management software were discovered last month. They appeared to mostly target U.S. governmental agencies in a spying operation.

Microsoft is keeping a compendium of tips for discovering such attacks at its Microsoft Security Response Center's Solorigate page, last updated on Dec. 31. "Solorigate" is Microsoft's one-word descriptor for the initial software implant in certain SolarWinds Orion management software versions that was used to set the stage for a "poisoned" Dynamic Link Library (DLL) file that facilitated the attacks.

The tainted Orion software was ultimately used by attackers to issue forged Security Assertion Markup Language (SAML) tokens and gain access privileges. Press accounts, like this one, have suggested that the sophisticated attack originated with some nation-state actor, with fingers pointing to Russia.

SolarWinds, in an updated security advisory, described the initial software implant, known as a supply-chain compromise, as "Sunburst." It was added during the software update process. Another piece of software, called "Supernova," gets added to the servers of victims to act as a command-and-control nexus. Supernova is used to deliver the attacker's malware, per the advisory's description.

Microsoft Victimized
It turns out that Microsoft itself was a victim of SolarWinds-based attack. Attackers used the exploit to view, but not modify, Microsoft's source code, according to an internal Microsoft investigation. However, Microsoft claimed that its best practices were good enough to account for such source-code exposures. Microsoft has an "inner source" software development approach that assumes a breach:

At Microsoft, we have an inner source approach -- the use of open source software development best practices and an open source-like culture -- to making source code viewable within Microsoft. This means we do not rely on the secrecy of source code for the security of products, and our threat models assume that attackers have knowledge of source code. So viewing source code isn't tied to elevation of risk.

A Reuters press account suggested that Microsoft software was compromised and used in the attacks via breaches of its Office reseller partners, citing unnamed sources. Microsoft countered that its software wasn't compromised.

Microsoft joined official investigations of the attack, which mostly (44 percent) targeted governmental IT departments. In a December blog post, Microsoft President Brad Smith called for greater government and software company collaboration to address such threats. He also rued the existence of so-called "mercenary" software companies, such as Israel-based Pegasus, that make malware for governments to spy on citizens and others. This view was echoed by Tom Burt, Microsoft's corporate vice president of customer security and trust, in another Microsoft announcement.

Microsoft notified "more than 40 customers" that were targeted by the compromised SolarWinds Orion software, with about 80 percent of them being located in the United States, Smith indicated. SolarWinds had estimated that "fewer than 18,000" of its customers had used the tainted Orion software versions.

Forged SAML Token Detection
The SolarWinds Orion compromise seems to have resulted in a series of perhaps useful articles from Microsoft on how to hunt down such security breaches. The U.S. National Security Agency also issued advice on detecting "abuse of authentication mechanisms."

Articles outlining the steps to take were mostly written by Alex Weinert, director of identity security at Microsoft. There's also advice from the Microsoft Detection and Response Team in this article, plus a description of how to use Microsoft Defender for the purpose in this security blog post. Tips on using Azure Sentinel to detect such attacks can be found in this article.

Weinert indicated in one article on the Active Directory identity verification process that resources using SAML tokens should be considered a possible risk. This issue is not software vendor-specific, he explained:

Any resource which trusts a customer's compromised SAML token signing certificate should be considered at risk. The SAML attack is not specific to any particular identity system or identity vendor you use. It impacts any vendor's on-premises or cloud identity system, and any resources that depend on industry-standard SAML identity federation.

To check for forged tokens, Microsoft recommended looking at logs for tokens having long expiration times as a clue. IT pros also can check for tokens that are used from "outside normal user locations." Weinert offered a bunch more tips. IT pros should "roll all SAML token signing certificates" and "consider reducing your reliance [on] on prem SAML trust where possible," among other measures.

Organizations can also check if illegitimate configuration changes have been made to the SAML service provider as an indicator of compromise. It'll show up in logs as an "anomalous administrative session associated with modification of federation trust relationships," he explained.

Sometimes attackers add administrative credentials to existing applications to "obfuscate their activity." IT pros can check for this technique by looking for an "anomalous administrative session associated with modification of federation trust relationships," as well as "unexpected service principals added to privileged roles in cloud environments."

For organizations using the Azure AD service, Weinert pointed to a workbook for use with the Azure Monitor solution. It can be used to find "indicators of compromise," as described in this article.

Microsoft 365 Security Tips
Weinert also outlined tips to protect Microsoft 365 environments in this article. So-called "hybrid" environments (using a combination of on-premises servers and services) can have vulnerable on-premises components, he contended.

"In hybrid deployments that connect on-premises infrastructure to Microsoft 365, many organizations delegate trust to on-premises components for critical authentication and directory object state management decisions," Weinert wrote. "Unfortunately, if the on-premises environment is compromised, these trust relationships result in attackers' opportunities to compromise your Microsoft 365 environment."

Weinert recommended using the Azure AD service and role-based access control to limit IT roles in scope and time. A least-privileged access approach should be taken. Credentials should not be stored in password vaults, he added.

Weinert also recommended using Azure AD with single sign-on instead of on-premises federation. If an organization needs to use legacy authentication methods, it can optimally be supported using Azure AD Application Proxy service, he indicated.

Another possible resource for detecting malicious activity for organizations using Microsoft 365 and Azure services is a newly released free tool, called "Sparrow," published by the Cybersecurity and Infrastructure Security Agency (CISA), which is part of the U.S. Department of Homeland Security. The tool isn't specifically associated with the Solorigate issue, though.