I made my WordPress administrator’s password ‘admin’ for 2 weeks and nothing happened. This is why and why threat intelligence is useful.
In my last experiment, What Happened When I Leaked My Server Password on Github.com, I configured a server with a very strong SSH password then ‘accidentally’ leaked it through a Github code repository. Within minutes people found the password and logged in. This time I tested a different approach and created a new WordPress site with the administrator username and password set to ‘admin’ for 2 weeks. Nothing happened. This is why nothing happened and why threat intelligence is important.
Prior to testing, I expected that any new WordPress server that appeared on the internet would be detected using an IP scanner within 7 days. Once discovered, brute-force attacks against the WordPress admin user would begin. Using the combination of admin:admin the site would be compromised very quickly.
To test that theory I created a honeypot installation of WordPress using a Docker container and a cloud hosting service unlinked to anything else I do online. Then I locked-down the host server and network to minimise the impact on others if the container was actually hacked. Next, I set the admin username and password to ‘admin’, then waited to see what happened. I didn’t give it a domain name, didn’t add it to any search indexes, and didn’t promote it in any way. I wanted to see if someone was actively looking for brand new servers that were vulnerable in this way.
What I Expected To Happen
I knew that once someone logged into my WordPress installation they would have full control over the content. They could upload malware to the server, install their own remote access tools, and do pretty much anything they wanted. I wanted my honeypot to be hacked so I could see first hand what criminals were up to.
Before I started I expected to see login attempts against my WordPress site’s admin portal within a couple of days. I see this on my craighays.com website constantly so I know it’s happening. I use a plugin that captures the usernames and passwords of failed login attempts and I review them every now and then to see where the combinations are coming from.
Sometimes the login attempts are the generic admin:admin or craighays:password123 kind of attempts. Other times they’re targeted attacks using my old passwords that have been compromised in publicly known website breaches. These don’t work but it’s fascinating to see old datasets still in circulation and active use.
So naturally, I expected to see the same thing on my honeypot site, but it never happened.
What Actually Happened
As with the previous experiment, generic web vulnerability scanners started to hit my website within minutes of it coming online. 11 different IPs contacted the webserver in the first 2 hours performing both fingerprinting checks and vulnerability tests.
While most scanners check one or two things before moving on, one host stood out in particular as they ran a full vulnerability scan against thousands of possible web vulnerabilities, all of which failed. When I first saw the logs all I could think was: ‘Are you being serious? One-third of the web runs on WordPress… I know you’re a bot… but just look over there, the door is wide open!’.
In summary, a couple of scanners picked up that WordPress was running and did some checks for plugins and themes with known vulnerabilities, but nothing even tried to log in. How disappointing. At least we gathered some threat intelligence in the process.
Why Nobody Exploited My Weak Password
I think the key thing here is that a vulnerability on its own does not mean you will be hacked with it. Every time criminals have compromised a system the following three things have been true:
- The system had a vulnerability
- An exploit was available
- Someone was actively trying to compromise to the system
Unless all three of these criteria are met a vulnerability will not lead to a compromise. That doesn’t mean it’s not a problem. A vulnerability is still a risk and a risk is still a bad event which hasn’t happened yet, but certainly could. As soon as all three line up, the risk becomes reality and you’ve been hacked.
In this experiment both the vulnerability (the weak password) and the exploit (common knowledge of that password) were present but nobody was actively trying to use it. Nobody was scanning the internet for new servers running WordPress with insecure administrator credentials. I dodged a bullet I intended to catch. But this type of information is what makes threat intelligence is useful.
What Is Threat Intelligence
To put it simply, threat intelligence is information about which attacks criminals are using right now. It tells you which software applications and their vulnerabilities are being exploited by which threat actors and for what purpose.
Why Threat Intelligence Is Useful
Software and systems are full of vulnerabilities. The vulnerabilities have always been there. Unless something significant changes in the way we write code we will always have them. It’s not until someone discovers a vulnerability and creates an exploit for it that a vulnerability becomes a feasible risk. When a malicious actor with an exploit starts to attack systems with that vulnerability it becomes a threat.
Threat intelligence allows you to prioritise your response to actual threats, deprioritising theoretical attacks that ‘could’ happen. The goal is to deploy your defences against the things most likely to affect you. If you were forced to pick one, it would be better to patch a ‘low’ rated vulnerability that is being actively exploited against your peers than to patch a ‘critical’ vulnerability which isn’t affecting anyone.
If I had 100 brand new WordPress servers with the username and password admin:admin and 100 brand new Windows servers without the patch for MS17-010, the Wannacry ransomware vulnerability, I would ask my team to fix the MS17-010 first as I know it’s being exploited in the wild.
What Intelligence Came From This Experiment?
While I would have loved to pick apart an actual attack on the honeypot, the absence of a result can still give useful information sometimes. Unfortunately, based on this one-off experiment* I can only hypothesise that nobody is scanning IP addresses in that range for new WordPress installations with the intent of brute-forcing the administrator password.
Other data sources show that brute-force attacks are being conducted on established sites. These sites are discoverable through search engines and referral links. Therefore, it is the discovery element of this attack vector, hunting for new targets by IP, which is not a significant threat. Once a site becomes known it’s almost certain that the weak password would be exploited.
*If I was building my own threat intelligence capability the server would live on indefinitely. There would be many more data capture points with the same, similar, and other configurations. Threat intelligence comes from everywhere, not just honeypots. Honeypots just make it easier to spot threats as legitimate users never see them.
This was a scratch on the surface of how threat intelligence works. We observe what’s happening in the real world and use it to make informed decisions. Where to allocate our people, time, and money. For most people and companies the size of the cybersecurity problem is far greater than resource they have to fight it. By prioritising correctly we can minimise as much risk as possible without fixing everything at once.