> For the complete documentation index, see [llms.txt](https://otter.gitbook.io/red-teaming/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://otter.gitbook.io/red-teaming/notes/aad/overview-of-azure-and-m365.md).

# Overview of Azure & M365

AAD (Azure Active Directory) is an identity and access management service: it allows users and applications to access resources like VMs, storage accounts or the M365 suite. All resources are maintained inside a Tenant which represent a company (like a domain for on-prem context).

### Tenancy structure and elements

Inside a tenant there is a **root management group** which is not enabled by default, under this group you can have child management groups, the following is the hierarchy for groups inside a tenant:

* AAD Tenant
  * Root Management Group (not enabled by default)
    * Child Management Group (enabled only if RMG is enabled)
      * Subscription
        * Resource Group
          * Resource

There are more than 200 types of resources in Azure but these are the most common ones

* Applications: serverless web application, API hosting
* Service Principal: an "identity" used to represent an application to access other resources Applications in AAD can be granted further access to other resources in the tenant using the a **service principal**, an entity that is automatically created along with the application. **Since single-factor authentication is the only authentication method supported for service principals, they represent a high-value target for threat actors.**
* Key Vaults: vault that stores secrets / certs / API keys ...
* Automation Accounts: equivalent of a service account that runs code to perform tasks inside a subscription
* Storage Accounts: accounts used to access cloud storage services
* Virtual Machines: cloud-hosted endpoints
* SQL Database: cloud-hosted SQL databases
* Managed Identity: an identity representing a single resource or a group of resources to facilitate authentication These are a type of service principal but they represent resources instead of applications and they allow access to those resources without the need for credentials; managed identities can either be user-assigned or system-assigned

### AAD roles vs RBAC roles

AAD roles (like *Global Admin*, *User Admin* ...) manage access to actions such as editing users or VMs while **RBAC** (Azure Role-Based Access) roles (like *Owner*, *Contributor*, *Reader* ...) manage access to Azure resources like VMs and storage accounts. AAD roles relate to the actual AD tenant itself (*Global Admin of the tenant*) while RBAC roles are more specific to the subscription, resource groups or management group.

### Azure Users & Groups

`user principal name` = email address of the user `object ID` = identifier of the user in Azure

Groups are a way to manage users in bulk; users can be added to groups in two ways:

1. Assigned manually by the administrator or group owner
2. Dynamically placed in a group based on parameters / characteristics / attributes of the user itself

### Hybrid Azure Environments

These are environments that configure ADFS (Active Directory Federation Services) and AAD.

A hybrid environment can be set up with three different types of authentication methods

1. AAD password hash synchronization (PHS): on-prem users use the same username and password to access AAD (this is the most common method)
2. Azure pass-through authentication (PTA): password validation is performed through an *agent* hosted on a on-prem server which validates the user's credentials, the password validation doesn't happen in the cloud but in the on-prem AD environment. This allows organizations to enforce on-prem security / password policies
3. Federation: the entire authentication process occurs on-prem

### Single Sign-on

This authentication mechanism is compatible with PHS and PTA; it allows users to sign directly into AAD without needing to type in their passwords, this is done by using **PTRs** (Primary Refresh Tokens).

### Log Sources

**Main Log Sources**

* Unified Audit Logs: collection of all logs pertaining M365
* Azure Audit Logs: tracks changes in AAD at a subscription level
* Azure Sign in Logs: tracks sign-in events in AAD
* Azure Activity Logs: tracks activities and actions take at a subscription level
* Message Tracing Logs: tracks the flow of emails within an organization

**Secondary Log Sources**

* AAD Provisioning Logs: tracks identities and actions taken on various systems
* Azure Resource Logs: tracks operations performed within a resource, not enabled by default
* Diagnostic Logs: allow to export logs and metrics of a resource
* Security Reports: tracks suspicious activities

The following is a table representing the values default values for log retention

|     Log Source     | AAD Free |    AAD P1    |    AAD P2    |
| :----------------: | :------: | :----------: | :----------: |
|  Azure Audit Logs  |  7 Days  |    30 Days   |    30 Days   |
| Azure Sign-in Logs |  7 Days  |    30 Days   |    30 Days   |
| Unified Audit Logs |  30 Days | Up to 1 year | Up to 1 year |

### Primary Refresh Tokens - PRTs

This kind of tokens are made of two components:

* Access token
* Refresh token

They allow authentication across all applications, the tokens are stored as a JWT and **they are issued with MFA** which means that a valid PRT allows to bypass MFA for a user.

PRTs begin with the string `eyJ` and can be fully decoded since they are JSON Web Tokens, if we actually decode one we'll be able to see that it's made of 3 main fields

1. Refresh token
2. `is_primary`: a boolean flag that tells us whether the token is primary or not
3. `request_nonce`