PHP webshell which probably hides the input inside an eval()ed obfuscated string

Hunt Hypothesis

This detection targets adversaries deploying advanced PHP webshells that execute obfuscated code within eval() functions to conceal malicious payloads and evade signature-based analysis. Proactively hunting for this behavior in Azure Sentinel is critical because these stealthy entry points often serve as the initial foothold for post-exploitation activities, allowing attackers to maintain persistent access while remaining undetected by standard monitoring tools.

YARA Rule

rule WEBSHELL_PHP_Double_Eval_Tiny
{
    meta:
        description = "PHP webshell which probably hides the input inside an eval()ed obfuscated string"
        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 = 70
        date = "2021-01-11"
        modified = "2026-02-23"
        hash = "f66fb918751acc7b88a17272a044b5242797976c73a6e54ac6b04b02f61e9761"
        hash = "6b2f0a3bd80019dea536ddbf92df36ab897dd295840cb15bb7b159d0ee2106ff"
        hash = "aabfd179aaf716929c8b820eefa3c1f613f8dcac"
        hash = "9780c70bd1c76425d4313ca7a9b89dda77d2c664"
        hash = "006620d2a701de73d995fc950691665c0692af11"


        id = "868db363-83d3-57e2-ac8d-c6125e9bdd64"
    strings:
        $payload = /(\beval[\t ]{0,500}\([^)]|\bassert[\t ]{0,500}\([^)])/ nocase wide ascii
        $fp1 = "clone" fullword wide ascii
        $fp2 = "* @assert" ascii
        $fp3 = "*@assert" ascii
        $fp4 = "--EXPECT--" ascii

        //strings from private rule capa_php_old_safe
        $php_short = "<?" wide ascii
        // prevent xml and asp from hitting with the short tag
        $no_xml1 = "<?xml version" nocase wide ascii
        $no_xml2 = "<?xml-stylesheet" nocase wide ascii
        $no_asp1 = "<%@LANGUAGE" nocase wide ascii
        $no_asp2 = /<script language="(vb|jscript|c#)/ nocase wide ascii
        $no_pdf = "<?xpacket"

        // of course the new tags should also match
        // already matched by "<?"
        $php_new1 = /<\?=[^?]/ wide ascii
        $php_new2 = "<?php" nocase wide ascii
        $php_new3 = "<script language=\"php" nocase wide ascii

    condition:
        filesize > 70 and filesize < 300 and (
            (
                (
                        $php_short in (0..100) or
                        $php_short in (filesize-1000..filesize)
                )
                and not any of ( $no_* )
            )
            or any of ( $php_new* )
        )
        and #payload >= 2 and not any of ( $fp* )
}

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

• Internal Research
• Source Rule

False Positive Guidance

Here are 5 specific false positive scenarios for the PHP Webshell with Eval’d Obfuscated String detection rule, including suggested filters and exclusions:

• Scenario: Automated Backup Script Execution via Cron

  • Context: Enterprise backup solutions (e.g., Veeam or custom scripts) often use PHP wrappers to compress logs before archiving. These scripts frequently utilize eval() on base64-encoded configuration strings to dynamically generate archive manifests without hardcoding logic.
  • Filter/Exclusion: Create an exclusion for the specific file path of the backup agent (e.g., /opt/veeam/scripts/php_backup_wrapper.php) and restrict the rule trigger to exclude processes spawned by the cron or systemd user, rather than interactive web server users like www-data.

• Scenario: CI/CD Pipeline Artifact Deployment

  • Context: During automated deployments using tools like Jenkins or GitLab CI, a PHP deployment agent executes a “health check” module. This module often decodes an obfuscated JSON payload containing the new version hash and evaluates it via eval() to verify integrity before applying changes.
  • Filter/Exclusion: Exclude traffic originating from known CI/CD runner IP addresses (e.g., internal subnet 10.20.50.x) and filter out events where the source user agent contains specific pipeline identifiers (e.g., Jenkins-Agent or GitLab-Runner).

• Scenario: Third-Party Analytics SDK Initialization

  • Context: Customer-facing applications integrate third-party analytics tools (such as Adobe Experience Cloud or Google Tag Manager). These SDKs often load dynamic tracking configurations by evaluating an obfuscated string containing event definitions and privacy consent flags upon page initialization.
  • Filter/Exclusion: Implement a whitelist for known vendor domains (e.g., *.adobe.com,