SolarWinds attack continues to grow in impact. This piece focuses primarily on the related attacks on Microsoft 365 (aka Dark Halo). The M365 attacks were not due to any sort of software or system vulnerability (beyond the initial SolarWinds vector),
but instead involve obscure configurations within M365 and associated single-sign-on (SSO) systems the attackers used to create privileged user sessions within M365. Once in, they then configured M365 features to exfiltrate data in a way that bypasses
most enterprises’ data loss prevention (DLP) systems and processes.
What Is the SolarWinds/Dark Halo Breach?
SolarWinds compromise is just the tip of the iceberg. We now know the same attackers (dubbed Dark Halo by security research firm Volexity) were able to leverage the access they gained through the compromised Orion software to gain privileged access to
enterprise IT infrastructure, and even bypass single sign-on (SSO) components to attack Microsoft 365 (M365) and spy on victims’ internal communications. In addition, new reporting suggests VMware vulnerabilities were also exploited to gain
access to SSO system components as well.
It is important to note that while the SolarWinds compromise is a traditional software supply chain attack and VMware exploit is a traditional enterprise software exploit, the techniques used to gain access to M365 and the M365 configurations are not
traditional technology exploits. They are merely configurations of SSO and M365 platform components not monitored by most IT security teams. By configuring SSO applications in a novel way, the attackers were able to gain complete access to privileged
and standard user identities. The M365 settings also enabled the attackers to use legacy protocols to exfiltrate massive amounts of data without triggering significant security team investigations for months.
In its Dec. 17 Alert AA20-353A, the Cybersecurity and Infrastructure Security Agency (CISA) clearly states this attack could be used against ANY SaaS platform. Abuse of authentication mechanisms has been shown to be the tactic, technique and procedure
(TTP) that scaled this attack beyond anything seen in many years (see Figure 1).
After analysis of the disclosures and investigations, we recommend organizations:
- Reset SSO platform configurations to re-establish integrity between SSO-reliant software-as-a-service (SaaS) platforms and on-premises directories.
- Re-evaluate M365 configurations and disable legacy data transfer protocols.
- Enhance SSO and M365 logging configurations and forward log data for analysis by security operations center (SOC) teams.
Restore SSO Platform Configuration Integrity
Evidence suggests the attackers effectively bypassed multifactor authentication (MFA) policies by stealing secrets the identity provider and application server were relying on for identity authentication integrity. The attackers gained access to data
stored within M365 using this technique, making it critical for impacted organizations to reset the identity provider connections associated with M365 (and any other critical enterprise SaaS platform). When configuring an SSO platform, two keys drive
session integrity between the SSO identity provider (in the case of Dark Halo, Cisco Duo) and the application server relying on authentication and authorization tokens provided by the SSO platform. In the case of Dark Halo, the attackers gained access
to the application server key for Exchange Online (EOL).
Based on the scale and scope of the Dark Halo activities disclosed to date, IANS strongly recommends enterprise security teams reset keys associated with their SSO platforms. To do this, disable currently configured SSO associations with M365 if using
third-party SSO identity providers, and then re-establish the configuration, thereby forcing the re-issuance of keys derived through the setup process. These documents explain how to configure Okta and Duo SSO for M365:
How to set up Okta for M365
How to set up Duo for M365
Organizations using Microsoft's own SSO technologies relying on Azure AD should begin with a complete privileged identity password and key reset process:
- Reset the MFA token, to break the link between AD and potentially cloned MFA soft tokens.
- Reset the password and monitor it to ensure only authorized users can successfully gain access to their accounts.
- Reset service account credentials. Once privileged human users’ identities have been reset, any service account associated with an impacted system should have its password and any derived keys (SSH, API tokens, etc.) reset. This is especially
important for all service accounts operating on identity provider directory service synchronization components.
Enable and Analyze M365 Auditing and Logging
Volexity’s blog post also outlined the IoCs they associated with attackers’ access
to M365 services, specifically those within EOL. The attackers used PowerShell commands to perform their reconnaissance work, and then configured specific users’ accounts to send data to attacker devices through legacy protocols.
Prior to January 2019, the default M365 settings for mailbox access logging were not configured to facilitate threat hunting for this Dark Halo activity. In a Microsoft article published last week, Microsoft says it has now enabled mailbox audit logging
for all organizations. However, calls with IANS customers last week revealed that some of those mailbox audit log settings were inconsistently applied, especially for users with EOL mailboxes configured before January 2019. To analyze the scale and
scope of any EOL compromise, it is critical to have those mailbox audit settings enabled. To get the current mailbox audit policy, run PowerShell with the following commands:
- Get-OrganizationConfig | Format-List AuditDisabled
- Get-Mailbox | Where-Object {$_.AuditEnabled -ne $True}
Security teams should then ensure the value is set to “False,” because “True” means auditing is disabled.
By default, M365 tenants only have access to the last 90 days of mailbox audit logs. It will be important to search through those logs to look for certain commands (outlined below). Even if your organization only has 90 days of logs, you may still discover
artifacts there. You can accomplish this through either manual export or the EOL Admin Center by selecting Compliance Management, Export mailbox audit logs.
Check Admin Auditing in Hybrid Exchange Environments
In addition to mailbox auditing, it is important to ensure admin auditing is correctly configured and those logs are retained for as long as possible, if they are not being forwarded to a SIEM.
This can be accomplished by running the following PowerShell command: Set-AdminAuditLogConfig
We recommend enabling “Verbose” logging and setting the retention value to 270 days.
Set Up Secondary Log Storage
If your organization has not yet configured a secondary log storage mechanism for M365 logs, now is the time to get that configured to protect against what will likely be an increased volume of M365 attacks using Dark Halo-like techniques. This can be
a complex and costly process, depending on your SIEM. The following links explain how to integrate M365 audit logging into some common SIEMs:
Check EOL Configuration Settings
Dark Halo attackers used some of the most obscure and least monitored protocols within EOL to exfiltrate data from target organizations’ M365 tenants. They accomplished this by associating an unauthorized device to a target’s mailbox and synchronizing
mail items to bypass data loss prevention (DLP) controls.
According to Volexity’s blog, the following PowerShell commands were executed against target M365 tenants and their hybrid on-prem Exchange infrastructure (the PowerShell commands outlined below are grouped by type of Exchange implementation and
attacker motivation):
- M365 attacker discovery/reconnaissance:
- Get-AcceptedDomain
- Get-CASMailbox
- Get-Mailbox
- Get-ManagementRoleAssignment
- Get-OrganizationConfig
- On-prem Exchange discovery/reconnaissance:
- Get-OwaVirtualDirectory
- Get-WebServicesVirtualDirectory
- M365 exfiltration:
- On-prem Exchange exfiltration:
- On-prem Exchange cleanup:
- Remove-MailboxExportRequest
Unless mailbox audit logging was enabled for your organization in March, many of these commands will not be detected in the standard audit or mailbox logs for EOL as having been run against your M365 tenant.
Responding to the SolarWinds/Dark Halo Breach
We recommend responding to the SolarWinds/Dark Halo breach by keeping the entire context within view and be disciplined enough to avoid single-system-exploit myopia. Organizations should prioritize everything outlined above within a larger project plan
that includes:
- Removal of SolarWinds technology from your organization.
- Remediation of all VMware vulnerabilities.
- Resetting of all privileged user accounts (interactive and services) associated with identity provider access and configuration.
- Resetting of all identity provider trust links, API keys and secrets.
- Comprehensive review of all API secrets (beyond just identity providers).
- Enabling robust M365 auditing as outlined above.
- Hunting for EOL PowerShell evidence indicating attacker access to M365 services.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.