How to Handle a Large Number of “Unfamiliar URLs” or Accesses to the “Login Page” in Your WordPress Access Logs

Here’s how to handle situations where your WordPress access logs contain a large number of “unfamiliar URLs” or “login page” entries.

Your WordPress site’s access logs may contain a large number of entries showing direct access to program files for plugins you haven’t installed or direct access to the login screen.

Web administrators reviewing their server access logs may notice a large number of entries showing direct access to program files for plugins you haven’t installed or direct access to the login screen.

Such access logs are actually quite common on WordPress sites. This is because hackers, targeting the vast number of WordPress sites—said to account for 30% of all websites— carry out indiscriminate vulnerability attacks to both discover and exploit sites with vulnerabilities in their code or login passwords.

Using automated tools, hackers launch these attacks— which they consider a “bonus” if successful —against a massive number of sites, even those without known vulnerabilities.

The fact that these attacks are recorded in the access logs is the reason why you see a large number of entries for “unfamiliar URLs” or access attempts to “login screens.”

Therefore, just because such access logs are recorded does not mean it is likely that a hacker has managed to break into your WordPress site (i.e., that the hack was successful and the site was compromised).

However, if you notice any suspicious activity on your site, the likelihood of a successful hack increases, so we recommend running a malware scan using a malware detection plugin or similar tool.

Is it possible to prevent hackers from exploiting vulnerabilities altogether?

For attacks on the login screen or password dictionary attacks (xmlrpc.php attacks), you can take significant countermeasures using security plugins —such as changing the login URL or detecting brute-force attempts and blocking the IP addresses involved.

However, it is extremely difficult to prevent in advance access attempts involving indiscriminate attacks targeting vulnerabilities in other plugins. This is because websites are designed to be accessible to anyone, and an attacker’s request is indistinguishable from that of a regular visitor.

Furthermore, while it is logically possible to implement countermeasures based on hackers’ typical vulnerability attack patterns, the reality is that every time a vulnerability is discovered or publicized, hackers create attacks tailored to that vulnerability and incorporate them into their tools—resulting in a never-ending cat-and-mouse game.

*Implementing countermeasures for each specific attack method is very costly.

Identify vulnerability attack methods (in most cases, the site does not have the vulnerability in question)
↓
Design server configurations and program functions to prevent attacks using those methods in advance
↓
Consider implementing these measures in a way that does not affect the site’s speed or functionality
↓
Implementation

*Given that tens of thousands of vulnerabilities are discovered each year, following the steps outlined above for every single one is not realistic.
*A more practical approach is to pinpoint and fix specific vulnerabilities found on a site as they arise

.

For this reason, the most reliable and efficient approach is to constantly monitor whether the site contains any of the most dangerous vulnerabilities and, if a vulnerability is discovered, to patch it as soon as possible through updates or other means.