Detect, correlate, contain: New Azure Firewall IDPS detections in Microsoft Sentinel and XDR

As threat actors continue to blend reconnaissance, exploitation, and post-compromise activity, network-level signals remain critical for early detection and correlated response. To strengthen this layer, we're introducing five new Azure Firewall IDPS detections, now available out of the box in the Azure Firewall solution for Microsoft Sentinel and Microsoft Defender XDR.

See It in Action 

This short demo walks through Azure Firewall's IDPS capabilities, the new Sentinel detections, and the automated response playbook — from malicious traffic hitting the firewall to the threat being contained without manual intervention. 

[Watch the demo → Coming soon!] 

Read on for the full details on each detection, customization options, and a step-by-step walkthrough of the automated response workflow. 

What’s new 

The Azure Firewall solution now includes five new analytic detections built on Azure Firewall. 

Where these detections apply 

These detections are available through the Azure Firewall solution in: 

• Microsoft Sentinel, enabling SOC centric investigation, hunting, and automation 
• Microsoft Defender XDR, allowing network level signals to participate in end-to-end attack correlation across identity, endpoint, cloud, and email 

They are powered by the AZFWIdpsSignature log table and require Azure Firewall with IDPS enabled (preferably with TLS inspection).

 

Customizing the detections to fit your environment 

The Azure Firewall IDPS detections included in the Microsoft Sentinel solution are designed to be fully adaptable to customer environments, allowing SOC teams to tune sensitivity, scope, and signal fidelity based on their risk tolerance and operational maturity. Each detection is built on the AZFWIdpsSignature log table and exposes several clearly defined parameters that customers can modify without rewriting the analytic logic.  

1. Tune alert sensitivity and time horizon

Customers can adjust the lookback period (TimeWindow) and minimum hit count (HitThreshold) to control how aggressively the detection triggers. Shorter windows and lower thresholds surface faster alerts for high-risk environments, while longer windows and higher thresholds help reduce noise in high volume networks.

2. Align severity with internal risk models 

Each analytic rule includes a configurable minimum severity (MinSeverity) aligned to Azure Firewall IDPS severity scoring. Organizations can raise or lower this value to match internal incident classification standards and escalation policies.  

3. Focus on relevant threat categories and behaviors 

Optional filters allow detections to be scoped to specific threat categories, descriptions, or enforcement actions. Customers can enable or disable: 

• • Category filtering to focus on specific attack classes (for example, command and control, exploit kits, denial of service, or privilege escalation). 
  • Description filtering to target specific behavioral patterns. 
  • Action filtering to alert only on denied or alerted traffic versus purely observed activity.  

This flexibility makes it easy to tailor detections for different deployment scenarios such as internet facing workloads, internal east-west traffic monitoring, or regulated environments with stricter alerting requirements.

4. Preserve structure while customizing output 

Even with customization, the detections retain consistent enrichment fields including source IP, threat category, hit count, severity, actions taken, and signature IDs ensuring alerts remain actionable and easy to correlate across Microsoft Sentinel and Microsoft Defender XDR workflows.  

By allowing customers to tune thresholds, scope, and focus areas while preserving analytic intent, these Azure Firewall IDPS detections provide a strong out of the box baseline that can evolve alongside an organization’s threat landscape and SOC maturity. 

 

Automated detection and response for Azure Firewall using Microsoft Sentinel 

In this walkthrough, we’ll follow a real-world attack simulation and see how Azure Firewall, Microsoft Sentinel, and an automated playbook work together to detect, respond to, and contain malicious activity, without manual intervention. 

 

Step 1: Malicious traffic originates from a compromised source

 

A source IP address 10.0.100.20, hosted within a virtual network, attempts to reach a web application protected by Azure Firewall. To validate the scenario, we intentionally generate malicious outbound traffic from this source, such as payloads that match known attack patterns. 

This is an outbound flow, meaning the traffic is leaving the internal network and attempting to reach an external destination through Azure Firewall. 

At this stage: 

• • • Azure Firewall is acting as the central enforcement point 
    • Traffic is still allowed, but deep packet inspection is in effect

 

Step 2: Azure Firewall IDPS detects malicious behavior

 

 

Azure Firewall's intrusion detection and prevention system (IDPS) is enabled and inspects traffic as it passes through the firewall. When IDPS detects patterns that match known malicious signatures, the action taken depends on the signature's configured mode: 

• • Alert mode: IDPS generates a detailed security log for the matched signature but allows the traffic to continue. This is useful for monitoring and tuning before enforcing blocks. 
  • Alert and Deny mode: IDPS blocks the matching traffic and generates a detailed security log. The threat is stopped at the network layer while full telemetry is preserved for investigation. 

In both cases, IDPS records rich metadata including source IP, destination, protocol, signature name, severity, and threat category. These logs are what power the downstream detections in Microsoft Sentinel. 

In this walkthrough, the signature is configured in Alert and Deny mode, meaning the malicious traffic from 10.0.100.20 is blocked immediately at the firewall while the corresponding log is forwarded for analysis. 

 

