Your website is moving super slow, or maybe not loading at all. Your login information doesn’t work and you know you’ve put in the right credentials. Or perhaps chunks of content are altered or gone completely. It’s becoming increasingly obvious that your website’s been hacked.
GIF courtesy of https://tenor.com/search/its-happening-gifs.
Well, there’s only one thing to do. Freak the f**k out!
No, obviously I’m kidding. Though since I’ve inserted that GIF, I think this is a good time to mention that I came up with about 12 punny names for this article. They’re… okay. I’m thinking I’ll pepper the post with them, so, enjoy, I guess?
This is not a hypothetical or academic article. Last week, serendipitous given that we’re promoting this new service, one of our larger domain management clients was hacked. They were the victim of hacking previous to switching over to our service, and their site is highly trafficked, so it’s not a total surprise. It took us several hours to fix and button up the site. But many WordPress site owners face significantly more downtime and cost when their sites are hacked. With millions of attacks daily and 72 records stolen every second according to Breach Level Index, these events are constant and costly.
So I figured we would turn our recent hack into a learning experience. I don’t mean for this to be a comprehensive checklist of what to do if your site’s been hacked. Trying to fix a hack yourself can result in losing or corrupting files, breaking your site, or giving up even more data to the hackers. If you have no clue about servers or system backends, best to leave it to the pros (there are ample services online that restore hacked sites). And for those who are familiar with their cPanel, SQL databases, and PHP file systems there are several step-by-step guides to finding and deleting hacker code and restoring your site (here’s the official guide, and here and here are a couple simple guides we like).
Return of the hack / Once again. GIF courtesy of https://tenor.com/search/return-of-the-hack-once-again-gifs.
This is meant to be a quick and practical overview for people who find themselves in a situation like ours:
Your site is running on WordPress
You know how to edit the theme
You have access to cPanel, phpMyAdmin, and site files
Step 1: Relax
Even if you can’t log in or if your site isn’t showing up in the browser, very likely the site content is still intact. So, you know, breathe.
In our case not only did the site look very funky, but the login page didn’t even resemble the normal WordPress login. (Normally, I would accompany a post like this with screenshots and instructions, but clearly I don’t want to give any specific information away about our client, so I guess you’ll have to… read. I know, ugh.)
If the login page looks weird, don’t log in. Likely, and this was our case, you’re not actually looking at the login page. If you want to be sure, you can check out the page code–by viewing the source code or opening developer tools in your browser–and look at HTML in the
section. There, you’ll see all the URLs that the page is referencing, and one of the first ones should be the actual page your viewing (which isn’t always the same URL as in your browser window). If the URLs listed aren’t your website, likely you’re on a fake login page. The goal of the hacker here is to get you to enter your username and password, which is then stored by them.
In our case, both the actual site and the login page were rerouting to a fake page created by the hackers.
Step 2: Scan
A Hack of the Clones. (Insert eye roll here.) GIF courtesy of https://tenor.com/search/really%3f-gifs.
Clearly you can’t log into WordPress. So you’ll need to get into your cPanel to fix the hack. But first, not knowing where the hack originated, best practice is to scan your computer for malware, trojans, and other viruses. There are tons of reputable (and free) antivirus programs out there, so I won’t get into all your options now. But I will say that we use Avira and Malwarebytes on our office Macs.
Once you know your own computer is virus free, time to log into your cPanel.
Step 3: Check databases
Two things you may want to do here. If you have some familiarity with common WordPress files, you may go right into the most common files in which hackers bury code. These are your .htaccess, wp-config.php, index.html, and php.ini files. You’ll need to understand these files well enough to spot malicious code, but given how common it is for hacks to effect these files, it’s a great place to start your search for malicious code.
The second thing you’ll want to check, especially if you can’t log into your WordPress dashboard, is your database. For this, open phpMyAdmin in your cPanel. Next, you’ll click on the database (in the left-hand navigation menu) that corresponds to your general WordPress software. You’ll want to check two things here. First, click the submenu item that ends in “-options”. Here, you’ll see the official URL of the site, you’ll see what theme is running, as well as the latest WordPress version.
A Hack of All Trades. Double reference, yes! GIF courtesy of https://tenor.com/search/aziz-azari-gifs.
In the case of our client, the official URL had been changed. That’s why our page and our login was rerouting. We simply needed to change this option back to the client’s actual URL and, voila, we could suddenly access the correct login page. The problem is not always the official site URL. You’ll want to check all the options on this subpage to make sure they match the details of your actual WordPress site.
The second item you need to check is the submenu item ending in “-users”. Again, this was part of the issue we needed to solve. This subpage will show you all the registered users for the WordPress site. Naturally, the most recently created user on our client’s site was a hacker. We had to delete this user (right from phpMyAdmin) and while we were there we also changed the passwords for all the other users. Be careful when doing this, as different web hosting programs use different encryption, which is a necessary part of changing the password. Reference your web hosting codex for more info on this. Also be aware that this will require you to contact your users and make sure they know their new passwords.
Step 4: Clean up
So we fixed the immediate cause of the issue. We were now seeing the correct website and login page. And after scanning through the pages of the site, it didn’t look like there were any other page bugs. We had also deleted the hacker’s username. But clearly they got in somehow. The next step was buttoning up the site.
Scott Hack-ula, anyone? GIF courtesy of https://tenor.com/search/so-if-you-excuse-gifs.
It was our suspicion that the hacker had been able to access either the web hosting account, cPanel, or WordPress admin due to a simple and easy-to-generate username and password. We immediately changed all the passwords and admin names to be cryptic and complex. That included email addresses, hosting login, cPanel access, FTP, and all WordPress accounts. In addition, we reviewed the security procedures for emails, password and file sharing, and we sent notifications to all site stakeholders that they needed to use the cryptic passwords we had created for them. No more Password1! .
Secondly, we checked all major WordPress files for malicious code. Don’t know what malicious code looks like? Luckily there are security plugins that can do this for you. We were already using two security plugins on the WordPress software, not to mention built-in software on cPanel, so we ran thorough scans looking for any suspicious code.
When it comes to WordPress, we really like WordFence. Even the free, basic version of this plugin offers great protection and data about hacking attempts to your site. The scans cover all site files and are excellent. Once a scan runs, you can review all files that have suspicious code and decide to keep or delete the code in question. And it can all be done from the WordPress Dashboard.
Lastly, we made sure that regular backups were running. These included backups of the WordPress content and settings, as well as cPanel file backups. Once we were sure we had deleted all malicious code (we ended up finding six corrupted files) we created full backups that we are now storing off-server, to use in the event of a future attack.
So, there you go. Several hours worth of work, but we got the site up-and-running and we’re confident that we deleted all dangerous code. That said, the last–and ongoing–step is to stay vigilant. Knowing the history of hacking on this site, we’ll being twice-weekly reviews of all login attempts, as well as manual reviews of the WordFence scans, deleting any code that doesn’t look familiar.
And finally: Strawberry Hackery, featuring Jennifer Lawrence. GIF courtesy of https://tenor.com/search/jennifer-lawrence-gifs.
Scan your local environment
Check database info and commonly attacked files
Change login information, clean up malicious code, and make sure you’ve got adequate security running
If there’s one take-away from this post, it should be this: 90% of all WordPress hacks, maybe more, can be avoided by doing a few really simple things. First, use strong usernames and passwords, and change them regularly (in today’s world, this is a no-brainer). Second, back up your WordPress content and settings, and your cPanel files. Third, get some reputable security plugin and review the information it collects.
And if all of this seems like a nightmare scenario or impossibly confusing, call the experts! Our domain management service comes with included website security and backups. For larger systems, we offer a digital security service designed to find and address exposure issues. And we’re always happy to help find and fix one-off security problems.
Get entrepreneur challenges, design advice + valuable marketing info direct to your inbox.