Microsoft Sentinel: Automating Threat Response in Azure

Azure Sentinel (Microsoft Sentinel)

Microsoft Sentinel is Azure’s cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation and Response) platform — a single service that collects security data from across your entire estate, detects threats using AI and analytics, investigates incidents, and automates responses.


What Sentinel Actually Is — SIEM + SOAR Combined

SIEM (Security Information and Event Management)
→ Collects logs from everything
→ Correlates events across sources
→ Detects threats using rules + AI
→ Surfaces alerts and incidents
SOAR (Security Orchestration, Automation and Response)
→ Automates response to detected threats
→ Runs playbooks (Logic Apps) automatically
→ Integrates with ticketing, ITSM, and remediation tools
→ Reduces mean time to respond (MTTR)
Sentinel = both in one service, built on Log Analytics

The Four Pillars

Pillar 1 — Collect

Data flows into Sentinel through data connectors — pre-built integrations that normalise log formats and write to Log Analytics tables:

Azure native connectors (free ingestion):

  • Microsoft Defender for Cloud
  • Entra ID sign-in and audit logs
  • Azure Activity logs (ARM operations)
  • Azure Firewall logs
  • NSG flow logs
  • Key Vault audit logs
  • Azure Kubernetes Service (AKS/ARO)

Microsoft 365 connectors:

  • Microsoft 365 Defender (XDR)
  • Office 365 (Exchange, SharePoint, Teams)
  • Microsoft Defender for Endpoint
  • Microsoft Defender for Identity
  • Microsoft Defender for Cloud Apps

Third-party connectors:

  • Palo Alto, Fortinet, Check Point firewalls
  • Cisco ASA, Umbrella, Meraki
  • Okta, CrowdStrike, SentinelOne
  • AWS CloudTrail, S3 access logs
  • GCP audit logs

On-premises via agents:

Windows VMs → Log Analytics Agent → SecurityEvent table
Linux VMs → Syslog → Syslog table
Network devices → CEF → AMA agent → CommonSecurityLog table

Pillar 2 — Detect

Sentinel detects threats through five types of analytics rules:

Scheduled rules — KQL queries on a timer
// Detect impossible travel — same user, two countries, <1 hour apart
let threshold_minutes = 60;
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == 0 // successful sign-in
| project TimeGenerated, UserPrincipalName,
Location, IPAddress,
Latitude = toreal(LocationDetails.geoCoordinates.latitude),
Longitude = toreal(LocationDetails.geoCoordinates.longitude)
| sort by UserPrincipalName, TimeGenerated asc
| extend PrevLocation = prev(Location, 1),
PrevTime = prev(TimeGenerated, 1),
PrevUser = prev(UserPrincipalName, 1)
| where UserPrincipalName == PrevUser
| extend TimeDiff = datetime_diff('minute', TimeGenerated, PrevTime)
| where TimeDiff < threshold_minutes
| where Location != PrevLocation
| project UserPrincipalName, Location, PrevLocation,
TimeDiff, IPAddress, TimeGenerated
Near Real-Time (NRT) rules — sub-1-minute detection
// Detect Azure Firewall blocking connections to known malicious IPs
AzureDiagnostics
| where Category == "AzureFirewallNetworkRule"
| where msg_s has "Deny"
| parse msg_s with * "from " SourceIP ":" SourcePort
" to " DestIP ":" DestPort ". Action: " Action
| join kind=inner (
ThreatIntelligenceIndicator
| where Active == true
| project NetworkIP, ThreatType, ConfidenceScore
) on $left.DestIP == $right.NetworkIP
| project TimeGenerated, SourceIP, DestIP, ThreatType, ConfidenceScore
Microsoft Security rules — auto-create incidents from Defender alerts

These automatically promote Defender for Cloud, Defender for Endpoint, and Defender for Identity alerts into Sentinel incidents with no KQL needed.

Fusion rules — ML-based multi-stage attack detection

Fusion uses machine learning to correlate low-severity signals across multiple products that individually look benign but together indicate an attack:

Signal 1: Entra ID — suspicious sign-in from anonymising proxy
Signal 2: Office 365 — mass email forwarding rule created
Signal 3: Azure — new service principal with owner role
Individual signals: low severity, easy to miss
Fusion correlation: HIGH severity — likely BEC (Business Email Compromise) attack
Anomaly rules — baseline + deviation detection

