Unlocking Lessons Learned From the 2023 Microsoft Exchange Online Intrusion

The cyberthreat landscape is evolving at an unforeseen pace as attacks increase in sophistication, velocity, and volume. One of the key threat vectors available to cyberattackers continues to be email. In 2023, the United States Department of State (DoS) and several other entities were the victims of a sophisticated email-based attack, the Microsoft Exchange Intrusion. The event sent shock waves across the cloud service provider (CSP) community and surfaced key vulnerabilities in cloud computing infrastructure and related identity-and email-based systems.

Following a complaint from a customer on 16 June 2023, Microsoft began investigating anomalous mail activity. These investigations revealed that on 15 May 2023, Storm-0558, a threat actor with espionage objectives, compromised and accessed the email accounts of 25 enterprises in the public cloud, including government departments and linked consumer accounts. This was possible due to a forged authentication token using an invalid Microsoft Service Account (MSA) key.¹

On 11 August 2023, the United States Cybersecurity and Infrastructure Security Agency’s Cyber Safety Review Board (CSRB) announced a review of this attack. The key objective was to gain an overview of practices in cloud-based identity and authentication systems affecting applicable CSPs and their clients.² Through comprehensive consultations with industry and government stakeholders, the CSRB released a report³ on 20 March 2024 outlining the sequence of events and recommendations for public consideration.

To strengthen organizational cybersecurity control environments, it is worth exploring insights and key considerations for implementing the CSRB’s post-Microsoft intrusion recommendations.

The Microsoft Exchange Intrusion and Related Events

On 15 June 2023, the US DoS detected suspicious email activity. The next day, security alarms were triggered by a special DoS rule known internally as “Big Yellow Taxi.” This rule helped analyze data from information events known as MailItemsAccessed. This logging capability is only available through Microsoft Purview Audit (Premium).⁴

The DoS contacted Microsoft and requested an investigation on 16 June 2023. Microsoft initiated an investigation for two weeks, the outcome of which proved that Storm-0558 was responsible for the suspicious activity in the DoS’s Outlook Web Access (OWA). Concurrently, Microsoft expanded its investigation and found 21 additional enterprises and 503 impacted accounts.⁵

The CSRB report outlines the sequence of events:

• Microsoft initially assumed that the threat actor had accessed the DoS’s accounts through typical phishing threat vectors.
• On 26 June 2023, Microsoft discovered that the threat actor had used OWA for suspicious activities using tokens.
• These tokens were found to be electronically signed with a special MSA cryptographical key that Microsoft used in 2016. It was intended to be abandoned in 2021 but was still in use in 2023.
• This discovery tipped off Microsoft that the threat actor had forged a token. This was possible due to the theft of a customer’s signing key. Nine months after the discovery of the intrusion, Microsoft clarified that its investigation was still in progress.
• By 27 June 2023, Microsoft identified the method used to access accounts and cleared related local data. This mitigation proved effective.

Key Findings and Recommendations From the CSRB

The CSRB report is an outcome of a comprehensive analysis conducted by the United States’s Cybersecurity and Infrastructure Security Agency’s CSRB through consultation with 20 industry enterprises.

The report contains findings and recommendations targeted toward CSPs and the US government. However, organizations of all kinds can glean valuable guidance from the CSRB report.

The CSRB’s recommendations can be grouped into seven themes (figure 1).

Adopting the CSRB’s Recommendations
The recommendations outlined in the CSRB report⁹ serve as an important reminder for organizations and leaders tasked with strategizing and defining cybersecurity programs. They must critically consider digital identity systems and the risk they pose—in particular, crippling access to email infrastructure. Further, many organizations develop bespoke software that employs customized digital identity systems and—in the absence of security considerations—could cause similar large-scale attacks.

Theme 1: The Value of a Security Culture
The first recommendation that emphasizes building a security culture was formed based on several key findings reported by the CSRB:

• The CSRB report addresses areas where Microsoft’s security culture was insufficient and makes recommendations for Microsoft to consider.
• Some of the report’s key findings explaining how Microsoft could have avoided errors that allowed the intrusion to succeed are:
  • Dependency on customers to report issues/anomalies instead of detecting a compromise of Microsoft’s cryptographic crown jewels
  • Lack of adoption of consistent security practices among CSPs
  • Lack of controls to detect a malicious laptop
  • Delay in correcting inaccurate public statements
  • A separate incident that occurred with a similar nation-state actor accessing sensitive emails, software code repository, and internal systems
  • Failure to display great standards of security, accountability, and transparency
• Further, the report mentions several key mitigation measures that could have helped in blocking Storm-0558’s exploitation of vulnerabilities in Microsoft’s systems, both internal and customer-facing:
  • Continuation of the physical rotation of keys
  • Completion of the migration of its MSA to rotate keys routinely
  • Placement of technical controls to generate alerts for aging keys
  • Avoidance of the error that allowed consumer keys to authenticate to enterprise customer data
  • Deployment of alerts to detect forged tokens that do not conform to Microsoft’s own token generation algorithms
  • Procurement of logs or other forensic data to determine how or when Storm-0558 had stolen the key
  • Prioritization of security risk management at a level commensurate with the threat and with Microsoft technology’s vital importance to more than one billion customers worldwide
  • Insufficient prioritization in rearchitecting its legacy infrastructure to address the current threat landscape

