Website Hacked? What to Do in the First 24 Hours

If your website has been hacked, what to do first is not to start deleting files. Lock the attacker out, take a copy of the site as it is, then clean it, fix how they got in, and only after that ask Google to clear any warnings. If customer data may have been exposed, you may also have reporting duties under Kenya's Data Protection Act.

The order matters. Owners who panic and restore a backup straight away often find the same spam pages back by Friday, because the door the attacker used is still open. Work through the steps below in sequence. Keep a notepad open and write down the time and what you did at each stage; you will need it later.

Signs your site is hacked

Hacks on small business sites are usually about using your site's reputation, not about you personally. That shapes what you see:

• Redirects. Visitors land on betting, loan app, pharmacy or adult sites. Often this only happens when they arrive from Google, or only on mobile, so the owner typing the address directly sees nothing wrong.
• The Japanese keyword hack. Search site:yourdomain.co.ke on Google. Thousands of pages in Japanese or another language selling fake goods mean someone has injected spam pages.
• Google or browser warnings. "This site may be hacked" in search results, or a red Chrome warning page.
• Host action. Your hosting company suspends the account or emails about malware or outgoing spam.
• Admin changes. New administrator users, changed passwords, unfamiliar plugins.
• Payment oddities. On an online store, checkout pages that look different or send customers to an unfamiliar payment page.

Any one of these is enough to start the process below.

Hour 0–2: contain and take a snapshot

1. Lock the doors

Change passwords in this order, from a device you trust (not the office PC if you suspect it is infected):

1. Domain registrar account
2. Hosting control panel and any FTP or SSH accounts
3. Website admin accounts, every one of them
4. The email account linked to all of the above
5. Database password, which will need updating in the site's configuration file

Turn on two-factor authentication wherever it is offered. Delete any admin user you do not recognise, but note its username and creation date first. If the site takes M-Pesa or card payments, regenerate the API keys in the Daraja portal or your gateway dashboard and tell your developer, because a compromised server may have exposed them.

2. Decide whether to take the site offline

If the site is redirecting customers to harmful pages or a checkout may be capturing payment details, put it into maintenance mode or ask your host to suspend public access. A day of downtime is better than customers losing money or Google flagging you for weeks. A defaced home page with no data at risk can usually stay up while you work.

3. Take a snapshot before cleaning

Download a full copy of the infected files and database and label it clearly as infected. This feels counter-intuitive, but you need it to work out how the attacker got in, to see whether customer data was accessed, and as evidence if you have to report the incident. Ask your host for the server access logs for the last 30 days as well; some hosts only keep them briefly.

Hour 2–12: find and remove the infection

There are two broad routes. Choose based on what you have.

Cleaning a WordPress site without a backup

• Note the exact versions of WordPress, the theme and every plugin.
• Replace the WordPress core folders with a fresh download from wordpress.org. Never reuse the old ones.
• Reinstall each plugin and theme from its official source. Any plugin or theme that came from a "free premium" download site goes in the bin; these nulled copies often contain the backdoor that started the trouble.
• Search the uploads folder for PHP files. Images folders should not contain PHP.
• Inspect the configuration file and .htaccess for unfamiliar code, especially redirect rules.
• Check the database for injected scripts in posts, widgets and options, and for spam pages and admin users.
• Run a malware scanner after cleaning, and again the next day.

Be honest about your limits. If you find yourself staring at long lines of scrambled code, that is the point to bring in someone who does this regularly. Half-cleaned sites are reinfected quickly.

Hour 12–24: clean up Google warnings and spam pages

Once the site is genuinely clean, deal with what Google has seen. You will need Google Search Console access; if you never set it up, our Search Console setup guide walks through verification.

1. Open the Security Issues report. It lists what Google detected, sometimes with example URLs.
2. Make spam URLs return an error. Injected pages should now return 404 or 410, not redirect to your home page.
3. Remove the worst of them. Use the Removals tool to temporarily hide spam URLs or whole spam folders from results.
4. Check for a rogue sitemap. Attackers sometimes submit their own sitemap. Delete any you do not recognise and resubmit yours.
5. Request a review. In the Security Issues report, explain briefly what you cleaned and how you fixed the entry point. Google's help pages on security issues describe the process.
6. Check owners and users. In Search Console settings, remove any owner you did not add. Attackers add themselves to resubmit spam.

Expect spam pages to linger in results for a while even after the warning lifts. Rankings usually recover once the clean-up holds.

Harden so it doesn't recur

Work out how they got in. The snapshot and logs from step 3 are where the answer is. The usual culprits on small business sites are:

• An outdated plugin or theme with a published vulnerability
• A nulled (pirated) theme or plugin with a built-in backdoor
• A weak or reused admin password, often shared by several staff
• An old forgotten copy of the site in a subfolder, such as /old or /test, still running ancient software
• Another infected site on the same hosting account

Then close the gaps:

• Update everything and remove what you do not use. Our guide to updating WordPress plugins safely covers doing this without breaking the site.
• One named admin account per person, with two-factor authentication.
• Delete old copies, test folders and staging sites you are not using.
• Set file permissions correctly and disable file editing from the WordPress dashboard.
• Set up offsite backups and uptime and malware monitoring.

The longer-term fix is a routine. Our website maintenance checklist lays out weekly, monthly and quarterly tasks that make a repeat much less likely.

Do you need to notify anyone?

This is where a website problem can become a legal one. Ask three questions:

1. Did the site hold personal data? Contact forms, customer accounts, order history, booking details, job applications.
2. Could the attacker have accessed it? If they had admin or database access, assume yes unless the logs show otherwise.
3. Is there a real risk of harm to those people? Exposed phone numbers and order histories can be used for targeted M-Pesa fraud calls, for example.

If the answers point to a personal data breach, Kenya's Data Protection Act requires the data controller to notify the Office of the Data Protection Commissioner within a short deadline, and in some cases to tell the affected people. The ODPC publishes its current breach-notification process at odpc.go.ke. Because the deadline runs from when you become aware, do not wait until the clean-up is finished to start this conversation. Our article on Data Protection Act compliance for websites explains the wider duties, and if you are unsure whether to report, speak to a lawyer the same day.

Others you may need to inform:

• Your payment provider or bank, if checkout pages or API keys were affected
• Your hosting company, especially if the site was sending spam
• Your customers, honestly and briefly, if they might receive fraudulent messages using their data
• The police or the national computer incident response team, for serious or criminal incidents

Mistakes that make a hack worse

A few reactions feel sensible in the moment and cost you days afterwards:

• Deleting the whole hosting account. You lose the evidence and any chance of finding out what data was touched.
• Installing three security plugins at once. They clash, slow the site and still will not remove a backdoor hidden in a theme file.
• Telling staff to keep sharing one admin login. If you cannot tell who did what, you cannot rule out an inside cause or a stolen password.
• Announcing "all fixed" on social media before checking from a phone on mobile data. Mobile-only redirects are common, and customers will notice before you do.
• Restoring the same backup twice. If it reinfects, the backup is not clean or the hole is still open. Stop and investigate.

Need a hand right now?

If your site is down or redirecting customers as you read this, contain it using the first section and then contact us with your domain name and what you are seeing. Our support team handles clean-ups, works out how the attacker got in, and sets up the backups and monitoring so you are not reading this article again in three months.