<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Automattic - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/vendors/automattic/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Mon, 20 Jul 2026 11:41:12 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/vendors/automattic/feed.xml" rel="self" type="application/rss+xml"/><item><title>PHP File Creation in WordPress Plugin Directory</title><link>https://feed.craftedsignal.io/briefs/2026-07-php-file-creation-wordpress-plugin/</link><pubDate>Mon, 20 Jul 2026 11:41:12 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-07-php-file-creation-wordpress-plugin/</guid><description>Attackers commonly establish persistence on compromised Linux WordPress web servers by creating malicious PHP files, often web shells, within the WordPress plugin directory, enabling remote access and command execution following initial compromise of a public-facing application.</description><content:encoded><![CDATA[<p>Threat actors frequently target WordPress installations on Linux web servers to establish persistence through the creation of malicious PHP files, typically web shells. This technique involves an initial compromise, often via a vulnerable public-facing application, followed by the upload or creation of a PHP file within the <code>/wp-content/plugins/</code> directory. Once deployed, these web shells can be accessed remotely via a web browser, allowing attackers to execute arbitrary commands, exfiltrate data, or further compromise the server and potentially the broader network. This activity is a critical indicator of post-exploitation, even if the initial access vector is unknown, and monitoring such file creations helps detect malicious activity aimed at maintaining long-term unauthorized access.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains initial access to a vulnerable WordPress server, often exploiting a known vulnerability in a plugin, theme, or WordPress core (e.g., CVE-2024-1234, if applicable).</li>
<li>The attacker uses their initial access to upload or create a malicious PHP file, often a web shell, within the <code>/wp-content/plugins/</code> directory of the WordPress installation.</li>
<li>The malicious PHP file is typically disguised with a name resembling a legitimate plugin file or a common utility script to evade detection.</li>
<li>The attacker accesses the newly created web shell via a web browser, sending specially crafted HTTP requests to invoke its functionality.</li>
<li>The web shell executes the attacker's commands on the underlying Linux operating system.</li>
<li>Through the web shell, the attacker performs actions such as data exfiltration, privilege escalation, or lateral movement within the network.</li>
<li>The web shell serves as a persistent backdoor, allowing the attacker to regain access to the compromised server at will.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful establishment of a PHP web shell in the WordPress plugin directory grants attackers remote code execution capabilities on the compromised Linux server. This can lead to severe consequences including, but not limited to, unauthorized access to sensitive data stored on the server, defacement of the website, use of the server for hosting malicious content (e.g., phishing pages, malware distribution), use as a C2 node, or further compromise of the internal network through lateral movement. The number of potential victims is vast, as WordPress powers a significant portion of the internet's websites, making it a frequent target for financially motivated cybercriminals and state-sponsored groups.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule &quot;Detect PHP File Creation in WordPress Plugin Directory&quot; to your SIEM and tune for your environment.</li>
<li>Ensure <code>file_event</code> logging for Linux endpoints is enabled, specifically monitoring file creation and modification events, to activate the rule above.</li>
<li>Regularly patch WordPress core, plugins, and themes to mitigate vulnerabilities that could lead to initial access and web shell deployment.</li>
<li>Implement file integrity monitoring (FIM) for critical WordPress directories like <code>/wp-content/plugins/</code> to detect unauthorized file changes.</li>
</ul>
]]></content:encoded><category domain="severity">low</category><category domain="type">advisory</category><category>persistence</category><category>initial-access</category><category>execution</category><category>web-shell</category><category>wordpress</category><category>linux</category><category>endpoint</category><category>threat-detection</category><category>vulnerability</category></item></channel></rss>