Phishing attacks are well known. The objective of this type of attack is to perform actions from a victim’s account or to retrieve information about the targeted person or company.

Despite their notoriety, they remain very effective for attackers. Indeed, among the attacks investigated by Wavestone CERT, about 51% of them start with the use of valid accounts, which includes phishing attacks.

We are all vulnerable to phishing attacks! An attacker with enough resources and information about their target can generate a trap sophisticated enough to trick them. Similarly, the Office365 and Azure product suites have features that can be exploited in less conventional attacks, the impacts of which users may not be aware.

Employee awareness, while necessary to address the most common threats, is not enough to address some of the more targeted or less traditional types of attacks. Tougher access requirements to cloud-hosted resources, good hygiene in managing access rights, and detection of unusual and suspicious access are all critical to a company’s defence strategy.

Attackers have a wide range of tools and possibilities to access documents stored on a company’s SharePoint, attempt to retrieve sensitive emails, or retrieve employee information. The traditional phishing attack as well as the device code authentication attack will be briefly explained below before looking at the illicit consent grant attacks in more detail.

The traditional phishing attack: a known threat preventable using multi-factor authentication

Traditional phishing attacks are usually based on sending a link directing the targeted victims to a site the attacker controls. Using an authentication login page similar to those used by employees of the targeted company, the attacker retrieves the credentials and passwords of the tricked users.

The traditional phishing attack is simple to implement in the absence of multi-factor authentication

The ease of implementing such an attack on a large scale makes it a tool of choice for untargeted attacks. One method to protect against this type of attack is to enforce the use of a second authentication factor.

It should be noted however that although more complex to implement, the interception of the second authentication factor is technically feasible and will be the subject of an upcoming dedicated article.

The attack via “device code” authentication: a little-known authentication method hijacked by attackers

This attack relies on the device authorization grant functionality[1]. This authentication method allows the authentication of a user on a device without a web browser. A code displayed on this device must then be entered on a computer or smartphone via the dedicated Microsoft site. This device will then have part of the access rights to Office 365 resources corresponding to the user who entered the code.

This functionality is not well known to users and can be exploited by an attacker for malicious purposes:

• The attacker first generates a device code, using the same process used by devices without a web browser.
• Then, the attacker’s objective will be to get the victim to fill in his device code on the https://microsoft.com/devicelogin For example, the attacker could pretend that to access a sensitive document, it is necessary to connect to this link using the code he generated.
• If the target accesses the link, fills in the code and authenticates, this will allow the attacker to impersonate the

Example of a device code phishing attack

This attack is more difficult for an attacker to carry out because of the short lifespan of the device codes: they are only valid for 15 minutes and must therefore be generated shortly before the user enters them. This attack is therefore more easily carried out within the framework of “phoning” attacks or phishing via Teams. For example, the attacker could call the victim, pretending to be part of the company’s IT support team, and ask the user to authenticate on the link indicated and fill in the code of his choice.

To protect against this type of attack, conditional access policies on Azure can be used to prohibit suspicious connections from devices not under the control of the company.

Illicit consent grant attack

In addition to these two methods, the illicit consent grant attack also allows an attacker to illegitimately gain access to an Azure environment. This attack was even initially easier for an attacker to implement than attacks via device code authentication. Faced with the resurgence of this threat, actions were taken in 2020 by Microsoft to limit the conditions for carrying out the attack. While hardened Azure configurations can completely block this threat, the configurations implemented by some companies expose them to this type of attack. What are the prerequisites for the realization of such an attack, what are the possible consequences and how to protect yourself?

What is the illicit consent grant attack?

To understand the principle of this attack, let’s put ourselves in the shoes of an employee who is a victim of such an attack:

• The victim receives a phishing email indicating an urgent action to be taken to keep their Microsoft account activated. Employees are made aware not to click on phishing links and not to enter their passwords on unknown platforms. The link in the format https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=<CLIENT_ID>&redirect_uri=<Attacker_controled_URL>&response_type=code&response_mode=query&scope=Mail.ReadWrite%20Files.Read.All%20Mail.Send%20User.Read contains a Microsoft-associated domain, which reassures the victim.
• When clicking on the link, the victim must authenticate themself. This authentication is often automatic since it benefits from Microsoft’s single sign-on (SSO). The victim then receives a request to grant permissions:

The malicious application asks the user to grant it permissions

• If the victim clicks “Cancel” out of caution, they are redirected to the attacker’s server with a URL like <Attacker_controled_URL>/?error=consent_required &error_description=AADSTS65004%3a+User+declined+to+consent+to+access+the+app.&error_uri=https%3a%2f%2flogin.microsoftonline.com%2ferror%3fcode%3d65004#. The attacker, understanding that the victim has not accepted the prompt to grant them permissions, can then redirect the victim to the phishing page, giving them the impression that the requested permissions must be accepted to proceed to the next step.
• Because of the legitimate domain name and the urgency indicated in the phishing email, the victim of the attack chooses to accept. They then see a message indicating that their account will be kept activated, as suggested in the initial email. The victim then resumes normal activity.

However, this consent allows the attacker to perform actions on behalf of the victim, depending on the permissions granted. Note that the illicit consent grant attack has many advantages for an attacker, including:

• The use of a Microsoft-associated URL when requesting consent, which is considered trusted and therefore implies less distrust on the part of targeted users.
• Obtaining persistent access for 90 days, without knowledge of the user’s password or second authentication factor if no conditional access policy is implemented.
• The ability to directly request Microsoft APIs to automatically retrieve files, emails, and other corporate resources accessible by the tricked user.

Technical sidebar

From a technical point of view, the illicit consent grant attack relies on the ability of an attacker to create an application that requires permission to be granted. Granting the permission is a feature that is regularly used by users without them realizing it, e.g., the Outlook client is allowed by default to retrieve and notify them of new incoming emails.

Here are the key steps when performing this type of attack (which is based on the authorization code grant flow of OAuth 2.0):

• The attacker creates an enterprise application on Azure AD (application registration), configures the permissions they want from users and instantiates a “client_secret” on the application. Some constraints related to this application are detailed below.
• The attacker sets up a server to which users will be redirected following the consent and indication of its URL as a valid redirection URL for the application.
• Following a user’s consent, the user will be redirected to the malicious site and a code will be provided to the attacker. This code is the proof to be shown to Microsoft that the user authorizes the application to do actions on their behalf.
• Using this code and the application’s “client_secret“, the attacker will be able to retrieve an OAuth token. This token is a receipt signed by Microsoft that specifies the actions that the victim authorizes to be done on his behalf. The attacker can also retrieve a “refresh_token” that allows to renewal of the validity of the OAuth token.
• This OAuth token can then be used to send requests to the Graph API in the name of the victim and therefore allows attackers to impersonate the user.

What are the consequences of such an attack?

While some permissions require administrator approval by default, other permissions can be granted directly by users in non-hardened Azure environments. The permissions that can be recovered by the attacker during this type of attack depend on the configuration of the targeted Azure AD tenant.

Here are some examples of possible abuse by an attacker who has managed to retrieve a user’s permissions on a non-hardened environment.

Actions that can be taken following a successful malicious consent attack on an unhardened Azure environment

• Azure Active Directory:
  • The Microsoft Graph User.ReadBasic.All permission allows retrieval of the email addresses of all users in a tenant, allowing the deployment of larger-scale phishing attacks from an initial compromise.
• Outlook:
  • Sending an email on behalf of a user can enable so-called “president fraud” attacks using the Microsoft Graph Mail.Send and Mail.ReadWrite permissions. A compromised employee with a high level of authority could, for example, send an email requesting that a large amount of money be sent urgently to a bank account not listed by the company.
  • Sent emails can also be hidden using Outlook filtering rules that can be modified using the MailboxSettings.ReadWrite permission. The attacker will then be able to redirect all emails related to his attack and associated replies to a different folder in the outbox and inbox.
• Teams:
  • Reading and sending messages via Teams (Microsoft Graph Chat.ReadWrite) is an effective method for an attacker to impersonate a user. This method can also be used to carry out “president fraud” attacks.
