Now what baffles me is according to logs they all them seem to have
logged-in directly to WordPress as if they know the password (since
it’s only one login attempt in line 16 above). This is true even for
sites only up one day ago and the passwords are not simple ABCs.It is also worth noting that only accounts with WordPress installed
were defaced. Normal HTML-only sites on the same server were not
defaced. And while it’s possible that there are key-loggers in client
stations it certainly don’t make sense as the hacker could’ve simply
used cpanel instead of gong to all the trouble in WP.Given these facts, how can a hacker login to WordPress and be
successful on one attempt?
You kinda answered your own question there, although you probably don’t realize it. But I’ll go ahead and make it explicit for you.
Important point to understand: This is a completely automated attack. Once you grasp that and the implications of it, then the answer is clear.
Firstly, the initial attack vector won’t be in your http logs, because that’s not the way they got in. They either accessed your server directly, or accessed the mySQL server directly. Either way, a false user was created on the site, or the admin password was changed directly using SQL commands.
After this, the login and injection of the script via the theme-editor was entirely automated. What’s you’re seeing is the “payload” portion of the attack.
Scripted attacks like this consist of three phases:
-
The actual attack, which gains them some form of access to the system. In some cases, this may be manual, but in most cases it’s done through an automated process which tries lots of attacks rapidly, until any of them succeeds.
-
Escalation, where the attack exploits the initial entry point in order to gain a higher level of privileges. For example, an SQL injection exploit can be used to create a new user in the database, and this can then be exploited to gain access to the PHP, which can be used to run arbitrary code.
-
Payload injection, where the escalated privileges are used to insert the payload. Usually spamming code or other pre-built crap.
The point being that each of these phases is mostly independent from the next one. You’re only seeing the last step in your logs here. The attacker gained immediate access to your site because the script knew the password already. The password was modified or access was gained via some other means.
And yes, sometimes this approach means that exploits run in stupid ways. It has to do with the automated script-kiddie nature of the systems being used. I’ve seen an attack where an FTP account was exploited, a PHP file was uploaded, the PHP file modified WordPress installations it found, and then the WordPress installs were used to inject spam into themes. The fact that the initial attack allowed directly injecting any PHP desired didn’t matter, the attacking system was wired to proceed in a specific process, even if most of the process was useless in some cases.