Cybersecurity & Information Security

Investigating a Suspicious Microsoft 365 Account: Entra, Mailbox, and Defender

6 min readPublished: August 5, 2026
Professional visual illustration on Microsoft 365 account investigation in Cloud Security and IR
Quick answer

A Microsoft 365 account investigation requires connecting Identity, Audit Logs, API actions, resources, regions, and sessions. Begin by preserving evidence and building a timeline, then perform documented containment.

Cloud investigation requires connecting identities, Control Plane, resources, keys, sessions, and security services. Since activity is distributed across services and regions, a timeline and understanding permissions are critical. This article focuses on Microsoft 365 account investigations and is intended for SOC analysts and Cloud investigators. The goal is to provide a methodology that can be applied in practice, during professional interviews, and in a work environment, without settling for a dictionary definition.

The main challenge is that data is almost always partial. SigninLogs, AuditLogs, OfficeActivity can indicate a direction, but their meaning depends on time, asset, user, and expected activity. Therefore, we will build the investigation around an investigation question, required evidence, and a clear criterion for completion.

The practical scenario in the article is: A timeline of a simulated cloud account. All examples are lab data or process descriptions. When it comes to Penetration Testing, Web, or Cloud, one must work only with explicit permission, a defined scope, and the ability to stop the test.

Event Validation

A professional investigation of a Microsoft 365 account begins with success and failure conditions. Define a positive case, a negative case, a boundary case, and similar legitimate activity. This allows for the identification of both False Negative and False Positive.

In an authorized environment, use a minimal action that proves the claim without causing damage. Save Input, Output, time, and version, and after remediation, retest the same scenario and also check for regression on nearby functions.

Entra sign-ins and Risk

The topic 'Entra sign-ins and Risk' is a central part of Microsoft 365 account investigation. It is recommended to break it down into three questions: what is the input, what decision do you want to make, and what evidence is sufficient to justify it. These questions prevent automatic tool usage without understanding the purpose.

In practice, record SigninLogs, AuditLogs, OfficeActivity, inbox rules, OAuth consent, compare to expected behavior, and define at least one pivot. The result should be verifiable by another analyst, including limitations and next steps.

Mailbox and Audit

The topic 'Mailbox and Audit' is a central part of Microsoft 365 account investigation. It is recommended to break it down into three questions: what is the input, what decision do you want to make, and what evidence is sufficient to justify it. These questions prevent automatic tool usage without understanding the purpose.

In practice, record SigninLogs, AuditLogs, OfficeActivity, inbox rules, OAuth consent, compare to expected behavior, and define at least one pivot. The result should be verifiable by another analyst, including limitations and next steps.

OAuth, Sessions and Endpoints

In a Microsoft 365 account investigation, identity and authorization are two different questions: who is the client, and what are they allowed to do on the resource. Examine Roles, Claims, Session, Object ownership, and changes throughout the lifecycle, rather than just assuming the user is 'logged in'.

A test matrix includes an anonymous user, a regular user, an object owner, another user, and an administrator. For each action, compare the Response and server-side effect. Changing an identifier or header is merely a testing means; the evidence is whether the server approved or denied an action contrary to policy.

Containment and Recovery

The response to a Microsoft 365 account investigation should mitigate risk without deleting evidence still needed. Start with a reversible and focused action, confirm ownership and authority, and document time, action, and result.

Long-term remediation addresses the root cause: permissions, configuration, Validation, Telemetry, process, or training. After implementation, retest and monitor for recurrence, instead of just closing the ticket.

Unique Focus Areas

