Webshells in Well-Known Paths: A Stealthy Persistence Vector

**TL;DR**

Attackers are actively probing `/.well-known/` on public websites and, in some cases, planting webshells there to gain durable access that blends into routine traffic. SANS Internet Storm Center honeypots recorded a surge of requests for PHP files under `/.well-known/`—including the `acme-challenge/` and `pki-validation/` subfolders—on September 25, 2025, and highlighted why adversaries like this location: it’s supposed to be reachable for standards-based checks (like Let’s Encrypt), and it often survives site updates. Defenders should log and alert on unexpected POSTs and parameterized GETs to `/.well-known/`, disable script execution and restrict writes in that path, and baseline what normal ACME traffic looks like. Map the behavior to MITRE ATT&CK T1505.003 (Web Shell) and use NSA/CISA guidance to hunt and remediate.

—

Most teams don’t think twice about `/.well-known/`. It’s a standard path defined by the IETF for “well-known” URIs—convenient places to publish service metadata or prove domain control. Because automated services depend on it, especially certificate issuance via the ACME HTTP-01 challenge, administrators intentionally expose this path to the internet. That practicality, however, creates a security blind spot: `/.well-known/` is reachable by design, sits under the web root, and is psychologically “hidden” due to the leading dot. Those traits make it a deceptively attractive place for attackers to probe and hide.

SANS Internet Storm Center handlers reported fresh honeypot hits specifically targeting `/.well-known/` for webshells on September 25, 2025. The diary includes concrete examples—requests like `/.well-known/xin1.php?p` and probes for `*.php` inside `/.well-known/acme-challenge/` and `/.well-known/pki-validation/`. The handler’s assessment is blunt: adversaries may choose `/.well-known/` because web deployments are less likely to overwrite its contents during routine updates, giving a planted shell better odds of surviving change. The same theme showed up in the Stormcast podcast the next day, underscoring that this isn’t theoretical. It’s happening now.

Understanding the legitimate purpose of `/.well-known/` is key to defending it without breaking production. Under ACME’s HTTP-01 challenge, your client drops a simple token file at `/.well-known/acme-challenge/`, and the certificate authority retrieves it over HTTP to confirm domain control. That’s a straightforward one-off GET for a static file; it doesn’t require query strings, request bodies, or script handlers. This behavioral contrast—simple GETs for tokens versus noisy, parameterized requests or uploads—gives you a clear detection baseline.

From a threat-model standpoint, a webshell under `/.well-known/` is just another instance of server-side code execution and persistence. In MITRE ATT&CK, that maps to T1505.003 – Server Software Component: Web Shell. Once a shell is in place, an adversary can enumerate the host, pivot to adjacent systems, exfiltrate data, or stage ransomware—often with traffic that looks like ordinary web requests. Treat any unexplained executable content in this path as a serious incident.

Effective detection starts with instrumentation. Log every request to `/.well-known/` and alert on POSTs, PUTs, or parameterized GETs that don’t match your allowlisted endpoints. Watch for script extensions (.php, .jsp, .aspx, .cgi) anywhere under `/.well-known/`. Pair your HTTP telemetry with file integrity monitoring to flag new or modified executable files in web-root, and correlate with process data for your webserver—e.g., child processes launching interpreters or shells. The NSA’s Cybersecurity Information Sheet on webshells provides concrete detection and response techniques you can adapt to your stack, and CISA’s alert summarizing the guidance is a useful entry point for policy-level stakeholders.

Hardening must preserve legitimate ACME behavior while eliminating the execution and write conditions attackers need. On Windows/IIS, use Request Filtering to deny script extensions and consider disabling “Allow unlisted file name extensions” where feasible, being mindful of extensionless routes in some frameworks. You can scope these controls to `/.well-known/` (and especially to everything under it except `acme-challenge/`) via web.config. On Apache, apply directory-scoped configuration to disable PHP and other interpreters for `/.well-known/`, serving only static files. On Nginx, keep the minimal static block for `acme-challenge/` and add a sibling rule that simply denies script extensions under `/.well-known/`. The goal is consistent: read-only tokens, no scripts, no uploads.

If you discover suspicious requests or files under `/.well-known/`, elevate to incident response immediately. Preserve volatile data and server logs, snapshot the system, and enumerate the web-root against a known-good baseline. Look for secondary persistence—scheduled tasks, startup scripts, or database-backed shells that survive file cleanup—and review outbound connections for command-and-control beacons. If the ACME path was abused, consider re-issuing certificates and rotating credentials touched by the web tier. Use the NSA guidance to structure your hunt and cleanup, and treat “one webshell” as a symptom that warrants a broader compromise assessment.

This technique isn’t entirely new. Researchers have periodically documented abuse of `/.well-known/` for malware delivery or phishing for years, precisely because the directory already exists and is open to the internet. What’s changed is current activity levels and the focus on hiding webshells there. With SANS honeypots now seeing active scans for executable files in `/.well-known/`—including within ACME subfolders—the path has moved from “theoretically risky” to “routinely probed.” That should be enough to justify adding specific controls, even in mature environments.

In practice, you don’t need to choose between uptime and security here. Keep the ACME workflow running by allowing static token reads in `/.well-known/acme-challenge/`, but remove every other capability an attacker would want. Deny execution, restrict writes, and alert on deviations from your baseline. Make `/.well-known/` a monitored zone, not a blind spot. The scans are already at your doorstep.

—

**References**

– SANS Internet Storm Center — “Webshells Hiding in .well-known Places” (Diary, Sept 25, 2025). Primary field observation and examples from honeypots.
– SANS Internet Storm Center — Stormcast (Sept 26, 2025). Podcast recap confirming the surge in `.well-known` scanning for webshells.
– IETF — RFC 8615 “Well-Known URIs.” Formal definition of the `/.well-known/` path.
– Let’s Encrypt — “Challenge Types (HTTP-01).” Operational context for the ACME token flow under `/.well-known/acme-challenge/`.
– NSA (Cybersecurity Information Sheet) — “Detect and Prevent Web Shell Malware.” Detection and remediation guidance.
– CISA — “NSA, ASD Release Guidance for Mitigating Web Shell Malware.” Policy-level summary and links to technical guidance.
– Microsoft Docs — “Request Filtering” and “File Name Extensions.” How to deny dangerous extensions or tighten request filtering in IIS.
– Apache hardening references — Directory-scoped approaches to disable PHP/script execution in a specific folder.
– Nginx configuration patterns — Denying script extensions under `/.well-known/` while allowing ACME token reads.
– Zscaler research — “Abuse of hidden `/.well-known/` directory in HTTPS sites.” Historical context on attackers abusing the directory.