A hacked website rarely announces itself with a defaced homepage. More often it shows up as a Google warning on your brand name, a hosting suspension email, customers reporting redirects to casino pages, or a sudden stream of spam in your sent mail folder. The first hour decides how much this costs you. Most of the damage in a security incident is not caused by the attacker; it is caused by the wrong response: restoring a backup over the evidence, changing one password while the backdoor stays in place, or leaving the site live while it serves malware to your own customers.

This guide is a working runbook for the first 60 minutes, written for business owners, marketing managers and the IT contact who gets the phone call. It is organised by time window, covers WordPress and custom Laravel applications, and separates what you can do yourself from what needs an engineer. It also covers what to log for your records, because under Egyptian data protection rules a breach involving personal data may carry reporting duties, and a clear timeline protects you.

Minutes 0 to 5: confirm it is real and stop the bleeding

Do not start by cleaning anything. Start by establishing what you are looking at, because several harmless problems look like hacks and several serious hacks look harmless.

Signs that point to a real compromise

Google Chrome or Search Console reports “Deceptive site ahead”, “This site may be hacked” or a Security Issues notice.
Visitors from search results are redirected to unrelated pages, but you, typing the address directly, see the normal site. This is a classic conditional redirect and it is designed to hide from the owner.
New administrator accounts you did not create, or plugin and theme files with modification dates you cannot explain.
Your search listing shows Japanese, pharmaceutical or gambling keywords under your page titles.
The hosting provider suspends the account for outgoing spam, malware or abnormal resource use.
Your domain email is rejected by recipients or lands in spam overnight.

Problems that are not hacks

An expired SSL certificate, a failed plugin update that throws a white screen, a DNS change that was never completed, and an exhausted PHP memory limit all produce alarming symptoms. Check the basics first: open the site in a private window, look at the browser error text, and ask the person who last touched the site what they changed. Five minutes of triage prevents a full emergency response to a broken update.

The first containment decision

If the site is serving malware, redirecting visitors or collecting card details, take it offline for the public immediately. This is not a failure; it is the correct move. A site that is down for two hours costs less than a site that infects customers for two days and then gets blacklisted for two weeks. The cleanest way is a maintenance page served by the web server or the CDN, not a plugin on the compromised application. If you use Cloudflare, enable “Under Attack” or add a firewall rule that blocks all traffic except your own IP address. If you cannot do that, ask your host to suspend public access while keeping SSH or file access for you.

If the business depends on the site for bookings or sales and a full shutdown is impossible, the compromise is probably limited to the front end. Even then, disable payment processing and form submissions until you know what is running.

Minutes 5 to 15: preserve evidence before you touch anything

This is the step most teams skip, and it is the reason they cannot answer the two questions management will ask afterwards: how did they get in, and what did they take.

Take a full snapshot

Ask your host for a snapshot of the account as it is now, or copy the web root and export the database yourself. Store the copy somewhere offline and read-only. Do not overwrite your existing backups with it, and do not restore anything yet. The compromised state is your evidence. If the attacker planted a backdoor, that file tells you the date and often the method.

Collect the logs while they still exist

Many hosts rotate access and error logs within days. Download them now. You want the web server access log, the error log, the PHP error log, and if available the SSH and FTP logs and the control panel login history. For a WordPress site, also export the list of users and their last login times. For a Laravel application, keep the storage/logs directory, the queue worker output and the database audit tables if you have them.

Write a timeline as you go

Open a shared document and log every action with a time stamp: who noticed, what they saw, what you changed. This is not bureaucracy. It becomes your incident report, your handover to the engineer, and your evidence if a customer, a payment partner or a regulator asks what happened.

Minutes 15 to 30: lock the doors

Now you cut the attacker’s access. The order matters, because changing credentials in the wrong order lets the attacker reset them back.

1. Secure the email account first

The administrator email address is the master key. Anyone who controls it can use “forgot password” on every other system. Change the email password, enable two-factor authentication, check for forwarding rules you did not create, and review the account’s recent sign-in activity. Do this before anything else, from a device you trust.

2. Rotate every credential the site has ever touched

Change them in this order and treat all of them as exposed:

Hosting control panel and domain registrar passwords, with two-factor authentication enabled on both.
SSH keys and SFTP or FTP accounts. Delete the ones nobody recognises, and stop using plain FTP altogether.
Database user password. Update it in wp-config.php or the Laravel .env file at the same time, otherwise the site loses its connection.
WordPress administrator, editor and shop manager passwords. Delete any account you do not recognise rather than just changing its password.
API keys: payment gateway, SMTP provider, Google Maps, reCAPTCHA, WhatsApp and CRM connections. Revoke and reissue them in each provider’s dashboard.

