What to do if your website is hacked

A hacked website is serious and recoverable. Act in order: isolate the site so visitors are not hurt, tell us, change every password from a computer you trust, restore a clean copy, then close the hole that let someone in.

On Beginner and Standard shared hosting (cPanel) in Australia we already keep Acronis hourly backups. Those copies live on a separate server and do not use your disk quota. Restore points sit in a 30-day window. Open cPanel from the portal. Do not guess a hostname.

On a VPS you manage files, snapshots, and the firewall yourself. Credentials and the console are on that server in the portal.

On a dedicated server, open a support ticket and we will walk you through access.

If the site is only down and you are not sure it was changed by someone else, start with My website is down - what to check first. If you typed a password on a fake page, also read Recognise and avoid phishing emails.

Do not wait on an email thread. Open a support ticket as soon as you confirm the site is compromised. Tell us the domain, what you see, and when you first noticed it.

Open cPanel

1. Sign in at the portal.
2. Open the hosting service for the site.
3. Click Log in to cPanel.

You do not need a server hostname to get in.

Immediate actions

1. Tell us, then take the site off the public internet

Open a support ticket. We can help isolate the account, check logs, and prepare a restore. Do not keep editing plugins or uploading "cleanup" scripts while the site is still live.

To stop visitors hitting the infected files yourself:

1. In cPanel, open Directory Privacy.
2. Open the site's document root (public_html for the main domain, or the addon / subdomain folder).
3. Turn protection on and set a username and password you have not used anywhere else.
4. Visit the site in a private window. You should get a login prompt, not the hacked page.

That is enough for the first hour. A simple static "we will be back" file is optional. Do not install a new security plugin on a site you already know is compromised.

On a VPS, stop the site at the web server or close 80 and 443 on the host firewall until you have a clean copy. See Set up a UFW firewall on Ubuntu.

2. Change every password, from a computer you trust

Use a device that did not have the infected site open, and a password manager. These are different secrets. Change each one you use for this site:

• Portal. Account → password. Then confirm two-factor authentication is on.
• FTP. In cPanel FTP Accounts, set a new password on every account that can reach this site, or delete ones you do not need. See Create an FTP Account and Connect.
• MariaDB. In MySQL Databases, set a new password on the database user. Then put the same password in the app config (wp-config.php for WordPress). Changing only one of those takes the site down. See Create a MySQL Database and User.
• CMS admin. WordPress, or whatever you run: every administrator login. Do not keep a user called admin.
• Mailboxes on this hosting, especially any address that receives resets. In cPanel Email Accounts, set a new mailbox password. See Create an Email Account.
• LochStudios Mail (Axigen) if this domain uses that product instead: Change your Axigen mailbox password.
• VPS SSH. Prefer new SSH keys and turn off password login.

We will never ask you to send a password by email or in a ticket.

3. Write down what you see

Before a restore overwrites the live files, capture:

• Screenshots of the defaced page, a browser warning, or unexpected redirects
• The date and time you first noticed it
• Extra users, odd files, or database rows you can already see

Paste that into the ticket. It helps us pick a restore point and find the door they used.

Assess the damage

Use the File Manager. Under Settings, turn on Show Hidden Files (dotfiles) so you can see .htaccess and other files that begin with a dot.

Check:

• Files. New .php files you did not add, especially in wp-content/uploads or the document root. Random names, copies of index.php, or a .htaccess that redirects visitors elsewhere.
• WordPress users. In wp-admin, Users: no extra administrators. If you cannot reach wp-admin, we can look after a restore.
• Database. In phpMyAdmin, look for users or content you did not create. Spam links in posts and options are common.
• FTP and cron. Extra FTP accounts. Unexpected lines in Cron Jobs.
• Mail and metrics. A sudden spike in resource usage, or mail going out that you did not send.

Visitor data. If the site stored emails, addresses, or card details, treat that as a possible data breach. See Notify affected people below. Do not try to decide that alone if you are unsure: put it in the ticket.

Ask yourself when the last clean copy is. On shared hosting, that is usually an hourly point from before the first odd file or extra user. If you are not sure when it started, we would rather go further back than restore an already infected hour.

Restore from a clean copy

Do not restore and then leave the same weak password, leftover FTP account, or outdated plugin. They will walk back in.

On shared hosting, ask us first. Every Beginner and Standard plan includes Acronis hourly copies. You do not download those files yourself.

1. Open a support ticket if you have not already.
2. Tell us the domain, what to restore (whole account, one site folder, one database), and the date and time you want to go back to.
3. Stop editing the live site so we do not overwrite new work, and so a restore does not land on files you just changed.
4. After we confirm the restore, keep Directory Privacy on until you have checked the site.

