Website Hacked

What Hacker Does When They Try to Regain Access to a Hacked WordPress Website Through a Backdoor

A couple of months ago, we talked about the difference between a website that is repeatedly hacked due to an unaddressed vulnerability and a backdoor. How you handle those situations is also different and you need to figure out which has occurred to handle it right. One way to help figure out which is occurring is to review the log files of requests to the website, after the website has been cleaned up, to see what the hacker then does. We did just that with a hacked WordPress website we were cleaning up that had an issue with backdoors.

The first requests the hacker made were to try to access malicious code that the hacker added that runs when accessing the website:

157.90.177.207 – – [03/Apr/2024:18:34:46 -0700] “POST /index.php?AyGb=Bcsmp HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36 Edg/115.0.1901.183”
164.92.131.172 – – [03/Apr/2024:18:34:47 -0700] “POST /index.php?AyGb=Bcsmp HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36”

After that failed because the website had been cleaned, they then made requests to many backdoor files they had previously placed on the website to try to regain access and add malicious code back on the website:

162.241.253.213 – – [03/Apr/2024:18:34:49 -0700] “POST /profile.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5.2 Safari/605.1.15”
198.57.247.231 – – [03/Apr/2024:18:34:50 -0700] “POST /[redacted]/wp-includes/PHPMailer/admin.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Mobile/15E148 Safari/604.1”
103.93.160.210 – – [03/Apr/2024:18:34:51 -0700] “POST /[redacted]/wp-includes/block-supports/quxgekpc.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 15_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/110.0.5481.83 Mobile/15E148 Safari/604.1”
64.202.190.47 – – [03/Apr/2024:18:34:54 -0700] “POST /.wp-cli/wp-login.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.3 Mobile/15E148 Safari/604.1”
192.185.4.62 – – [03/Apr/2024:18:34:56 -0700] “POST /[redacted]/wp-includes/js/imgareaselect/options.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; RMX2103) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Mobile Safari/537.36”
185.26.106.164 – – [03/Apr/2024:18:34:57 -0700] “POST /[redacted]/wp-includes/block-supports/mptrluah.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 13; SM-A715F) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Mobile Safari/537.36”
162.241.230.71 – – [03/Apr/2024:18:34:57 -0700] “POST /[redacted]/wp-content/uploads/2022/profile.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.6,2 Safari/605.1.15”
161.35.61.218 – – [03/Apr/2024:18:34:58 -0700] “POST /[redacted]/wp-admin/css/fkeyshcu.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; vivo 1915) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Mobile Safari/537.36”
217.117.128.10 – – [03/Apr/2024:18:35:00 -0700] “POST /[redacted]/wp-includes/theme-compat/ldgjoguq.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_0_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.0 Mobile/15E148 Safari/604.1”
50.62.150.220 – – [03/Apr/2024:18:35:02 -0700] “POST /cgi-bin/wp-login.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Mobile/15E148 Safari/604.1”
132.148.120.153 – – [03/Apr/2024:18:35:03 -0700] “POST /[redacted]/wp-includes/images/admin-ajax.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36”
198.57.247.226 – – [03/Apr/2024:18:35:04 -0700] “POST /wp-content/plugins/olympus-google-fonts/includes/customizer/controls/js.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_1_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Mobile/15E148 Safari/604.1”
182.50.132.94 – – [03/Apr/2024:18:35:05 -0700] “POST /[redacted]/wp-content/uploads/2022/profile.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; M2010J19SG) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Mobile Safari/537.36”
69.163.178.127 – – [03/Apr/2024:18:35:07 -0700] “POST /[redacted]/wp-includes/block-supports/quxgekpc.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 10; M2004J19C) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.101 Mobile Safari/537.36”
69.49.241.41 – – [03/Apr/2024:18:35:08 -0700] “POST /[redacted]/wp-includes/block-supports/mptrluah.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; arm_64; Android 11; 21091116UG) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 YaBrowser/23.1.4.84.00 SA/3 Mobile Safari/537.36”
157.230.240.43 – – [03/Apr/2024:18:35:10 -0700] “POST /.wp-cli/wp-login.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/273.0.547966426 Mobile/15E148 Safari/604.1”
95.216.8.84 – – [03/Apr/2024:18:35:11 -0700] “POST /[redacted]/wp-includes/PHPMailer/admin.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 6.0; ALE-L21) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.74 Mobile Safari/537.36”
63.228.175.170 – – [03/Apr/2024:18:35:12 -0700] “POST /profile.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Mobile/15E148 Safari/604.1”
50.87.144.121 – – [03/Apr/2024:18:35:13 -0700] “POST /[redacted]/wp-includes/images/admin-ajax.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_1_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Mobile/15E148 Safari/604.1”
92.222.10.62 – – [03/Apr/2024:18:35:15 -0700] “POST /[redacted]/wp-includes/theme-compat/ldgjoguq.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.4 Safari/605.1.15”
103.74.116.113 – – [03/Apr/2024:18:35:21 -0700] “POST /[redacted]/wp-admin/css/fkeyshcu.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; CMA-LX2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.98 Mobile Safari/537.36”
202.28.78.37 – – [03/Apr/2024:18:35:23 -0700] “POST /[redacted]/wp-includes/js/imgareaselect/options.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Mobile/15E148 Safari/604.1”
169.45.200.230 – – [03/Apr/2024:18:35:25 -0700] “POST /wp-content/plugins/olympus-google-fonts/includes/customizer/controls/js.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Mobile/15E148 Safari/604.1”
50.62.176.231 – – [03/Apr/2024:18:35:26 -0700] “POST /cgi-bin/wp-login.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/273.0.547966426 Mobile/15E148 Safari/604.1”
109.105.49.240 – – [03/Apr/2024:18:35:27 -0700] “POST /index.php?vfb=Klkw HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Mobile/15E148 Safari/604.1”
157.90.145.251 – – [03/Apr/2024:18:35:28 -0700] “POST /index.php?vfb=Klkw HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36”
81.169.250.132 – – [03/Apr/2024:18:35:30 -0700] “POST /index.php?TgAD=utRBi HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Mobile/15E148 Safari/604.1”
203.245.28.189 – – [03/Apr/2024:18:35:33 -0700] “POST /index.php?TgAD=utRBi HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/115.0.5790.130 Mobile/15E148 Safari/604.1”
148.113.173.205 – – [03/Apr/2024:18:35:39 -0700] “POST /?Zzw=AUFBo HTTP/1.1” 301 244 “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.3 Mobile/15E148 Safari/604.1”
51.91.44.167 – – [03/Apr/2024:18:35:43 -0700] “POST /index.php?WeXQ=yuej HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36”
208.113.205.120 – – [03/Apr/2024:18:35:44 -0700] “POST /index.php?WeXQ=yuej HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36”
184.168.118.22 – – [04/Apr/2024:00:07:17 -0700] “POST /[redacted]/wp-content/themes/qop043n9/cbgyjuye.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; SM-A202F) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.62 Mobile Safari/537.36”
142.93.14.237 – – [04/Apr/2024:00:07:25 -0700] “POST /[redacted]/wp-includes/rest-api/themes.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 10; SM-A405FN) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Mobile Safari/537.36”
198.57.247.188 – – [04/Apr/2024:00:07:26 -0700] “POST /[redacted]/wp-includes/rest-api/themes.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 13_1_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Mobile/15E148 Safari/604.1”
185.162.31.173 – – [04/Apr/2024:00:07:30 -0700] “POST /[redacted]/wp-includes/Requests/bsqukfha.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 13_1_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Mobile/15E148 Safari/604.1”

