when faced with multiple explanations for a phenomenon, the simplest one that adequately explains the observed evidence is likely to be the most accurate
The Principle of Parsimony
The three lessons below should be considered a supplement to 25 Simple Ways To Secure Your Apps.
Secure by Design: Beyond User Vigilance
The root cause of this breach was password spray. This means the most effective prevention for this breach would have been the adoption of passwordless or certificate-based authentication. As mentioned in my previous post, I don’t see end-user training as effective against a determined attacker. Defense in depth means that anything that helps even a little should be considered, but passwordless and phishing-resistant auth methods provide the biggest bang for the buck. Microsoft mentions educating users to review sign-in activity to protect against password spray attacks. This might help an investigation, but would this have prevented the compromise? No.
Educate users to review sign-in activity and mark suspicious sign-in attempts as “This wasn’t me”.
Microsoft, Midnight Blizzard: Guidance for responders on nation-state attack
Relying on end-users to check their activity logs is dubious protection. Relying on them to distinguish a safe app from a phishing app in 2024 is irresponsible. Phishing-resistant passwordless authentication binds the auth method to the app. This removes your end-user from judging whether this login screen is truly your company’s login screen. There is a window of vulnerability when the user first authenticates to the app, but this window is much smaller than the entire lifetime of your user’s access to the app.
New Lesson #1: Protect your service accounts
Service accounts often need to be exempted from MFA. However, securing them with a password or symmetric key is a last resort. Here is a decision tree:
- Does your service support Managed Service Identities?
- The secret stays within Azure components within the Azure data center. This is best.
- Examples: Azure resources, Arc managed on AWS VM, Arc managed on on-prem. Supported Azure resources
- If not, does your service support Workload Identity Federation?
- Use this for non-Azure resources. Your code still doesn’t handle the credential.
- Examples: Google Cloud, GitHub Actions, and Workloads running on Kubernetes. Supported scenarios
- If not, does your service support Service Principal authentication with certificates?
- If you must manage creds, use certificates for asymmetric key authentication that is not susceptible to password spray attacks and never transmits secrets. Manage the cert in Azure Key Vault.
- If not, does your service support Service Principal authentication with a secret?
- A shared secret is a password (just usually not a predictable one generated by a human). At least use Azure Key Vault.
- If not? Ok, we are entering strange territory. We must use easily-guessable, vulnerable-to-password-spray passwords for highly-privileged service accounts? If I were anywhere close to this decision, I would insist this decision be put at the top of the risk register (#10 from 25 Simple Ways To Secure Your Apps). I would also write a small password spray tool that would email all the easy-to-guess passwords for all highly privileged accounts in the environment to executives each week. Why should attackers have all the fun?
New Lesson #2: Notify your admins and users of strange behavior
End-user monitoring of activity logs will not prevent compromise. However, data mining and machine learning can surface abnormal activity closely correlated with compromise. Here are examples where judicious alerting can strengthen your security posture:
- Notify users when a new authentication method is registered for their account (#15 from 25 Simple Ways To Secure Your Apps).
- Establish baseline access patterns for privileged accounts and notify when activity deviates from baseline (e.g., granting high application permissions).
- Define policies to closely manage and review highly privileged app permission grants and alert on policy violations.
Today’s machine learning tools enable us to detect application access patterns and deviations. Here is a visualization of application access clusters we recently performed for a client based on Entra ID sign-in logs. Eleven well-defined application access clusters establish a baseline of application access. We can use these clusters to clean up user permissions, alert of strange new access behavior, or define phases for application upgrades or migrations.
New Lesson #3: Secure your helpdesk against attacks
Security is an ever-evolving game of cat and mouse. As phishing-resistant credentials (rightfully) become broadly adopted, attackers will move to the next weakest pathway – resetting credentials through the helpdesk. Helpdesk social engineering was the root of the MGM ransomware attack. Accenture’s CISO has put together this 10-step guide to strengthening your service desk against attack.
My Take
Microsoft recently experienced a security breach and provided details to help others defend against similar attacks. While some criticized elements of the piece as “morally indefensible,” Microsoft did offer some helpful information. Take this quiz; I’ll send you my more detailed take on the incident and the communications around it.