The detection rule identifies potential adversary use of the MD5 API, which may indicate attempts to hash data for obfuscation or exfiltration. SOC teams should proactively hunt for this behavior in Azure Sentinel to uncover early-stage malicious activity that could evade traditional detection methods.
YARA Rule
rule MD5_API {
meta:
author = "_pusher_"
description = "Looks for MD5 API"
date = "2016-07"
strings:
$advapi32 = "advapi32.dll" wide ascii nocase
$cryptdll = "cryptdll.dll" wide ascii nocase
$MD5Init = "MD5Init" wide ascii
$MD5Update = "MD5Update" wide ascii
$MD5Final = "MD5Final" wide ascii
condition:
($advapi32 or $cryptdll) and ($MD5Init and $MD5Update and $MD5Final)
}
This YARA rule can be deployed in the following contexts:
This rule contains 5 string patterns in its detection logic.
Scenario: System update using a legitimate package manager that includes MD5 checksums for verification
Filter/Exclusion: Exclude processes related to package managers like apt, yum, or dnf by checking the process name or command line arguments.
Scenario: Scheduled job running a script that generates MD5 hashes for file integrity checks
Filter/Exclusion: Exclude processes associated with scheduled tasks (e.g., cron, task scheduler) and scripts known for file integrity monitoring.
Scenario: Admin task using md5sum or certutil to verify digital certificates or files
Filter/Exclusion: Exclude processes where the command line includes md5sum or certutil and is initiated by an admin user with elevated privileges.
Scenario: Log file parsing or data processing that includes MD5 hashes as part of data normalization
Filter/Exclusion: Exclude processes that are parsing logs or processing data and involve tools like logrotate, ELK stack, or Splunk.
Scenario: Security tool or SIEM system generating MD5 hashes for event correlation or artifact analysis
Filter/Exclusion: Exclude processes associated with security tools like Splunk, QRadar, or SIEM platforms that use MD5 for internal processing.