Microsoft has reconfirmed that the “Solorigate” advanced persistent threat attackers saw some of its source code, although “only a few individual files were viewed.”
The company had indicated last month that some of its source code was viewed, although not modified, by the attackers who are thought to be part of a nation-state espionage group. Microsoft’s software development best practices assures that so-called “secrets” (passwords) aren’t put into its code, so it doesn’t consider viewing the code to be a general software security risk.
Source Code Viewed
Last week, Microsoft was more specific about what was viewed. Source code was viewed for the following software components:
- a small subset of Azure components (subsets of service, security, identity)
- a small subset of Intune components
- a small subset of Exchange components
The attackers were searching for secrets, but Microsoft confirmed they weren’t in the code.
Microsoft also asserted that its systems weren’t used to attack other organizations, which was an early claim when the Solorigate breaches were initially disclosed.
The investigation also found no indications that our systems at Microsoft were used to attack others. Because of our defense-in-depth protections, the actor was also not able to gain access to privileged credentials or leverage the SAML techniques against our corporate domains.
The “SAML techniques” phrase refer to the use of a malignant dynamic link library file inserted in SolarWinds Orion management software and subsequently leveraged to provide attacker access to credentials. The attackers apparently also tapped older software with too many permissions and leveraged Active Directory Federation Services used in computing environments in order to gain access to Microsoft’s services used in the victims’ environments. The aim of these complex maneuvers was to tap Exchange Online e-mails.
Best Practices Advice
In a follow-up announcement, Vasu Jakkal, Microsoft’s corporate vice president for compliance and security, offered some “lessons learned” customer guidance. She also urged organizations to shift to a “zero-trust posture,” where internal network traffic gets verified prior to granting access.
Jakkal specifically mentioned the problem of old and insecure software being leveraged by attackers to gain access to cloud services using on-premises identity systems:
Gaps in protecting identities (or user credentials), like weak passwords or lack of multifactor authentication, are opportunities for an actor to find their way into a system, elevate their status, and move laterally across the environments targeting email, source code, critical databases and more. We witnessed this in Solorigate when abandoned app accounts with no multi-factor authentication were used to access cloud administrative settings with high privilege.
This method was earlier confirmed by software security firm Malwarebytes. It, as well as Microsoft, was a victim of the widespread attacks, which targeted software companies and government agencies.
Another recommendation mentioned by Jakkal is for organizations to adopt cloud-based identity and access services, instead of relying on on-premises solutions. It was an almost implicit statement against using federation with Active Directory Federation Services (a Windows Server role).
Here’s how Jakkal put it:
One of the things our customers should consider is managing identity and access from the cloud. When you rely on on-premises services, like authentication server, it is up to a customer to protect their identity infrastructure. With a cloud identity, like Azure Active Directory, we protect the identity infrastructure from the cloud. Our cloud-scale machine learning systems reason over trillions of signals in real time. So, we can detect and remediate attacks that nobody else can see.
Lastly, Jakkal urged organizations to collaborate and share information to better respond to attacks. She recommended joining the Microsoft Security and Compliance Tech Community discussion forums.
Reference: https://redmondmag.com/articles/2021/02/22/solorigate-attackers-saw-microsoft-code.aspx