The hacker tried to access over 30 different backdoor files that they placed on the website. It isn’t uncommon for many of those files to have been added and for them to be placed widely across the website’s file structure, as was the case here. Because we had already cleaned out all of those files, the hacker was unsuccessful in regaining access.

Also notably there, the hacker was making the requests from many IP addresses, which is a good example of why trying to stop hackers by blocking access to certain IP addresses is not an effective security measure. (The requests also made it look like the request were coming from a variety of web browsers.)

If you need help with a hacked WordPress website, we can help you.

A WordPress Website That is Hacked and Redirecting to Another Website May Redirect Intermittently

While we are often contacted to deal with cleaning up hacked WordPress websites, we also often run across hacked WordPress websites when we are contacted about doing other work. We mentioned a recent instance where a WordPress website that was running slowly was hacked. In another instance, while checking on a website to see what software it was running, we got redirected to another website. What was going on? The website was hacked, but determining that isn’t always easy from the outside, as the redirects can happen intermittently and you don’t necessarily have any other way of spotting the hack from the outside.

While some redirects occur because of JavaScript code being loaded by a web page, so you can see the code even if it doesn’t cause a redirect in a particular instance, others occur before the web page loads. When the redirect occurs can vary. In this particular situation, the redirect had happened for us when we directly accessed the website, but didn’t happen the second time. The results of a tool we have to check if website are redirecting from Google showed the same pattern. Here was the result of that the first time we requested the page:

