Azure Firewall Premium's Threat Intelligence mode uses Microsoft's curated threat feed to alert or deny traffic to and from known-malicious IPs, domains, and URLs. When an internal host attempts to reach a TI-flagged destination, the firewall logs the event to AzureDiagnostics with Category AzureFirewallThreatIntelLog.
This SOP covers two detection paths: firewall TI deny log analysis to identify the internal source and destination, and IDPS signature correlation to determine if the traffic matched a known exploit or C2 protocol signature.
☰ Table of Contents
01 — BACKGROUND
TECHNIQUE OVERVIEWAzure Firewall Premium receives Microsoft Threat Intelligence feeds and can be configured in Alert mode (log and allow) or Alert and Deny mode (log and block). A TI alert in Deny mode means the firewall already blocked the traffic — your job is to identify the internal host that initiated the connection and assess whether this was a C2 attempt, malware callback, or scanning activity.
| Field | Value |
|---|---|
| MITRE Technique | T1071 — Application Layer Protocol (C2 via HTTPS/HTTP) |
| Sub-technique | T1048 — Exfiltration Over Alternative Protocol |
| Log Sources | AzureDiagnostics (Category=AzureFirewallThreatIntelLog), AzureFirewallNetworkRuleLog, AzureFirewallApplicationRuleLog |
| Key Fields | msg_s (action, source, destination, port), Category, TimeGenerated |
| Firewall Modes | Alert only (traffic passes) vs Alert and Deny (traffic blocked) |
| Detection Priority | HIGH — firewall TI match is a validated indicator, not a heuristic |
If Azure Firewall is in Alert mode only (not Deny), the traffic reached its destination despite the TI match. Treat Alert-mode TI logs as confirmed outbound communication, not blocked attempts.
02 — IDENTIFICATION
2 INDICATORSThe AzureDiagnostics ThreatIntelLog contains the source IP that triggered the TI match — identifying this host is the critical first step before the attacker rotates their C2 domain and evades the firewall rule.
- 1Open Sentinel → Logs → ensure AzureDiagnostics table is available and the Azure Firewall is sending diagnostic logs.
- 2Paste the KQL below; set time range to Last 4 hours.
- 3Review
SourceIPfields — this is the internal host that attempted the TI-matched connection. Map to asset inventory. - 4Review
Action_s— Deny means firewall blocked it; Alert means the traffic reached its destination and requires urgent escalation. - 5Count occurrences per SourceIP — 3 or more attempts to the same TI destination confirms automated beaconing, not a one-time browser redirect.
| Field / Value | Meaning | Action |
|---|---|---|
| Action_s = Deny | Firewall blocked the connection — traffic did not reach the TI-matched destination | INVESTIGATE SOURCE |
| Action_s = Alert | Alert-only mode — connection succeeded and reached the malicious destination | ESCALATE IMMEDIATELY |
| Hit count > 3 | Recurring attempts to the same TI destination — automated process (implant), not browser | ESCALATE |
| msg_s IDPS | IDPS signature match in addition to TI — known exploit or C2 protocol fingerprint identified | ESCALATE |
If Azure Firewall diagnostic logs are not flowing to Sentinel, navigate to Azure Firewall resource → Diagnostic settings → Add diagnostic setting and enable all log categories to the Sentinel Log Analytics workspace.
Azure Firewall IDPS logs protocol-level signatures (Cobalt Strike over HTTPS, Metasploit stager, known malware C2 patterns) — an IDPS match alongside a TI deny is definitive confirmation of a malicious connection attempt.
- 1Navigate to the Azure Firewall resource in the portal → Logs → use the IDPSSignatureHitCountLog table or query AzureDiagnostics with Category
AzureFirewallIDPSLog. - 2Paste the KQL below to cross-reference IDPS hits against the source IP identified in I1.
- 3Review
SignatureName— entries mentioning Cobalt Strike, Metasploit, Mimikatz, or known malware families confirm active exploitation tooling. - 4Check
Severity— Critical or High IDPS severity triggers immediate SEV1 declaration. - 5Cross-reference source IP against Defender for Endpoint device inventory to identify hostname, owner, and recent process activity.
Cross-reference the firewall source IP against Entra ID Sign-in logs — if the same IP was used to log into Azure services in the past 24 hours, the compromised machine may already have valid Azure credentials cached, dramatically expanding the blast radius.
03 — CONTAINMENT
IMMEDIATE ACTIONAlert-mode TI events (Action = Alert) mean the connection succeeded. This is a confirmed exfiltration or C2 attempt — do not treat Alert-mode logs as lower priority than Deny-mode logs.
- 1Identify the hostname from the source IP via Assets → Devices in security.microsoft.com → search by IP.
- 2Isolate the device: Actions → Isolate device.
- 3In Azure portal, navigate to Azure Firewall → Rules (classic) → Network rule collection → add an explicit deny rule for the source IP to all outbound destinations.
- 4If Alert mode is enabled on TI, switch to Alert and Deny immediately: Azure Firewall → Threat intelligence → Alert and deny.
- 5Open IR ticket with: source IP/hostname, TI destination IP, Action type (Alert/Deny), IDPS signatures, hit count, and first/last seen timestamps.
04 — ERADICATION
CLEANUP- 1Run a full Defender AV scan on the isolated source host to identify and quarantine the malicious process.
- 2Review the host's Device Timeline in Defender for Endpoint — trace back 48 hours from the first firewall TI hit to identify initial access.
- 3Check scheduled tasks, registry run keys, and WMI subscriptions for persistence established by the implant.
- 4Verify Azure Firewall Threat Intelligence is set to Alert and Deny (not Alert only) in Firewall Policy → Threat intelligence.
- 5Enable IDPS in Signature mode = Alert at minimum, Alert and Deny preferred — navigate to Firewall Policy → IDPS.
- 6Review all other internal hosts that contacted the same TI destination IP in the same timeframe — scope potential lateral spread.
- No new AzureFirewallThreatIntelLog events from source IP in past 2 hours
- Source host AV scan complete — implant quarantined
- Firewall TI mode confirmed as Alert and Deny
- IDPS enabled on Azure Firewall Policy
- All hosts that contacted TI destination IP investigated
05 — ESCALATION
ESCALATION PATHS| Condition | Severity | Action | Notify |
|---|---|---|---|
| Alert mode — connection reached TI destination | SEV1 | Full IR, isolate host, treat as active C2 | SOC Lead → CISO |
| Deny mode, recurring hits, IDPS match | SEV1 | Isolate host, IR ticket, malware removal | SOC Lead → IR Team |
| Deny mode, single hit, no IDPS | SEV3 | Investigate source host, 4-hour monitoring | SOC Lead (async) |
| Legitimate service misidentified by TI feed | INFO | Firewall exclusion, document, close | None |
Ensure Azure Firewall is never left in Alert-only mode for TI-matched traffic. Alert-only mode provides visibility but no protection — change to Alert and Deny as part of every SOP-35 resolution.
Stay Threat-Ready
Follow CyberHawk Threat Intel for daily SOC analyst playbooks, detection engineering guides, and threat intelligence.