"High Risk" User Classifications Caused by MACE — little recap

While I was still peacefully frolicking through the land of dreams, the real alert wave was just beginning. The first OpsGenie alerts were rolling in on my phone and iPad like an angry stampede — and before I could even process what year it was, my brother barged into the room, eyes wide, declaring:

"Your iPad downstairs is freaking out — I think Jira (as he could read the App Name on my iPad) is trying to contact aliens."

Turns out, in a span of just 3 minutes, we were blessed with 94 glorious notifications from different customers (Microsoft 365 Defender has detected a security threat). Yes, ninety-four. At 6:20 in the morning (Swiss local time).

Just the kind of serenity every Security admin hopes for on a Saturday. 😅

🔍 What Happened?

Saturday morning, several organizations — including some of our customers — reported sudden login blocks for licensed Entra ID P2 users. These users were being flagged as "High Risk", triggering Conditional Access policies which were configured to block users which are on a risk state "High". So there was now a bunch of users with no possibility to log in...

Upon investigation, we found the common factor as we saw the display name and the service principle ID in the audit log:

After that we gone further after the service principal ID and saw it got onboarded shortly before updating the users with the risk status:

🔍 MACE, whats that?

So we now knew, it was not a misconfiguration on our side which caused this behaviour it was a new enterprise application which was onboarded and flagged those users... but why?

☕️ At this point, after my first cup of coffee, I felt brave enough to dig into the depths of Microsoft's Documentation and see what MACE stands for...

As we can see on the Microsoft Docs, MACE is the abbreviation that Microsoft uses for leaked credentials in Entra ID Protection. But what does that mean?

Sure, we all know what leaked credentials mean, but what’s the perspective from Microsoft’s side on this?

Leaked credentials
Calculated offline. This risk detection type indicates that the user's valid credentials leaked. When cybercriminals compromise valid passwords of legitimate users, they often share these gathered credentials. This sharing is typically done by posting publicly on the dark web, paste sites, or by trading and selling the credentials on the black market.
When the Microsoft leaked credentials service acquires user credentials from the dark web, paste sites, or other sources, they're checked against Microsoft Entra users' current valid credentials to find valid matches.
(For more information about leaked credentials, see common questions.)

So basically, Microsoft ran a little "black market bingo" in the background — and if your users’ passwords matched any dark web dump, boom, welcome to High Risk Club.

🛠 How to Identify If You're Affected

Should you be among the affected — well, you already know.
Whether it hit you during your peaceful Saturday morning, your relaxing afternoon coffee, or right as you were about to close your laptop for the weekend... those alerts made sure your chill plans were instantly on hold. 😅

Admins can run the following KQL query to investigate activity by the MACE app:

CloudAppEvents
| where ActionType has "Add service principal"
| where ObjectName contains "MACE"
| project TenantId, ObjectName, Timestamp

Additionally, the entra id audit logs where you can filter after the Service Principal ID gives you some insights about the activity of the new enterprise application:

📞 Microsoft's Response

We raised a Severity A support ticket with Microsoft. They confirmed awareness of the incident but have not yet clarified whether this is due to:

• A misconfiguration or false positive
• A real security incident or credential breach

As of the latest status update:

STATUS: Active as of Sat, 19 Apr 2025 05:40:31 UTC
SUMMARY: You may observe an increase in alerts for Identity Protection.
NEXT STEPS: Microsoft is actively investigating.

So, nothing groundbreaking here — aside from a Reddit community that absolutely exploded, promptly spinning up a fiery thread dedicated to unraveling this mysterious "incident"! 🔥

Microsoft also has a handy “Common Questions” section related to leaked credentials, which I’m including here for the sake of completeness.

So, after about 25 minutes of deep-diving into logs, chasing alerts, and piecing together all the available information (minus the still-open Severity A ticket), we were finally in a position to reach out to our customers with an overview of the situation. But that left us with the big question: How do we actually resolve this? At this stage, we still didn’t know whether we were dealing with a series of false positives or if these users had genuinely been compromised.

Microsoft had already included a "How to resolve this" section in their documentation:

Investigating leaked credentials detections

If this detection identified a leaked credential for a user:

Recommended action: Confirm the user as compromised, and invoke a password reset if not already performed by self-remediation. Block the user if an attacker has access to reset password or perform MFA and reset password and revoke all tokens.

📣 Our Response

As soon as the alerts started pouring in on our side — (Guess who was on call? Yep… lucky me. Yay. 😅) — we kicked into action. Within just 30 minutes of initial investigation, we proactively reached out to affected customers and began mitigating the impact.

We could have simply dismissed the risk classification — but since we operate under the "assume breach" principle, we chose a more cautious approach. We proactively informed our customers and enforced a password reset for the affected users. This ensures that, regardless of whether the next login occurs via Microsoft 365, an Entra-joined device, or a hybrid-joined machine, (depends on the customer) the user will be required to change their password. This approach allowed us to stay on the safe side.

Additionally, we immediately jumped on a call with our SOC to discuss the current situation. As a result, the affected users are now subject to enhanced monitoring to detect any further suspicious activity.

Despite all this, no suspicious activity has been observed beyond the usual noise — such as random brute-force attempts and Azure Smart Lockouts, which we see regularly and are mitigated by default protections.

🧠 Final Thoughts

In my opinion, the integration itself isn’t a bad thing — in fact, it’s yet another clever addition to Microsoft’s identity protection arsenal. The idea behind it is solid. The execution, however? Meh.

To my knowledge, this behavior wasn’t broadly communicated in advance, which led to a day filled with more confusion (and caffeine) than necessary. While we were able to respond quickly and effectively, the lack of transparency turned what could have been a non-event into a semi-chaotic Saturday.

With that said: Happy Easter to everyone who had the pleasure of spending their weekend with logs, alerts, and hastily opened Teams calls. 🐣💻

And of course, to those lucky ones who enjoyed a peaceful, uninterrupted weekend — we salute you. 😄