To successfully implement the first recommendation, enterprises must factor in certain considerations:

• Executives must be accountable for security within their organizations. Further, as a default, enterprises should ensure that products and services are secure by design by prioritizing security over features.
• Organizations should support their users and customers by providing a secure environment and contributing to the cybercommunity through programs designed to raise security awareness.
• Organizations should diligently evaluate the security related logging options provided by CSPs. The CSRB specifically calls for CSPs to provide such logging capabilities as a core element of cloud offerings and offer customers foundational tools for detecting, preventing, or quantifying an intrusion, recognizing that many customers will still require additional or third-party analytic capabilities to build a fully mature security program. The CSRB urges CSPs to stop the commercial practice of providing enhanced security logging services.
• Organizations should diligently identify and assess their key management, token management, and other identity/authentication-related controls as a part of protection practices.

Theme 2: Good Practices Based on a Clear Threat Model
The second recommendation, adopting good practices based on a clear threat model, stems from the following items highlighted in the CSRB report:

• The CSRB conducted a review with CSPs and found that several practices could significantly improve the security of cloud-based systems:
  • Automated periodic key rotation
  • Storage of keys in segregated systems
  • Implementation of stateful token validation
  • Scope limit keys
  • Use of private data in token generation algorithms
  • Use of tokens bound to operation rather than broad bearer tokens
• The CSRB notes that Google, Amazon Web Services, and Oracle Cloud Infrastructure have adopted the mentioned practices.

To effectively adopt the recommended practices, enterprises can:

• Assess bespoke digital identity systems and/or any integration with the CSP-provided identity systems to adopt practices that reduce the risk of complete system-level compromise. These practices include:
  • Use of stateful tokens—Mechanisms store records in a database. These are to be used when tokens are signed and distributed, and validated against a unique database at the time of access.
  • Automated frequent key rotation—Rotate encryption keys frequently (e.g., weekly). Use automated rules combined with monitoring.
  • Per customer keys (key scope)—Assign unique encryption keys to users to limit the scope of access and impact to related identities/systems.
  • Bound tokens—Digitally bind tokens to specific sessions to prevent token theft and token replay attacks.
  • Common authentication libraries—Implement standardized authentication libraries to seamlessly automate consistent token validation behavior and authorization policies.
  • Secure key storage—Store key data in segregated systems and leverage technologies such as dedicated hardware security modules (HSMs) to reduce the risk of key compromise.
  • Linkable tokens—Adopt practices that help link tokens extracted from the same root authentication message. Further, provide transparency to users in logs for better tracking and discovery.
  • Private data use in token generation algorithm—Insert unique/private data into generated tokens to differentiate between tokens that are authentic vs. those that are forged.
• Thoroughly assess logging practices for digital identity systems and associated components, including root key material, to prevent complete compromise.
• Utilize forensics to detect exfiltration of keys or related secrets, including logging all access to systems that maintain such data and any private keys stored within them. These logs should be monitored continuously.
• Work with CSPs to identify whether the practices mentioned have been implemented and create a threat detection model to identify and monitor any control failures.
• Evaluate CSPs and internal processes to conduct a robust compromise assessment and remediation process during acquisitions or mergers to ensure that weaknesses in the acquired environment are known and mitigated.

Theme 3: Audit Logging Norms
The third recommendation—to log audit norms—arose from the CSRB’s finding that logs are essential for detection, response, and recovery from cybersecurity incidents. In the case of incidents that involve nation state-backed threat actors, logs become crucial. Despite this, default audit logging capabilities are quite disparate amongst CSPs.

To improve logging, enterprises should consider the following:

• The recommendation requires a Cybersecurity and Infrastructure Security Agency-led task force of CSPs to define and adopt minimum standards for default audit logging capabilities in cloud services.
• It is equally critical that organizations that leverage services provided by CSPs carefully review the logging capabilities available and consider appropriate retention and recovery capabilities to support incident investigation.

Theme 4: Digital Identity Standards and Guidance
Modern threat actors possess advanced techniques to compromise identity systems, and many CSPs have not implemented emergent standards or elevated the benchmark for future digital identity standards. To remedy this, the CSRB created the fourth recommendation: that organizations should put standards and guidance in place for digital identity. This can be achieved through the following actions:

• The recommendation requires CSPs and industry bodies to review the current state of digital identity standards and uphold the requirements for consistent implementation across key areas such as key rotation, stateful credentials, credential linking, and scope. Furthermore, organizations should adopt emerging standards, such as Open Authorization (OAuth 2.0), and Demonstrating Proof-of-Possession (DPoP), among others.
• It is equally critical for organizations that provide identity services, both internally and externally, to critically evaluate the requirements of the identity standards set by CSPs.
• Special attention should be paid to cases where identity systems involve bespoke/customized development. In such cases, consider adopting standards such as those provided by the OpenID Foundation,¹⁰ the Organization for the Advancement of Structured Information Standards (OASIS),¹¹ and the Internet Engineering Task Force (IETF).¹²

