While trying to determine how websites are hacked is one of the three important components of a proper hack cleanup, what have seen is that many security companies fail to even attempt to do that. There are a number of possible reasons why that is, including people doing work they don’t have the necessary skills to handle (which seems to be a general issue when it comes to web development) and security companies realizing they can get away with cutting corners even if produces a bad result of their customers. Another possibility, though one that would assume that these companies had ever attempted to try to actually do things properly, is that often important evidence is no longer available once you are bought in to clean things up and therefore your ability to say with certainty what happened will be limited.
One of the most important items to have access to determine how the website was hacked is logging of requests for the website. In some cases though there is only logging available for requests made to the website from within the last 24 hours, while the hacker may have first gained access days, weeks, months, or even years before that.
Depending on the software being used on a website there may be separate logging made by it that is still available even if the other logging is no longer available. For example, Drupal logs recent events including logins and provides the username and IP address that was used to log in. That is stored in its database and then viewable through the admin interface of the software.
For WordPress websites there are plugins that provide similar capability to Drupal’s built in logging, but one of those isn’t likely to have been installed on a hacked website before it was hacked. But it turns out there is a more limited logging of logins that is stored in the database. That has been helpful to us as it has allowed us to be able to provide better information on what has happened with hacked WordPress websites we have been hired to clean up, so we thought it would be worthwhile sharing information on that, using a website were recently cleaning up as an example.
With WordPress, data on user accounts is stored in two tables in the database. The first _users includes the basic details on the accounts, like the username and when the account was created. That info looks like this when viewed in the phpMyAdmin database administration tool:
Additional user data created by WordPress and plugins is stored in the _usermeta table. One of those is the session_tokens, which is data to keep track of logins. An entry of that looks like this in phpMyAdmin:
The user_id value in that is the equivalent of the ID value in the _users table. So that entry would relate to the user “admin” shown before.
The full value of meta_value entry there is:
a:1:{s:64:"[redacted]";a:4:{s:10:"expiration";i:1528715599;s:2:"ip";s:14:"139.228.121.62";s:2:"ua";s:77:"Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/D47D";s:5:"login";i:1528542799;}}
For the purposes of trying to get better understanding of a hack, two pieces of that are usually of importance.
The first is the listing of the IP address that the login came from. Which looks like this ‘”ip”;s:14:”139.228.121.62″‘ in our example. The IP address there is from Indonesia, which isn’t where anyone should have been logging in to this website should be coming from.
The second is the listing of when the login occurred. Which looks like this ‘”login”;i:1528542799’ in our example. The time value there is in Unix time, which can be converted to normal date and time format using a tool this one.
With those two things you can gather more information on what accounts where recently logged in to and from where. That is particularly useful in confirming that a hacker had access to admin area of WordPress and then you can use data from the _user to get a better idea of how they might have gained access.
With that website we could see that a hacker was able to log in to a legitimate WordPress admin account and also had logged in to another account that was created after the hacking had started.