Skip to content
Elastic Beat for fetching and shipping Office 365 audit events
Go Makefile Python Batchfile
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.


O365beat is an open source log shipper used to fetch Office 365 audit logs from the Office 365 Management Activity API and forward them with all the flexibility and capability provided by the beats platform (specifically, libbeat).

The latest release is v1.2.0, our first non-alpha release! It captures the updated documentation and new ECS field mapping processor in the default config file.

There is still a lot on the to-do list and probably more than a few bugs! Please open an issue or submit a pull request if you notice any problems in testing or production.

Getting Started with O365beat

The easiest way to get started with o365beat is to use the pre-built binaries available in the latest release.

These pre-built packages include configuration files which contain all the necessary credential information to connect to the audit logs for your tenancy. The default configuration file (o365beat.yml) pulls this information from your environment, like so:

  # period Defines how often API is polled for new content blobs
  # 5 min default, as new content (probably) isn't published too often
  # period: 5m

  # pull secrets from environment (e.g, > set -a; . ./ENV_FILE; set +a;)
  # or hard-coded here:
  tenant_domain: ${O365BEAT_TENANT_DOMAIN:}
  client_secret: ${O365BEAT_CLIENT_SECRET:}
  client_id:     ${O365BEAT_CLIENT_ID:}     # aka application id (GUID)
  directory_id:  ${O365BEAT_DIRECTORY_ID:}  # aka tenant id (GUID)
  registry_file_path: ${O365BEAT_REGISTRY_PATH:./o365beat-registry.json}

  # the following content types will be pulled from the API
  # for available types, see
    - Audit.AzureActiveDirectory
    - Audit.Exchange
    - Audit.SharePoint
    - Audit.General

See below for more details on these values.

NOTE: If you decide to hard-code these values, be sure to replace the ${:} syntax, which pulls from the environment. For example, use tenant_domain: not tenant_domain: ${}.

Prerequisites and Permissions

O365beat requires access to the Office 365 Management APIs for your tenancy. Instructions for getting this set up are available in the Microsoft documentation

Once you have this set up, you'll be able to get the information needed in the config file. One tricky thing is dealing with the odd naming conventions. If you look in o365beat.yml you’ll see some of the synonyms: client id is also called the application id, and the directory id is also called the tenant id. In the Azure portal, go to "App registrations" and you’ll see the Application (Client) ID – a GUID – right there in the application list. If you click on that you’ll see the application (client) id and the directory (tenant) id in the top area.

App Details in Azure Portal

The client secret is a little trickier, you can create them by clicking the "Certificates & secrets" link on the left there. Be sure to copy it somewhere or you’ll have to create a new one … there’s no facility for viewing them later. The default config file expect these config values to be in your environment (i.e., as environment variables), named O365BEAT_TENANT_DOMAIN, O365BEAT_CLIENT_SECRET, etc. You can hard-code them in that file if you like, especially when testing, just be smart about the permissions.

Finally, the azure app registration permissions should look like this:

App Permissions in Azure Portal

You can edit those using that “API permissions” link on the left, with more detailed instructions available from Microsoft. The beat should automatically subscribe you to the right feeds, though that functionality is currently undergoing testing.


To run O365beat with all debugging output enabled, run:

./o365beat --path.config . -c o365beat.yml -e -d "*" # add --strict.perms=false under WSL 1

NOTE: By default o365beat doesn't know where to look for its configuration so you have to specify that explicitly. If you see errors authenticating it may be the beat's not seeing your config. Future versions will have more helpful error messages in this regard.

Receive with Logstash

If you're receiving o365beat logs with logstash, use the input type beats:

input {
  beats {
    port => "5044"


As of v1.2.0, o365beat includes a processor to map the raw API-provided events to Elastic Common Schema (ECS) fields. This allows this beat to work with standard Kibana dashboards, including capabilities in Elastic SIEM.

Implementing this as a processor means you can disable it if you don't use the ECS functionality, or change from "copy" to "rename" if you only use ECS. We may end up adding some ECS stuff in the "core" of the beat as well, but this is a decent start.

See the Office 365 Management API schema documentation for details on the raw events. The ECS mapping is as follows (excerpt from o365beat.yml):

# from:
# to:

  - convert:
        - {from: "Id", to: "", type: string}                # ecs core
        - {from: "RecordType", to: "event.code", type: string}      # ecs extended
        # - {from: "CreationTime", to: "", type: ""}                # @timestamp
        - {from: "Operation", to: "event.action", type: string}     # ecs core
        - {from: "OrganizationId", to: "", type: string} # ecs extended
        # - {from: "UserType", to: "", type: ""}                    # no ecs mapping
        # - {from: "UserKey", to: "", type: ""}                     # no ecs mapping
        - {from: "Workload", to: "event.category", type: string}    # ecs core
        - {from: "ResultStatus", to: "event.outcome", type: string} # ecs extended
        # - {from: "ObjectId", to: "", type: ""}                    # no ecs mapping
        - {from: "UserId", to: "", type: string}             # ecs core
        - {from: "ClientIP", to: "client.ip", type: ip}             # ecs core
        # - {from: "Scope", to: "", type: ""}                       # no ecs mapping

Please open an issue or a pull request if you have suggested improvements to this approach.

If you'd like to build yourself, read on.

Build Requirements


To build the binary for O365beat run the command below. This will grab vendor dependencies if you don't have them already, and generate a binary in the same directory with the name o365beat.


Test (none so far!)

To test O365beat, run the following command:

make testsuite


make unit-tests
make system-tests
make integration-tests
make coverage-report

The test coverage is reported in the folder ./build/coverage/


Each beat has a template for the mapping in elasticsearch and a documentation for the fields which is automatically generated based on fields.yml by running the following command.

make update


To clean O365beat source code, run the following command:

make fmt

To clean up the build directory and generated artifacts, run:

make clean


To clone O365beat from the git repository, run the following commands:

mkdir -p ${GOPATH}/src/
git clone ${GOPATH}/src/

For further development, check out the beat developer guide.


The beat frameworks provides tools to cross-compile and package your beat for different platforms. This requires docker and vendor-ing as described above. To build packages of your beat, run the following command:

make release

This will fetch and create all images required for the build process. The whole process to finish can take several minutes.


  • Tests
  • Update underlying libbeat to 7.3.x (currently 7.2.x)
  • ECS field mappings beyond the API's common schema
  • ECS field mappings for API's common schema
You can’t perform that action at this time.