Theme Five: Transparency Requirements for CSPs
The CSRB’s fifth recommendation is enforcing transparency requirements for CSPs. The report notes that CSPs leverage economies of scale to develop advanced capabilities, positioning them to lead all stakeholders effectively. Stakeholders expect CSPs to inform them of security incidents in a timely manner as investigations progress. This includes corrections made throughout the workflow.

When implementing this recommendation, enterprises should note the following:

• CSPs in the United States are obligated to report incidents initiated by a nation-state-backed actor. This is enforced through contractual provisions.
• Additionally, CSPs should clearly outline what is within their scope to investigate following an incident and what is excluded. This is to clearly define responsibilities between CSPs and customers, including correcting public/customer statements promptly.
• CSPs are encouraged to report cloud-based vulnerabilities using the CWE process and reinforce the standard requirements for disclosures.
• Organizations should assess the changing digital landscape and collaborate with their CSPs to integrate these practices within their internal processes.

Theme Six: Victim Notification Processes
The CSRB also noted the importance of robust victim notification processes, the sixth recommendation. It was observed that the victims in the Microsoft attack either ignored, did not see, or mistook the notifications as spam or a phishing scheme. This resulted in delays in containment, eradication, and response activities.

To avoid making a similar mistake, organizations may wish to:

• Explore alternative notification mechanisms, such as mobile networks, to inform victims of critical cyberattacks involving nation-state actors.
• Develop a communication strategy using a medium that is not an email-based solution to inform victims of the impact and response actions required. This is especially critical when the organization’s core communication channels are impacted.

Theme Seven: The Latest Security Standards and Compliance Frameworks
The final recommendation from the CSRB is the adoption of the latest security standards and compliance frameworks. The CSRB states that current compliance practices for government cybersecurity do not include key management or token issuance. To address this, the report recommends updating the FedRAMP program along with other related frameworks, such as the NIST Risk Management Framework.

While the recommendation is directed at FedRAMP and NIST, it is imperative for large organizations with obligations in cybersecurity compliance and regulatory expectations to stay informed about updates from NIST, such as NIST SP 800-53,¹³ and other leading research and standards’ bodies. It is also recommended to align internal policies and controls and keep security practices updated.

Mapping CSRB Recommendations to the NIST CSF
Today, most cybersecurity governance programs aggregate controls at a high level and the intricacies associated with implementing configuration-level controls are lost through layers of control mapping.

The CSRB report is an effective call to action for cybersecurity professionals to tie the lowest level of technical controls into a high-level governance view, ensuring that risk emerging out of such low-level technical controls is visible to those in charge of organizational governance.

Figure 2 depicts the mapping of themes from the CSRB report to the Functions and Categories of NIST’s Cybersecurity Framework (CSF) 2.0, released in February 2024.¹⁴ This mapping can be further extended to align with other industry leading frameworks or an organization’s own policies and processes.

Embedding the key considerations from the themes into the policies, procedures, and reporting mechanisms implemented at an organization that has already adopted the NIST CSF ensures that the risk emerging from such controls is tagged and appropriately communicated at the right governing forums.

Conclusion

As cybersecurity becomes a national and global concern, all organizations should be held accountable for their actions. Organizations should ensure the delivery of secure products and services by embedding the principles of digital trust. The cyberthreat landscape will continue to evolve, and organizations must secure their data to reduce the negative impact of cyberattacks on human life and society. The outlined recommendations and key considerations serve as a reference for organizations charged with building and maintaining a secure digital ecosystem.

Endnotes

¹ MSRC (Microsoft), “Microsoft Mitigates China-Based Threat Actor Storm-0558 Targeting of Customer Email,” 11 July 2023
² United States Department of Homeland Security, “Department of Homeland Security’s Cyber Safety Review Board to Conduct Review on Cloud Security,” USA, 11 August 2023
³ Cyber Safety Review Board (CSRB), Review of the Summer 2023 Microsoft Exchange Online Intrusion, 20 March 2024
⁴ CSRB, Review of Microsoft Exchange Intrusion
⁵ CSRB, Review of Microsoft Exchange Intrusion
⁶ CVE
⁷ MITRE
⁸ FedRAMP.gov, “Program Basics,” USA
⁹ CSRB, Review of Microsoft Exchange Intrusion
¹⁰ OpenID Foundation
¹¹ International Organization for Standardization (ISO), “Organization for the Advancement of Structured Information Standards (OASIS)” 
¹² IETF
¹³ National Institute of Standards and Technology (NIST), NIST Special Publication 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, USA, September 2020
¹⁴ NIST, “NIST Releases Version 2.0 of Landmark Cybersecurity Framework,” USA, 26 February 2024

NINAD DHAVASE | CISA

Is a cyber governance, risk, and compliance (GRC) specialist for a leading sports and entertainment company in Australia. He has 14 years of experience in cybersecurity.

His previous experience included working with India’s largest stock exchange and clearing corporation, where he led cybersecurity GRC management. He volunteers with ISACA^® in various capacities and has been a presenter at ISACA and other leading conferences and training sessions in Australia, India, and Singapore.