Cybersecurity & Information Security

Azure Security Incident Investigation: Sentinel, Entra, and Defender

6 min readPublished: August 5, 2026

Professional visual illustration on the topic of Azure security incident investigation in the field of Cloud Security and IR

Quick answer

Azure security incident investigation requires connecting Identity, Audit Logs, API actions, resources, Regions, and Sessions. Start 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 Azure security incident investigation and is intended for SOC and Cloud analysts. The goal is to provide a working 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. Microsoft Sentinel, Entra sign-ins, and Activity Logs can indicate a direction, but their meaning depends on time, asset, user, and expected activity. Therefore, we will build the investigation around an investigative question, required evidence, and a clear completion criterion.

The practical scenario in the article is: a scenario of unusual permission and resource change. All examples are laboratory data or process descriptions. When dealing with Penetration Testing, Web, or Cloud, one must work only with explicit permission, a defined Scope, and the ability to stop the test.

Defining Tenant/Subscription Scope

The process of investigating an Azure security incident is built in stages with stopping points. Define a goal, Scope, sources, permitted actions, required evidence, roles, and a completion criterion. In offensive environments, add Stop conditions and an emergency channel.

Each stage must have a clear Output: an asset map, Timeline, Finding, Rule, Playbook, or report. Moving to the next stage occurs only when the Output is sufficient and reliable; this prevents random work or scope creep without approval.

Entra and Identity

The topic 'Entra and Identity' is a central part of working on Azure security incident investigation. It is recommended to break it down into three questions: what is the input, what decision do we want to make, and what evidence is sufficient to justify it. These questions prevent automatic tool use without understanding the goal.

In practice, list Microsoft Sentinel, Entra sign-ins, Activity Log, Defender for Cloud, resource changes, compare to expected behavior, and define at least one Pivot. The result should be verifiable by another analyst, including limitations and next steps.

Activity logs and Resources

The topic 'Activity logs and Resources' is a central part of working on Azure security incident investigation. It is recommended to break it down into three questions: what is the input, what decision do we want to make, and what evidence is sufficient to justify it. These questions prevent automatic tool use without understanding the goal.

Defender and Sentinel

The topic 'Defender and Sentinel' is a central part of working on Azure security incident investigation. It is recommended to break it down into three questions: what is the input, what decision do we want to make, and what evidence is sufficient to justify it. These questions prevent automatic tool use without understanding the goal.

Containment, Recovery and Review

The response to an Azure security incident investigation should reduce risk without deleting evidence that is still needed. Start with a reversible and focused action, confirm ownership and authority, and document time, perpetrator, and result.

Long-term remediation addresses the root cause: permissions, configuration, Validation, Telemetry, process, or training. After implementation, retest and monitor for signs of recurrence, rather than settling for closing a Ticket.

Unique Checkpoints

For this topic, it is recommended to build a focused evidence map in advance. The main checkpoints are: Microsoft Sentinel, Entra sign-ins, Activity Log, Defender for Cloud, resource changes, managed identity. This list is not an automatic Checklist; each item is chosen because it can link an entity, action, and time or explain legitimate behavior.

Microsoft Sentinel: Define the expected value, what would be considered abnormal, and what additional source would verify the finding.
Entra sign-ins: Define the expected value, what would be considered abnormal, and what additional source would verify the finding.
Activity Log: Define the expected value, what would be considered abnormal, and what additional source would verify the finding.
Defender for Cloud: Define the expected value, what would be considered abnormal, and what additional source would verify the finding.
resource changes: Define the expected value, what would be considered abnormal, and what additional source would verify the finding.
managed identity: Define the expected value, what would be considered abnormal, and what additional source would verify the finding.

When one of the checkpoints is unavailable, the gap must be documented and an alternative selected. For example, if a Process identifier is unstable, one can use time, Host, User, and Parent; if a Payload is encrypted, use Metadata, volume, frequency, and TLS/DNS context.

Recommended Workflow

Define a Scope and a single working question regarding Azure security incident investigation.
List the data sources and required evidence: Microsoft Sentinel, Entra sign-ins, Activity Log, Defender for Cloud.
Create a short Baseline of normal behavior or expected outcome.
Perform the minimal test in a lab environment and save time, input, and output.
Build a Timeline or comparison table and separate fact from interpretation.
Pivot to an additional source to confirm or refute the initial explanation.
Summarize the decision, limitations, recommended action, and Retest criterion.

Practical Scenario

The chosen scenario is an unusual permission and resource change scenario. 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 must be submitted that another analyst or tester can review: a screenshot or Export of the evidence, a short Timeline, an initial hypothesis, corroborating evidence, a limitation, and a recommendation. When there is insufficient evidence, the correct conclusion is that the scenario has not been proven.

Stage	What to do	Output
Preparation	Define Scope, time, and goal. List which fields or evidence from Microsoft Sentinel, Entra sign-ins, Activity Log are expected to appear.	Short test plan
Data Generation	Perform a safe and simulated action related to Azure security incident investigation, without real information or impact on a production system.	Controlled event/request/flow
Collection	Collect the raw evidence and context from an additional source. Verify Time zone, identifiers, and integrity.	Two linked pieces of evidence
Analysis	Write what each piece of evidence proves, what it does not prove, and what is the possible legitimate explanation.	Interim conclusion
Completion	Choose closure, escalation, Finding, or Tuning; add a recommendation and Retest.	Documented output

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.
State Time zone, tool version, and collection time.
Save the raw data before filtering or changing.
Write what the finding proves and what is still unknown.
Define owner and next action with due date.

Common Mistakes

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

Summary and CTA

Azure Security Incident Investigation: Sentinel, Entra, and Defender is a topic that connects technical knowledge to 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 to linked articles, perform the lab exercise, and save the output as part of a professional portfolio.

FAQ

Does Azure security incident 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 chain of evidence and alignment with expected behavior.

What to do when some data is missing?

Document the missing data, 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?

Retention time depends on policy, regulation, cost, and incident type. It is important to pre-define Retention, Legal hold, and the ability to export evidence in a verifiable format.

How to practice without risking a real system?

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