Website Hacked | White Fir Design Blog

Spammers Still Pretending to Have Hacked Websites to Collect Bitcoins From Unwitting Website Owners

Yesterday we got a spam contact form submission claiming our website had been hacked and demanding a ransom. It is part of what looks to be a new large wave of an ongoing spam campaign, which has been going on for at least several years. It is a hoax and websites receiving the message have not been hacked. This was the message we received:

PLEASE FORWARD THIS EMAIL TO SOMEONE IN YOUR COMPANY WHO IS ALLOWED TO MAKE IMPORTANT DECISIONS!

We have hacked your website https://www.whitefirdesign.com and extracted your databases.

How did this happen?

Our team has found a vulnerability within your site that we were able to exploit. After finding the vulnerability we were able to get your database credentials and extract your entire database and move the information to an offshore server.

What does this mean?

We will systematically go through a series of steps of totally damaging your reputation. First your database will be leaked or sold to the highest bidder which they will use with whatever their intentions are. Next if there are e-mails found they will be e-mailed that their information has been sold or leaked and your https://www.whitefirdesign.com was at fault thusly damaging your reputation and having angry customers/associates with whatever angry customers/associates do. Lastly any links that you have indexed in the search engines will be de-indexed based off of blackhat techniques that we used in the past to de-index our targets.

How do I stop this?

We are willing to refrain from destroying your site’s reputation for a small fee. The current fee is $2500 in bitcoins (BTC).

Please send the bitcoin to the following Bitcoin address (Copy and paste as it is case sensitive):

3LKf6NWhJA8L5cmD5p9u6WksjW9SC2jauu

Once you have paid we will automatically get informed that it was your payment. Please note that you have to make payment within 7 days after receiving this e-mail or the database leak, e-mails dispatched, and de-index of your site WILL start!

How do I get Bitcoins?

You can easily buy bitcoins via several websites or even offline from a Bitcoin-ATM.

What if I don’t pay?

If you decide not to pay, we will start the attack at the indicated date and uphold it until you do, there’s no counter measure to this, you will only end up wasting more money trying to find a solution. We will completely destroy your reputation amongst google and your customers.

This is not a hoax, do not reply to this email, don’t try to reason or negotiate, we will not read any replies. Once you have paid we will stop what we were doing and you will never hear from us again!

Please note that Bitcoin is anonymous and no one will find out that you have complied.

In our case, it is rather obvious to be a false claim, since, among other things, the database for our website doesn’t contain any sensitive information that would be of any value to anyone or be a concern if it was released. Looking at the log for our website, the spammer only visited the contact page, which makes it more obvious that this is a hoax.

For others who don’t deal in security as we do, it is easy enough for someone to believe this could be true, but it is a hoax. Unfortunately, it looks like someone did fall for it.

Hacker Impersonated GoDaddy When Hacking GoDaddy Hosted WordPress Websites

While working on cleaning up a hacked WordPress website recently we found a hacker had tried to disguise some of what they were doing by making it seem like it was coming from GoDaddy. GoDaddy, possibly not coincidentally, was the web host for the hacked website we were dealing with.

GD-Stats

The first element of this we found was a malicious plugin with the slug gd-stats. If you were looking at the Installed Plugins page in the WordPress admin area, you would see this information for that plugin:

That labels the plugin as being named GD-Stats and being from GoDaddy, Inc, though the link is to wordpress.com.

The description is weird:

Most leading CMS platforms like WordPress use Ajax in their architecture.

In looking to see if others had encountered a malicious plugin with the same name, we found a topic on WordPress’ forum from early in February where someone else hosted with GoDaddy had run into this:

This morning, I found that our WordPress website has been hacked by someone in Moscow. They uploaded the file “gd-stats.zip” then installed the plugin. Now when I go to our wordpress.org log in page, I put in my credentials, it takes me to a completely blank screen. When I went to our website, it doesn’t have the dashboard option available to log into. We’re hosted through GoDaddy. I’m waiting on their support team as well.

In a follow up they wrote this:

