> For the complete documentation index, see [llms.txt](https://msdocs.aohwv.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://msdocs.aohwv.com/quick-start/step-4-microsoft-365.md). # Step 4 — Microsoft 365 Microsoft 365 audit logs show what people do inside **Exchange, SharePoint, OneDrive and Teams**: inbox rules, mailbox access, file downloads and sharing. When an account is compromised, these logs show what the attacker did after getting in. Unlike the other sources, Microsoft 365 logs **don't use the Event Hub**. Your SIEM pulls them directly from Microsoft through the **Office 365 Management Activity API**. {% hint style="info" %} **Time:** about 20 minutes {% endhint %} ### Before you start * **Global Administrator**, or **Application Administrator** plus **Compliance Administrator** * Your SIEM vendor's guide for its **Microsoft 365** or **Office 365** connector ### 1. Confirm auditing is on Auditing is on by default for most organizations, but it's worth checking. 1. Sign in to the [Microsoft Purview portal](https://purview.microsoft.com). 2. Go to **Solutions** → **Audit**. 3. If you see a banner that says **Start recording user and admin activity**, select it. If there's no banner, auditing is already on. {% hint style="info" %} If you just turned auditing on, it can take up to a few hours before records appear. {% endhint %} **Optional:** to confirm with PowerShell, connect to Exchange Online and run: ```powershell Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled ``` **True** means auditing is on. ### 2. Create an app registration for your SIEM Your SIEM needs its own identity to read the audit logs. 1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com). 2. Go to **Entra ID** → **App registrations** → **+ New registration**. 3. **Name:** siem-m365-audit 4. **Supported account types:** *Accounts in this organizational directory only* 5. Select **Register**. 6. On the app's **Overview** page, copy the **Application (client) ID** and **Directory (tenant) ID**. ### 3. Grant permissions 1. In the app, go to **API permissions** → **+ Add a permission**. 2. Select **Office 365 Management APIs** → **Application permissions**. 3. Under **ActivityFeed**, check **ActivityFeed.Read**. 4. Select **Add permissions**. 5. Select **Grant admin consent for *****\[your organization]***, then **Yes**. {% hint style="info" %} **Setting up** [**Purview (Step 6)**](/quick-start/step-6-purview.md) **too?** It uses this same app. You'll add one more permission there, so you don't need a second app. {% endhint %} ### 4. Create a credential 1. In the app, go to **Certificates & secrets**. 2. Use the option your SIEM supports. Check your SIEM's Microsoft 365 connector guide: * **Certificate (more secure):** upload a certificate your SIEM provides or supports. Use this if your SIEM allows it * **Client secret (most common):** select **+ New client secret**, set an expiry, and copy the **Value** immediately (it's only shown once) {% hint style="danger" %} **Treat the secret like a password.** Store it in Azure Key Vault or your password manager. Set a reminder before it expires, because when it does, logs stop flowing to your SIEM with no warning. {% endhint %} {% hint style="warning" %} **Using a client secret? Reduce the risk:** * Set a **short expiry**, such as 6–12 months, and rotate it on schedule * Use this app **only** for your SIEM, with **ActivityFeed.Read** and nothing else * Make sure **ServicePrincipalSignInLogs** are collected (Step 2), so your SOC can see if the app signs in from somewhere unexpected * With **Workload ID**, limit the app to your SIEM's IP addresses using Conditional Access {% endhint %} ### 5. Connect your SIEM Enter these in your SIEM's Microsoft 365 connector: | Detail | Where to find it | | --------------------- | ------------------------------------------ | | Tenant ID | App **Overview** → Directory (tenant) ID | | Client ID | App **Overview** → Application (client) ID | | Certificate or secret | From part 4 | Your SIEM will ask which **content types** to collect: | Content type | Collect? | What it includes | | ------------------------------ | ------------------------------------------------------------------------------ | ---------------------------------------------------------------- | | **Audit.Exchange** | **Yes** | Inbox rules, mailbox access, mail forwarding, permission changes | | **Audit.SharePoint** | **Yes** | SharePoint and OneDrive file access, downloads and sharing | | **Audit.General** | **Yes** | Teams, Copilot, Power Platform and other services | | **Audit.AzureActiveDirectory** | **No** | Entra ID sign-ins and changes, already collected in Step 2 | | **DLP.All** | **Yes (if you use DLP.** [**See Step 6**](/quick-start/step-6-purview.md)**)** | Data loss prevention events | {% hint style="warning" %} **Filter out everyday Copilot use.** Audit.General includes everyday Copilot use (**CopilotInteraction**), which tracks usage rather than threats. See **Step 5 — Copilot** for how to filter it. {% endhint %} ### What your SOC can detect with these logs * **Inbox rules** that forward, hide or delete mail, a classic sign of email compromise * **Mail forwarding** set up to an outside address * **Mailbox access** (MailItemsAccessed), showing which emails an attacker read * **Mass file downloads** from SharePoint or OneDrive * **Files shared** with outside or anonymous users * **Mailbox permission changes**, such as one user granted access to another's mailbox * **eDiscovery searches** that could be used to find sensitive data ### Verify 1. Open a file in SharePoint or OneDrive. 2. In the Purview portal, go to **Audit** and search for your activity to confirm it was recorded. 3. In your SIEM, search for the same event. Microsoft 365 audit data can take **several hours** to arrive, so check back later if it's not there yet. {% hint style="info" %} **Have Defender for Cloud Apps?** Much of this activity also arrives through Defender XDR in the CloudAppEvents table (Step 3). Ask RedLegg whether to collect both or rely on one. {% endhint %} ## Related * [Step 3 — Defender XDR](/quick-start/step-3-defender-xdr.md) — Alerts and endpoint, email and identity events * [Step 5 — Copilot](/quick-start/step-5-copilot.md) — Filtering everyday Copilot use --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://msdocs.aohwv.com/quick-start/step-4-microsoft-365.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.