Is this log entry a threat? Looking for a Custom Rule to detect Web Shell activity in static paths.

[Third Nht]

Hi everyone,

I am currently monitoring logs via Wazuh Manager for a WordPress site. I do not have direct terminal access to the web server, so I am relying on Wazuh alerts and logs to report issues to the server admin team.

I’ve spotted some suspicious log entries that weren't flagged by default rules, and I’m concerned they might be a Web Shell (Backdoor) activity.

Example Log Entries (Redacted for Security):

1. [DOMAIN] 172.68.x.x - - [19/Feb/2026:14:01:21 +0700] "GET /wp-content/themes/[THEME]/assets/src/js/theme/FieldsetRowPlain.php?d=2f7661722f77[...HEX_REDACTED...]&s=2e6874616363657373 HTTP/1.1" 200 4228
2. [DOMAIN] 172.68.x.x - - [23/Feb/2026:12:18:12 +0700] "GET /wp-content/plugins/[PLUGIN]/Admin/BuilderComponentRow.php?6c696768746f6e&d=2f7661722f77[...HEX_REDACTED...] HTTP/1.1" 200 5085

Observations:

• Suspicious Path: PHP files are being executed from within /js/ or deep inside Plugin/Theme asset folders.
• Hex Parameters: The parameters d= and s= are Hex-encoded (Decodes to server paths like(d) /var/www/html/... and(s) .htaccess,index.php,web.config). like s=2e6874616363657373(.htaccess) , s=7765622e636f6e666967 (index.php) , s=696e6465782e706870 (web.config)

My Questions:
1.From your experience, is this a confirmed threat (Web Shell or anything else)?
2. Is it normal for a WordPress site to have hex-encoded strings in URL parameters

[Anthony Faruna]

Hello,

Thank you for sharing the log samples and your observations. Based on what you’ve provided, this activity is highly suspicious and not typical of legitimate WordPress behavior.

1. Is this a confirmed threat?

While we cannot confirm compromise without file system access, the indicators strongly suggest malicious activity, likely related to a web shell or file disclosure backdoor.

Key red flags:

• PHP execution inside asset directories such as /js/ or deeply nested theme/plugin folders. These locations normally contain static files (JavaScript, CSS, images), not executable PHP scripts.

• Hex-encoded parameters (d= and s=) that decode to internal filesystem paths like /var/www/..., .htaccess, index.php, or web.config.

• HTTP 200 responses, which may indicate that the script is successfully processing the request.

This pattern is consistent with web shells that:

• Accept encoded file paths as parameters

• Read sensitive files from disk

• Return their contents in the HTTP response

It is not standard WordPress behavior.

2. Are hex-encoded URL parameters normal in WordPress?

Hex-encoded parameters are not inherently malicious. They are sometimes used for:

• Tokens

• Hashes

• Obfuscated identifiers

However, in this context, where the decoded values correspond to server paths and sensitive configuration files, this is not normal for WordPress core, themes, or plugins.

Combined with the unusual file location and execution pattern, this strongly increases the likelihood of malicious intent.

Please take the following recommended next steps

Since you don’t have direct shell access, you can escalate this to the server administration team with the following recommendations:

1. Inspect the referenced PHP files

   • Verify whether the files actually exist.

   • Review their contents for obfuscated code (e.g., eval(), base64_decode(), gzinflate(), etc.).

2. Check file integrity

   • Compare theme/plugin files against clean copies from official sources.

   • Look for recently modified or newly created PHP files in wp-content.

3. Review WordPress admin accounts

   • Check for unauthorized users.

   • Reset passwords if compromise is suspected.

4. Search for similar requests

   • Query for other .php?d= or .php?s= patterns.

   • Identify repeated source IPs or automated scanning behavior.

5. Consider restoring from a known clean backup if a compromise is confirmed.
   

Regards

--
You received this message because you are subscribed to the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wazuh/11960774-5131-4818-8341-a856c989e8d3n%40googlegroups.com.