InfoSec-Specific Executive Development for
CISOs and Aspiring Security Leaders.
Live Faculty-led instruction and interactive
labs to build you and your team's InfoSec skills
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.
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:
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:
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:
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.
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:
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
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.
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
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.
December 6, 2022
By IANS Research
Improve your attack surface management plan using 9 steps to mitigate risk and strengthen enterprise security posture.
December 1, 2022
By IANS Faculty
Improve your vendor management program using six focus areas to benchmark program maturity and identify key pitfalls to avoid.
November 29, 2022
Learn how to integrate IT, OT and physical security programs to reduce risk, improve efficiency and streamline processes across the organization.