Website Path Brute-Force and AI Scraper Probes targeting env file - Threat Alert

Open almost any public website’s access logs and you will see the same odd pattern: a flood of requests for files that were never meant to be public. Environment files, editor configs, phpinfo pages, control-panel proxy paths, GraphQL endpoints, even Exchange export-tool URLs. Most of those requests never succeed. The danger is not the volume, it is the one deployment mistake that turns a routine probe into a full compromise.

This analysis looks at a typical “Top Paths” chart from web analytics and security monitoring, the kind of view operators see on Cloudflare-style dashboards and origin log summaries worldwide. The hit counts below illustrate common automated scraper and path brute-force behaviour. They are not evidence that any named site was breached. They are a map of what the internet’s bots try first.

Representative top paths (hits): / (183), /favicon.ico (95), /robots.txt (8), /.env (7), /config.json (6), /.well-known/security.txt (6), /__proxy_subdomain_cpanel (4), /info.php (4), /apple-touch-icon-precomposed... (4), /api/graphql (4), /.vscode/sftp.json (4), /ecp/Current/exporttool/microsoft... (4).

What the chart shows

The chart is dominated by two harmless-looking paths: the site root and /favicon.ico. Browsers, uptime monitors, scrapers and SEO tools all hit those constantly. Below that sit the interesting rows, low absolute counts, high security meaning.

• Benign / expected traffic: /, favicons and Apple touch icons. These are noise for security teams unless they suddenly spike with hostile user-agents.
• Reconnaissance helpers: /robots.txt and /.well-known/security.txt. Both are usually published on purpose; scanners still fetch them first to learn layout and contacts.
• Credential and config fishing: /.env, /config.json, /.vscode/sftp.json, /info.php. These are classic “did someone leave secrets on the web root?” probes.
• Stack fingerprinting: /api/graphql, cPanel-style proxy paths, and Microsoft Exchange ECP export-tool URLs. A 200 here tells an attacker which product you run, and which CVE checklist to open next.

In other words, the chart is a miniature internet attack surface survey. Automated bots are not inventing paths unique to one victim; they are spraying the same wordlist at every hostname they can resolve.

High-risk paths explained

/.env , Modern stacks (Laravel, Node, Docker Compose, many PaaS apps) store database passwords, API keys, JWT secrets and cloud credentials in .env. If the web server serves that file with HTTP 200, treat it as a full compromise candidate: rotate every secret in the file, check auth logs on connected services, and move the file outside the document root. Variants such as /.env.bak, /.env.production and /api/.env are equally popular with scanners.

/config.json , Frontend and backend config files often leak API base URLs, feature flags, third-party keys or internal hostnames. Even “non-secret” config helps attackers map your architecture. Never deploy raw config under a public path; inject only the values the browser truly needs.

/info.php (and phpinfo) , A leftover phpinfo page dumps PHP version, loaded modules, include paths, environment variables and sometimes credentials. It is pure reconnaissance gold. Remove every debug dump from production; if you must keep one temporarily, bind it to VPN or IP allow-lists and delete it the same day.

/.vscode/sftp.json , Popular VS Code SFTP extensions store host, username and sometimes plaintext passwords in this file. When it is committed to a repo or uploaded to the live web root, attackers gain a direct ticket onto the origin server. Add .vscode/ and sftp.json to .gitignore, never deploy editor folders to production, and prefer SSH agents over passwords in the config.

cPanel proxy paths (e.g. /__proxy_subdomain_cpanel) , Hosting panels historically expose proxy rewrite paths that can reach management interfaces even when ports 2082/2083/2086/2087 look closed. Scanners probe these paths to fingerprint cPanel/WHM and to hunt for known session or auth flaws. Keep panels patched, restrict management access by IP or VPN, and treat unexpected hits on proxy paths as high-priority alerts, especially after critical cPanel advisories.

/api/graphql , Finding GraphQL is step one; enabling introspection or field suggestions is often step two for attackers. An open schema reveals types, mutations and relationships that speed up injection, IDOR and DoS testing. Disable introspection in production, enforce authentication on mutations, and apply query depth/cost limits plus WAF rules for GraphQL abuse.

Exchange ECP export-tool path (/ecp/Current/exporttool/microsoft...) , This ClickOnce endpoint has long been used by scanners to fingerprint Microsoft Exchange build versions from the assembly identity in the response. Version leaks feed ProxyShell-era and later exploit targeting. If you do not run Exchange on that host, a 404 is fine; if you do, keep Cumulative Updates current, put ECP behind strong auth and network controls, and monitor for mass versioning probes.

/robots.txt as recon , robots.txt is not a lock. It is a polite note to well-behaved crawlers. Listing Disallow: /admin or /backup advertises those paths to anyone reading the file. Use it for SEO, not secrecy; protect sensitive URLs with authentication and edge ACLs instead.

