Attack Analysis: Vulnerability Scanner vs. Multify Proxy

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

This is typical vulnerability scanner behavior. Not a targeted hack, but automated reconnaissance. Such scanners work continuously, scanning 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 website 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. Developers store API keys, database passwords, and payment system tokens in them. One such file gives an attacker full access to the infrastructure without any traces of a hack. According to GitGuardian, in 2024, secrets in public repositories were discovered more than 12 million times, with .env being among the top three most common. The 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 website is built on, so it checks all popular options in a row.

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 — is 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, in some configurations arbitrary code execution. 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 in less than an hour. 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 websites 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 most often have nothing to do with the real 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 where a person actually works.

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 receives a denial before it can learn anything.

CrowdSec — an open-source behavioral analysis engine. WAF works with each request separately, CrowdSec looks at the sequence: what exactly this IP has been requesting over the past 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 ran through its standard dictionary in a minute and a half and left empty-handed. The client's site did not receive a single malicious request.

When a site 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 site, 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 site 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 replacement 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 falling into behavioral patterns. WAF and CrowdSec reduce the attack surface, but do not provide a hundred percent guarantee. For critical sites, a penetration test and anomaly monitoring are needed.

No. The geolocation of the scanner's IP 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.