• OneDrive and SharePoint:
  • Read access to files accessible on OneDrive and SharePoint (Microsoft Graph Files.Read.All) can provide access to all files accessible by the user. In addition, SharePoint files are often stored with permissive access rights which could allow attackers to retrieve a large number of files. It is not uncommon, for example, to have access to scripts or configuration files containing passwords in clear text.
  • In addition, SharePoint’s search capabilities, including reading and indexing the content of Office files, can be used to target certain keywords such as “password”.
  • The writing rights on a SharePoint file (Microsoft Graph Files.ReadWrite.All) can also have a significant impact: SharePoint’s versioning features limit the recording of old file versions to 100 versions by default. This means that in case of automated and successive rewrites more than 100 times, the initial version of the file would no longer be recoverable. This would allow an attacker to erase a large amount of data if an account with write rights to sensitive files is compromised. In case of deletion, it would then be necessary to contact Microsoft support to try to recover the data from the daily cold backups.
• OneNote:
  • Synchronized OneNote files (Microsoft Graph Notes.ReadWrite or Notes.Read.All) can contain sensitive information such as meeting minutes, and confidential information, but also technical information such as passwords stored in an unsecured manner.
• Azure Resources:
  • Access to key vaults and storage accounts (Azure Key Vault and Azure Storage user_impersonation) can give access to sensitive elements in case of compromise of developer or technical user accounts. These elements can facilitate the compromise of Azure resources such as virtual machines and serve as a rebound point for an external attacker.

These actions can have serious impacts on a company. In addition, they can facilitate more elaborate attacks by disclosing sensitive information to an external attacker.

If approved by an administrator, more sensitive permissions can be retrieved such as write access to all Azure Active Directory information.

Finally, administrators have the right to grant all users permission to an application of the tenant. In this case, the identity of all users could be impersonated to grant permission.

Microsoft’s implementation of the “risk-based consent step-up” to limit attacks by illicit consent

In response to this threat, Microsoft implemented additional protections in November 2020 to limit the impact of this type of attack. The “risk-based consent step-up” feature aims to raise a warning and ask for an administrator’s validation in case of a permission request that seems fraudulent.

The access request from an unverified application considered sensitive is blocked by default

This applies in the case of a permission request by an unverified application created outside the targeted tenant. By default, all permissions are affected, except for reading the target user’s profile, to facilitate single sign-on (SSO) with third-party applications.

This restriction is implemented by default on all Azure tenants.

Although these restrictions limit attacks, 3 types of applications can still be used for malicious purposes: legacy applications, applications internal to the targeted tenant and verified applications.

• Legacy applications:
  • To allow for backward compatibility, no warning message is displayed for a permission request from an application created before November 2020.
  • Prerequisite for the attacker: have an application created on an Azure tenant before November 2020 or compromise a tenant containing such applications.
• Internal applications of the targeted tenant:
  • These applications are not covered by the “risk-based consent step-up”. By default, all users of an Azure tenant have the right to create an enterprise application on their tenant, which makes it easier to attack an unhardened environment.
  • Prerequisites for the attacker: to have a first compromised account on the IS of the targeted company, to realize that the creation of applications is authorized for standard users and to deploy an internal application to the tenant.
• Verified applications:
  • Verified applications are not covered by the risk-based consent step-up. The Microsoft verification process requires integration into the Microsoft Partner Network.
  • Prerequisite for the attacker: have a verified application or compromise an Azure tenant with verified applications and hijack the use of these legitimate applications.

Possible remediations

To limit the probability and impact of such attacks, the following recommendations can be applied and adapted to the company’s context:

• Allow only applications explicitly approved by administrators. This configuration is the most secure, but the validation step can be a bottleneck since it is usually the Global Administrators and Privileged Role Administrators who must give validation. In practice, some rights can also be granted via Cloud Application Administrators or Application Administrators.

Granting privilege consent by standard users can be blocked via Azure AD configurations

• Limit the permissions which can be granted. An administrator can specify Low-risk permissions that can be granted directly by users.

