Website Hacked? What to Do in the First 24 Hours

Which Changes Suggest Your Website Has Been Compromised?

Unexpected redirects, unknown administrator accounts, and security warnings are strong reasons to investigate. A compromise can also remain hidden behind normal-looking pages. Check both what visitors see and what has changed on the server.

• Visible changes: defaced pages, unfamiliar pop-ups, or redirects that appear only on mobile devices or visits from search results.
• Search changes: spam pages indexed under your domain or browser and search-engine security warnings.
• Access changes: unknown administrators, new SSH keys, or successful logins from unexpected locations.
• Server changes: modified application files, unfamiliar scheduled tasks, or outgoing spam.
• Business signals: hosting suspension, unusual traffic, or customer reports about strange emails and payment pages.

A website malware scan can identify known malicious code. A clean result does not establish that the site is safe, because a hidden access mechanism, or backdoor, may escape detection.

If a customer reports "my website has been hacked" symptoms on your domain, record the exact URL and circumstances. A redirect that you cannot reproduce from your own browser still deserves investigation.

First Hour: Stop Exposure Without Destroying Evidence

The first hour of website security incident response should limit further damage while preserving the information needed for investigation. Isolate affected systems, restrict access, and save logs before cleanup changes them. Assign one coordinator to maintain the incident timeline and track decisions.

0-15 Minutes: Record and Contain

1. Record the discovery. Note who reported the issue, when it appeared, and which URLs were involved. Capture screenshots and use a consistent time zone.
2. Protect visitors. Serve a static maintenance page with HTTP status 503 from a trusted proxy or separate environment. Ensure infected pages cannot still be reached directly.
3. Contact the hosting provider. Ask for containment assistance, available logs, snapshots, and any evidence of the entry point.
4. Isolate the affected system. Block unnecessary network access while preserving a controlled investigation path. Avoid rebooting or reinstalling it before evidence is captured.

The FTC's technical response guidance recommends disconnecting affected equipment from the network without switching it off before forensic review. Powering down can erase evidence held in memory.

Containment arrangements depend on who controls the infrastructure. Our support and incident-response commitments explain the support framework, while project-specific responsibilities and targets belong in the agreed service scope.

15-60 Minutes: Restrict Access and Save Logs

Preserve evidence before deleting suspicious files. Keep original copies in separate, access-controlled storage, and perform analysis on working copies.

• Export web server, application, database, SSH/FTP, and hosting control panel logs.
• Preserve available CDN, firewall, and authentication logs before retention limits remove them.
• Capture a snapshot of the affected files and database. Label it as compromised evidence, not a recovery backup.
• Restrict the admin panel, suspend unknown accounts, and pause unnecessary contractor access.
• Tell support staff where to send customer reports and screenshots.

Document each change, including emergency access revocations. The time windows below are a working guide, not a guarantee that investigation or restoration will finish within one day.

1-4 Hours: Establish What the Attacker Could Access

Scope analysis determines which systems, accounts, and data the attacker reached. Review access history alongside file and configuration changes. Include neighboring sites and integrations, because the affected website may be only one part of the incident.

• Authentication: compare failed and successful logins, session creation, new users, and privilege changes.
• System activity: examine privileged command history, unfamiliar SSH keys, and scheduled tasks such as cron jobs.
• Application changes: inspect recently uploaded files, executable files in upload folders, and altered application code.
• Connected environments: check staging sites, shared databases, deployment systems, and other sites under the same hosting account.
• Attacker activity: look for spam publishing, phishing pages, data exports, or outbound attacks.

For example, an unfamiliar checkout script requires more than a file cleanup. Review when it appeared, which pages loaded it, and whether it sent information to an external host.

Build a timeline that distinguishes confirmed findings from hypotheses. Missing log entries do not prove that no access occurred, especially when logging was disabled or records may have been altered.

4-12 Hours: Close the Entry Point and Prepare a Clean Environment

Recovery preparation combines root cause analysis, a trusted rebuild, backup verification, and credential rotation. Removing visible malware alone leaves uncertainty about hidden access. We favor a clean environment because it gives the team a stronger basis for validating the restored site.

Finding the Root Cause

Investigate the mechanism that allowed access. Typical entry points include:

• Outdated CMS components, plugins, or server software.
• Weak passwords or stolen credentials.
• Vulnerable custom code or unsafe file uploads.
• Exposed administration tools with inadequate access controls.
• Compromised contractor or deployment accounts.

