Epilogue to the WordPress VPS compromise investigation By SepedaTua — CrushEdge.com After writing all of this down, I realized there was one more useful question. Not: “What did the attacker do?” But: “What would I do differently if I could go back to the day before the incident?” That is probably more useful than another list of malware strings. Because…

The final practical part of a real-world WordPress VPS compromise investigation By SepedaTua — CrushEdge.com The restore was the easy part. The harder question was: How do I make sure I don’t have the same problem again next week? I could restore the websites from a known-good backup, start Apache and MariaDB, and call it a day. That would be…

Part 5 of a real-world WordPress VPS compromise investigation By SepedaTua — CrushEdge.com By now, the server was restored. That was the part I cared about most. But I didn’t want this whole incident to end with: “Well, I got hacked, restored a backup, and hopefully everything is fine.” That’s not very useful to anyone else. So I took the…

Part 4 of a real-world WordPress VPS compromise investigation By SepedaTua — CrushEdge.com By this point I had enough evidence to say: The server had been compromised. I had malicious PHP. I had disguised image files. I had a PHP-based file manager. I had an encoded payload. I had a native executable associated with cryptomining. I had suspicious database activity….

Part 3 of a real-world WordPress VPS compromise investigation By SepedaTua — CrushEdge.com There was another problem waiting for me after the filesystem investigation. MySQL. And this one was partly my own fault. I had a legitimate reason for allowing remote MySQL connections. Some of my applications live on temporary cloud VPS instances. I create a VPS when I need…

Part 2 of a real-world WordPress VPS compromise investigation By SepedaTua — CrushEdge.com In Part 1, I stopped the server and started looking at the filesystem instead of immediately trying to get the websites back online. The first confirmed webshell was bf6f03.php. Then I found something more interesting. The attacker had apparently decided that naming a file shell.php was too…