Granting privilege consent by standard users can be limited to rights considered non-sensitive via Azure AD configurations

• Create a legitimate application validation process and admin consent workflow to track and justify these validations. By tightening up the consent process, it is necessary to jointly implement a simple and intuitive way for users to request exceptions to grant permissions related to legitimate use cases. These exceptions must be tracked and justified to ensure the legitimacy of the requests.
• Regularly review the rights granted to applications (Enterprise applications): permissions granted by users should be reviewed to ensure that only legitimate applications have rights to the tenant’s Office 365 resources.

Regular review of trusted applications on an Azure tenant facilitates checking that the privileges granted are still valid

• Monitor suspicious access to Office 365 resources. For example, it is possible to set up alert rules on the number of files downloaded over a short period of time to identify data exfiltration attempts.
• Limit access rights to SharePoint files to what is strictly necessary: files that are accessible to all users within a company should be checked at regular intervals and access rights to the most sensitive files should be reviewed to ensure that only the necessary people have access.

Conclusion

The various phishing attacks presented in this article are based on a lack of hardening of Azure AD configurations. The implementation of a second authentication factor, while necessary for traditional phishing attacks, is not sufficient to protect against the other attacks presented. For attacks via device code authentication, administrators can implement conditional access policies to limit suspicious connections from devices not under the control of the organization. For illicit consent grant attacks, the most effective measure is to only allow applications approved by administrators.

These three elements of hardening, although simple in appearance, can be the subject of real security projects to consider the existing configurations and usages, in particular by ensuring that existing applications are not blocked by these measures, and by implementing regular review and validation processes for new applications.

Bibliography

https://aadinternals.com/post/phishing/

https://jeffreyappel.nl/protect-against-oauth-consent-phishing-attempts-illicit-consent-attack/

https://positivethinking.tech/insights/what-is-an-illicit-consent-grant-attack-in-office-365/

https://docs.microsoft.com/en-us/azure/active-directory/develop/publisher-verification-overview

https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/user-admin-consent-overview

https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent

https://www.microsoft.com/en-us/security/blog/2021/07/14/microsoft-delivers-comprehensive-solution-to-battle-rise-in-consent-phishing-emails/

[1] https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code

Cet article Illicit consent grant attacks targeting Azure and Office 365: still a threat? est apparu en premier sur RiskInsight.

In fact, if there’s one thing you need to protect, it’s your administrators!

Whether it concerns authentication methods, third-party application permissions via APIs (allowing a third-party application to synchronize data with an external storage service, for example) or changing retention policies, an administrative action can significantly affect the data and security of the tenant on a larger scale. If it is necessary to make this point even more explicit, a Global Administrator has the ability to access all data or manage all the settings of Office 365, Windows 10, Azure AD… but also Azure!

What are the native functionalities in the Microsoft platform?

Which rights models within Microsoft 365?

To date, Microsoft 365 has two main levels of rights. These two levels schematically allow the delegation of administrative rights by adapting to different organisational models (small / medium / large, centralised / decentralised):

• Azure AD roles: Administration of Azure AD and Microsoft 365 services;
• RBAC roles: Administration of objects within services.

Level One: Using Azure AD roles to manage services

The person behind the opening of the tenant automatically takes over the role of General Administrator. He can then appoint other administrators to accompany him in his tasks. As far as possible, Global Admin’s rights should not be used in order to limit overexposure of the administration accounts. It is good practice to limit this general role to a maximum of 3-4 accounts. In addition, for almost all actions there is an equivalent service administration role (e.g. SharePoint Administrator, User Administrator, etc.).

These service administration roles are also known as Azure AD roles. Each service can be viewed as an Azure AD application. An administrator would thus be equivalent to the owner of the service in question. At the time of writing this article, Microsoft offers 59 different roles, which provides a good level of segregation of rights in most cases.

However, the default roles provide access to the entire Admin Service for the entire tenant and may in some cases provide access to the underlying data (e.g. for SharePoint Administrator, Exchange Administrator and User Administrator).