Compare your findings with the hosting provider's evidence. For PHP applications, our analysis of the October 2026 PHP security vulnerabilities provides context for checking runtime exposure. A published vulnerability is a lead to investigate, not proof of how this incident happened.

If the precise entry point remains uncertain, document that uncertainty and remove the suspected access paths through rebuilding and access changes. An unexplained compromise should not receive an automatic approval to relaunch.

Website Malware Removal or a Clean Rebuild?

Website malware removal can stop a known malicious behavior while leaving other changes behind. A clean rebuild replaces the compromised operating environment and application code with trusted versions. Restore reviewed content and business data separately.

Google's foundational hacked-site guidance describes reinstalling from trusted sources and checking backups before restoration. The article dates from 2008, so its recovery principles should be distinguished from its older tool names.

On managed or shared hosting, arrange a fresh environment with the provider rather than attempting an operating-system rebuild yourself. Webdelo DevOps and Infrastructure covers the infrastructure work that can support this recovery path.

How to Restore a Hacked Website From Backup

Choose the backup against the earliest credible evidence of compromise, not the day someone noticed the problem. The latest backup may already contain malicious code.

1. Restore the candidate backup into an isolated environment with outbound integrations disabled.
2. Compare application files against trusted releases or a reviewed source repository.
3. Inspect the database for unknown administrators, injected scripts, and altered settings.
4. Review uploaded files and scan for malicious content.
5. Apply security updates and close the identified entry point before testing.

A verified older backup may omit legitimate recent orders or submissions. Reconcile those records separately instead of importing the entire compromised database without review.

Rotate Secrets From a Trusted Environment

Stolen credentials remain usable after malware is removed. Revoke known compromised access during containment, then issue replacement credentials from a clean device into the trusted environment. Replacing secrets on a server still controlled by an attacker can expose them again.

• Replace administrator, hosting, email, and deployment credentials.
• Rotate database passwords, SSH keys, and API keys.
• Replace payment, CRM, and other integration tokens.
• Invalidate active sessions and review recovery methods.
• Enable multifactor authentication, or MFA, for administrative access.

Check staff email addresses against known breach records using a service such as Have I Been Pwned. Never submit current passwords or private keys to an unfamiliar checking service.

12-24 Hours: Test Business Functions and Decide Whether to Relaunch

Relaunch requires evidence that the entry point is closed, the deployment is clean, and business functions behave correctly. Credential rotation and active monitoring are also release conditions. If those checks fail, extend containment rather than treating hour 24 as a deadline.

Forms, CRM, and Payment Checks

• Submit test forms and verify their destinations, including hidden email recipients.
• Check CRM connections, email integrations, and webhooks for unexpected endpoints.
• Compare checkout scripts and payment settings with approved configurations.
• Run test orders through payment confirmation and the connected business systems.
• Verify that logs and alerts capture the test activity without exposing sensitive values.

A successful page load is not a sufficient acceptance test. Our Web Development work includes the application and integration logic that these recovery checks need to cover.

Search Warnings and Spam URLs

Check the Security Issues and Manual Actions reports in Google Search Console. Remove attacker-created content at its source, and make deleted spam URLs return an appropriate 404 or 410 response.

Use the Removals tool when temporary hiding from search is needed. It does not delete content from the server or resolve a security issue. Request the relevant review after remediation, and allow time for warning removal and search visibility to recover.

Assign Owners and Completion Criteria

The coordinator should collect technical sign-off before the business owner approves reopening. This table assigns suggested owners and observable completion criteria.

Investigate Whether Customer Data Was Accessed or Exposed

A technical exposure review examines whether the attacker could read, export, or intercept customer information. Review database activity and data flows alongside file changes. Record where missing evidence prevents a firm conclusion.

• Inspect available database logs for unusual bulk queries, exports, or unfamiliar accounts.
• Look for database dumps and customer files in publicly accessible directories.
• Review form handlers for changed recipients or additional external requests.
• Inspect checkout scripts for unauthorized collection of entered information.
• Check outbound connections and transfers to unknown destinations.

If customer information is publicly accessible, block access immediately and retain a restricted evidence copy. Request removal of search-engine copies and check for republication elsewhere. Do not delay containment to finish documenting every exposed record.

