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.