Figure 1 – Example of sensitive rights

In the case of advanced maturity, it is possible to go further in the segregation of rights by creating personalised Azure AD roles. In concrete terms, this means deciding what permissions this role has (e.g. “microsoft.directory/applications/create” allows you to create applications in Azure Active Directory).

The downside will be that it will be more complicated to audit the administration and that it will be necessary to monitor the evolution of services to ensure that permissions remain consistent with the needs of administrators.

Second level: Using the RBAC model to manage objects

Certain services such as Exchange Online, Intune, Security and Compliance Centres or Cloud App Security offer specific RBAC rights models.

As its name suggests, Role Based Access Control (RBAC), allows for the implementation of more refined permissions management; with the ability to define roles for defined perimeters (e.g. for certain user groups). For example, it will be possible to create “Helpdesk A” and “Helpdesk B” in Exchange Online to give support rights to two separate teams on a perimeter A and a perimeter B.

How to provision the accounts of administrators?

The first question is how to create an administrator’s identity. Two strategies are possible:

• The creation of an account in the organisation’s identity repository, which will then be synchronised with Azure AD (ex: wavestone.com);
• The creation of the account directly in Azure AD. This account will then be called “cloud-only” (example: wavestone.onmicrosoft.com).

Regardless of the administration role, it is recommended for a SaaS service such as Microsoft 365 that the account be located as close as possible to the administered resource. Here, this amounts to using cloud-only accounts. The objective is twofold: to protect against a possible unavailability or of a compromise of the organisation’s identity repository.

How to assign permissions?

The second question is how to assign the right privileges to the administrative roles created.

In the case of service administration

In order to assign an AAD role, it is possible to use 3 methods (via the portal or the corresponding PowerShell command):

• The Azure portal (portal.azure.com): this is the method that should be favoured, as it allows the association of rights as close as possible to the resources and the use of PIMs, which we will discuss in the rest of the article;
• The Microsoft 365 portal (admin.microsoft.com): it is possible to carry out the assignment of roles directly through the main administration portal. However, this method is not compatible with PIM;
• The use of third party IAM tools: these solutions now have connectors with Office 365 to perform identity and privilege provisioning. These solutions offer less granularity, are not compatible with PIM and are a source of common errors. For example, synchronisation is typically one-way, resulting in the administration account reappearing if it is only deleted in Azure AD.

Note that it is also now possible to assign an Azure AD role to a security group (Cloud only) via a preview feature. This may simplify certain administrative models, such as where the Unified Communications team needs the SharePoint Administrator role and Teams Administrator. However, be careful with the management of this group.

In the case of the administration of objects

For RBAC roles, the definition of roles is done directly in the administration platform of the service concerned. It is then possible to assign the role in question manually or to a security group, in the portal or via an IAM solution.

Figure 2 – Natives functionalities of the solution

How to build and implement your administration model?

What strategy to define your rights model?

The construction of a delegation model must be based on the principle of least privilege. The core of the work is to make an inventory of the cases of Office 365 administration usage and to match your teams with the available rights.

This can be an opportunity to rethink the organisation of teams dealing with the working environment. Two observations are quite significant:

• Mobile terminals and workstations are intended to be managed by unified solutions (UEM) such as Intune, Workspace One or MobileIron, and therefore by the same team.
• Security and compliance tools are increasingly integrated natively in Office 365. It is therefore necessary to break down the wall that existed between the workplace world and the security world, in order to create a team with the same ambition: to create and maintain a controlled and secure platform.

Office 365 has the particularity of bringing together a multitude of different services, such as file or information storage (SharePoint, OneDrive), communication tools (Exchange, Teams) but also security (Defender, Information Protection, etc.). It is therefore essential to group the services into categories and define a correspondence matrix between team and administration roles.

Concretely, we advise you first to use the default Azure AD roles for service administration, and then to define more granular roles with RBAC and custom roles.

It is also interesting to identify the most sensitive roles, such as those allowing access to data or security settings (for example: Global Admin, Exchange Admin, Security Administrator and Application Administration) in order to be able to adapt the security of these roles.