3. Invalidate every active session and rotate the secret keys

Stolen session cookies keep working after a password change unless you invalidate them. In WordPress, replace the authentication keys and salts in wp-config.php; this logs out every user, including the attacker. In Laravel, change the APP_KEY only if you understand what it encrypts (it invalidates encrypted cookies and any encrypted database fields), and clear the sessions table or session store.

4. Check the places attackers hide for re-entry

Resetting passwords is useless if a backdoor remains. Look for these specifically:

PHP files inside wp-content/uploads or the Laravel public/storage path. Uploads folders should hold media, never executable code.
Recently modified files in the web root. A simple sort by modification date on the file system often reveals the infection date in seconds.
Files with names that imitate core files, such as wp-config-sample.php copies, class-wp-cache.php in odd folders, or random character names.
A modified .htaccess file with redirect rules, or an auto_prepend_file directive in .user.ini or php.ini that loads malicious code on every request.
Scheduled tasks. In WordPress, list cron events; in Laravel and on the server, check the scheduler and crontab for entries you did not add.
Database rows. Malicious JavaScript is often injected into posts, widgets, the options table and theme settings. Search for strings such as eval(, base64_decode and unfamiliar script src domains.
Rogue administrator users, application passwords and API tokens.

Minutes 30 to 45: find the entry point and decide between cleaning and rebuilding

Cleaning without finding the entry point is the most common reason a site is reinfected within a week. The attacker came in somewhere. If that door is still open, the cleaning is temporary.

The five usual causes

For typical business sites, the cause is almost always one of the following, in rough order of how often it occurs:

An outdated or abandoned plugin or theme with a known vulnerability. Automated scanners probe the internet for specific vulnerable versions within hours of a public disclosure. Premium plugins installed from unofficial sources are a particular risk, because they often ship with a backdoor.
Stolen or reused credentials. A password leaked from another service, a staff member’s infected laptop, or a shared login that a former contractor still has.
Weak hosting isolation. On cheap shared hosting, one compromised site on the same account can infect all the others sharing it. If you run several sites in one hosting account, treat all of them as compromised.
Exposed admin and development files. A publicly reachable .env file, a forgotten phpinfo page, a database dump left in the web root, or an open phpMyAdmin.
Insecure custom code. Unvalidated file uploads, SQL injection in a search or booking form, or an API endpoint without authorisation checks. This is more common in rushed custom builds than in well-maintained WordPress cores.

How to read the evidence

Take the modification date of the oldest suspicious file and search the access log around that time. Look for POST requests to unusual URLs, requests to files inside the uploads directory that end in .php, and repeated hits to xmlrpc.php or wp-login.php from one address. The first malicious request usually shows up as an odd URL right before the new file appears. That URL names the vulnerable component.

Clean or rebuild?

There are two valid paths, and the choice depends on how much you can trust the code.

Clean in place is acceptable when the infection is small and well understood: one or two injected files, a single compromised plugin, a clear entry point, and logs that confirm nothing else was touched. Reinstall WordPress core files from a fresh download, delete and reinstall every plugin and theme from the official source, and compare the result against the clean originals file by file.

Rebuild on a clean server is the safer choice when the attacker had administrator or shell access, when the entry point is unknown, or when the server itself is suspect. You provision a new account, install a fresh WordPress or deploy the Laravel application from your version control repository, import only the database content and the uploads media after scanning them, and switch the domain over. It takes longer, but you end up with a system you can vouch for. For a revenue-generating site, this is usually the correct call.

Never restore a backup without knowing its date relative to the infection. A backup from three days ago may already contain the backdoor. Restore the backup that predates the earliest suspicious file, then patch the entry point before going live, otherwise the same attack succeeds again within hours.

Minutes 45 to 60: verify, harden and bring the site back

Verification before relaunch

Before removing the maintenance page, confirm that the cleanup held. Run a malware scan with at least two different tools, because every scanner misses something. Compare core file checksums against the official ones: WordPress provides this in WP-CLI with the core and plugin verify-checksums commands. Check the database for injected scripts. Browse the site in a private window from a mobile network, not from your office, to catch conditional redirects. Check the page source of the homepage, a product page and a contact page for unfamiliar external scripts.

Hardening that closes the same door

Update WordPress core, every plugin and every theme, and remove anything inactive. A deactivated plugin with a vulnerability can still be exploited if its files are on disk.
Disable file editing from the dashboard with a constant in wp-config.php, and block PHP execution inside the uploads folder at the web server level.
Enforce two-factor authentication for every administrator, and limit administrator accounts to the people who need them.
Put a web application firewall in front of the site, either at the CDN or on the server, with rate limiting on login and XML-RPC endpoints.
Set correct file permissions: typically 644 for files and 755 for directories, with configuration files locked down further and owned by the right user.
Move to SFTP or SSH keys only, and disable FTP.
For Laravel, set APP_DEBUG to false in production, confirm the .env file is outside the public directory, and keep dependencies current with regular composer audit runs.

Clearing the search and browser warnings

If Google flagged the site, a clean site does not remove the warning on its own. Open Search Console, go to Security Issues, and submit a review request once you have removed the injected content. Describe what you found and what you fixed. Google normally responds within days, and a vague request is more likely to be rejected. Also check that injected spam pages are removed so they return a 404 or 410 status, not a 200, and that your sitemap lists only legitimate URLs. Submit the clean site to any other blacklists that flagged it, such as Norton Safe Web or your email provider’s reputation lists.

The business side: who needs to be told

A technical recovery without a communication plan leaves the incident half handled.

Customers and partners

If personal data may have been exposed, such as names, phone numbers, emails, booking details or order history, tell the affected people plainly and early. Say what happened, what data was involved, what you did, and what they should do, for example change reused passwords or watch for suspicious messages. Do not guess about scope. If the logs cannot prove that data was not accessed, say so honestly.

If card payments run through your site, contact your payment gateway. Gateways have their own incident procedures, and a hosted payment page that redirects to the gateway reduces your exposure greatly. If your checkout collects card numbers on your own pages, a compromise there is a far more serious event and needs immediate specialist involvement.

Egyptian data protection law

Law No. 151 of 2020 on personal data protection places obligations on organisations that control or process personal data, including security measures and breach handling. The practical position is that an incident involving personal data should be documented thoroughly, assessed with legal advice, and reported where the law and the regulator’s executive rules require it. Your timeline from the first hour is the foundation of that assessment. We cover what a business website must do under the law in a separate checklist on this blog.

Your own team

Agree on one spokesperson and one channel. Rumours inside a company spread faster than the malware, and staff who do not know what happened tend to reset the wrong passwords or restore the wrong backup.

What a hacked site really costs, and why prevention is cheaper

The direct cost of cleanup is rarely the largest line. The larger costs are lost bookings and enquiries during downtime, lost search visibility if the site was blacklisted or filled with spam pages, the cost of notifying customers, and lost trust, which is hard to price and slow to rebuild. For hotels, real estate developers and corporate service firms, where one enquiry may be worth thousands of dollars, a week of lost enquiries outweighs a year of proper maintenance.

The unglamorous controls are the ones that prevent most incidents: automatic security updates for core and plugins, tested off-site backups kept on a separate system, uptime and file-change monitoring that alerts a human within minutes, and a least-privilege approach to accounts. We lay out what a maintenance retainer should include, and what it should cost in the Egyptian market, in our guide to website maintenance cost in Egypt.

A one-page incident checklist to keep

Print this and keep it where your team can find it. It is deliberately short.

Minutes 0 to 5: confirm the symptoms, take public traffic offline if the site serves malware or redirects.
Minutes 5 to 15: snapshot files and database, download all logs, start a timestamped timeline.
Minutes 15 to 30: secure the admin email, rotate hosting, database, SSH, CMS and API credentials, reset secret keys, remove unknown users, hunt backdoors.
Minutes 30 to 45: identify the entry point from logs, choose between cleaning in place and rebuilding on a clean server.
Minutes 45 to 60: scan with two tools, verify checksums, harden, relaunch, request a Google review if flagged.
Same day: notify affected customers and partners, record the incident, schedule a follow-up check for day 7 and day 30.

Why reinfection happens on day seven

The most dangerous moment in an incident is the week after it. Attackers who found one door often leave a second one for later, and automated bots keep retrying the same vulnerable URL. Monitor the access logs daily for the first week, keep file-change alerts on, and re-run the scan on day 7 and day 30. If the same malicious request pattern appears again, the entry point was not closed.

If you do not have an engineer who can read server logs and trace an entry point, the best time to arrange one is before the incident. Kemetova builds and maintains custom WordPress and Laravel systems from Hurghada for hotels, developers and corporate clients across Egypt, with security updates, monitoring and tested restore procedures built into the engagement. A site restored from a verified backup, with an alert that fired in the first minute, turns a crisis into a ticket.

Your Website Was Hacked: What to Do in the First 60 Minutes