Review service-provider permissions and verify claimed fixes through tests or logs. Our guide to protecting customer data when working with IT contractors addresses access boundaries relevant to this review.

Incident snapshots can themselves contain sensitive information. Apply restricted access and controlled handling consistent with our data security practices.

Avoid Actions That Hide the Cause or Preserve Attacker Access

Recovery mistakes either destroy evidence or carry the compromise into the restored environment. A site that looks normal can still contain stolen-access paths. Use explicit checks rather than appearance as the measure of success.

• Deleting suspicious files immediately: preserve evidence before modifying them.
• Trusting one scanner or plugin: combine scanning with access, configuration, and code review.
• Restoring the latest backup automatically: verify its contents and timing first.
• Changing passwords on a compromised device: use a trusted workstation and clean destination environment.
• Forgetting integration accounts: include contractors, APIs, deployment tools, and active sessions.
• Stopping monitoring after relaunch: keep alerts focused on the original entry point and signs of renewed access.

Estimate Recovery Costs and Business Disruption Separately

Incident losses include technical recovery work and disruption to sales or operations. Separate confirmed expenses from estimates. This gives the business a useful basis for prioritizing recovery and prevention.

• Technical costs: investigation, rebuilding, data reconciliation, testing, hosting changes, and additional security tooling.
• Commercial impact: missed orders, lost leads, and advertising that continued sending visitors to an unavailable site.
• Operational impact: support workload, manual processing, and staff time diverted from normal work.
• Search impact: reduced organic traffic while warnings or attacker-created pages affect visibility.

Estimate missed sales using comparable trading periods and normal conversion patterns. Distinguish delayed orders from permanently lost orders to avoid double-counting.

For a cross-market launch, also check whether localized campaigns and regional forms remain paused or misrouted. These dependencies belong in digital support for entering new markets and should have named recovery owners.

Compare prevention costs with your incident's actual impact rather than an industry-wide claim. Understanding what website maintenance includes helps separate routine upkeep from emergency investigation and rebuilding.

Prevent Website Hacking by Removing What Enabled the Incident

Repeat compromise becomes possible when restoration preserves a vulnerable component, stolen credential, or hidden backdoor. Prevention starts with closing those paths. Updates, access controls, tested backups, and monitoring then keep the recovery from becoming a temporary fix.

Why Websites Get Hacked Again After Recovery

Restoring a backup and changing one administrator password leaves other access paths unresolved. A vulnerable plugin or stolen deployment key can still provide entry.

Our preferred recovery path addresses the cause before public release. It combines trusted application code with reviewed data, complete credential rotation, and restricted access. Monitoring then checks whether those controls hold.

Use a Website Security Audit to Test the Controls

A website security audit should verify that controls work, including backup restoration and alert delivery. Cloudflare's recovery guidance recommends updated software, protected admin access, backups, and managed web application firewall rules. A web application firewall, or WAF, filters suspicious web requests but does not replace application fixes.

Assign an owner to each control and retain the test results. A backup job marked successful has limited value until the team proves it can restore usable data.

How Webdelo Assesses an Incident and Plans Recovery

Webdelo provides a technical incident assessment and a plan for safe website recovery. We begin with containment and evidence, then define the work required for a controlled relaunch. Timing depends on the compromise, available records, and the condition of the backups.

Webdelo builds and supports complex digital products, with technical leadership that includes Webdelo CTO Andrew Popov. Recovery planning connects application behavior with infrastructure and operational responsibilities.

The assessment covers:

• Affected systems and gaps in the available evidence.
• The identified entry point and required corrective work.
• Backup verification and the proposed rebuild approach.
• Credential rotation and integration dependencies.
• Business tests and documented relaunch criteria.
• Monitoring and measures to reduce repeat compromise.

Request a technical incident assessment and a safe website recovery plan from Webdelo. Share the affected domain, observed symptoms, and available hosting details through the agreed support channel. Keep passwords and sensitive evidence out of the initial message.

Let Verified Readiness Determine the Relaunch

A safe recovery follows a deliberate order: contain exposure, preserve evidence, establish scope, close the entry point, and validate the rebuilt site. The first 24 hours organize that work, but they do not determine when the website is ready to reopen.

Before approving relaunch, require recorded checks and named owners for ongoing monitoring. Keep unresolved risks visible until they are addressed.