Detects DirtyFrag exploit code POC usage in Linux environments

Hunt Hypothesis

This detection identifies active exploitation of the DirtyFrag vulnerability within Linux systems by monitoring for specific proof-of-concept (POC) execution patterns that adversaries leverage to achieve privilege escalation and arbitrary code execution. Proactive hunting for this behavior in Azure Sentinel is critical because DirtyFrag represents a high-severity kernel-level threat capable of compromising system integrity, necessitating immediate identification before attackers can establish persistence or move laterally across the environment.

YARA Rule

rule EXPL_LNX_DirtyFrag_ForensicArtefacts_May26 {
   meta:
      description = "Detects DirtyFrag exploit code POC usage in Linux environments"
      author = "Florian Roth"
      reference = "https://github.com/V4bel/dirtyfrag/tree/master"
      date = "2026-05-08"
      score = 75
      id = "bda5e087-8eb7-55bd-a5ff-0eef91d63bcf"
   strings:
      $xa1 = "/V4bel/dirtyfrag.git" ascii
      $xa2 = "static const uint8_t shell_elf[PAYLOAD_LEN] = {" ascii
      $xa3 = "/usr/bin/su page-cache patched (entry 0x%x = shellcode)" ascii
   condition:
      filesize < 800KB
      and 1 of ($xa*)
}

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 3 string patterns in its detection logic.

References

• https://github.com/V4bel/dirtyfrag/tree/master
• Source Rule

False Positive Guidance

Here are 5 specific false positive scenarios for the DirtyFrag exploit code POC usage detection rule, tailored for a legitimate enterprise Linux environment:

• Scenario: Automated vulnerability scanning agents (e.g., Tenable Nessus, Qualys, or OpenVAS) executing kernel patch verification scripts.

  • Context: These tools often run Proof-of-Concept (POC) payloads to verify if the ext4 filesystem is vulnerable to DirtyFrag by attempting specific write operations on mounted volumes.
  • Filter/Exclusion: Create a rule exclusion for processes running under dedicated service accounts (e.g., tenable, qualys) or whitelist specific executable paths such as /opt/qualys/daemon/qd_agent and /usr/bin/nessusd.

• Scenario: Scheduled backup jobs utilizing the rsync utility with extended attributes preservation.

  • Context: Nightly cron jobs (e.g., 0 2 * * * /usr/local/bin/backup.sh) that use rsync to copy large datasets over NFS or ext4 mounts may trigger the specific file fragmentation and metadata manipulation patterns associated with the DirtyFrag POC.
  • Filter/Exclusion: Exclude events where the parent process is a known scheduler (e.g., cron, systemd-timer) and the command line arguments contain flags like --xattrs or --chown.

• Scenario: DevOps CI/CD pipelines running container image builds with Docker or Podman.

  • Context: During the build phase, tools often create temporary layers on ext4 volumes to test filesystem integrity and layer caching, which mimics the exploit’s behavior of manipulating inode metadata.
  • Filter/Exclusion: Whitelist processes running within known container orchestration namespaces (e.g., `docker