The Endgame for SolarWinds Attack Was Victim Cloud Data - Binary Defense

Threat Watch

Threat Watch The Endgame for SolarWinds Attack Was Victim Cloud Data

The Endgame for SolarWinds Attack Was Victim Cloud Data

In a recent blog post, Microsoft revealed that the end goal for the attackers associated with the SolarWinds breach was obtaining access to client cloud data. The attackers started with compromising a DLL in official Solar Winds Orion updates to enable backdoor access to infected devices across multiple domains. The threat actors selected high-value target organizations that they had backdoor access to, and used that access to steal local and domain credentials of high-value users and move laterally. Once these users are found, the attackers created valid SAML tokens by either stealing the SAML signing certificate or modifying the existing federation trust. Lastly, the attacker created tokens that were used to access cloud resources, exfiltrate emails, and maintain persistence.

ANALYST NOTES

As more information about a potential end goal comes to light, recent guidance concerning protecting SAML tokens from both the NSA and Microsoft becomes a higher priority. Gaining a clear picture of who has authorization to different cloud resources is as important as on-premise resources. Managing authorized user activity, following the recommended guidance around SAML, and building detections for anomalous user activity can enable an organization to protect themselves better. One way for threat hunters to detect “Golden SAML” attacks is to compare the security events from the Active Directory Federation Server (ADFS) event ID 1200 and 1202 to the corresponding cloud service provider logs, and note any discrepancies in which the cloud service provider showed a federated authentication, but there was no matching event 1200 and 1202 from the ADFS. That could indicate that a SAML request was forged by an attacker, rather than issued by the ADFS after a successful authentication. Another method that attackers can use to impersonate users is to add a new trusted ADFS domain. To monitor that, look for event ID 307 in the ADFS logs to find federation service configuration change events, and correlate with event ID 510 using the same instance ID to find “Configuration: Type: IssuanceAuthority” where the domain listed as the new authority is unauthorized. Resources for further learning are listed below.

Resources and References:
Using Microsoft 365 Defender to protect against Solorigate
https://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/

NSA warns of hackers forging cloud authentication information
https://www.bleepingcomputer.com/news/security/nsa-warns-of-hackers-forging-cloud-authentication-information/

Detecting Abuse of Authentication Mechanisms (NSA)
https://media.defense.gov/2020/Dec/17/2002554125/-1/-1/0/AUTHENTICATION_MECHANISMS_CSA_U_OO_198854_20.PDF