Written in collaboration with @Chi_Nguyen (Program Manager CxE Azure Sentinel Team)
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.
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.
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.
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.
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"]);
(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
)
)
These detections are available as Analytic Rules in Azure Sentinel and can be quickly deployed by following the steps below.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.