Azure Activity Log analysis, step by step, in your browser

TL;DR. Export the Activity Log (plus Key Vault, storage and flow logs if you have them), open the Azure Forensics analyzer, drop the files or a ZIP, and read in this order: coverage → verdict → findings → timeline → entities → remediation. Everything runs locally as WebAssembly in a Web Worker; nothing leaves the browser. Budget 30 minutes for a first pass on a typical subscription.

This is the procedure I follow when someone hands me a folder of Azure exports and asks "were we breached?". The tool gives a fast first answer; the steps below are about reading that answer critically.

Before you start: what to load

The analyzer reads these sources and recognises each format automatically:

Loose files, whole folders (the resourceId=/…/PT1H.json trees), ZIPs and .gz files work as they are. If you do not have exports yet, how to export the Activity Log and resource logs lists the commands.

Include at least a week before the suspected start. Several rules are "first seen" rules that learn what is normal during the first 72 hours of the data; without that history they cannot run.

Step 1: load the files

Open the analyzer. Drop files on the drop zone, or use Choose files / Choose a folder. ZIPs are unpacked in the browser. Each file is read in 4 MB chunks and streamed to the Rust analyzer, so multi-gigabyte exports do not need to fit in memory twice.

To see what a result looks like first, click Try a sample. It loads a synthetic export of a fictional company (Kestrel Freight) and is labelled as such on screen. The fictional incident walkthrough explains that sample finding by finding.

Step 2: check coverage before the verdict

The Coverage block is the most important thing on the page and the most often skipped. It lists, per source — Activity Log, Key Vault, Storage, NSG / VNet flow logs, Defender for Cloud — the number of events and the time range, or "not provided".

Below it, the tool lists detections that could not run, with the reason:

• log source not provided — for example, all Key Vault rules when no AuditEvent log was loaded;
• needs more than 72 h of history — first-seen rules on a short export.

A "Clean" verdict with Key Vault and storage marked "not provided" means "the control plane looks clean"; it says nothing about data access. The limitations article covers this in depth.

Also look at the Files tab: every file skipped is explained (empty, not a log, Avro, Parquet, UTF-16, unreadable ZIP), and duplicates across exports are counted and merged.

Step 3: read the verdict and the findings

The verdict is deliberately simple and documented:

Why lists the rule IDs behind the verdict. Each finding then shows:

• the rule title and severity, and a stable rule ID (AZ-RBAC-003, AZ-VM-001…) you can cite in a report;
• how many distinct actions matched, first and last seen;
• the principals, IPs and resources involved;
• groups for threshold rules (for example one caller reading 12 distinct secrets within an hour);
• network flows for flow rules;
• MITRE ATT&CK techniques, linked.

Read every high finding's evidence. A rule is a heuristic: a platform team assigning Owner, or a backup job reading hundreds of blobs, can match. The detections table on the tool page lists every rule, and the rule file itself documents each rule's known false positives.

Step 4: walk the timeline

The Timeline tab lists every event behind a medium, high or critical finding, in chronological order. This is where an attack chain becomes readable: role assignment, then Run Command, then a managed-identity token used from outside, then secrets read, then a SAS minted, then logging deleted.

Click an event to see the normalised fields (operation, caller, caller type, application ID, object ID, IP, resource, user agent, correlation ID, source file) and the original record exactly as exported. Switch between UTC and local time with the toggle; report in UTC.

The correlationId matters: the Activity Log writes several events for one operation (Started, Accepted, Succeeded). The analyzer counts distinct actions, but when you quote an event in a report, quote the correlation ID too.

Step 5: pivot on principals, IPs and resources

The Entities tab is the pivot table of the investigation:

• Principals: users, service principals, managed identities, SAS tokens (identified by a hash) and anonymous access, with first and last seen and the number of findings.
• IP addresses: public or private, with flow-log totals sent and received when flow logs were loaded.
• Resources: filterable by Key Vaults, storage accounts, VMs and network.
• Subscriptions.

Click any row to filter the Events table to it. The question to ask of an attacker IP is "what else did this IP do?". The question to ask of a compromised identity is "when did it first behave differently?".

The Events table also supports free-text filtering (operation, principal, IP, resource, rule), source and result filters, and a Flagged only switch.

Step 6: remediation and export

The Remediation tab turns the findings into an ordered checklist: rotate credentials, remove role assignments, isolate VMs, rotate Key Vault secrets and storage keys, restore logging and Defender plans, block IPs, investigate the identity side in Entra ID. Ticks are kept in the page only.

For the case file:

• CSV exports the events table (with a guard against spreadsheet formula injection);
• JSON report exports the full result: verdict, findings, timeline, entities, coverage.

What the tool will not do for you

• It does not see anything you did not export. No API calls, no tenant access.
• It does not analyse Entra ID sign-ins or app credentials; that is the job of the sibling m365forensics.com.
• It does not prove absence. A careful attacker can stay under a threshold.

For the process around the tool — what to preserve first, how to contain — start from the incident response guide.

Related articles

• How to export the Azure Activity Log and resource logs
• An Azure breach, walked through (fictional case)
• Azure log forensics limits: retention and missing logs