Step 3: Firewall logs are sent to Log Analytics 

 

 

All Azure Firewall logs, including IDPS logs, are sent to a Log Analytics workspace named law-cxeinstance. 

At this point: 

• • • Firewall logs are centralized 
    • Logs are normalized and can be queried 
    • No alerting has happened yet, only data collection 

This workspace becomes the single source of truth for downstream analytics and detections.

 

Step 4: Microsoft Sentinel ingests and analyzes the Firewall logs

 

 

The Log Analytics workspace is connected to Microsoft Sentinel, which continuously analyzes incoming data. 

Using the Azure Firewall solution from the Sentinel Content Hub, we previously deployed a set of built-in analytic rule templates designed specifically for Firewall telemetry. 

One of these rules is: “High severity malicious activity detected”. This rule evaluates IDPS logs and looks for: High-confidence signatures, known exploit techniques and malicious categories identified by Firewall IDPS. 

 

Step 5: Sentinel creates an incident

 

 

When the analytic rules are met, Microsoft Sentinel automatically: 

• • • Raises an alert 
    • Groups related alerts into an incident 
    • Extracts entities such as IP addresses, severity, and evidence 

In this case, the source IP 10.0.100.20 is clearly identified as the malicious actor and attached as an IP entity to the incident. 

This marks the transition from detection to response. 

 

Step 6: An automation rule triggers the playbook

 

 

To avoid manual response, we configured a Sentinel automation rule that triggers whenever: 

• • • An incident is created 
    • The analytic rule name matches any of the analytic rules we configured 

The automation rule immediately triggers a Logic App playbook named AzureFirewallBlockIPaddToIPGroup. This playbook is available as part of the Azure Firewall solution and can be deployed directly from the solution package. In addition, a simplified version of the playbook is published in our GitHub repository, allowing you to deploy it directly to your resource group using the provided ARM template. 

This is where automated containment begins. 

 

Step 7: The playbook aggregates and updates the IP Group 

 

 

The playbook performs several critical actions in sequence: 

1. 1. 1. Extracts IP entities from the Sentinel incident 
      2. Retrieves the existing Azure Firewall IP Group named MaliciousIPs 
      3. Checks for duplicates to avoid unnecessary updates 
      4. Aggregates new IPs into a single array/list 

Updates the IP Group in a single operation. It is important to note that the playbook managed identity should have contributor access on the IP Group or its resource group to perform this action. In our scenario, the IP 10.0.100.20 is added to the MaliciousIPs IP Group.

 

 

Step 8: Firewall policy enforces the block immediately

 

 

Azure Firewall already has a network rule named BlockMaliciousTraffic configured with: 

• • • Source: MaliciousIPs IP Group 
    • Destination: Any 
    • Protocol: Any 
    • Action: Deny 

 

Because the rule references the IP Group dynamically, the moment the playbook updates MaliciousIPs, the firewall enforcement takes effect instantly — without modifying the rule itself. 

Traffic originating from 10.0.100.20 is now fully blocked, preventing any further probing or communication with the destination. The threat has been effectively contained. 

When a SOC analyst opens the Sentinel incident, they see that containment has already occurred: the malicious IP was identified, the IP Group was updated, and the firewall block is in effect — all with a full audit trail of every automated action taken, from detection through response. No manual intervention was required. 

 

Conclusion

With these five new IDPS detections, Azure Firewall closes the gap between network-level signal and SOC-level action. Raw signature telemetry is automatically transformed into severity-aware, MITRE ATT&CK-mapped alerts inside Microsoft Sentinel and Microsoft Defender XDR — giving security teams correlated, investigation-ready incidents instead of isolated log entries. 

Combined with automation playbooks, the result is a fully integrated detect-and-respond workflow: Azure Firewall identifies malicious behavior, Sentinel raises and enriches the incident, and a Logic App playbook contains the threat by updating firewall policy in real time — all without manual intervention. 

These detections are included at no additional cost. Simply install the Azure Firewall solution from the Microsoft Sentinel Content Hub, and the analytic rules automatically appear in your Sentinel workspace — ready to enable, customize, and operationalize. 

Get started today:

• Azure Firewall with Microsoft Sentinel overview
• Automate Threat Response with Playbooks in Microsoft Sentinel
• Azure Firewall Premium features implementation guide

 

Recent real‑world breaches underscore why these detections matter. Over the past year, attackers have repeatedly gained initial access by exploiting public‑facing applications, followed by command‑and‑control activity, web shell deployment, cryptomining, and denial‑of‑service attacks. Incidents such as the GoAnywhere MFT exploitation, widespread web‑application intrusions observed by Cisco Talos, and large‑scale cryptomining campaigns against exposed cloud services demonstrate the value of correlating repeated network‑level malicious signals. The new Azure Firewall IDPS detections are designed to surface these patterns early, reduce alert noise, and feed high‑confidence network signals directly into Microsoft Sentinel and Microsoft Defender XDR for faster investigation and response.

Your network telemetry is a first-class security signal - let it work for you!

 

Visit us at RSA 2026 to see the full detection-to-containment workflow live.