Running a static site saved me from getting hacked

Posted on

After removing all client-side analytics from my site over a year ago, I’m now looking into my server logs. While Google Analytics could give me a detailed picture of what is going on, I don’t need that information. Rough page views and maybe referrers are more than enough for me right now.

After poking around my server logs for a few minutes, most page views seem as you’d expect. A few odd things stand out, which are as hilarious as they are educational.

For example, I found several attempts to navigate to /wp-login.php on my server. That URL leads to the default login form on a standard WordPress installation. I have never run WordPress on this server. This is a sign of someone trying to find vulnerable installations across the web. It’s nothing targeted, but a broad attempt to find sites that aren’t up to date. They are usually run using basic scripts that scan for a variety of things.

The scan weirdly also looked for /wp-content/plugins/wp-file-manager/readme.txt in particular. My best guess is that there is a known vulnerability in that WordPress plugin. By looking for its README file, an attacker can learn if a site has that plugin installed. I never even considered that was a way to get this information.

There are a few other suspicious endpoints they scanned for. Among them are ones that would tell them if I’m running Spring Boot, Solr, Laravel, MySQL, or one of many others. I am going to drill into this a little further, but it seems harmless so far. It’s interesting that even small sites like mine are part of these scans. In a way, running a static site instead of WordPress saved me from getting hacked now.

My main takeaway is to always rename the name of WordPress’ default login form. Attackers seem to scan for /wp-login.php specifically. The login form will work fine under another name. Use an obscure name, because these scripts scan for things like /admin as well.

Grid overlay