Sentinel builds behavioural baselines and alerts on deviations:

  • Unusual volume of data downloaded by a user
  • Login at an unusual time of day for this account
  • Process execution pattern not seen before on this host

Pillar 3 — Investigate

Incidents

Every triggered analytics rule creates an alert. Sentinel groups related alerts into incidents — the unit of work for a SOC analyst:

Incident: Possible BEC attack — john.smith@contoso.com
Severity: High
Status: New
Assigned: SOC Analyst 2
Alerts:
├── Impossible travel detected (Entra ID)
├── Mass forwarding rule created (Office 365)
└── New privileged service principal (Azure Activity)
Entities:
├── User: john.smith@contoso.com
├── IP: 185.220.101.45 (Tor exit node)
└── Host: LAPTOP-JSmith
MITRE ATT&CK:
├── T1078 — Valid accounts
├── T1114 — Email collection
└── T1098 — Account manipulation
Investigation graph

A visual relationship map automatically built from incident entities — shows how a user, IP, host, and mailbox are connected without manual correlation:

185.220.101.45 (Tor IP)
↓ signed in as
john.smith@contoso.com (user)
↓ created
Forward-all-mail rule (Office 365)
↓ same session created
sp-finance-automation (service principal)
↓ granted
Owner role on subscription

Entity pages

Every entity (user, IP, host, app) gets a timeline page showing all activity across all data sources — 90 days of context assembled automatically:

User: john.smith@contoso.com
Last 90 days:
├── Sign-ins: 847 (normal pattern: Mon-Fri 8am-6pm EST)
├── Anomalous sign-ins: 3 (Tor, Russia, Ukraine)
├── Files accessed: 12,847
├── Emails sent: 2,341
├── Azure resource operations: 156
└── Risk score: 94/100 (UEBA)

Pillar 4 — Respond (SOAR)

Playbooks are Azure Logic Apps triggered automatically when an incident is created or updated. They automate the first-response actions that would otherwise require a human:

Playbook 1 — Block compromised user automatically
Trigger: Sentinel incident created
Condition: Severity == High AND Entity type == User
Actions:
1. Get user details from Entra ID
2. Disable user account in Entra ID
3. Revoke all active sessions (MFA re-auth required)
4. Send Teams message to SOC channel:
"User john.smith auto-disabled — incident #1234"
5. Create ServiceNow ticket with incident details
6. Add comment to Sentinel incident:
"User account disabled at 14:32 UTC by playbook"
Playbook 2 — Isolate compromised VM
Trigger: Sentinel incident created
Condition: Severity == High AND Entity type == Host
Actions:
1. Get VM resource ID from entity
2. Apply isolation NSG (deny all inbound + outbound except Bastion)
az network nsg rule create --name ISOLATE --priority 100
--access Deny --direction Inbound --source-address-prefix *
3. Take VM disk snapshot (forensic preservation)
4. Tag VM: {"Status": "Isolated", "IncidentId": "1234"}
5. Notify SOC team via email + Teams
6. Create Jira ticket for IR team
Playbook 3 — Enrich IP with threat intelligence
Trigger: Sentinel alert contains IP entity
Actions:
1. Query VirusTotal API for IP reputation
2. Query Shodan for open ports and services
3. Query AbuseIPDB for abuse reports
4. Add enrichment comment to incident:
"IP 185.220.101.45:
VirusTotal: 47/92 vendors flagged malicious
AbuseIPDB: 847 reports, 100% confidence malicious
Shodan: Tor exit node — AS16276 OVH"
5. If malicious score > 80:
→ Add IP to Azure Firewall deny list automatically

KQL — The Query Language of Sentinel

Everything in Sentinel is queried with KQL (Kusto Query Language):

