On Friday evening, Microsoft announced that Cozy Bear (APT29) had compromised a corporate Microsoft cloud tenant using a simple password spraying attack to gain their initial foothold.Â
They then used the account's permissions to access Microsoft corporate email accounts, including from members of the executive team and the cybersecurity function.
According to Microsoft, the adversaries were persistent in the corporate cloud infrastructure for more than two months before being discovered.
According to the IBM X-Force Cloud Threat Landscape Report 2023, compromised credentials are the most common initial access vector in cloud incidents. This breach shows that it doesn't matter how well you're managing your cloud security posture (with CNAPP tools, for example) or how quickly you remediate vulnerabilities and compliance issues — it's a technique that immediately bypasses all those controls.
This blog post describes what we know so far about the breach, along with best practice recommendations you can take to reduce the risk of similar breaches using preventative measures, plus suggestions for real-time monitoring and detection controls that will enable your SecOps team to detect and contain adversaries earlier in the kill chain.
The Gem cloud security research team has already been fielding questions from customers about how to respond to the breach and what key measures organizations should have in place to ensure they’re ready for similar attacks. We will update this blog as more information becomes public.
What We Know
Information about the breach is still developing and several key questions about the attack remain unanswered, but Microsoft’s initial report attributes the attack to a threat actor known as Midnight Blizzard, a Russian state-sponsored group also known as APT29 and Cozy Bear – the group responsible for the 2019 SolarStorm and 2016 DNC attacks.
Although this is a sophisticated nation-state adversary, the attack was executed using a classic password spraying attack (MITRE T1110.003) rather than an exotic technique like exploiting a zero-day vulnerability or executing a supply chain attack.
The official response from the Microsoft Security Response Center (MSRC) indicates that the attacker achieved initial access beginning in late November 2023. The password spraying attack successfully compromised a legacy, non-production, test tenant.
Details regarding how the attack accessed this sensitive data from the original access point are not yet known. Microsoft indicates that there is no evidence that customer environments or customer data were affected.
How to Respond
Organizations should take steps to ensure that they can detect and respond to these types of password spraying attacks. Our guidance includes preventative measures, which will help organizations ensure these types of attacks fail, as well as steps to detect and respond in the case of a breach.
Preventative Measures
Enforcing a healthy security posture is an important first step. In particular, organizations should:
Enforce multi-factor authentication (MFA) on access to sensitive resources across the organization. This should be true for any interactive login, including through the command-line interface, and across all active and managed tenants (even those that have been deprecated)
Migrate deprecated or non-supported tenants into larger, managed and monitored tenants
Where possible, leverage a VPN solution and enforce a conditional access policy to limit access to tenants from the internet.
These preventative measures will help ensure that attacks such as these do not succeed. But like any security control, these preventative measures may fail, and should be augmented with further defense-in-depth. To achieve this goal, proactive measures to detect and respond to threats are necessary.
Proactive Cloud Threat Detection and Incident ResponseÂ
Proactive cloud threat detection and incident response starts with ensuring you have the visibility and telemetry to even know if you’ve been compromised. To detect password spraying, organizations should ensure that they are collecting and analyzing sign-on logs throughout their Azure environment.
Note, however, that by default, these logs are only retained for between 7 and 30 days, depending on the particular parameters of your Azure subscription. It’s crucial that organizations consider extending these retention limits and ensure that these policies align with their threat model. In the case of Microsoft, the attacker originally gained initial access in late November, but the attack was not detected until January: had Microsoft been working with only default retention, crucial forensic evidence would have been lost and the organization would have been blind to the original source of the attack.
Once retention is configured, organizations should ensure that they have appropriate real-time monitoring in place to detect the attack. The key in the Microsoft attack would have been detecting unusual sign-ins to sensitive applications. To detect these threats, as a start, Gem recommends alerting when the following events are observed:
Access from unusual IP addresses
Sign-ins by known users at unusual times
Sign-ins from unusual service principles or unusual tenants
Sign-ins with unusual user-agents
To reduce noise, these alerts can be prioritized based on organizations context: admins, senior leadership, and users who lack MFA can generate high-severity alerts, whereas other less sensitive users can be deprioritized.
The Gem platform also reduces noise by automatically building a profile of all cloud entities (users, instances, storage buckets, etc.) and how they interact with each other, so that it only surfaces anomalous interactions.
In addition to monitoring sign-in attempts, organizations can also monitor their network activity. Large numbers of failed login attempts can generate unusual bandwidth spikes. Restricting alerting on bandwidth spikes to specific IP addresses or specific ASNs owned by cloud providers can reduce noise for these alerts.
Gem’s cloud security research team will continue to monitor closely as more information is released, and update with any further findings or recommendations as more detail becomes available. Our team is available to discuss – should you have any specific questions about how to secure your own cloud environment (AWS, Azure, GCP, Okta, etc.), please don’t hesitate to reach out.