How to delegate administration rights on objects in a multi-entity context ?

Before talking about security in the strict sense of the word, there is another question. Although the configuration of services and security parameters can only be done centrally, local teams need to carry out support actions: creation or modification of an internal or guest account, resetting of authenticators, creation of a Microsoft 365 group or a distribution list, etc.

The service administration roles, the Azure AD roles, do not offer privilege segregation by perimeter; an Exchange Online administrator will therefore be able to handle all mailboxes. It will not be conceivable to give them in complex organisations or in regulated contexts. Several strategies are available, depending on the maturity and complexity of the organisation.

In the case of small structures, it is easiest to use the native functionalities:

• RBAC roles: RBAC Exchange and Intune roles generally provide the right level of granularity to manage objects in native portals;
• Administrative Units: Administrative Units, finally in GA since the end of September, are the equivalent of RBAC for Azure Active Directory. They take the form of containers in which an administrator can create or modify objects, which makes sense for support activities.

In the case of larger structures, good practice is not to manage objects (users, mailboxes, groups, SharePoint sites, etc.) directly in native portals. What is needed is an interface that allows all these objects to be managed, while taking into account the business logic and the target administration model. Below are three examples of interfaces:

• In-house development of a “Custom Automation Engine”: this interface will be decorrelated from the IAM and very often a large powershell / Graph API machine;
• Integration of a connector to the current IAM solution in order to present a complete management of the objects by disregarding their direct hosting;
• Investment in a SaaS Management Platform (SMP): software publishers have specialised in the creation of management tools for Office 365, combining object administration, licence management and security and operational supervision functions. Among these solutions, which are still relatively unknown, are ManageEngine, CoreView and Quadrotech.

Please note: this interface, dedicated to support teams, will be distinct from an interface open to all users allowing them to centrally create guest users, SharePoint sites, Teams, etc. In concrete terms, this second interface could be integrated with ITSM tools, SMP or even be developed based on Power Apps and Graph API.

How to protect access to these accounts ?

10 measures to secure administration accounts

Depending on the security licenses, mainly the EMS bundle, Microsoft provides a number of controls to secure administration accounts.

Most of these could also be obtained via third-party tools.

Basic measures to secure the administration account

1. A dedicated administrator account

An administrator must have an account dedicated to administration, different from the office automation account. It should be cloud-only where possible (e.g. wavestone.onmicrosoft.com).

2. Multi-Factor Authentication

Multi-factor authentication is no longer an option today, and even less so for administrators.

This measure is available for everyone, for all licences:

• Via MFA for Office 365 (also called MFA with per-person inheritance) which forces a challenge at every connection;
• Via Security Defaults which forces an additional factor to be registered for all users and imposes the MFA for administrators at each login;

It is also important to ensure that legacy authentication protocols that do not support MFA are disabled. These would allow single sign-on to be bypassed.

It will also make sense to limit the types of additional factors available; what is the point of securing administration accounts if the second factor is the administrator’s Gmail address.

Highly recommended security measures

3. Unlicensed Office 365 account

Without a licence, it will not be possible for an administrator to access the different services and data of the platform, or to have a mailbox.

Please note that some services, such as Power Apps or Power BI, require a licence to access the administration portal. In practice, it can be interesting to create a security group that allocates the necessary licences for administrators.

4. Conditional Access (with Azure AD P1)

Conditional access allows you to evaluate the context when accessing an Office 365 service and to authorise access accordingly. For example, access can be blocked depending on the type of workstation used (whether managed by the company or not), the network on which the user is connected, the application in question or the user’s administrative role.

In a Zero Trust logic, there should be no differentiation between the internal and external network, especially for administrators, but rather focus on the status of the workstation and the risk of connection.

5. Password Protection (with Azure AD P1)

Azure AD Password Protection provides controls over passwords. It will thus be possible to prohibit the use of a current password or a derivative (with a list predefined by Microsoft or maintained by the organisation).

A good practice is to apply this protection to all Cloud-only administration accounts as a minimum.

6. Azure AD Identity Protection (with Azure AD P2)