On this topic, it is recommended to build a focused evidence map in advance. The main focus areas are: SigninLogs, AuditLogs, OfficeActivity, inbox rules, OAuth consent, session revocation. This list is not an automatic checklist; each item is chosen because it can link an entity, action, and time or explain legitimate behavior.

  • SigninLogs: Define the expected value, what would be considered anomalous, and what additional source would verify the finding.
  • AuditLogs: Define the expected value, what would be considered anomalous, and what additional source would verify the finding.
  • OfficeActivity: Define the expected value, what would be considered anomalous, and what additional source would verify the finding.
  • inbox rules: Define the expected value, what would be considered anomalous, and what additional source would verify the finding.
  • OAuth consent: Define the expected value, what would be considered anomalous, and what additional source would verify the finding.
  • session revocation: Define the expected value, what would be considered anomalous, and what additional source would verify the finding.

When one of the focus areas is unavailable, document the gap and choose an alternative. For example, if a Process identifier is not stable, you can use time, Host, User, and Parent; if a Payload is encrypted, use Metadata, volume, frequency, and TLS/DNS context.

Practical Scenario

The chosen scenario is a timeline of a simulated cloud account. The purpose of the exercise is not to prove attack capability, but to practice safe collection, comparison, and documentation. Before starting, define simulated data, a time window, and an expected outcome.

At the end of the exercise, a product that another analyst or tester can review should be submitted: a screenshot or export of the evidence, a short timeline, an initial assumption, corroborating evidence, a limitation, and a recommendation. When there is insufficient evidence, the correct conclusion is that the scenario was not proven.

StageWhat to doDeliverable
PreparationDefine scope, time, and goal. List which fields or evidence from SigninLogs, AuditLogs, OfficeActivity are expected to appear.Short test plan
Data GenerationPerform a safe and simulated action related to Microsoft 365 account investigation, without real information or impact on a production system.Controlled event/request/flow
CollectionCollect the raw evidence and context from an additional source. Ensure time zone, identifiers, and integrity.Two linked pieces of evidence
AnalysisWrite what each piece of evidence proves, what it does not prove, and what the possible legitimate explanation is.Interim conclusion
CompletionChoose closure, escalation, finding, or tuning; add recommendation and retest.Documented deliverable

Practical Checklist

  • Check and document: Principal and session.
  • Check and document: API action.
  • Check and document: Resource and region.
  • Check and document: Source IP and user agent.
  • Check and document: Audit event ID.
  • Check and document: GuardDuty/Defender/SCC finding.
  • Specify Time zone, tool version, and collection time.
  • Save the raw data before filtering or modification.
  • Write what the finding proves and what is still unknown.
  • Define owner and next action with a due date.

Common Mistakes

  • Focusing on only one area.
  • Rotating a key before preserving the timeline.
  • Not checking AssumeRole or Token.
  • Ignoring the Control Plane.
  • Not mapping effective permissions.
  • Inferring that geographical location proves an attack.

Summary and CTA

Investigating a Suspicious Microsoft 365 Account: Entra, Mailbox, and Defender is a topic that connects technical knowledge with work discipline. Start with a question, collect only relevant evidence, preserve context and time, and choose an action that can be justified and retested.

In HPI's Cybersecurity & AI track, these principles are practiced using systems, logs, and labs. A natural progression is to move on to the linked articles, perform the lab exercise, and save the output as part of a professional portfolio.

FAQ

Does a Microsoft 365 account investigation alone prove an attack or weakness?

No. It provides a signal or finding that requires context, validation, and an additional source. A professional conclusion relies on a sequence of evidence and consistency with expected behavior.

What do you do when some data is missing?

Document the missing information, check for an alternative source, and reduce the level of certainty. Do not fill in fields with assumptions or present 'Unknown' as normal.

How long should evidence be retained?

The time depends on policy, regulation, cost, and the type of incident. It is important to define retention, legal hold, and the ability to export evidence in a verifiable format in advance.

How can one practice without risking a real system?

Use virtual machines, simulated data, CTFs, or a dedicated lab. In authorized tests, define Scope, Stop conditions, and backup before starting work.

Want to check if this track is right for you?

Leave your details and an HPI advisor will get back to you for a short, no-obligation fit call.

Your details are stored securely.

For SOC and Cyber Security studies within the Cybersecurity & AI program

Want to hear the details? Leave your info and we'll get back to you.

Related articles