01 · Task
Task
The owner of a WooCommerce shop heard about the problem from customers. At the payment stage, an extra window appeared and asked for card details. That window came from a skimmer, a script planted in the shop that captures payment card details during a purchase and sends them to the attackers. The order still goes through normally, so the theft itself is easy to miss. The antivirus scanner installed in the shop reported several suspicious files, but deleting them changed nothing. I had to establish how the attacker had got in, what exactly they had done and how many orders had gone through the tampered payment step, and present the findings in a form the client’s lawyer could use for the report to the data protection authority.
02 · Solution
Solution
I started with the server logs rather than the files. The timeline showed a series of requests to one WordPress API endpoint. Through it, the attackers exploited a recently disclosed security hole in WordPress core, created administrator accounts and got into the admin panel without a password, using forged session cookies. A few days later, one of the groups planted the skimmer. It sat in the database, in a settings field of a plugin used for inserting scripts, which is why the file scanner could not see it.
Then I took these steps:
- I compared all WordPress core files with the official version and checked the server for unknown files. There were no web shells, and the scanner’s alerts turned out to be false alarms.
- I deleted the attackers’ accounts, cleared the field with the skimmer and replaced all keys and passwords for the admin panel, the database and login sessions. The stolen login details stopped working, and everyone who was logged in was logged out.
- I found out why the shop had not installed updates: two automatic update mechanisms were blocking each other. I fixed this and checked that security updates run again.
- I added a firewall rule that blocks the API endpoint used in the attack and updated the plugins with known security holes.
- From the logs, I determined the actual period when the skimmer was active and the number of orders that went through it, and checked for traces of the customer database being downloaded.
03 · Result
Result
The shop is selling again, with clean code, working updates and the attack vector blocked. Instead of guesses, the client’s lawyer received material with a specific time window and a list of the orders at risk. This limited the notification to the customers who were actually affected. I describe how I handle cases like this on the WordPress malware removal page.
