Can Your Microsoft 365 Tenant Answer ‘What Did That Account Do?’

Logs you cannot search are not a security control. Many Microsoft 365 tenants find that out in the middle of an incident, when the question is simple: what did this account do, and when?

The fix is cheap and boring, and it is best done before anything goes wrong. This article covers a short set of checks that tell you whether your tenant can answer that question.

Why logs decide the outcome

When an account is taken over, responders typically need to answer four things. How did the attacker get in? What did they touch? Did they create persistence, such as inbox rules, forwarding or app consents? Is the access closed?

Every one of those questions is answered from audit data. If auditing was off, retention was too short, or nobody knows who can run a search, the honest answer becomes “we cannot tell.” That often means a wider and more expensive cleanup, because you have to assume the worst.

Six checks to run this week

1. Confirm the Unified Audit Log is on. In Exchange Online PowerShell:

Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled

You want to see True. If it is False, turn it on and note the date, because anything before that date is probably gone.

2. Verify mailbox auditing is not disabled at the organization level. Mailbox auditing is on by default in current tenants, but defaults can be overridden:

Get-OrganizationConfig | Format-List AuditDisabled

You want to see False.

3. Find out your actual retention. Retention commonly depends on licensing and settings, and the default period can be shorter than the time an intruder sits unnoticed. Write down the real number for your tenant, then ask whether it is long enough for how quickly you would realistically notice a problem.

4. Look at sign-in and directory logs in Entra. Retention in the admin portal is also limited. If you want a longer history, export those logs to storage you control, or to a monitoring platform.

5. Run a search drill. Pick a test account, create a harmless inbox rule, then confirm you can find that event in the audit search. Do this before an incident, and confirm which role holders are allowed to search. A tool nobody has permission to use does not help at 2 a.m.

6. Alert on the high-signal events. Commonly useful ones include new inbox rules, new forwarding, new OAuth consent grants, changes to MFA methods, and new admin role assignments. These are the quiet steps that business email compromise often relies on.

Rollout notes

• Turning on auditing is low risk, but exporting logs can add storage cost and access questions. Decide who owns the exported data and who can read it.
• Treat the exported logs as sensitive. They can include user activity details.
• Document the search procedure on one page and keep a copy outside the tenant.

If you suspect an incident right now

Do not wait for a perfect log review before acting. Contain promptly: reset the account credentials, revoke sessions and tokens, and remove rules, forwarding and app consents. In parallel, export or preserve the relevant audit data so it does not age out of the retention window while you work.

Logging does not stop an attack. What it does is turn a long argument about what might have happened into a short, evidence-based answer. That tends to make containment faster and scoping more accurate.

Message us to talk through your M365 logging plan.