Office365 Attacks: Bypassing MFA, Achieving Persistence and More - Part I

APTs are actively attacking Office 365 (O365) – finding mechanisms to bypass MFA and to impersonate users regardless of whether you reset their passwords. When I was looking through the Mitre mapping of O365 attacks, I noticed that it didn’t include many methods of intrusion and actions on objectives that can occur with O365. In conversations with several clients, I couldn’t help but notice that there’s still a heavy focus on “endpoint” style attacks and not much resource / thought put into attacks that can occur in the cloud.

Attacking O365 gives an attacker many benefits… it allows an attacker to impersonate users, alter MFA settings, register malicious devices, access Teams messages, download sensitive emails, access SharePoint, OneDrive, register malicious applications and various other actions that could allow them to maintain persistence in your environment. This blog post explores the various ways O365 can be attacked. I will be writing a Part II follow up that describes the methods of detection for each attack.

As a part of my own learning as well as a way of bringing more attention to these styles of attacks, I’ve decided to build out a matrix of various attack techniques that can be leveraged on O365. This is by no means comprehensive and if you notice anything I have missed, please let me know on twitter (@inversecos) and I will amend this matrix. 



The following section provides a high-level explanation of the various attacks in the matrix. I will be posting a second part to this blog that will explore detection mechanisms. This is by no means a comprehensive list of all attacks on O365. If there are things I have missed, please let me know and I will amend the matrix.


Azure AD PowerShell – Any users in the domain can utilise this Graph module to export the full list of users, domain information, user roles. Depending on role permissions, this PowerShell module will allow you higher functionality such as adding owners to service principals, getting credentials for service principals, adding roles to members and creating users and administrative members. Security researchers @Doughsec and @madeleyjosh highlighted in their recent Blackhat presentation that until recently, MFA was not enforced for the use of this module.

Enumerate Domains – Using the “AADInternals” tool created by Dr Nestori Syynimaa, non-users can enumerate domains that are owned under a particular organisation.

Enumerate Users – The AADInternals tool (along with some other various methods which will be discussed in the Initial Access section) also allows non-users to enumerate the existence of users. Methods for user enumeration when single sign-ons are enabled:

Initial Access

Bruteforce via OWA – This is a typical password-spray attack that red teamers typically utilise to gain access to a user’s mailbox instance.

Bruteforce EWS – Exchange Web Services allows legacy authentication meaning that although MFA might be enabled within an organisation’s O365 instance, MFA is not required to log in to EWS. I’ve worked engagements with APTs that have used this to gain access to mailboxes. Logging is also semi limited with EWS and doesn’t log all logon attempts. Access to EWS allows a user to read emails, send emails, view calendars etc.

Bruteforce OAuth, Auto Login, AAD Sign in form – Logins via these APIs are allowed when Seamless SSO is enabled. There’s varying degrees of logging enabled / non-existent for each one.

Phishing Emails – Phishing lures that are sent to contacts within an organisation made to steal credentials or establish foothold within an environment.

Golden SAML – An attack that allows an attacker to move from on-premises to the cloud through breaching the AD FS server. I’ve done a write-up on this here.

MFA Bypass via IMAP/SMTP/POP – Bruteforce through legacy protocols.

PTA Skeleton Keys – PTA is one of the methods of authentication utilised to allow users sign into on-premises and cloud-based applications with the same password. For this attack to work, an attacker needs to compromise the server that is facilitating the PTA and needs to hook or perform code injection to fetch the passwords of synchronised users. This will allow an attacker to log into Azure AD / Office 365.


Enumerate Users/Admins/Roles/Permissions – Further access to user accounts within the domain allows users to further probe and conduct reconnaissance on other users/administrators/roles/groups and permissions. This allows attackers to identify global administrator roles, what groups they are in, their SIDs and other useful information that can allow an attacker to impersonate a user.

Enumerate MFA Settings – When Azure AD is configured, MFA settings can be set surrounding account lockouts, trusted IPs (range of IPs that can bypass MFA) and defining named locations through conditional access. These can be altered by attackers to add their attacker IP in the trusted IPs list to bypass MFA. I put this in discovery because it’s a piece of recon that an attacker can do, but this recon can lead to further actions.


Change MFA Settings – Given sufficient permissions, attackers can modify MFA settings including altering conditional access to add their IP in the trusted IPs list. Attackers can also add their numbers to the MFA and alter how the MFA functions for particular users.

Enumerate Teams / OneDrive / Sharepoint / Email / Skype etc – Once logged in, an attacker has full access to compromised account’s Teams, OneDrive, SharePoint, Email and other applications. Attackers are able to download files and emails and read Teams messages.

Downgrade License – APT style attacks often see attacker downgrading the O365 license from E5 to E4. This allows an attacker to evade logging and detection as the E5 license has several more security features along with longer logging capabilities.

Impersonate Users – When a Golden SAML attack is utilised, attackers can impersonate and logon as any user. Password resets does not void the attacker’s ability to access and impersonate the user.

Assign Service Principal Role – Applications need a service principal account to do things in Azure and Azure AD. If a service principal has the role of “global administrator” an attacker can log into Azure PowerShell as that service principal with “global administrator” rights.

User Access Administrator Role Toggle – If an attacker has global administrator rights, they can enable a toggle grants them access and ownership of anything within Azure. This effectively allows an attacker to access and run scripts on Azure VMs and other things.

eDiscovery Abuse– Attackers can conduct searches and enumerate content within O365 applications. The use of eDiscovery allows them to search and access content across all applications.


Golden SAML Allows an attacker to impersonate any user and bypass MFA despite password resets. I’ve done a write-up on this here.

Malicious App Registrations
– Users can be sent a phishing link to allow permissions to a malicious application. Once approved, the token is generated for the malicious application and it’s authorized to perform actions on behalf of the user i.e. read emails, access files and whatever else is defined. This can also be done within a portal if the attacker has already gained access to the account.

User account creation – Given the right permissions, malicious accounts can be created in the domain.

Modifying Conditional Access – Trusted IPs can be altered by attackers to bypass MFA through modifying conditional access.

Adding Service Principals with Read/Write – Attackers can log into Azure Powershell as a service principal. Therefore, when API permissions have been assigned to applications that allow read/write to various resources i.e. mail in mailboxes. Those can be accessed by an attacker.

Mailbox Rule Creations – As per usual BEC cases, rule creations can be made by attackers to forward emails to an attacker mailbox, delete emails or move emails to random folders.

Mailbox Folder Permissions – Rights delegations allows an attacker to access content from another mailbox. This can include actions which allow an attacker to send emails as that user or have full access.

Mail Flow (Transport Rules) – In Exchange Online, Mail flow (transport rules) are built to allow an admin to manage messages that flow through an organisation. This affects messages in transit (before they land in an inbox). Attackers can leverage these rules to intercept messages, forward messages with certain phrases, to “delete” messages and other actions.


Post a Comment

Popular posts from this blog

Forensic Analysis of AnyDesk Logs

How to Reverse Engineer and Patch an iOS Application for Beginners: Part I

Successful 4624 Anonymous Logons to Windows Server from External IPs?