regex pos

Hunt Hypothesis

This hunt targets adversaries employing specific string pattern matching to identify malicious file artifacts or suspicious command-line arguments within Azure Sentinel logs. Proactively hunting for these regex-based indicators allows the SOC team to uncover stealthy reconnaissance activities that may bypass standard signature-based detections due to their low-severity classification.

YARA Rule

rule regex_pos
{
meta:
	author = "@patrickrolsen"
	reference = "POS malware - Regex"
strings:
	$n1 = "REGEXEND" nocase
	$n2 = "RegExpr" nocase
	$n3 = "regex"
	$s4 = "[1-5][0-9]{14}=(?!1201|1202|1203|1204|11|10|09|08|07|06|05|04|03|02)[0-9]{5}[0-9]*"
	$s5 = "[47][0-9]{13}=(?!1201|1202|1203|1204|11|10|09|08|07|06|05|04|03|02)[0-9]{5}[0-9]*"
	$s6 = "(?:0[0-5]|[68][0-9])[0-9]{11}=(?!1201|1202|1203|1204|11|10|09|08|07|06|05|04|03|02)[0-9]{5}[0-9]*"
	$s7 = "(?:011|5[0-9]{2})[0-9]{12}=(?!1201|1202|1203|1204|11|10|09|08|07|06|05|04|03|02)[0-9]{5}[0-9]*"
	$s8 = "(?:2131|1800|35\\d{3})\\d{11}=(?!1201|1202|1203|1204|11|10|09|08|07|06|05|04|03|02)[0-9]{5}[0-9]*"
	$s9 = "([0-9]{15,16}[D=](0[7-9]|1[0-5])((0[1-9])|(1[0-2]))[0-9]{8,30})"
	$s10 = "((b|B)[0-9]{13,19}\\^[A-Za-z\\s]{0,30}\\/[A-Za-z\\s]{0,30}\\^(0[7-9]|1[0-5])((0[1-9])|(1[0-2]))[0-9\\s]{3,50}[0-9]{1})"
	$s11 = "[0-9]*\\^[a-zA-Z]*/[a-zA-Z ]*\\^[0-9]*"
	$s12 = "\\d{15,19}=\\d{13,}"
	$s13 = "\\;?[3-9]{1}[0-9]{12,19}[D=\\u0061][0-9]{10,30}\\??"
	$s14 = "[0-9]{12}(?:[0-9]{3})?=(?!1201|1202|1203|1204|11|10|09|08|07|06|05|04|03|02)[0-9]{5}[0-9]*"
condition:
	uint16(0) == 0x5A4D and 1 of ($n*) and 1 of ($s*)
}

Deployment Notes

This YARA rule can be deployed in the following contexts:

• Microsoft Defender for Endpoint — Custom indicators / advanced hunting
• Email Gateway — Attachment scanning
• File Share Monitoring — Periodic scanning of shared drives
• YARA CLI — Manual threat hunting on endpoints

This rule contains 14 string patterns in its detection logic.

References

• POS malware - Regex
• Source Rule

False Positive Guidance

Here are 4 specific false positive scenarios for the regex_pos detection rule in an enterprise environment, along with suggested filters or exclusions:

• Scenario: Scheduled Antivirus Real-Time Scanning

  • Context: Enterprise endpoint protection tools like CrowdStrike Falcon or Microsoft Defender for Endpoint frequently scan large files (e.g., .iso, .zip, database dumps) in real-time. The scanning engine often generates temporary regex patterns to match file signatures, which can trigger the regex_pos rule when processing high-volume directories during off-hours.
  • Suggested Filter: Exclude processes with known AV executable names (e.g., csagent.exe, MsMpEng.exe) and filter out events where the command line contains specific scanning flags like /scan or --realtime.

• Scenario: Automated Log Parsing by SIEM Ingestion Agents

  • Context: Data ingestion agents such as Splunk Universal Forwarder, Datadog Agent, or Elastic Filebeat run continuous background jobs to parse application logs. These agents utilize complex regular expressions (POSIX or PCRE) to extract fields from verbose logs, causing the detection logic to flag their internal regex compilation and matching activities as suspicious.
  • Suggested Filter: Create an exclusion for the specific service accounts running these agents (e.g., svc-splunk-forwarder, dd-agent) and limit the scope to file paths within standard log directories (e.g., /var/log/, C:\Program Files\...).

• Scenario: Source Code Compilation and Static Analysis

  • Context: In development environments, build servers like Jenkins, GitLab CI, or IDEs such as Visual Studio execute static code analysis tools (e.g., SonarQube, ESLint) during the build pipeline. These