// Find all failed logins followed by success from same IP
// (credential stuffing pattern)
let failed_logins = SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != 0 // failed
| summarize FailCount = count() by IPAddress, UserPrincipalName
| where FailCount > 10;
let successful_logins = SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == 0 // success
| project IPAddress, UserPrincipalName, SuccessTime = TimeGenerated;
successful_logins
| join kind=inner failed_logins on IPAddress
| project IPAddress, UserPrincipalName,
FailCount, SuccessTime
| order by FailCount desc
// Detect Azure privilege escalation — new owner role assignment
AzureActivity
| where TimeGenerated > ago(1d)
| where OperationNameValue == "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE"
| where ActivityStatusValue == "Success"
| extend RoleDefinitionId = tostring(
parse_json(Properties).requestbody.properties.roleDefinitionId)
| where RoleDefinitionId contains "8e3af657-a8ff-443c-a75c-2fe8c4bcb635" // Owner
| project TimeGenerated, Caller, ResourceGroup,
SubscriptionId, RoleDefinitionId
// Hunt for lateral movement via PsExec or WMI
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID in (4688, 4624) // process create + logon
| where ProcessName has_any ("psexec", "wmic", "winrm")
or CommandLine has_any ("\\\\", "invoke-wmimethod", "wmiexec")
| summarize count() by Computer, Account, ProcessName, CommandLine
| order by count_ desc

MITRE ATT&CK Integration

Sentinel maps every analytics rule to MITRE ATT&CK tactics and techniques — giving you a visual coverage matrix:

TacticExample TechniqueSentinel Detection
Initial AccessT1078 Valid AccountsImpossible travel rule
PersistenceT1098 Account ManipulationNew owner role assignment
Privilege EscalationT1134 Token ImpersonationService principal abuse
Defence EvasionT1562 Impair DefencesDiagnostic setting deleted
Credential AccessT1110 Brute ForceFailed login threshold
Lateral MovementT1021 Remote ServicesPsExec / WMI detection
ExfiltrationT1048 Exfil over Alt ProtocolLarge blob download
ImpactT1486 Data EncryptedRansomware file extension

Sentinel in Hub and Spoke Context

In an enterprise hub and spoke topology, Sentinel sits at the subscription/tenant level — above the network, collecting from everything:

Microsoft Sentinel (Log Analytics Workspace)
│ data connectors
┌────┴──────────────────────────────────┐
│ │
Hub VNet Spoke VNets
Azure Firewall logs AKS/ARO audit logs
VPN Gateway logs VM security events
Bastion session logs NSG flow logs
DNS resolver logs App Gateway WAF logs
On-premises (via MMA/AMA agent)
Windows Security Events
Linux Syslog
Network device CEF

Sentinel vs Defender for Cloud

Microsoft SentinelDefender for Cloud
TypeSIEM + SOARCSPM + CWPP
FocusThreat detection + responsePosture management + workload protection
ScopeCross-tenant, multi-cloudAzure resources + connected clouds
DataAll log sourcesAzure resource configuration + telemetry
OutputIncidents + playbooksRecommendations + alerts
Use togetherDefender feeds alerts into SentinelSentinel adds SOAR response to Defender alerts

They are designed to work together — Defender for Cloud detects threats at the resource level and feeds high-fidelity alerts into Sentinel, which correlates them with signals from every other source and automates the response.


Pricing Model

Sentinel pricing has two components:

Log Analytics ingestion — pay per GB ingested:

  • Pay-as-you-go: ~$2.76/GB
  • Commitment tiers: 100 GB/day → 500 GB/day → lower per-GB rate

Sentinel capacity reservation — flat daily rate above the free Log Analytics tier:

  • First 10 GB/day per workspace: free
  • Above 10 GB/day: ~$100–$400/day depending on tier

Free data sources — no ingestion charge for:

  • Microsoft Defender alerts
  • Entra ID audit + sign-in logs (Basic SKU)
  • Azure Activity logs
  • Office 365 management activity

Key Takeaway

Microsoft Sentinel is the security brain of your Azure estate — it ingests logs from every corner of your infrastructure (Azure, Microsoft 365, on-premises, third-party), correlates signals using AI and KQL-based rules, groups related alerts into actionable incidents mapped to MITRE ATT&CK, and automates first-response actions through Logic App playbooks. In a hub and spoke network, it sits above the topology collecting from every layer — firewall, gateway, Bastion, ARO, VMs, and on-premises — giving your SOC a single pane of glass across the entire estate.

Leave a Reply