Written in collaboration with @Chi_Nguyen (Program Manager CxE Azure Sentinel Team)
Introduction
Recent attacks highlight the fact that in addition to implementing appropriate security protection controls to defend against malicious adversaries, continuous monitoring, and response is a top priority for every organization. To implement security monitoring and response from a networking perspective, you need visibility into traffic traversing through your network devices and detection logic to identify malicious patterns in the network traffic. This is a critical piece for every infrastructure/network security process.
Readers of this post will hopefully be familiar with both Azure Firewall which provides protection against network-based threats, and Azure Sentinel which provides SEIM and SOAR (security orchestration, automation, and response) capabilities. In this blog, we will discuss the new detections for Azure Firewall in Azure Sentinel. These new detections allow security teams to get Sentinel alerts if machines on the internal network attempt to query/connect to domain names or IP addresses on the internet that are associated with known IOCs, as defined in the detection rule query. True positive detections should be considered as Indicator of Compromise (IOC). Security incident response teams can then perform response and appropriate remediation actions based on these detection signals.
Scenario
In case of an attack, after breaching through the boundary defenses, a malicious adversary may utilize malware and/or malicious code for persistence, command-and-control, and data exfiltration. When malware or malicious code is running on machines on the internal network, in most cases, it will attempt to make outbound connections for command-and-control updates, and to exfiltrate data to adversary servers through the internet. When this happens, traffic will inevitably flow out through the network egress points where it will be processed and logged by the by devices or ideally a firewall controlling internet egress. The data logged by devices/firewalls processing internet egress traffic can be analyzed to detect traffic patterns suggesting/representing command-and-control or exfiltration activities (also called IOCs or Indicator of Compromise). This is the basis of network-based detections discussed in this blog.
When customers use Azure Firewall for controlling their internet egress, Azure Firewall will log all outbound traffic and DNS query traffic if configured as a DNS Proxy, to the defined Log Analytics workspace. If a customer is also using Azure Sentinel, they can ingest log data produced by Azure Firewall and run built-in or custom Analytic Rules templates on this data to identify malicious traffic patterns representing IOCs, that these rules are defined to detect. These rules can be configured to run on a schedule and create an incident (or perform an automated action) in Azure Sentinel when there is a match. These incidents can then be triaged by the SOC for response and remediation.
What’s New
Up until now, there were only a couple of Analytic Rule based detections for Azure Firewall available in Azure Sentinel. We are excited to announce availability of eight new detections for well-known IOCs in Azure Sentinel based on traffic patterns flowing through the Azure Firewall. The table below provides a list of new detections which have been added recently and are available to you at the time of publishing this blog.
| No. | Sentinel Analytic Rule Name | Sentinel Repo Link |
|
1. |
Solorigate Network Beacon |
|
|
2. |
Known GALLIUM domains and hashes |
|
|
3. |
Known IRIDIUM IP |
|
|
4. |
Known Phosphorus group domains/IP |
|
|
5. |
THALLIUM domains included in DCU takedown |
|
|
6. |
Known ZINC related maldoc hash |
|
|
7. |
Known STRONTIUM group domains |
|
|
8. |
NOBELIUM - Domain and IP IOCs - March 2021 |
The screenshot below shows the new Azure Firewall detections in the Azure Sentinel Analytic Rule blade.
How Network Based Detection Work
To understand how these detections work, we will examine the “Solorigate Network Beacon” detection which indicates a compromise associated with the SolarWinds exploit. The query snippet below identifies communication to domains involved in this incident.
- We start by declaring all the domains that we want to find in the client request from the internal network
let domains = dynamic(["incomeupdate.com","zupertech.com","databasegalore.com","panhardware.com","avsvmcloud.com","digitalcollege.org","freescanonline.com","deftsecurity.com","thedoccloud.com","virtualdataserver.com","lcomputers.com","webcodez.com","globalnetworkissues.com","kubecloud.com","seobundlekit.com","solartrackingsystem.net","virtualwebdata.com"]);
- Then we perform a union to look for traffic destined for these domains in data from multiple sources which include Common Security Log (CEF), DNS Events, VM Connection, Device Network Events, Azure Firewall DNS Proxy, and Azure Firewall Application Rule logs
(union isfuzzy=true
(CommonSecurityLog
| parse ..
),
(DnsEvents
| parse ..
),
(VMConnection
|parse ..
),
(DeviceNetworkEvents
| parse ..
),
(AzureDiagnostics
| where ResourceType == "AZUREFIREWALLS"
| where Category == "AzureFirewallDnsProxy"
| parse msg_s with "DNS Request: " ClientIP ":" ClientPort " - " QueryID " " Request_Type " " Request_Class " " Request_Name ". " Request_Protocol " " Request_Size " " EDNSO_DO " " EDNS0_Buffersize " " Responce_Code " " Responce_Flags " " Responce_Size " " Response_Duration
| where Request_Name has_any (domains)
| extend DNSName = Request_Name
| extend IPCustomEntity = ClientIP
),
(AzureDiagnostics
| where ResourceType == "AZUREFIREWALLS"
| where Category == "AzureFirewallApplicationRule"
| parse msg_s with Protocol 'request from ' SourceHost ':' SourcePort 'to ' DestinationHost ':' DestinationPort '. Action:' Action
| where isnotempty(DestinationHost)
| where DestinationHost has_any (domains)
| extend DNSName = DestinationHost
| extend IPCustomEntity = SourceHost
)
)
- When this rule query is executed (based on schedule), it will analyze logs from all the data sources defined in the query which also includes the Azure Firewall DNS Proxy and Application Rule logs. The result will identity hosts in the internal network which attempted to query/connect to one of the malicious domains which were declared in Step 1
Instructions to Configure Azure Firewall Detections in Sentinel
These detections are available as Analytic Rules in Azure Sentinel and can be quickly deployed by following the steps below.
- Open the Azure Sentinel blade in the Azure Portal
- Select the Sentinel workspace where you have the Azure Firewall logs
- Select Analytics blade and then click on Rule templates
- Under Data Sources, filter by Azure Firewall
- Select the Rule template you want to enable and click Create rule and configure rule settings to create a rule
Summary
Azure Firewall logs can help identify patterns of malicious activity and Indicators of Compromise (IOCs) in the internal network. Built-in Analytic Rules in Azure Sentinel provide a powerful and reliable method for analyzing these logs to detect traffic representing IOCs in your network. With added support for Azure Firewall to these detections, you can now easily detect malicious traffic patterns traversing through Azure Firewall in your network which allows you to rapidly respond and remediate the threats. We encourage all customers to utilize these new detections to help improve your overall security posture.
As new attack scenarios surface and associated detections are created in future, we will evaluate them and add support for Azure Firewall or other Network Security products, where applicable. You can also contribute new connectors, detections, workbooks, analytics and more for Azure Firewall in Azure Sentinel. Get started now by joining the Azure Network Security plus Azure Sentinel Threat Hunters communities on GitHub and following the guidance.
Additional Resources
- To learn more about Azure Firewall, visit: https://docs.microsoft.com/en-us/azure/firewall
- To learn more about Azure Sentinel, visit: http://aka.ms/ninjatraining