Microsoft 365 is now the heart of the information system of many companies: messaging, collaboration, document sharing, business applications, just as Google Workspace is. 

This centrality makes it a strategic target. However, new attacks no longer seek to break existing protections: they exploit legitimate cloud mechanisms and slip under the radar of traditional security measures.

We will see the types of current attacks on Microsoft 365, OAuth abuses, exploitation of Microsoft APIs or AD, bypassing MFA... and how to deal with them in a concrete way.

They get back in without going through the cracks… What are the solutions?

Historically, Microsoft 365 security relied on vulnerability detection, configuration hardening, and identity protection (Multi-Factor Authentication -MFA-, Conditional Access). This model is now insufficient. 

In recent months, new and highly targeted attacks on Microsoft 365 have emerged.​

With AI and a deep understanding of cloud environments, attackers are now targeting Microsoft 365 authorization mechanisms without exploiting any technical vulnerabilities, thus remaining invisible. How?

Many organizations believe that enabling MFA is enough to secure the environment. However, MFA protects authentication, but not always the use of previously granted permissions. It is precisely this discrepancy that is being exploited today.

New attack vectors on Microsoft 365

Here are some of the most effective tactics identified today. They rely on legitimate functionalities:

• OAuth[1]Consent Abuse

By inducing a user to consent to a malicious application, the attacker obtains valid tokens, sometimes with high permissions (Mail.Read, Files.Read.All, Directory.Read).

In concrete terms, this could be the case of an employee who receives an email seemingly from Microsoft stating: “Your Outlook session is about to expire. To avoid interruption, please revalidate your access.” This is what happened last month within a large group with an easy-to-imagine business impact (see Cyber Press 2026 report).

• Persistence via App Registration 

Creating or modifying Azure AD applications to maintain persistent access, even after password changes or session revocations.

Concrete example: The user asks their IT manager: “To fix an integration problem with Power Automate, can you register this application and give it the following API permissions? It’s urgent, it’s for management.”

Why is this critical? Because the attacker can generate tokens at will, act via Microsoft Graph, and maintain access for months!

• Living-off-the-Cloud  

Exclusive use of Microsoft Graph API, making the activity difficult to distinguish from legitimate use.

This is the case when the attacker uses Microsoft Graph and already has a valid OAuth token, a persistent App Registration, or even a compromised account.

This is particularly dangerous because the attacker, instead of relying on malware, uses official Microsoft APIs. ​

• Bypass MFA indirect 

MFA protects authentication, but not always the use of tokens already issued.

In concrete terms, this is the case of a user who clicks on a malicious OAuth application: they authenticate normally and validate the MFA. Then they click on “Accept” the permissions.

In these different scenarios, no credentials are stolen, and traditional security measures remain ineffective. They are present without our knowledge.

A common mistake we see with our clients is that they think MFA protects everything, even after authorizing a suspicious action. They assume that because they authorized it with their phone, it's secure. And if it were malicious, MFA would have blocked it.

But it's important to understand that MFA validates identity, not the legitimacy of the application. Therefore, it doesn't block the subsequent use of the token. 

In these scenarios, no credentials are stolen, and traditional controls remain blind. 

[1]"Open Authorization" is the de facto industry standard for online authorization. OAuth is an authorization protocol, not an authentication protocol.

They're in the place without us knowing.

It is urgent that we change our defense strategies!

To counter these attacks, it is necessary to add controls after authentication. 

Here are some best practices to implement quickly, but there may be others depending on how attacks evolve:

Steps to strengthen Microsoft 365

Strict governance of OAuth consents

1. • Strict governance of OAuth consents
   • Implement an administrator validation workflow
   • Regularly audit the applications and permissions granted.

These are fairly simple rules to implement and they significantly strengthen the level of security.

Behavioral identity monitoring

1. • Detect abnormal Microsoft Graph usage (volumes, times, geolocation)
   • Identify persistent, non-interactive access points

It's a bit more technical. Without specialized tools, this behavioral monitoring is impossible. SIEM will be the first building block to implement, coupled with XDRs. But ideally, we should go further with UEBA (User & Entity Behavior Analytics).

Stricter conditions for access

1. • Apply application-specific rules and APIs
   • Restrict long-term tokens and force their expiration

It's a bit of work, but fairly easy to do.

Journaling and extended visibility

1. • Centralize Azure AD, Unified Audit Log and Graph logs
   • Correlate events related to authorization, consent, and access to resources

Here too, tools like SIEM will be extremely useful. But given the colossal amount of information to process per second, it will be necessary to rely on high-performance AI to detect abnormal behavior as quickly as possible.

Identity-oriented Zero Trust approach

1. • No longer consider an authenticated identity as implicitly reliable
   • Continuously reassess the context and behavior

It is essential to increase automated controls and no longer rely solely on standard mechanisms.

These are just a few examples. But the attackers' stance could change in the coming weeks.

Conclusion

These changes and this monitoring are quite complex. If you don't have the time or resources, consult experts. The risk is significant enough.

Most organizations have the necessary technical building blocks, but lack continuous and centralized monitoring, as well as the expertise to interpret weak signals. Yet it is precisely these weak signals that reveal these new attacks.

In any case, Microsoft 365 security is no longer simply a matter of configuration or patches. It now relies on real expertise based on mastering identities, permissions, and legitimate uses.

It's the same struggle for other online collaborative suites (Google Workspace...).

The attackers are no longer forcing the door…

They use the keys they are given.