Use Apache .htaccess to execute php code inside .htaccess

Hunt Hypothesis

This detection identifies adversaries who exploit the Apache web server’s .htaccess configuration file to embed and execute malicious PHP code, bypassing standard application logic boundaries. A SOC team should proactively hunt for this anomaly in Azure Sentinel because attackers often leverage this technique to establish persistent backdoors or deploy web shells that evade traditional signature-based scanning focused on primary script directories.

YARA Rule

rule WEBSHELL_PHP_In_Htaccess
{
    meta:
        description = "Use Apache .htaccess to execute php code inside .htaccess"
        license = "Detection Rule License 1.1 https://github.com/Neo23x0/signature-base/blob/master/LICENSE"
        author = "Arnim Rupp (https://github.com/ruppde)"
        reference = "Internal Research"
        score = 75
        date = "2021/01/07"
        modified = "2023-07-05"
        hash = "c026d4512a32d93899d486c6f11d1e13b058a713"
        hash = "d79e9b13a32a9e9f3fa36aa1a4baf444bfd2599a"
        hash = "e1d1091fee6026829e037b2c70c228344955c263"
        hash = "c026d4512a32d93899d486c6f11d1e13b058a713"
        hash = "8c9e65cd3ef093cd9c5b418dc5116845aa6602bc92b9b5991b27344d8b3f7ef2"

        id = "0f5edff9-22b2-50c9-ae81-72698ea8e7db"
    strings:
        $hta = "AddType application/x-httpd-php .htaccess" wide ascii

    condition:
        filesize <100KB and $hta
}

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

References

• Internal Research
• Source Rule

False Positive Guidance

Here are 5 specific false positive scenarios for the detection rule “Use Apache .htaccess to execute php code inside .htaccess”, including suggested filters and exclusions:

• Scenario: CMS Plugin Auto-Updates (e.g., WordPress or Magento)

  • Context: Content Management Systems like WordPress often use plugins that dynamically generate .htaccess rules during auto-updates. These plugins may inject PHP logic directly into the file to handle URL rewriting, caching headers, or security tokens immediately after an update cycle completes.
  • Filter/Exclusion: Exclude files located within standard CMS plugin directories (e.g., */wp-content/plugins/*/.htaccess or */magento/app/code/*/etc/*.htaccess) where the modification timestamp aligns with a known scheduled maintenance window or CI/CD deployment job.

• Scenario: Scheduled Cron Job for Log Rotation and Analysis

  • Context: A system administrator runs a nightly cron job using cron to rotate access logs. The script modifies .htaccess temporarily to enable PHP-based log parsing modules (e.g., custom error handlers) that execute only during the rotation window before reverting changes or leaving them active for the next day’s analysis.
  • Filter/Exclusion: Create a rule exclusion based on the process name initiating the change, specifically filtering out modifications made by root user via the cron daemon (e.g., ProcessName = 'crond' AND User = 'root').

• Scenario: Deployment of Custom WAF Rules via Configuration Management Tools

  • Context: DevOps teams utilize tools like Ansible, Puppet, or Chef to push Web Application Firewall (WAF) configurations. These tools often deploy .htaccess files containing PHP snippets that execute security checks (like IP allow-listing logic) as part of a standard infrastructure-as-code pipeline execution