As reported by Ars Technica, cybersecurity researcher Denis Sinegubko has been monitoring ongoing website hacking activities for a long time. Now, he has identified a major pivot from crypto wallet drainers to brute-force password-cracking attacks on WordPress sites. Why is this happening, what does it mean, and what can you, as an end user, do? We'll dive into all of the need-to-know information right away below.
First, let's talk "Why." Earlier in February, Sinegubko, writing for Sucuri's blog, discussed an increase in "web3 crypto malware," particularly malware used to inject crypto drainers into existing sites or use phishing sites for the same purpose.
These new attacks function differently, and are instead utilizing visitors' PCs for en masse password cracking attempts. The likely reason for this divergence in approach is because it will take a very long time for the active "crypto drainers" to actually turn a profit, if they even manage to do so before getting blocked.
As Sinegubko says, "This is how thousands of visitors across hundreds of different websites unknowingly and simultaneously try to bruteforce thousands of other third-party WordPress sites. And since the requests come from the browsers of real visitors, you can imagine this is a challenge to filter and block such requests."
While the original write-up provides the full gruesome details of the hack and how it works, the gist of what you need to know is quite simple.
Any infected WordPress site can have its visiting users (or their browsers) put to automated work on guessing author or admin passwords for other WordPress sites. Attackers are estimated to be guessing, with over 41,800 passwords for each impacted site. However, only one of the thousands of sites checked in the original Securi blog post was compromised with this method.
You don't need to do too much as an end user to avoid this. Keep your passwords secure, and if you don't trust the website you're visiting, NoScript can be an essential solution to prevent these types of exploits. AdBlockers may or may not do the job as well, but NoScript is as harsh as the solutions get.
For WordPress admins and those concerned about this, verify that none of your passwords, especially system-critical passwords, are default or lazily set in any way. Proper password practice and firewalling your WordPress admin page and "xmlrpc.php" file are the recommended solutions for WP site owners who want to get ahead of this.
