Adversaries may use HTTP communications to exfiltrate data or establish command and control channels, which could indicate covert network activity. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify potential data exfiltration or C2 attempts that may evade traditional detection methods.
YARA Rule
rule network_http {
meta:
author = "x0r"
description = "Communications over HTTP"
version = "0.1"
strings:
$f1 = "wininet.dll" nocase
$c1 = "InternetConnect"
$c2 = "InternetOpen"
$c3 = "InternetOpenUrl"
$c4 = "InternetReadFile"
$c5 = "InternetWriteFile"
$c6 = "HttpOpenRequest"
$c7 = "HttpSendRequest"
$c8 = "IdHTTPHeaderInfo"
condition:
$f1 and $c1 and ($c2 or $c3) and ($c4 or $c5 or $c6 or $c7 or $c8)
}
This YARA rule can be deployed in the following contexts:
This rule contains 9 string patterns in its detection logic.
Scenario: System updates via HTTP using Windows Update
Filter/Exclusion: process.name != "wuauserv" or process.name != "svchost.exe" (specific to Windows Update service)
Scenario: Internal HTTP-based API communication between microservices
Filter/Exclusion: destination.ip in (internal_network_range) or source.ip in (internal_network_range)
Scenario: Scheduled backup jobs using HTTP for data transfer
Filter/Exclusion: process.name != "backupexec.exe" or process.name != "vssvc.exe" (specific to backup tools)
Scenario: Admin task using curl or wget to fetch configuration files from a trusted internal server
Filter/Exclusion: process.name != "curl.exe" or process.name != "wget.exe" or destination.ip in (trusted_servers_list)
Scenario: Log aggregation using HTTP (e.g., via ELK Stack or Graylog)
Filter/Exclusion: process.name != "logstash.exe" or process.name != "graylog-server" or destination.ip in (log_aggregation_servers)