Restore points are merged across a 30-day window (hourly for the last 12 hours, then daily and weekly). Do not wait until the only good copy is older than that.

Full backup options, including a copy you made in Backup / Backup Wizard: Download and Restore a Backup. For WordPress, a Toolkit or Installatron backup is fine if you took one before the compromise. See Back Up and Migrate a WordPress Site.

Do not restore a full cPanel .tar.gz yourself. Ask us.

On a VPS, restore from a snapshot or copy you kept off that server. We do not run Acronis on the VPS for you. Open a support ticket if you want us to walk through it.

After the restore, before you take Directory Privacy off:

• Load the site and a few inner pages in a private window (you will need the Directory Privacy login).
• Confirm content, products, and customer records look like the clean date.
• In File Manager, look again for leftover .php in uploads and for a .htaccess you did not write.
• For WordPress, check Users and apply Toolkit Security and Updates. See Secure Your WordPress Site.
• Confirm AutoSSL is still valid in SSL/TLS Status. If the padlock is gone, see Understanding SSL/TLS and HTTPS.

Then turn Directory Privacy off. You do not need to change DNS for a normal restore. Leave AtlasDNS as it is.

If the site is a white screen or HTTP 500 after the restore, see Fix the WordPress White Screen of Death / HTTP 500 or Fix a 500 Internal Server Error, and tell us in the ticket.

Close the door

A restore without this step is a pause, not a fix.

Then follow Keep your website secure: updates, the hourly copies we already keep, and logins that only have the access they need.

Harden the account

• Apply WordPress Toolkit Security measures. Do not install two security plugins that both scan files.
• Disable the WordPress theme and plugin file editors (DISALLOW_FILE_EDIT). Toolkit can do that for you.
• Leave Remote MySQL empty unless something outside this account must connect. See Allow Remote MySQL Access.
• Delete leftover backup zips from public_html. They count toward disk and are easy to fetch if the site is hit again.

On a VPS

• Patch the OS. See First steps on a new VPS and Enable Automatic Security Updates.
• Restrict SSH to keys.
• Keep TLS current with Certbot.

Notify affected people (if you hold their data)

If the site collected emails, phone numbers, addresses, or card details, and someone else may have read that data:

• Tell those people as soon as you reasonably can
• Say what kind of data was involved and what you have done (restore, new passwords, the door closed)
• Suggest they change reused passwords and watch card statements
• Keep notes for your own records

Rules differ by country and by what you stored. We can help you understand what was on the hosting account. We cannot give legal advice. If cards were processed on a third-party checkout, talk to that processor as well.

After you are live again

• Watch the site for a week: homepage, wp-admin Users, File Manager, and resource usage.
• Keep the ticket open if anything odd comes back. We can look at logs with you.
• Turn on automatic updates for WordPress (at least minor and security releases) in Toolkit.
• Keep taking your own copy before a redesign or a plugin experiment. Hourly copies are not a file you download yourself.

If you keep getting reinfected after a clean restore, stop publishing the site again and open a support ticket. The original hole is still open, or a backdoor is still on the account.

When to ask us

Open a support ticket if any of these are true. Most of them already are, the moment you know the site was changed.

• You cannot tell when it started, or which files are theirs
• You suspect the custom code, not only a plugin
• You have restored (or we have) and it comes back
• You hold customer data and need help seeing what was on the account
• This is a VPS or dedicated server and you want us on the session with you

We will restore from an hourly copy on shared hosting and help you close the door. You do not need a third-party "cleanup" product as the first step.

Need hosting first? Browse shared hosting, VPS, or dedicated. After the account is ready: Getting started after you order hosting.

Related

• Keep your website secure
• Create strong passwords and use a password manager
• Recognise and avoid phishing emails
• Understanding SSL/TLS and HTTPS
• Secure Your WordPress Site
• Install WordPress
• Back Up and Migrate a WordPress Site
• Download and Restore a Backup
• Use the File Manager
• Create an FTP Account and Connect
• Manage a Database with phpMyAdmin
• Create a MySQL Database and User
• Create an Email Account
• Set up a cron job
• Choose your PHP version
• Read your resource usage and metrics
• Allow Remote MySQL Access
• Change your Axigen mailbox password
• My website is down - what to check first
• Fix a 500 Internal Server Error
• Fix the WordPress White Screen of Death / HTTP 500
• Set up a UFW firewall on Ubuntu
• Secure SSH with key-based authentication
• First steps on a new VPS
• Enable Automatic Security Updates
• Get a Free SSL Certificate with Certbot
• Getting started after you order hosting