Attack Analysis: Vulnerability Scanner vs. Multify Proxy

May 29, 2026, 17:04. Two IP addresses from Côte d'Ivoire connected to the Multify proxy server. Over the next 90 seconds, they enumerated almost 100 URLs and received 100 rejections.

This is typical vulnerability scanner activity. Not a targeted hack, but automated reconnaissance. Such scanners operate continuously, crawling millions of websites in search of one thing: an open file with keys, passwords, or configuration, or a known vulnerability in a CMS. It doesn't matter what the site is built on — WordPress, Drupal, Joomla, or a custom engine. The scanner checks everything using a standard dictionary.

Multify, as a reverse proxy, takes all incoming traffic. The scanner hits Multify's infrastructure, not the client's website directly. Proxy protection is the protection of client websites.

Here is a list from a real log:

`` /.env /.env.production /.env.local /.env.bak /wp-config.php /config/database.php /config/secrets.yml /azure-credentials.json /gcp-credentials.json /private.key /database.sql /dump.sql ``

This is not a random set, but a standard dictionary compiled from real leaks. Every file on this list was once found publicly available on someone's production server.

Environment Variables — .env files and their variants. In them, developers store API keys, database passwords, and payment system tokens. One such file gives an attacker full access to the infrastructure without any traces of a breach. According to GitGuardian, in 2024, secrets in public repositories were discovered more than 12 million times, with .env being among the top three most frequent. A developer adds the file to .gitignore, but on the server after deployment, it remains in the public directory, and no one checks.

CMS and Framework Configs — wp-config.php (WordPress), Joomla configs, Drupal, Laravel, Symfony, Rails files. The scanner doesn't know what the site is built on, so it checks all popular variants consecutively.

Cloud Keys — gcp-credentials.json, azure-credentials.json, service-account.json, terraform.tfvars. A hit means access to a cloud account with all data and potential bills for tens of thousands of dollars.

Encryption Keys — private.key, server.key, rails/master.key. An open private key allows decrypting all traffic or forging signatures.

Logs and Dumps — error.log, debug.log, database.sql, dump.sql. Logs often contain user data, file paths, and sometimes passwords in plain text.

Infrastructure Configs — nginx.conf, docker-compose.yml, web.config. From these, one can learn the internal network topology and find the next entry point.

CMS Vulnerabilities — a separate category. As soon as a new CVE is published, scanners start checking all websites, often within a few hours. According to Google Project Zero, the median time from CVE publication to the first attacks is 15 days, but for vulnerabilities with a public PoC, this time has been reduced to a few hours. An example currently in active exploitation: CVE-2026-9082, SQL injection in Drupal Core on PostgreSQL (versions 8.0 to 11.3.9). The vulnerability lies in how Drupal constructs SQL queries via JSON:API: an attacker passes an array key with nested SQL in the filter parameter, and Drupal inserts it into the query without sanitization. Without authorization, via a regular HTTP request. Result: database dump, admin account creation, arbitrary code execution in some configurations. CVSS 9.8, critical (for comparison: Log4Shell, which brought down half the internet in 2021, received 10.0). The patch was released on May 20, a working PoC appeared on GitHub less than an hour later. On May 22, the vulnerability was added to the CISA Known Exploited Vulnerabilities catalog. In the first 48 hours, more than 15,000 exploitation attempts were recorded on almost 6,000 sites in 65 countries.

The May 29 attack was exactly like that. WAF worked according to OWASP CRS signatures, CrowdSec added both IPs to the blocked list. The client did not know about it.

The scanner went through all categories at once, in 90 seconds.

The scanner launched from two addresses simultaneously. Modern scanners distribute the load across multiple IPs to stay below the threshold of simple rate-limit rules. If the protection triggers on "more than 10 requests per minute from one IP," the scanner simply makes 5 from each. At the same time, the IPs themselves often have no relation to the actual attacker — these are rented VPS, compromised servers, or botnet machines around the world. Côte d'Ivoire here is a random geography, not the place from which a person is actually working.

An interesting detail from the log: the first request from the second IP returned 200 — the scanner first checked the main page, made sure the site was alive, and only then began enumeration. This is a sign of a tool, not random traffic.

WAF (Web Application Firewall) — an application-level firewall. Unlike a network firewall, which looks at IPs and ports, a WAF reads the content of an HTTP request: URL, headers, body. It analyzes each request before it reaches the site.

The basis of the rules is — OWASP Core Rule Set (CRS), an open set of attack signatures supported by the non-profit OWASP Foundation. CRS covers configuration file enumeration, SQL injection, XSS, and other common vectors. Requests to .env, .sql, .key, wp-config.php, and dozens of other extensions are blocked immediately. The WAF does not know if the file exists on the server — it blocks by request name, and the scanner is denied before it can learn anything.

CrowdSec — an open-source behavioral analysis engine. While a WAF works with each request individually, CrowdSec looks at the sequence: what exactly this IP is requesting over the last few minutes.

One request to .env might be a broken link. Ten requests to .env, .env.production, .env.local, .envrc in 30 seconds is no longer a user. CrowdSec recognizes this pattern by scenarios (behavioral rules) and blocks the IP. Blocked addresses are added to a common threat database used by thousands of servers worldwide. A scanner detected on one site immediately becomes an unwelcome guest everywhere.

The scanner processed the standard dictionary in a minute and a half and left with nothing. The client's website did not receive a single malicious request.

When a website connects to Multify, all incoming traffic goes through a proxy. The client connected Multify for localization, not for protection. But since the proxy is in front of the website, all of Multify's infrastructure protection automatically extends to it.

Leaks through open files are one of the most common vectors for hacking. They don't happen due to complex exploits, but due to trivial errors: a developer deployed a project and forgot to remove .env. Placed a test database dump in a public folder. Left a config with passwords on the server. Scanners find such files within a few hours, long before anyone on the team notices the error.

If the client's website runs on Drupal with PostgreSQL, the WAF at the proxy level blocks characteristic request patterns: complex filter parameters to /jsonapi, requests to /user/login?_format=json with non-standard bodies. The scanner does not reach the site. But this is not a substitute for a patch: if the site is directly accessible bypassing the proxy, there is no protection.

Modern scanners distribute requests across multiple addresses to stay below the threshold of simple rate-limit rules. CrowdSec looks at behavior, not the number of requests from a single IP, so this technique doesn't help.

No. WAF blocks requests by path name before they reach the application. The scanner does not know if the file exists on the server — it receives a denial at the proxy level.

A targeted attack is more complex: the attacker knows the target, uses non-standard vectors, and works slowly to avoid behavioral patterns. WAF and CrowdSec reduce the attack surface, but do not provide a hundred percent guarantee. For critical sites, penetration testing and anomaly monitoring are needed.

No. The IP geolocation of the scanner is the geolocation of the machine being used, not the attacker. Blocking by country is pointless: the next attack will come from Brazil, the Netherlands, or Russia.