The details of that are not going to mean much to those not familiar with HTTP headers, but what is going on is that when requesting the page from Google the request was being temporarily redirected (a 302 redirect) to Location: https://ootooghangoh.shop/?u=k8pp605&o=c9ewtnr&t=ggdown.

A temporary redirect just means that web browser (and other systems) shouldn’t store the redirect and automatically redirect the next time.

When running the same request again, the redirect didn’t happen again:

In both cases, trying again few hours later, the redirect again occurred with the first attempt, but not on subsequent requests.

In other situations, the redirect might only in other situations, including only requests from mobile devices.

Just to make it a bit harder to determine what is going on, it is also possible that there is malware on someone’s computer that is causing a redirect.

If you are unsure of if your WordPress website is hacked, please contact us to get a second opinion on your belief that it might be hacked.

Kentico CMS Still Being Abused to Host Spam Files on Websites, Possibly Through Vulnerability

Two days ago, we looked at one method web spammers are using to post spam files on to websites, abusing the Webform module for Drupal. Another aspect of this involves a less popular content management system, Kentico CMS. Like the abuse of that Drupal module, this isn’t a new issue. Lorenzo Franceschi-Bicchierai covered this situation in June of last year at TechCrunch.

What is going on there, though, isn’t as clear. The TechCrunch article had this response from the developer of Kentico CMS:

“We are aware of this particular risk that could have happened with Kentico 12 or older versions. This was identified years ago as a result of a misconfiguration, and we already addressed it at the time and changed our documentation,”

It’s unclear what addressing it means and if this was an end-user misconfiguration or a developer misconfiguration.

The security fixes listed version 12 of Kentico CMS on the software’s Hotfixes page, including two fixes for vulnerabilities that allowed uploading files that shouldn’t have been allowed. We found another claim of a similar issue that was supposed to have been addressed in version 11.0.45 of the software, though we couldn’t find a mention on the Hotfixes page of a security fix in that version.

So this is possibly caused by a vulnerability in an old version of Kentico CMS or possibly abuse of intended upload functionality that was addressed in new versions of the software.

For those running Kentico CMS or other web software that have websites that appear to be hacked, we can help you to get that properly cleaned up.

Just Because a WordPress Plugin You Use Has a Vulnerability It Doesn’t Mean It Got Your Website Hacked

As we have talked about recently, there is often confusion over how websites have been hacked. One issue that comes up from time to time is the claim that a WordPress plugin that contains an unfixed minor vulnerability is the source of a hack. Here is one recent claim of that:

i would strongly urge you to remove it now. My site was hacked several times before I realized it was because of this plug in. It sucks because I was unable to find a replacement and have to do it by hand.

The vulnerability that is known to exist in that plugin would allow someone logged in to WordPress with the Contributor or Author role to cause malicious JavaScript code to be included on frontend pages on the website. (Higher level-users already have the capability to do the equivalent of that.)

Unless you have an untrusted individual with access to WordPress with the Contributor or Author role, either intentionally or because someone with that level of access had their account breached, you don’t have to worry about that. So the chances of that being exploited are slim.

It’s possible that the quoted individual had that situation, but almost no websites will, so the chances of the plugin being the cause of hacks on websites is very small.

