What Changed

The AzureWAFmatching_log4j_vuln Analytic Rule (v1.0.4 to v1.0.5) has been updated to handle schema variations in Azure Diagnostics WAF logs:

  1. details_message_s is now resolved via column_ifexists before the where filter, using AdditionalFields.details_message_s as fallback. Previously this column was referenced in the where clause without being explicitly extended, meaning deployments where this field surfaces only via AdditionalFields (newer diagnostic schema) would evaluate it as null and never match.

  2. details_msg_s added to IOC matching and projection: The where clause now includes details_msg_s has_any (log4jioc), and the project statement outputs details_msg_s = column_ifexists(“details_msg_s”, tostring(AdditionalFields.details_msg)). This column variant appears in some WAF log schemas and was entirely absent from detection coverage.

Detection Logic

  • Primary table: AzureDiagnostics (filtered to MICROSOFT.NETWORK / ApplicationGatewayFirewallLog and FrontdoorWebApplicationFirewallLog)
  • Core logic: matches Log4j JNDI injection IOCs (log4jioc watchlist) across requestUri_s, details_message_s, details_msg_s, and details_data_s; extracts and Base64-decodes the malicious command from the JNDI expression
  • Entity mapped: IP (MaliciousHost / clientIp_s)

Security Impact

Environments where WAF diagnostic logs emit details_message_s only via AdditionalFields (as opposed to a top-level column) would have seen zero matches from this rule for that field path. Similarly, any WAF log source emitting details_msg_s as the message column was entirely outside detection scope. Both gaps are now closed.

MITRE Mapping

  • T1190 — Exploit Public-Facing Application (Log4Shell / CVE-2021-44228)

Affected Files

Solutions/Apache Log4j Vulnerability Detection/Analytic Rules/AzureWAFmatching_log4j_vuln.yaml
(packaging artefacts: 3.0.9.zip, ReleaseNotes.md, Solution_Log4j.json, mainTemplate.json)