No it wasn’t Godaddy. It was from someone in Moscow who hacked our site at 4:30 AM. They installed the gd-stats.zip and the plug in but I finally got into our Godaddy account and deleted the plug in so we’re good now.

There was a reply from someone else with the same plugin, but no mention of the web host of the affected website.

For a hacker to add that plugin to the website they would already have to have access to the website in some way. In trying to determine what that was, we ran across a major problem, it appeared that GoDaddy had about a week before moved the website to a new cPanel account. That meant that among things, the last modified dates on malicious files were not meaningful, since it just listed the time of the move. It isn’t clear why that happened because of the partially unmanaged nature of the website at the time. Whatever was the case, the malicious plugin appeared to exist from before there was logging available that could have shed light on that. So we hit a dead end there.

Users Table

Another piece of the hack might help to further explain how the hack happened. In the WordPress database table storing the users of the website, _users, we found two non-legitimate Administrators accounts.

Both accounts were listed as being listed as being registered at 0000-00-00 00:00:00, which shows that they were not created through the normal registration process, since if they were, the time they were registered would be there.

Both of the accounts were also meant to look like they came from GoDaddy, with the usernames being:

gd_support
gd_sys_kafhi

Curiously the email address for them doesn’t use a GoDaddy-like domain, instead opting for wordpress.org.com:

gd_support@wordpress.org.com
gd_sys_kafhi@wordpress.org.com

Again we ran into a problem, since the logging isn’t available to see what it would show about how the hacker created those accounts.

There are several routes that could have occurred through. They could have been added through a SQL injection vulnerability on the website that allowed for adding things to the database, but most SQL injection vulnerabilities don’t permit that type of action, so that seems unlikely.

More likely would be that the hacker was able to get direct access to the database. That could be because of a security issue with the website, with the web host, or combination of the two. GoDaddy has had issues with improper security of database access, we posted about another hacked website where that came in to play in April.

February Time Frame

Looking at the session_tokens entries in the WordPress database’s _usermeta table, we found that one of those accounts was logged in to from a Russian IP address, 185.4.65.27, on February 4. That matches up with what was described in that WordPress forum topic.

Notifying GoDaddy

We are going to contact GoDaddy’s security team to let them know about this impersonation and maybe they can check if other websites they host still contain that plugin.

Having Us Clean Up Your Hacked WordPress Website Can Save You Money and Downtime

Getting your WordPress website hacked is bad, what makes that worse is how many security companies are then there to take advantage of you when you try to deal with that hack. Yesterday we published a post about how a web host, HostGator, and web security provider, SiteLock, had gotten someone dealing with a hacked WordPress website to pay $300 dollars for an unnecessary security service. That was after it was decided to restart the website from scratch because of the hacking. So at that point this person had payed more than it costs to hire us to properly clean up a hacked WordPress website and they didn’t have a functioning website.

If they had hired us, we would have gotten the website cleaned and back running already, as we can usually have the cleanup done within a few hours of being brought in. It could get worse, as we noted recently, starting from scratch can in sometimes actually result in you getting back to square one, having a hacked WordPress website.

MalCare Review: It’s Obvious They Are Taking Advantage of Their Customers

If you deal with security, as we do, it often isn’t hard to tell that companies are taking advantage of their customers, but most of them at least try to hide it to some degree. That isn’t the case with a provider named MalCare. Here, for example, is the interstitial we got shown on their homepage when we recently visited it:

In small text at the bottom it says, “No Thanks, I will let my site be hacked :(“. That makes no sense. A malware scan would show if a website is already hacked, it won’t actually do anything to stop a website from being hacked. Either they don’t understand what they are doing at all, or they have no problem lying to their potential customers.

Getting past that, the first message shown on their homepage was this:

Scrolling down a bit, you get more of the same:

That all sounds great, but it again makes no sense if you have a basic understanding of security. Before we explain why, it’s worth noting that not only doesn’t this make any sense, but MalCare contradicts the claims being made there, right on their website. For example, while the above claims “MalCare’s fully automated malware removal lets you get rid of all virus and backdoor forever”, the pricing page touts one of the features being “Unlimited Automatic Malware Removal”:

If they are removed forever, then you wouldn’t need “unlimited” malware removals.

Also, there is a big contradiction in that at the top of their website they highlight an “Emergency Hack Cleanup” service, where they claim the website is cleaned up within 12 hours:

If their instant cleaning service actually properly cleaned up hacked websites, why would anyone need another service that takes up to 12 hours?

That page also includes this incredible customer testimonial, which ties back to the claims MalCare makes not making sense:

If you are spending hours each month cleaning up malware on your clients’ websites, that means those website are being hacked repeatedly and are still not being properly secured. Who would publicly admit to that? Cleaning up those files doesn’t address the security issue that is leading to them being hacked, so it isn’t surprising that there would continue to be issues.

To properly deal with a hacked website, there are three key components:

Clean up the hack.
Get the website secured as possible (which usually involves getting Drupal, contributed modules, and themes on the website up to date).
Try to determine how the website was hacked and fix that.

The MalCare service doesn’t even claim to address latter two of those, which means that the websites using the service can get hacked over and over. Hence the “unlimited” malware removals.

Based on years of real world experience, things are likely worse than that. What we have found is that automated tools for cleaning up malware, which are actually used by many providers (contrary to how multiple providers claim to be the only ones), don’t produce great results. They both miss plenty of malicious files, but also produce plenty of false positives. That MalCare provides a manual service would indicate that they know this to be the case, while also claiming otherwise. What we have also found repeatedly, is that security companies that don’t try to determine how websites have been hacked miss malicious files that they would have otherwise found. So automated malware removal is quick, but it isn’t good, hence again, why MalCare itself provides a manual cleanup service.

MalCare Thinks Cleaning a Website Doesn’t Involve Making Sure it Works

In looking around more about MalCare we found this odd situation where the reviews of their WordPress plugins are mostly unrelated to the plugin. One of them seems rather informative as to how little you get when you pay for their manual service.

The reviewer wrote this:

I purchased the expensive pro version of this and it did not solve the issue and broke my site.

I bought with confidence because it says on their site :
“Guaranteed 100% WordPress Malware Removal. Without breaking your website.”
and
“Get 3X your money back if we cannot remove your malware.”

I have contacted them many times and they refuse to refund my money. It says get 3x your money back but you will not even get it back 1x time
I also asked them to close my account and delete my credit card informations which the also refuse to do.

The substantive part of the response from MalCare is this:

The website was broken because of the changes that you had done to the website via FTP. This detail was mentioned & conveyed by you on the email thread. You had also mentioned that because we were not able to recover the data & make the website look like before, you’re requesting a refund.

But unfortunately, we have no control over plugin & theme data that is on the website which was lost because of the malware attack. At best, we can assist you with cleaning the site which our team has.

We cannot process a refund because our refund policy clearly states that a refund can be processed only if we are unable to clean the website. But in this case, we did clean all the malware from the site.

As a company that has been doing cleanups of hacked WordPress websites for over a decade, we have never left a website broken after a cleanup. We wouldn’t even consider doing that. If data was truly gone, then we couldn’t restore it, obviously, but we would have determined that before starting the process instead of making a promise, we couldn’t keep. We also charge after the work is done, not before, which we have always felt is better a guarantee.

Numbers Never Lie

When looking at the websites of services like this one, one thing that is easy to check to see if they look legitimate is the stats they show. Not surprisingly, like the others, they don’t point to any independent testing of their services effectiveness, but they do claim to be compatible with 5,000+ web hosts:

We can safely say they couldn’t even name 5,000 web hosts, much less have they determined if they were compatible with that many.

NortonLifeLock Safe Web Blocks Websites Without Providing Basic Details to Justify Doing So

The power of big tech companies to censor has recently been getting spotlighted quite a bit. One element of that which doesn’t seem to get nearly as much focus when that comes up, is whether those actions are being taken in line with the stated policy justifying it when not involving high profiles actors and if there is a fair process to fix a mistake or undo things if changes have been made. While the focus on that censoring is usually in relation to social networks, it can impact other areas as well. NortonLifeLock’s Safe Web system being an example of one with problems, which we ran across again while dealing with a website that had been hacked.

The website was cleaned of malicious code about a month ago. But the company doing that Sucuri, failed to do other work that is part of a proper cleanup, so we were brought in. Another issue with the website is it being blocked NortonLifeLock’s software that relies on their Safe Web system. The block page shown when using their Norton Safe Search Enhanced extension for the Chrome web browser warns “Dangerous Webpage Blocked” and “This is a known dangerous web page. It is highly recommended that you do NOT visit this page.”:

That most likely would be connected to the hack, but it isn’t clear and, even if it is connected, there is no way to tell if that is based on the state of the website before it was cleaned or after.

Clicking the “View Full Report” button brings up the entry for the website on NortonLifeLock’s Safe Web website, which provides almost no additional detail. At first glance it just provides the same exact information:

Clicking the “Click here to submit dispute” link provides one additional detail, the website has been categorized as “Malicious Sources/Malnets”:

If you don’t know what that means, you are not alone, as despite dealing with hacked website for years, we are not familiar with any significance of that terminology.

How exactly are you supposed to reasonably dispute such an action when you don’t know what is you are even disputing?

While in this situation the website was in fact hacked, so the blocking could be justified, NortonLifeLock isn’t exactly a company that has shown it should be trusted. One of their predecessor companies paid major fines for false claims and the other has years worth of behavior that seems like it should have put them out of business.

Hacker Using SQL Injection Vulnerability to Add “magentoupdate” Admin Account to Magento Websites

As is a common occurrence, we were recently hired to re-clean a hacked website that the security company Sucuri, which is owned by GoDaddy, had repeatedly failed to properly clean. This time it was a Magento based ecommerce website we were cleaning. As is standard issue in those situations they had missed malicious code that should have been easy to find. What we also found was that the hacker had been able to add an additional admin account, unfortunately that had occurred prior to the time period logging was still available, so we didn’t have evidence of how that had been done.

In a situation where we haven’t been able to determine how the hacker has gotten access, part of our cleanup process is to recheck things for a couple of weeks to see if the hacker tries to get back in. In this case the admin account returned a couple of days later.

For others dealing with the admin account in this situation had these details:

User Name: magentoupdate
Email: support@media.com
First Name: support
Last Name: support:

With the logging available from when this occurred we found a log entry where one of the URL parameters was this:

');insert%20into%20%60admin_user%60%20(firstname,lastname,email,username,password,created,lognum,reload_acl_flag,is_active,extra,rp_token,rp_token_created_at)%20values%20('support','support','support@media.com','magentoupdate','8df1e8abd8ce4761633042eb8958db97:rp',NOW(),0,0,1,'N;',NULL,NOW());INSERT%20INTO%20%60admin_role%60%20(parent_id,tree_level,sort_order,role_type,user_id,role_name)%20VALUES%20(1,2,0,%22U%22,(SELECT%20user_id%20FROM%20admin_user%20WHERE%20username%20=%20'magentoupdate'),'support');

That is SQL code that generates that admin user, which would be exploited through a SQL injection vulnerability. In this case it involved exploiting a SQL injection vulnerability in an extension on the website, which we then patched up.

These Security Rules Are Not an Indication Your WordPress Website is Hacked

Recently we mentioned the importance of security companies checking to make sure that websites they are being contacted about cleaning are in fact hacked. The reason for that is often problems unrelated to a hack are believed to beloved to be caused one, leading to people looking for unnecessary cleanups.

In one reason situation the person who contacted us was sure that their WordPress website was hacked due to rules (or code) in the web.config, which is a configuration for websites being hosted on IIS web servers, for the website that actually were there to protect the website.

As an example of what was at issue, the following rule would restrict accessing .php files in the WordPress uploads directory, which would prevent a hacker from running code if they could upload .php files through some vulnerability:

<rule name="Deny scripts from wp-content/uploads for WordPress instance #6" enabled="true" stopProcessing="true">
	<match url="^wp-content/uploads/.+\.php" />
	<conditions />
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>

The rules may have been generated by the Plesk control panel.

Here are all the rules in question in case someone else is searching for information on this:

<rule name="Block wp-config.php for WordPress instances" enabled="true" stopProcessing="true">
	<match url="wp-config.php" />
	<conditions />
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>
<rule name="Deny scripts from wp-includes for WordPress instance #6" enabled="true" stopProcessing="true">
	<match url="^wp-includes/.+\.php" />
	<conditions>
		<add input="{REQUEST_URI}" pattern="^/wp-includes/js/tinymce/wp-tinymce\.php$" ignoreCase="false" negate="true" />
	</conditions>
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>
<rule name="Deny scripts from wp-content/uploads for WordPress instance #6" enabled="true" stopProcessing="true">
	<match url="^wp-content/uploads/.+\.php" />
	<conditions />
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>

Is the “Insecure content blocked: the page is trying to load scripts from unauthenticated sources.” message related to malware or another hack?

We recently had someone contact us looking for a cleanup of a hacked website due to the Chrome web browser displaying the message “Insecure content blocked: the page is trying to load scripts from unauthenticated sources.” when visiting their website, which they thought was caused by malware on the website. It was good that they contacted us and not one of the many unscrupulous security companies out there, as instead of taking people’s money before even knowing if our service is really needed, we actually make sure the website is hacked first (when there is a real hack, we don’t charge until the work on the cleanup is completed).

In this case the website wasn’t hacked, instead it was simply a case where some of the URLs for content on the page were using HTTP URLs even when pages of the website were requested over HTTPS, which creates a minor security issue, hence the warning.

What is important to note though is that this type of situation could be caused by malware, as it could be a situation where a hacker has added HTML code to the website’s pages that causes requests to malicious content over HTTP even when the pages are served over HTTPS. So if you start seeing the warning without having changed anything on the website, a hack could be a cause of the message.

The important take away from this is that you want to make sure to confirm that your website is hacked before hiring someone to clean it. If a company is interested in taking your money before even confirming it is hacked, they probably don’t have your best interest at heart, which based on our experience of being brought in to deal with the results of others improperly handling hacked websites for years, could lead you to have even more problems than the initial hack.

Vulnerability in Older Versions of MODX Being Exploited

Quite often with hacked websites outdated software is pointed to as the source of the hack. That is usually a claim that is made without any knowledge if the claim is actually true. Many security companies that market themselves as having unique expertise in dealing with hacked websites don’t even attempt to determine how websites are hacked, despite that being one of the three key components of a proper cleanup, so they would have no idea what the cause might be. Often times these companies don’t seem to even have a cursory knowledge of what they are talking about either, as an example, one well known security company, Sucuri, once told people to update software despite it being well known that the vulnerability being exploited in the software was in the then current version of the software (that kind of thing somehow never stopped journalists from repeating misleading and false claims made by that company or people claiming that they are a reputable company).

From what we have seen those baseless claims are usually easy to spot as there usually isn’t even a specific vulnerability that is pointed to as being the cause of the hack, which should be something known if someone has actually done the work to determine the source of the hack and determined it was outdated software.

As example of finding out that outdated software was actually the cause of a hack, we were recently brought in to clean up a hacked MODX website. MODX websites have not been a common type of website needing cleanups from us recently, so the software in use on the website was of some note right away.

In trying to determine how a website was hacked the logging is probably the most important resource, but the files can often tell you a lot, and both of them can work together to speed up the process. In the case of this website there was an obviously malicious file named dbs.php in the root directory of the website. That file had also had a number of POST requests made to it, which are requests that contain additional data and of which most requests sent by hackers are of that type, sent to it shortly before we started the cleanup. Looking back at the logging to where that file was first requested we found it in a set of requests sent by an IP address from Ukraine:

134.249.50.5 – – [19/Jul/2018:19:55:23 -0400] “GET / HTTP/1.1” 403 134 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36”
134.249.50.5 – – [19/Jul/2018:19:55:23 -0400] “POST /connectors/system/phpthumb.php HTTP/1.1” 403 134 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36”
134.249.50.5 – – [19/Jul/2018:19:55:24 -0400] “GET /dbs.php HTTP/1.1” 403 134 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36”

The first request there is for the homepage of the website. The second one sends a POST request to a file /connectors/system/phpthumb.php. Finally there is a request for the dbs.php file. Based on that, it would appear that the file phpthumb.php would be the vector for adding the dbs.php file.

In reviewing the file phpthumb.php there wasn’t anything in the file itself that looked like a vulnerability that would permit uploading a file as that series of requests would indicate was what the hacker would be attempting to do. In fact the file only contained four lines of code that just called on code in other files:

define('MODX_CONNECTOR_INCLUDED', 1);
require_once dirname(dirname(__FILE__)).'/index.php';
$_SERVER['HTTP_MODAUTH'] = $modx-&gt;user-&gt;getUserToken($modx-&gt;context-&gt;get('key'));
$modx-&gt;request-&gt;handleRequest(array('location' =&gt; 'system','action' =&gt; 'phpthumb'));

Instead of digging through more code at that point we instead did a web search for “/connectors/system/phpthumb.php” and though that we got pointed to the issue. There was a post of the details of a vulnerability that matched what we had seen that was published on July 13 and what seems more important, code for exploiting the vulnerability that was released on July 18. On this website the first attempt to exploit it was one July 19, so it would seem the code to exploit it was quickly utilized by hackers.

That vulnerability had been fixed in version 2.6.5 of MODX, which was released on July 11, and the developers provided clear notice of the need to update due to security fixed in it. Writing in the release announcement

Today we released MODX Revolution 2.6.5. It contains fixes for two critical security vulnerabilities affecting all versions at or prior to 2.6.4. Upgrading to 2.6.5 should be considered mandatory.

and

Upgrading is Critical

Revolution 2.6.5 contains critical security enhancements, you should upgrade to 2.6.5 now. See below for more info.

We cannot stress the importance of diligently upgrading to the latest version of MODX enough. While no software is 100% secure, powering your site with the most current version usually helps protect you from hackers that rely on exploiting outdated software. If you’re not sure what version of MODX Revolution you’re running, log into your website Manager. If the version number doesn’t appear in the top left-hand corner of the Manager, go to Manage>Reports>System Info.

The two vulnerabilities refer to the ability to upload files and to remove files/directories. From the post with the details of the vulnerability it sounds like in version 2.5.1 to 2.6.4 the ability to exploit the file upload vulnerability would be more restricted than was the case with the website were dealing, which was running 2.4.1.

Cleaning Up After This Hack

On this website the hacker had done quite a number on it. The .htaccess file in the root directory had been removed, leading to all the pages other than the homepage to no longer being functional. That seems to have been done to remove any restriction in the .htaccess file that would have blocked the hacker from sending requests to the malicious files they were uploading. When trying to go to the admin area you would be redirected to another website due to the content of all of the JavaScript files on the website being replaced with malicious code.

The best option to clean up after this would be restore a clean back up from before the hack (making sure that all of the existing files are removed during the restoration). Seeing as the vulnerability wasn’t disclosed until July 13, a backup from before then would be a good option. You might be able to get way with one from before July 18 as well. A review of the logging by someone familiar with all of this would likely be able to confirm when the hacker hacked the website.

From what we could see from that website, it would appear that there are likely multiple hackers exploiting this vulnerability and doing different things, so it wouldn’t be possible to provide general instruction on what to remove from the website to clean up if there isn’t a backup available (though based on past experience that won’t necessarily stop someone from claiming to provide that and unintentionally or intentionally leading people astray).

If you are looking for a professional cleanup from this or any other hack of a MODX website we provide a service for that. We can also upgrade MODX for you.

Data on Previous Logins Stored in Database Can Help Determine How WordPress Websites Were Hacked

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.