/.well-known/security.txt , Per RFC 9116, this file is a feature, not a vulnerability: it tells researchers how to report issues. Publish it with a monitored contact, a future Expires date, and preferably a PGP key. The residual risks are spam reports and attackers abusing listed contacts, manageable if you monitor the inbox and keep the file accurate.

Recon vs exploit

Most of the hits in a chart like this are reconnaissance, not exploitation. The bot asks: “Does this file exist? Which stack is this? Is the panel online?” A 404 or a blank 403 usually ends that chapter for that IP.

Exploitation begins when reconnaissance succeeds:

• A 200 on /.env or sftp.json can yield live credentials within seconds.
• A live GraphQL introspection response can become a roadmap for abuse of mutations.
• An Exchange version string can be matched against a CVE matrix before a real exploit payload is sent.
• A reachable cPanel proxy path can become the entry point for panel auth bugs once a vulnerable build is confirmed.

That is why operators should treat sensitive-path probes as early-warning telemetry. The probe itself is not the breach. The exposed file or unpatched panel is.

Also separate scrapers from bruteforce path scanners. Favicon and touch-icon traffic is usually scrapers and browsers. The dense cluster of .env, config.json, info.php, editor configs and panel paths is scanner behaviour, often from bulletproof VPS ranges, research zgrab sweeps, or commodity botnet wordlists.

Recommended fixes for website owners

1. Never commit or deploy secrets. Keep .env, SFTP configs, service-account JSON and private keys out of git and outside the web root. Use a secrets manager or platform environment variables. If a secret was ever web-accessible, rotate it immediately.
2. Deny dangerous paths at the edge and origin. Add web-server or CDN rules that return 404/403 for /\.env, /\.git, /\.vscode, backup extensions, phpinfo, and known panel proxy paths you do not need publicly. Prefer a WAF managed ruleset (for example OWASP CRS-style restricted-file rules) plus custom deny lists.
3. Rate-limit and ban scanners. Pair CDN WAF rate limits with fail2ban (or equivalent) jails on origin access logs: one jail for sensitive-path hits, another for bursty 404 scanning, with thresholds high enough that real users are not blocked.
4. Remove debug surfaces. Delete info.php, leftover installers, sample apps and staging configs from production. Inventory every public path with a periodic crawl of your own site.
5. Harden APIs and panels. Disable GraphQL introspection in production; require auth; set query cost limits. Patch cPanel/WHM and Exchange promptly; restrict management interfaces to VPN or allow-listed IPs.
6. Publish the right public files on purpose. Keep a clean robots.txt that does not advertise admin URLs. Maintain a current security.txt so good-faith researchers can reach you without guessing.
7. Monitor and respond. Alert on first-time hits to high-risk paths, especially HTTP 200/301 responses. When a secret path returns 200, assume compromise until proven otherwise: rotate keys, review access logs, and check for secondary footholds.

A practical Nginx-style deny pattern many operators use (adapt to your stack) blocks common secret filenames under the document root and logs the attempt for fail2ban. CDN rules that challenge or block obviously hostile user-agents add another cheap layer, remembering that targeted enumeration of real API paths may still look “normal” to a generic WAF, so application-aware limits matter too.

International context

Path probing is a global background radiation of the public internet. The same wordlists hit Indian MSME WordPress sites, European SaaS tenants, US Exchange deployments and shared hosting fleets in Asia. CERT teams and national CSIRTs routinely warn about exposed credentials and unpatched panels; the underlying lesson is identical across borders: automated scanners do not care about your jurisdiction, only your HTTP status codes.

For organisations in India, this sits squarely under day-to-day cyber hygiene expected under CERT-In incident-reporting culture and the Digital Personal Data Protection (DPDP) duty of care, an exposed .env that dumps customer data is both a security incident and a privacy incident. In the EU/UK, GDPR controllers face similar accountability if a leaked config leads to personal-data exposure. In the US and elsewhere, sector rules and state privacy laws raise the same bar: preventable secret exposure is hard to defend after the fact.

The constructive takeaway for operators everywhere is modest and actionable. You cannot stop the probes. You can make sure every sensitive path returns nothing useful, every secret lives outside the web root, every panel is patched and locked down, and every odd 200 on a dangerous URL wakes someone up.

Frequently Asked Questions

Does a hit on /.env mean we were hacked? No. It usually means a scanner asked. You were only compromised if the file (or a variant) was actually served. Check status codes and response bodies in your logs.

Should we remove security.txt because scanners request it? No. Keep it. It is an RFC 9116 best practice for vulnerability disclosure. Scanners fetching it is expected; an unmonitored contact address is the real problem.

Is blocking /robots.txt a good idea? Generally no. Search engines need it. Instead, stop listing sensitive paths in Disallow and protect those paths with real access controls.

What should we do first if /.env or sftp.json returned HTTP 200? Take the file offline, rotate every credential it contained, review authentication and deployment logs, and scan for webshells or unexpected admin users. Then fix the deployment process so it cannot happen again.

Written by: Cyber Security Team, Ministry of Cyber Affairs