4 ms·
Section 13 onwards makes for a great read as to how this all went down. The attacker used a common security scanning tool Nikto, which would have told them that
by graystevens 9y ago
Section 13 onwards makes for a great read as to how this all went down. The attacker used a common security scanning tool Nikto, which would have told them that WordPress and its plugins were horrifically out of date. Any tool could have found this (WPScan, Nessus.. a manual check through HTML source), but Nikto was likely identified due to some common defaults such as the User-Agent within the requests etc.
Once they identified the vulnerability to exploit, it seems they used genuine credentials to then place webshells on the server which gave them persistence - a low-level reverse shell if you will, allowing them to traverse the file system, execute commands as if they had genuine access. Next up, a quick grep for plaintext credentials that they can then pivot with. There are still questions around how those credentials were obtained, but they'd don't specifically call them out as being default.
The report then jumps to the person accessing databases (including payment card info.. whoops) - the question here is why did a Wordpress instance have access to such data? I can't imagine it would have needed it, so I suspect that they either had one huge DB server containing the backend for this WordPress instance, plus their customer data & payment info databases/tables. Or, the malicious actor traversed the internal network, using the WordPress as a pivot point.
Last point worth calling out, is that they are unsure how much of the data was actually exfiltrated - "[...] the transaction/payment card information referred to above was located and accessed: it cannot be ascertained whether or not some or all of that information was indeed exported, but that is a very realistic possibility."
This is a common problem with breaches, and an area what active monitoring can help. By planting unique details/tokens into the database (users, payment information etc.), you can start scanning for them on the clear and dark web. As and when they appear, you can confirm if the data was exfiltrated (and with many honeypots, pinpoint time of the breach). This is one of the many reasons I put BreachInsider[0] together.
[0]https://breachinsider.com https://breachinsider.com
- Neil44 9y agoMaybe they had the same database user for the Wordpress as something more sensitive, or maybe apache/php running as a user with more access than needed alowed them to pull more creds from the code for other apps on that box. Good reason to use enviroment variables rather than hard code. Either way, keeping sensitive customer information anywhere near a public facing Wordpress install is nuts, if that's what they did.
- walshemj 9y agopossibly the WordPress install did not use a dedicated db user/password - its possible that the root user and password was used.
- graystevens 9y agoGood point, the report calls out that the root password for 40+ servers was the same, and that a large number of employees knew or used it. Seems sensible to transfer that same mentality across to other sensitive accounts.
- walshemj 9y agoOuch having worked at BT our internal security would have had afield day with that - but Mobile telecoms where always considered much weaker technicaly.