616 attack attempts in 8 days

There was no actual attack. All 616 external security events registered between July 7th and 15th turned out to be noise generated by automated bots—scanners that mass-check thousands of sites looking for known WordPress vulnerabilities. Our site isn't built on WordPress, so the paths they were searching for never existed, and each attempt ended with a block or 404 error.

The numbers

What exactly they were looking for—and why it's dangerous for an unprotected site

The paths below are classic WordPress targets. In our case, they were harmless because these files simply don't exist, but it's worth understanding why these specific paths are being searched for at all.

/wp-login.php - 273 requests, 197 unique IPs This is the WordPress admin login form. Bots attempt brute-force attacks—automatically testing thousands of username and password combinations, hoping to guess valid credentials. If a site has weak passwords or no login attempt limiting, such an attack can result in complete admin access.

/xmlrpc.php - 255 requests, 183 unique IPs A legacy WordPress interface file used for remote publishing. It's a popular attack target for two reasons: it can be used for password guessing much faster than the standard login form (hundreds of combinations in a single request), and it can be abused for DDoS amplification attacks against third parties through its "pingback" function.

/en/wp-json/wp/v2/users/me - 23 requests, 21 unique IPs A WordPress REST API endpoint that can expose valid usernames by default. This isn't an attack in itself, but a reconnaissance step—discovering actual usernames allows an attacker to target subsequent brute-force attempts more effectively.

/.env - 14 requests, 12 unique IPs This is the only target on our list with genuine damage potential. .env files typically contain database passwords, API keys, and other secrets. If such a file is accessible from the outside (due to server misconfiguration), its exposure could mean complete system compromise—not just the website, but also related services. In our case, Next.js doesn't serve this file publicly, so all attempts ended with 404 or block responses.

/lv/wp-content/uploads - 7 requests, 7 unique IPs The WordPress uploads folder. If misconfigured (for example, allowing PHP file execution), an attacker who has gained minimal access can upload a malicious script and gain complete server control.

How our security monitoring works

These data don't come from typical server logs—they're analyzed by our custom-built AI security system that monitors all incoming traffic, classifies each event by severity, and makes blocking decisions in real time. The system is connected to a Discord notification channel where a summary report is published twice daily—how many events occurred, how many were blocked, and whether there's anything requiring attention.

In addition to regular reports, the system also has what we call a page call mechanism—a direct urgent notification to the development team that bypasses the usual twice-daily summary and alerts immediately when something requires instant response. Unlike the typical noisy log (where hundreds of bot requests are simply registered and silently blocked), a page call is reserved for rare, truly significant incidents.

Practically, a page call works like this: a direct urgent alarm is received on a phone, informing of what's happened. This alarm cannot be dismissed (snoozed)—to stop it, you must get up and log into the system. Once someone from the team logs in, the page call is silenced, and the system shows who exactly has taken on incident resolution. When the issue is resolved, the system automatically checks the code for errors and vulnerabilities before deployment—first in our private GitHub repository, then on the server, and finally on the live site—to ensure a consistent, patched version everywhere.

In the recent period, this mechanism has activated twice:

• An attempt to access the .env file—since this file can contain database passwords and API keys, the system classified it as a high-risk event and immediately alerted the team, despite the request being automatically blocked.

• gramatika.evoex.eu unavailability—when this subdomain site became unreachable, the system recognized it as a service disruption (not a security incident) and immediately notified the team so they could respond quickly and restore the service.

This two-level approach—silent logging for mass bot noise, but immediate alerts for rare, truly important incidents—allows the development team not to lose focus among hundreds of harmless scan attempts, while simultaneously ensuring that a genuinely significant event won't be missed until the next scheduled report.

Origins

Most traffic came from the USA (157), France (52), the UK (48), Vietnam (46), Germany (39), Singapore (36), and India (32). User-Agent strings were spoofed as typical browsers—a classic botnet indicator attempting to appear as a real visitor.

The trend is sharply declining

Event count by day (07-07 to 07-15): 148 → 137 → 75 → 61 → 110 → 41 → 38 → 13 → 1.

The decline correlates with the permanent blocking of 95 IP addresses—the defense is working exactly as intended.

Conclusion

There were no successful attacks, no data breaches, no form spam or authentication failures. All attempts were automated WordPress scanners looking for targets that don't exist here. This doesn't indicate that security is unnecessary—quite the opposite. It shows that a properly configured, non-WordPress architecture and active IP blocking effectively prevent even mass automated attacks before they can reach anything of value.