Trying to figure out how a hacked WordPress website was really hacked is a standard part of our hack cleanup process for WordPress websites. Our hack cleanups include a free lifetime subscription to our Plugin Vulnerabilities service, which includes providing fixes for unfixed plugin vulnerabilities.

The Difference Between a Backdoor and a Vulnerability on Your Repeatedly Hacked Website

If you have a reoccurring problem with a hack of your website, there are multiple causes that could underly it. Two of those, a backdoor and a vulnerability, are sometimes confused. Understanding the difference is important to dealing with the problem.

A backdoor is some method for the hacker to continuing access to the website, which they place on the website. That often is a file that the hacker can send commands to on the website and those commands will run. Those backdoor files can sometimes be rather complex, but other times are really simple.

A vulnerability is an existing security issue on the website that gives a hacker some access they shouldn’t have.

A key difference between these two issues is how you deal with them. If you were to restore the website back to its state before the hacking, a backdoor couldn’t exist on the website. A vulnerability will still exist if you do that.

Another key difference is who has access in each situation. With a backdoor, only one hacker would have access, unless some other hacker figures out about their backdoor. A vulnerability, by comparison, could be exploited by many hackers.

We recently had someone come to us that thought there was a backdoor on their website, but the change being made with what they thought was a backdoor allowed any hacker access. What they actually had was a vulnerability they hadn’t addressed.

If you need help with a hacked website, we can help you.

Your WordPress Website Might Be Hacked if It Is Loading Very Slowly or Not Loading at All

We were recently contacted by someone looking to move their website off of WordPress because of downtime the website was experiencing. WordPress websites shouldn’t have problems with downtime unless something is going wrong with the website or the web hosting it is on. The solution to that wouldn’t be to move off of WordPress, but to address the problem. So what was going on?

When we went to view the website, we found that either it was slowly loading or not loading at all. Pulling up a cached copy of the website’s homepage through the Bing search engine, we were redirected to a malicious website. Viewing the source code of the cached copy of the homepage, we found that it contained obfuscated malicious code (the same code existed on the live website). So the problem here was that the website had been hacked. The solution to that is to clean up the hack, not switch to other software that could also be hacked.

If you are having a problem with your website, get in touch with someone who can assess what is going wrong. We can help you with that. If you need a hacked WordPress website cleaned up, we can also help with that.

Sucuri and MalCare Don’t Address the Source of Hacked Websites, Leading to Results Like This

Earlier in the week, we were mentioning that many hack cleanup providers don’t do the essential work of trying to figure out how websites were hacked. If you hire one of them, you might get lucky, and that doesn’t matter because the hacker hit the website once and moved on, but with more persistent hackers, that isn’t going to work out. Here is a fresh example of that involving two of those providers, Sucuri and MalCare:

A WordPress site I work for hosted on WPEngine has suffered from a malware attack. The attack was noticed when a consent management pop up started appearing on the home page. WPEngine’s security team from Sucuri hasn’t been much help as they’ve scanned and “removed” the problem 5 times now. I’ve also used a premium service from MalCare which did basically what Sucuri did, scanned said “it’s fixed” and then it came back.

That person tried a lot of things to deal with this:

I have enabled a number of security features including disabling enumeration, 2FA, custom wp login url, automatic password lockout after 2 tries, changing file permissions on certain files, enabled automatic alerts on file changing or file addition, deleted non essential users, changed passwords to all current users multiple times…

What they really need is to bring someone in who will work through trying to figure out how the hacking is continuing, addressing that, and trying to figure out how it started.

If you are in need of someone who will actually do that work, we do that for WordPress websites and other types of website.

Can you determine how a website has been hacked?

Your website has been hacked. A fairly obvious question is how was it hacked. Can you determine that? The short answer is maybe.

Another short answer is that many people you might bring in to deal with that won’t try to do that. They should. So why don’t they? A lot of them are using automated tools to do cleanups and they don’t have the expertise to try to figure out how it was hacked. Doing a (possibly poor quality) automated hack cleanup is cheap, having employees who do the work to try to determine how it got hacked, isn’t so cheap. There are further reasons they don’t do this. Many security providers’ businesses are built around security remaining poor, so finding and fixing new vulnerabilities isn’t a great for them. There is also the issue that many providers are partnered with sources of insecurity. One provider, Sucuri, is owned by GoDaddy, who admitted, belatedly, that their own insecurity got lots of customers’ websites hacked. Unsurprisingly, Sucuri doesn’t really try to figure out how websites are hacked.

