Is Your Website Hacked? Steps to Prevent Further Damage

When a website suddenly displays foreign pages, sends spam, or creates new administrator accounts, the first reaction is usually panic. Site owners want to quickly delete suspicious files, reinstall WordPress, or change all passwords at once.

The problem is that hasty actions can erase important traces. You may successfully remove symptoms, but you won't know the attacker's entry point or if there is still hidden access. A good incident response is not just about making the website look normal again, but also about limiting damage, finding the source of the problem, and then restoring the system on a more secure foundation.

1. Ensure This is Truly a Security Incident

Not all errors are signs that a website has been hacked. A broken theme, failed plugin updates, cache configuration, or DNS changes can also make pages look strange.

However, treat the situation as a security incident if you find signs such as:

• There are administrator accounts, PHP files, or plugins that you never created.
• Visitors are redirected to gambling, phishing, or suspicious download pages.
• The website is sending large amounts of email without clear activity.
• Admin passwords suddenly cannot be used.
• Core files change without a scheduled update.
• Hosting or search engines issue malware warnings.

Save screenshots, timestamps, affected URLs, and error messages. This simple record helps compare the website's condition before and after recovery.

2. Limit Access Without Immediately Deleting Evidence

If the website is still actively used, the first step is to reduce the likelihood of further damage. Contact your hosting provider and ask for assistance in putting the site in maintenance mode or temporarily restricting access.

For websites with sensitive data, you can also temporarily disable login features, forms, or transactions. Do not immediately delete the entire website folder. Suspicious files, server logs, file change times, and lists of running processes can help identify attack patterns.

If you can still access the dashboard, do not just change the password for one account. Check the user list, roles of each account, recovery emails, application tokens, and active login sessions. Delete unknown accounts after recording their basic information.

3. Cut Off Access That May Have Leaked

After initial evidence is collected, change credentials from a device that is confirmed clean. Do not change passwords through a computer suspected of being infected with malware or keyloggers.

Prioritize the following access:

1. Website administrator accounts.
2. Hosting accounts and server panels.
3. FTP, SFTP, or SSH accounts.
4. Database passwords.
5. Email accounts used for recovery.
6. API keys, application passwords, and integration tokens.

Use unique passwords and enable two-factor authentication for administrator accounts. WordPress also recommends regular updates, access restrictions, and recovery planning as part of ongoing security, not a one-time action.

4. Look for the Most Likely Entry Points

The goal of the inspection is not to find out who the attacker is, but to identify vulnerabilities that need to be closed before the website is restored.

Check for several common possibilities:

• Outdated plugins, themes, WordPress core, PHP, or server components.
• Reused administrator passwords on other services.
• Hosting or FTP accounts that are no longer used but still active.
• Upload files that accept dangerous extensions or do not restrict file types.
• API endpoints or forms that do not validate input.
• Database queries that construct SQL directly from user input.

In custom applications, use prepared statements for database queries and perform allow-list based input validation if possible. For output to web pages, user data must be escaped according to its context. OWASP emphasizes that preventing XSS is not just about installing a WAF, but also ensuring that untrusted data is processed and displayed securely.

5. Check Logs and File Changes

Logs can help answer three important questions: when suspicious activity started, which endpoints were called, and which accounts were used.

If available, check access logs, error logs, authentication logs, dashboard activity, file changes, and notifications from firewalls or CDNs. Look for patterns such as many login attempts, requests to unusual files, repeated uploads, or access from unreasonable locations and times.

Compare website files with a clean copy from official sources. Do not assume every foreign file is automatically dangerous, as some plugins do create additional files. Conversely, do not assume that files with normal-looking names are necessarily safe.

6. Restore from Trusted Sources

If a backup is available before the compromise time, use that backup as a recovery point. Ensure the backup is not connected to the infected system and check its date carefully. Backups made after the attacker entered may already contain harmful files or accounts.

For WordPress, the recovery process ideally includes the WordPress core, themes, plugins, database, and server configuration. Reinstall components from official sources, then install only the plugins and themes that are truly necessary. Nulled plugins or themes should not be used because their origin and code integrity cannot be trusted.

After recovery, change all important credentials back. Do not use old passwords even if they do not appear to have been misused.

7. Harden the System After the Website is Back Online

A website that appears normal is not necessarily safe. Conduct further checks before opening all features to the public.

• Update WordPress, plugins, themes, PHP, and server components.
• Remove unused plugins, themes, accounts, and services.
• Disable the default file editor in WordPress with define( 'DISALLOW_FILE_EDIT', true ); if not needed.
• Limit database access rights according to application needs. Application accounts should not have database administrator rights.
• Ensure the website and administration area use HTTPS.
• Enable file change monitoring and login notifications.
• Keep regular backups in a separate location and periodically test the restore process.

For PHP applications using sessions, also check cookie settings such as HttpOnly, Secure, and SameSite. These settings help reduce the risk of session theft or misuse, but do not replace proper access validation and session management.

What Does This Mean for Us?

Incident response is not exclusive to large companies. Personal blogs, small online stores, and organizational websites also need to have a clear action sequence. At a minimum, you should know who can access hosting, where backups are stored, how to disable the website, and when to seek professional help.

A simple checklist kept before problems occur is often more useful than dozens of security plugins. Security does not mean guaranteeing that a website will never be attacked. The goal is to minimize the chances of an attack, limit its impact, and ensure the website can be restored without guessing from scratch.

What You Can Do Now

1. Record all accounts that have administrator, hosting, database, and recovery email access.
2. Ensure the last backup can be opened and is truly recoverable.
3. Enable two-factor authentication for important accounts.
4. Remove unused plugins, themes, accounts, and integration tokens.
5. Create a brief document containing hosting contacts and steps to disable the website in an emergency.

Sources & Further Reading

• OWASP Cross Site Scripting Prevention Cheat Sheet
• OWASP SQL Injection Prevention Cheat Sheet
• WordPress Hardening Guide
• WordPress Brute Force Protection Guide
• PHP Session Security Settings

– Rio Yotto @rioyotto