Wazuh Microsoft 365 monitoring

The Wazuh server pulls Microsoft 365 audit data from the Office 365 Management Activity API. Nothing pushes events into Wazuh. The chain has four links: an Entra ID app registration authenticates to the API, the tenant's audit content types are enabled as subscriptions, the Wazuh server retrieves content blobs on a schedule, and decoders and rules convert the raw records into alerts stored in the Wazuh indexer. Each link has a configuration owner. Your identity team owns the app registration and its permissions, your Microsoft 365 administrators own the audit settings in the tenant, and your Wazuh team owns the server, decoders, rules and polling. Confirm the exact permissions, subscription steps and outbound endpoints in the current Wazuh documentation before you open firewall rules, because the Wazuh server needs network paths to Microsoft's endpoints.

The first decision is which workloads to subscribe to. Exchange, SharePoint, OneDrive and Teams are the workloads named for this topic, but each subscription adds a separate content stream with its own event types, volume and alert logic. Start with the workloads that produce your highest-risk signals, such as mailbox access and sharing changes, and confirm with Microsoft's current documentation which content types each workload publishes. Subscribing to everything at once makes it harder to tune rules, because you cannot tell which noise belongs to which source. A narrower first subscription also gives your SOC a short list of alerts to validate before the rule set grows.

The second decision is the polling interval, which sets alert latency. The Wazuh server only checks for new content when it polls, so the interval controls the longest wait between an action in Microsoft 365 and the matching alert in the dashboard. Microsoft also makes audit content available with its own delay after the event occurs, so the end-to-end latency is the combination of both. Ask your SOC which alerts need near-immediate handling and which can wait for a batch review, then test the interval against those expectations. A shorter interval means more API calls and more processing on the server, so check the documented API limits for your tenant and set the interval with those limits in mind.

The third decision is ingestion volume. Volume depends on the subscribed content types, the size of your tenant, how many users generate audit activity, and how many decoders and rules process each record. Plan indexer storage and retention from a measured baseline rather than from assumptions. A practical approach is to enable one workload in a test tenant or a pilot group, measure the records and alerts it produces over a representative period, and then add workloads one at a time. Ask any partner for a sizing method that uses your tenant's real audit volume, and record which assumptions the estimate depends on.

This page covers only the Management Activity API path. It does not cover agent-based collection on Microsoft hosts, such as installing Wazuh agents on Windows servers or endpoints to collect host telemetry. That is a different collection method with different deployment work, and it does not replace tenant-level audit collection. Decide early whether you need both, because the two methods produce different event types, need different permissions, and feed different alert rules.

Start with a first alert set small enough that every alert gets reviewed, and limit it to activity where a single event is already suspicious. Group candidate alerts into four categories: mailbox rule creation and forwarding changes, sharing link creation and external sharing, administrative changes close to sign-in such as authentication method changes and privileged role assignments, and bulk download or mass deletion of SharePoint and OneDrive content. For each category, check which rules already ship with the Wazuh server and which gaps need local rules. Take rule names and IDs from the ruleset installed on your server and from your own tuning files, not from this page or from older examples online.

Test every rule against sample events before it goes live. Pull a real audit record for each operation from your own tenant, generated by a test account performing a harmless action, and run it through the Wazuh log test tool on the server. Confirm that the decoder extracts the fields the rule depends on, that the rule fires at the level you expect, and that a near-miss event from an ordinary user does not fire it. Operation names in the Office 365 Management Activity API must be confirmed from a live tenant, because the names you find in documentation or community posts may not match the records your tenant actually produces. Keep each test sample in version control next to the rule it proves.

Set severity by asking who acts on each category and how quickly. Mailbox forwarding changes usually belong with the security operations queue, while administrative changes near sign-in belong with the identity team on call. Wazuh alert levels decide what appears in the dashboard and what the integrator forwards, so a rule set where most alerts are high severity trains responders to ignore them. Reserve the top levels for events that need action within the hour, and route only those to paging channels using level and group filters. Confirm the paging path works with a controlled test alert before you rely on it, and record who receives each level.

Document the finished rule set as evidence of monitoring scope. For each rule, record its ID, title, whether it ships with Wazuh or was written locally, the Microsoft 365 operation it depends on, its expected level, its owner, the date of its last test and any tuning changes. The register also shows gaps, which assessors often ask about more directly than the rules themselves. Ask your assessor or compliance lead what format they expect. Review the register after each Wazuh upgrade, because shipped rules can change between releases and your local rules may need adjustment.

Before anyone relies on Wazuh alerts from Microsoft 365, run a test plan that proves the feed carries known actions into the Wazuh indexer and that the matching rules fire correctly. Use a non-production or tightly controlled tenant, and perform a small set of actions whose outcome you can predict: create an anonymous or organization sharing link on a test file, add a mailbox forwarding or inbox rule to a test mailbox, and upload a file to a Teams channel. Record the time and the account used for each action. Then confirm in the indexer that each event appears with the fields your rules depend on, such as the operation name, the acting user, the workload, the object identifier and the client address. Field names depend on your deployment, so confirm them against your own indexed events rather than a generic list.

Next, check the alerting behavior. Each test action should produce one alert from the matching rule, not zero and not several. Duplicate or repeated alerts usually point to overlapping collection windows, a rule that matches more than one field, or events being indexed twice, so inspect the alert history for each test ID. Measure the delay between the action and the alert, and compare it with the response-time requirement your security team set before testing began. Write that requirement down first. If the measured delay is longer than the requirement, identify where the time goes, including the latency of the Microsoft audit data itself, which you should confirm in Microsoft's documentation for the log types you collect.

Then test the failure modes that cause silent gaps. Restart the Wazuh server while the collector is running, perform a new test action after the restart, and confirm that events from before the restart are not indexed a second time and that the new action is picked up. Next, rotate the app registration credential in the test tenant following your normal rotation procedure. Confirm that the feed resumes without manual rework and that any action performed during the rotation window either appears after the feed resumes or is recorded as a known gap. Repeat these checks after each upgrade of the Wazuh server or change to the collection settings, because those changes can alter behavior.

Keep the results as evidence. For each test, record the test identifier, the action performed, the time and actor, the expected and observed fields, the alert identifier, the measured delay, the pass or fail result, the tester and the configuration version in use. Attach these records to the change ticket for the deployment, and store them where your compliance lead can retrieve them. A compliance assessor who asks how the monitoring was validated will expect this kind of record. DeployOpen can prepare the test plan and the evidence pack, but the independent assessor decides whether the evidence meets the framework requirement.