Your best chance of figuring out how a website is hacked is bringing in someone who has experience trying to determine that as soon as possible. The longer you wait, the more likely that evidence, particularly logging, will be gone. If you bring in someone after a cleanup has been done, that will further limit the evidence available.

We wouldn’t recommend trying to figure this out yourself. We often deal with people that have to varying degrees tried that. We often find that they are suggesting possible sources of the hack that are not really possible or would be highly unlikely.

Even if you bring in someone who has a lot of experience doing this, they may not be able to determine the source of the hack, not because of a fault on their part. The fault is that there isn’t the evidence needed to determine this. For example, if a web host is getting hacked, most of the evidence of that would only be available to the web host. So someone else would only have circumstantial evidence to work with.

Even if the source can’t be determined, it is important to try to determine the source of the hack. A large reason for that we have found is that it helps to make sure the hack is fully cleaned up. We are often brought in to re-clean websites where there wasn’t attempt to determine that and when we do that we find parts of the hacked that were missed before.

The Location of Malware on a Website Probably Won’t Show Source of the Hack

It isn’t uncommon to see people claiming that certain software is the cause of their website being hacked based solely on malicious code being found in a file from the software. In reality, the files being impacted by malware usually have no connection with the cause of the hack. Instead, once the hacker has the ability to modify existing files, they can usually change any files. Sometimes hackers will modify all the files of a certain type. Other times, they will modify random files. They may also add new files in random locations.

There is one major exception to this. If a hacker gains access to the website through a vulnerability that allows uploading files to a certain location, then finding malicious files there is a strong indication that was the cause.

While the location of malicious code likely doesn’t tell you how the website was hacked, log files can go a long way to telling you that. That depends on having logging for the method of access the hacker used and that logging being available for when the website was hacked. If a hacker got in through FTP access, but you don’t have a log of that, then you are out of luck. If the hacker originally gotten in months ago, but the hack was only spotted recently, there is a good chance that logging is no longer available.

Even if you have logging available that would show the source of the hack, you need to be able to pick that out of the logging data. That is where having someone that deals with doing that on a regular basis will produce better results than trying to review the logging yourself.

The Cause of a WordPress Website Having User Registration Suddenly Enabled and the Default Role Being Set to Administrator

Oftentimes, when it comes to how WordPress websites have been hacked, it is hard to say without doing a proper cleanup what was the original source of the hack. But in some cases it is easy to say what was likely the cause. Take this description of what happened with a recently hacked WordPress website:

Yesterday at 23:08 I received an email from my wordpress “Admin Email Changed”: “[…]The new admin email address is ad@example.com.[…]”

Right after that, a new user registered, cryptic username “wpnew_kmyjzvfyoflv” This username had admin role!

Today in the morning when I realized, I checked, in the settings was “Anyone can register” checked and standard userrole is Administrator.

What you have there is a hacker being able to change three WordPress settings. The admin email address for the website, whether anyone can register for an account, and the default user role for new accounts. How could they do that? Either they would need the ability to directly change the content of the database used for the website or they would need to be able to change arbitrary WordPress settings.

You can rule out the first as the likely cause, as a hacker could, among other things, create a new Administrator account without going through additional steps if they have direct access to the database.

That leaves the second option. The cause of that is almost certainly going to be what is usually referred to as an option update vulnerability. That is a type of vulnerability that hackers are guaranteed to try to exploit if they know about them.

In addition to cleaning up whatever the hacker does once they have changed the WordPress settings, you need to make sure the vulnerability has been fixed to address this. That might be as simple as updating a plugin, if it has had that type of vulnerability and it has been fixed. If you don’t know what the source is and you don’t have the capability to figure that out, then it is time to bring in someone who has the capability to both review the log files for the website and review the plugins being used on the website.