Azure Firewall's built-in Threat Intelligence feed (powered by Microsoft Defender TI) automatically denies traffic to/from known-malicious IPs and FQDNs and generates an alert. Azure Firewall Premium extends this with a full signature-based IDPS (Intrusion Detection and Prevention System) that detects exploitation attempts, C2 traffic patterns, and malware communication within encrypted HTTPS streams via TLS inspection. These are high-fidelity, low-false-positive alerts — Azure Firewall TI deny events should always be investigated, not tuned out.
Key data sources: AzureDiagnostics (Category = AzureFirewallThreatIntel or AzureFirewallIDPS), AzureFirewallNetworkRule (Standard tier network rule denies), AzureFirewallApplicationRule (Application rule with TI-based deny), DeviceNetworkEvents (MDE — identifies the internal process behind the blocked connection).
☰ Table of Contents
01 — BACKGROUND
TECHNIQUE OVERVIEWAzure Firewall's Threat Intelligence mode can be set to Alert-only or Alert-and-Deny. In Alert-and-Deny mode, connections to/from TI-matched IPs/FQDNs are blocked and logged as ThreatIntel category events. Azure Firewall Premium adds a deep packet inspection IDPS engine with 58,000+ signatures (Suricata-based) that can detect C2 protocols, exploit payloads, and malware traffic even over HTTPS when TLS inspection is configured. The key distinction for analysts: a TI deny means the firewall blocked the traffic (the connection failed), so the question is not "was data stolen?" but "which host attempted the connection, and is the underlying implant still present?"
| Field | Value |
|---|---|
| MITRE Techniques | T1071 — Application Layer Protocol (blocked C2) T1048 — Exfiltration Over Alternative Protocol (blocked exfil attempt) |
| Kill-chain Phase | Command & Control (blocked) / Exfiltration (blocked) |
| Primary Log Sources | AzureDiagnostics (Category: AzureFirewallThreatIntel, AzureFirewallIDPS) AzureFirewallNetworkRule, AzureFirewallApplicationRule |
| Log Analytics Table | AzureDiagnostics with ResourceType = "AZUREFIREWALLS" |
| Key Fields | msg_s (full log message), SourceIP, DestinationIP, DestinationPort, Protocol, Action, ThreatIntelReason, IDPSSignatureId |
| Default Severity | TI deny: SEV3 (blocked, investigate source host). IDPS match in Alert mode (not blocked): SEV2 (traffic passed, active threat). |
A TI-based DENY means the connection was blocked by the firewall. The internal host behind that deny still has the malware/implant that attempted the connection. Investigate the source IP to find and remediate the underlying compromise — the block only stopped one attempt; the implant will retry.
02 — IDENTIFICATION
2 INDICATORSWhen Azure Firewall blocks a TI-matched connection, the firewall log shows the internal source IP — but that IP is typically a private RFC1918 address (10.x.x.x, 172.16.x.x) that must be correlated to a hostname and then to an MDE device record to find the specific compromised endpoint. Azure Firewall Standard logs to the AzureDiagnostics table; Premium IDPS events appear in a separate Category=AzureFirewallIDPS entry. The ThreatIntelReason field contains the IOC match description — extract this and cross-reference with ThreatIntelligenceIndicator for context.
- 1Run the TI deny query below. The
msg_sfield contains the full log line includingThreatIntelReason— parse this to get the matching IOC description (e.g., "Malware: Qakbot C2", "Botnet: Mirai", "RiskLevel: High"). - 2Take the
SourceIPfrom the firewall log (RFC1918 internal IP) and search it in DeviceNetworkEvents to identify the hostname and the initiating process. Navigate to MDE → Assets → Devices → filter by IP address. - 3Check whether Azure Firewall is in Alert-and-Deny mode or Alert-only mode: In Azure Portal → Azure Firewall → Firewall Policy → Threat Intelligence. If in Alert-only, the connection was NOT blocked and requires immediate escalation.
- 4Count repeated TI denies from the same source IP in the last 24 hours — >5 denies to the same destination IP/FQDN is a C2 beacon being repeatedly blocked. The implant is still active and retrying.
| Alert Category / Field | Meaning | Severity |
|---|---|---|
| Category = AzureFirewallThreatIntel, Action = Deny | TI-matched connection blocked — internal host tried to contact known-bad IP/FQDN; implant likely present | MEDIUM–HIGH |
| Category = AzureFirewallIDPS, Action = Alert | IDPS signature matched but traffic allowed (Alert mode) — active malicious traffic passed through; investigate immediately | HIGH |
| Category = AzureFirewallIDPS, Action = Deny | IDPS signature matched and traffic blocked (IPS mode) — exploitation or C2 attempt stopped; investigate source | MEDIUM |
| Repeated denies (>5) from same SourceIP | C2 beacon retrying after block — active implant present on the source host; requires isolation | HIGH |
| ThreatIntelReason contains "Ransomware" | Connection to ransomware group infrastructure — pre-ransom staging or payment contact; escalate to SEV1 | CRITICAL |
Azure Firewall Premium IDPS matches are more granular than TI denies — the signature ID maps to a specific known attack pattern (e.g., SID 2027379 = Emotet C2 HTTP POST, SID 2014726 = Cobalt Strike beacon). When IDPS is in Alert mode (not IPS/Block), the matching traffic passed through — meaning this is not a blocked attempt but confirmed active malicious traffic. The IDPSSignatureId field in the log allows you to look up the exact Suricata/Emerging Threats rule and understand the precise attack technique being detected.
- 1Run the IDPS query below. Extract the
IDPSSignatureIdand look it up in the Firewall Policy → IDPS → Signature Rules blade to see the rule description and recommended action. High-severity signatures (severity = 1) require immediate response. - 2Check whether IDPS is in Alert or Alert and Deny mode for the matched signature: if Alert-only, the traffic passed and the host may already be compromised. If Alert-and-Deny, the traffic was blocked but the source host is still compromised.
- 3Cross-reference the source IP against MDE DeviceNetworkEvents to find the specific endpoint. Look at
InitiatingProcessFileNamefor the connection that matched the IDPS rule — this identifies the malware binary.
| IDPS Severity | Meaning | Action |
|---|---|---|
| IDPSSeverity = 1 (High) | Confirmed exploit attempt, C2 protocol, or active malware communication | Immediate isolation |
| IDPSSeverity = 2 (Medium) | Suspicious traffic pattern — possible attack or misconfiguration | Investigate within 1hr |
| IDPSSeverity = 3 (Informational) | Potentially risky but not confirmed malicious — tune or monitor | Review and tune |
| IDPS in Alert mode (not Deny) | Traffic passed — IDPS only logged, did not block; higher urgency than Deny mode matches | Treat as active threat |
To switch a high-severity IDPS signature from Alert to Deny mode without affecting all rules: Azure Portal → Azure Firewall Policy → IDPS → Signature Rules → search for the SignatureId → set Mode to "Deny". This is a surgical fix that blocks only the matched attack signature without enabling full IPS mode on all traffic.
03 — CONTAINMENT
DECISION + ACTIONS- 1Verify TI mode immediately: If Azure Firewall is in Alert-only mode, change to Alert-and-Deny now — every minute in Alert-only means active C2 traffic is passing. In Azure Portal: Firewall Policy → Threat Intelligence → mode = Alert and Deny.
- 2Custom deny rule: Even with TI mode = Alert-and-Deny, create an explicit network rule to deny all traffic to/from the IOC IP — this ensures it's blocked even if the TI feed expires or is updated.
- 3NSG restriction: Apply an Azure NSG (Network Security Group) outbound deny rule on the affected VM's NIC or subnet as a second control layer. This provides defence-in-depth if Azure Firewall routing is bypassed.
04 — ERADICATION
CLEANUP & RECOVERY- 1Remediate source VM: Use MDE Live Response (or Azure Serial Console for non-MDE VMs) to terminate the malicious process, collect the binary for analysis, and remove persistence. For Azure VMs, Azure Disk Snapshot the OS disk before remediation for forensics.
- 2Review Firewall Policy rules for bypass gaps: Inspect Azure Firewall Application Rules and Network Rules for any overly permissive outbound rules that might bypass TI checking — e.g., wildcard
*FQDN rules or rules with action=Allow that pre-match before TI evaluation (explicit allow rules bypass TI in some policy configurations). - 3Enable diagnostic logging if missing: Verify Azure Firewall diagnostic logs are being sent to Log Analytics AND Sentinel. Navigate to: Azure Firewall → Diagnostic Settings → confirm all log categories (AzureFirewallNetworkRule, AzureFirewallApplicationRule, AzureFirewallThreatIntel, AzureFirewallIDPS) are enabled.
- 4IDPS mode hardening: After incident resolution, review top IDPS signatures from the last 30 days. Switch severity-1 signatures from Alert to Deny mode in Firewall Policy to prevent future traffic passing on the same attack patterns.
05 — ESCALATION
THRESHOLDS & CONTACTS| Condition | Action | Severity |
|---|---|---|
| TI deny + repeated attempts + process attributed | Escalate to SOC Lead — isolate VM; treat as active compromise; invoke IR playbook | SEV2 |
| Firewall in Alert-only mode + IDPS match passed | Escalate to SOC Lead immediately — active malicious traffic passed; treat as breach; check for data exfil | SEV1/SEV2 |
| Ransomware IOC in ThreatIntelReason | Escalate to CISO — pre-ransom staging; invoke BCP; notify Azure subscription owner | SEV1 |
| Multiple Azure VMs same TI deny IOC | Escalate to CISO + Cloud Security team — potential lateral movement within Azure VNet | SEV1 |
| Single TI deny, low severity, no repeat | Monitor only; add explicit deny rule; close ticket after 48hr with no repeat | SEV3 |
CyberHawk Threat Intel
Built by Rudra Verma | Senior Cyber Security Architect & Researcher
"They can't exploit you if you are the Exploit."
Authorized security research & penetration testing only. Unauthorized use is illegal.