Azure AD Identity Protection adds a notion of risk in the evaluation of user access and behaviour. Concretely, it will be advisable to define the following policies;

• Risky users: Force password change for an administrator likely to be compromised (with a Medium or High risk);
• Risky sign-in: Forcing an MFA challenge during risky access (e.g. anonymous or unusual IP).

7. Azure AD Privileged Identity Management (with Azure AD P2):

Azure AD Privileged Identity Management is a service to control the assignment and use of administrative roles:

• Allocate just-in-time rights by giving an eligible role instead of a permanent one;
• Submit role activation to third party validation;
• Set up an end date for an administrative role;
• Force recertifications of administrators.

It will be relevant to distinguish the so-called sensitive roles from the others during implementation.

The monitoring of eligible administrators allows, as a bonus, to become aware of the real use of administration rights and therefore to clean up the list of administrators more easily.

It should be noted that the PIM functionalities have recently been extended to the different groups, which makes it possible to set up “Just-in-time” for more exotic cases such as RMS / AIP Super-Users.

To go even further

8. Supervision of administrator actions to detect abnormal behaviour

Once all these security measures are in place, all that remains is for you to implement supervision to detect non-compliance with the previous rules and abnormal behaviour.

And for this, nothing better than to refer to our article on the subject to understand the available logs.

9. Setting up a Privileged Access Workstation

Administration is by definition a critical action. It must be carried out within a perimeter of trust. The provision of PAW, or administration post, will enable us to achieve this objective.

The configuration of the administration station should be simple (no local administration rights, restricted Internet browsing, blocked USB ports, pre-installed PowerShell modules, etc.). But restricting the connection of an Office 365 administrator from this workstation may cause more problems. There are several possibilities for this:

• In a modern context, a simple answer is to rely on Microsoft tools: define an administration workstation profile in Intune and assign it to the administrators. With a conditional access rule, it is possible to require a compliant workstation when connecting.
• In a more traditional model, it is possible to set up an authentication silo with administrators and associated workstations. In this way, we would have a model similar to the third-party model well known to AD teams.
• Other approaches are also possible, even if more complex: association of a certificate and a reverse proxy or even a bastion.

10. Keep up to date with good practices and news

It cannot be repeated often enough that Office 365 is a Cloud platform and is constantly evolving. Keeping up to date will continue to increase its level of security over time.

Figure 3 – The security of accounts, measures that can be counted on the fingers of one hand

Focus on glass breaking accounts

A good practice in the administration of the Microsoft platform is the setting up of administrator accounts that allow control over the platform to be regained in the event of an incident.  These are called glass-breaking accounts. These accounts should allow full control over the Office 365 tenant and are therefore assigned the role of Global Administrator.

These accounts must be secure; however, we must not forget their specificity which consists in using them in the event of an incident. Thus, the security imposed on these accounts must remain compatible with the urgent nature of their use.  These accounts must therefore comply with the following recommendations:

• To be cloud-only accounts
• No MFA configured (or at least a third party MFA)
• Storage of the password in a safe which only identified members of the security team or Office 365 can access
• Setting up alerts to check that these accounts are not used outside of an incident procedure requiring the use of glass breakage.

It is also recommended not to use a specific naming convention for these accounts, they should not catch the eye of a possible attacker!

Conclusion

Security on Office 365 is based on technical measures to protect administrator accounts, as well as the implementation of a target administration model, which includes clear governance and processes, tools to implement this delegation of rights, and mechanisms to maintain it over time.

But whatever protection measures are implemented, security rests first and foremost with the administrators of the solution. Awareness raising and controls for administrators will be essential.

Administrators must bear in mind that their accounts give access to extremely sensitive information and actions: they are therefore the preferred target of hackers!

As O365 is constantly evolving, each new feature introduced by Microsoft may also bring with it its share of security problems that need to be studied and taken into account. Take the opportunity to update your documentation: O365 risk analysis, service configuration, delegation model…always without forgetting to allow your administrators to train!

Cet article How to manage administration in Microsoft 365? est apparu en premier sur RiskInsight.