« Unusual Base64 Encoding/Decoding Activity Suspicious Curl from macOS Application »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.29

PHP File Creation in WordPress Plugin Directory

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

PHP File Creation in WordPress Plugin Directory

edit

Detects the creation of a PHP file in the WordPress plugin directory, which is a common technique used by attackers to establish persistence on a compromised web server. Attackers may upload a malicious PHP file and call it from a web browser to gain remote access to the server.

Rule type: eql

Rule indices:

  • logs-endpoint.events.file*

Severity: low

Risk score: 21

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Linux
  • Use Case: Threat Detection
  • Tactic: Persistence
  • Tactic: Initial Access
  • Use Case: Vulnerability
  • Data Source: Elastic Defend
  • Resources: Investigation Guide

Version: 2

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit
## Triage and analysis

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating PHP File Creation in WordPress Plugin Directory

This alert flags a new or modified PHP file under a WordPress plugin folder when it was written by a web server, PHP handler, shell, or download utility. That matters because attackers often hide webshells or rogue plugin code there to survive on a compromised site and run commands remotely. A common pattern is exploiting a vulnerable plugin to upload a backdoor into wp-content/plugins and then calling it from a browser.

Possible investigation steps

  • Determine whether the new PHP file is part of a legitimate plugin installation or update by comparing its path, filename, hash, and timestamp against the official plugin package and your deployment records.
  • Review the file contents for common webshell indicators such as obfuscation, eval or base64_decode chains, command execution functions, upload handlers, or hardcoded external URLs, and extract any indicators for broader searching.
  • Correlate the write time with web access logs and WordPress or PHP logs to identify the originating HTTP request, source IP, authenticated user, target endpoint, and any upload or admin action that preceded the file creation.
  • Trace the creating activity through parent and child processes, execution user, working directory, and any concurrent shell or download activity to separate expected maintenance from exploitation or post-compromise staging.
  • Inspect the rest of the WordPress environment for related signs of compromise, including other newly modified plugin or theme files, unexpected administrator accounts, suspicious scheduled tasks, dropped archives, or unusual outbound connections.

False positive analysis

  • A legitimate WordPress plugin installation or update can create or modify PHP files under wp-content/plugins through the normal web application update flow; verify the file path, name, hash, and timestamp match an approved plugin package and any recent administrator update activity.
  • Authorized maintenance such as restoring a plugin from backup or deploying plugin code with bash, sh, curl, or wget can also trigger this alert; verify the process lineage and maintenance records show an expected bulk file change rather than an isolated unfamiliar PHP file.

Response and remediation

  • Isolate the affected web server or container from the network and disable external access to the compromised WordPress site while preserving the malicious PHP file, related plugin directories, and relevant logs for evidence.
  • Remove attacker persistence by deleting the malicious PHP file and any companion backdoors, rogue plugins, modified .htaccess entries, cron jobs, systemd timers, SSH keys, or unauthorized WordPress administrator accounts created during the intrusion.
  • Reset exposed secrets by rotating WordPress admin passwords, hosting control panel credentials, SSH keys, database passwords, API tokens, and session cookies that may have been accessed from the compromised host.
  • Restore the site from a known-good backup or redeploy the affected plugin and WordPress core from trusted packages, then verify hashes and review wp-content/plugins, wp-content/themes, and uploads for any remaining unauthorized PHP files or recent modifications.
  • Escalate to incident response immediately if the webshell executed commands, multiple hosts show similar plugin-directory writes, sensitive data may have been accessed, or the attacker obtained root privileges, and expand scoping across reverse proxy, WAF, database, and authentication logs.
  • Harden the environment by patching the exploited plugin or WordPress version, removing unused plugins, enforcing least-privilege write access so the web server cannot write to plugin directories, enabling MFA for administrators, and adding monitoring for new executable files under web content.

Setup

edit

Setup

This rule requires data coming in from Elastic Defend.

Elastic Defend Integration Setup

Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

Prerequisite Requirements:

  • Fleet is required for Elastic Defend.
  • To configure Fleet Server refer to the documentation.

The following steps should be executed in order to add the Elastic Defend integration on a Linux System:

  • Go to the Kibana home page and click "Add integrations".
  • In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
  • Click "Add Elastic Defend".
  • Configure the integration name and optionally add a description.
  • Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
  • Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. Helper guide.
  • We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
  • Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. For more details on Elastic Agent configuration settings, refer to the helper guide.
  • Click "Save and Continue".
  • To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. For more details on Elastic Defend refer to the helper guide.

Rule query

edit
file where host.os.type == "linux" and event.type in ("creation", "change") and (
  process.name in (
    "nginx", "apache2", "httpd", "php-cgi", "php-fcgi", "php-cgi.cagefs",  "sw-engine-fpm",
    "wget", "curl", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh", "busybox"
  ) or
  process.name like ("php-fpm*", "lsphp*", "*.cgi", "*.fcgi")
) and
file.path like~ "*/wp-content/plugins/*"

Framework: MITRE ATT&CKTM

« Unusual Base64 Encoding/Decoding Activity Suspicious Curl from macOS Application »