Your Website Has Been Hacked: The First 24 Hours and Who Needs to Do What

The first sign may be a customer reporting a redirect, a search result promoting products you do not sell, an unfamiliar administrator account, a payment-page warning or a hosting provider suspending the site. Whatever the signal, treat a suspected website compromise as a business incident—not merely a broken page.

The first 24 hours shape the cost and credibility of the response. Moving too slowly can leave customers and connected systems exposed. Moving too quickly can delete logs, overwrite timestamps, alert an intruder or restore the same vulnerability into production.

The Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC) says organisations should report cyber security incidents internally and to ASD as soon as possible, while considering legislative and regulatory obligations. The Office of the Australian Information Commissioner (OAIC) frames a data-breach response around four actions: contain, assess, notify and review.

This runbook translates those principles into website decisions. It is not a substitute for forensic, legal, privacy, insurer or law-enforcement advice. The right sequence will depend on the attack, the website architecture and the information involved.

Before touching the site, appoint one incident lead

An incident becomes harder when the developer changes files, the host restores a backup, marketing posts an update and an executive contacts customers independently. One accountable incident commander should coordinate decisions, maintain the timeline and approve changes.

Open an incident record using a communication channel that is not dependent on the possibly compromised website or its email account. Record:

when and how the issue was detected
the exact symptoms, URLs, screenshots and alerts
people and suppliers notified, with times
actions taken, by whom and why
systems, credentials and data believed to be affected
evidence locations and chain of custody
customer, revenue and operational effects
decisions still awaiting technical or legal advice.

Do not use the compromised WordPress administrator account to coordinate the response. If an attacker controls website or email access, they may see password resets or internal messages.

The response team and its responsibilities

Small organisations may have one person filling several roles, but the responsibilities still need names.

Role	First-day responsibility	Decision boundary
Incident commander	Own priorities, timeline, approvals and handovers	Balances containment, evidence, service and communications
Technical or forensic lead	Preserve evidence, determine entry point and scope, direct eradication	Advises what can be changed without compromising investigation
Website partner	Explain application architecture, implement approved website changes and validate journeys	Does not make legal notification or forensic attribution decisions
Host, cloud, CDN and domain providers	Preserve platform logs or snapshots, isolate services, protect accounts and support restoration	Work within their platforms and escalation processes
Privacy and legal advisers	Assess personal-information impact, privilege, contracts and notification duties	Decide legal positions and required notices
Communications lead	Prepare accurate staff, customer, partner and media messages	Publishes only approved, evidence-based information
Business owner	Identify critical services, customer harm and acceptable downtime	Approves business trade-offs and expenditure
Cyber insurer or broker	Confirm policy conditions, panel providers and consent requirements	May need to approve external incident-response costs
Finance and operations	Reconcile orders, payments, leads and fulfilment	Identifies silent business-data damage

Check the cyber insurance policy before appointing vendors if practical. Some policies require prompt notice or use of an approved incident-response panel. That check must not become a reason to leave customers exposed.

Minutes 0–60: confirm, contain and preserve

Confirm the signal without broad exploration

Capture what was observed, including full URLs, timestamps, alert identifiers, source IP information and screenshots. Check from a clean device and network where possible. Do not click suspicious downloads, run unknown scripts or browse widely through a compromised administrator session.

A single defaced page does not reveal the incident’s scope. An attacker may also hold hosting, domain, CDN, email, analytics, payment, deployment or administrator credentials. Treat each as a hypothesis to test.

Contain the harmful customer path

Containment may mean placing the website behind a controlled maintenance page, disabling checkout or forms, blocking a malicious route, revoking a compromised account, applying an edge rule or isolating the server. Choose the least destructive action that stops likely harm.

If card entry or account login may be affected, protecting visitors takes priority over keeping the full journey live. Preserve a simple, accurate service message through a trusted layer where possible. Do not place a maintenance plugin inside the same compromised application and assume the problem is contained.

The ASD incident guidance recommends planning for evidence collection and preservation and obtaining forensic or legal advice where required. Its incident-response planning guidance also stresses detailed incident records.

Preserve before you clean

Ask relevant providers to preserve available:

web server, application, PHP and database logs
WAF, CDN, load balancer and DNS logs
authentication and administrator activity
SFTP, SSH, control-panel and deployment history
file-system and virtual-machine snapshots
current database and file copies
security-tool alerts and configuration
email, payment and API-provider logs
copies or hashes of suspicious files.

Retention can be short, and a restore or redeployment may overwrite evidence. Record who collected each item, when, how and where it is held. Avoid modifying original artefacts; work from controlled copies when investigation requires it.

Escalate through trusted contacts

Contact providers through known portals or previously verified numbers, not contact details presented by a suspicious message. Notify the insurer, legal/privacy adviser and specialist incident responder based on the organisation’s plan. Australian organisations can report a cyber incident to ASD through ReportCyber and seek help through 1300 CYBER1, as described by ASD’s recovery support.

Hours 1–4: determine scope and protect control points

The objective is not yet to produce a perfect root-cause report. It is to find which trust boundaries might be lost and prevent further access.

Map the affected estate

Create a rapid system map covering:

production and staging websites
host or cloud account
domain registrar, DNS and CDN
WordPress users, SFTP/SSH and database accounts
source repository and deployment pipeline
transactional email and staff email
CRM, ERP, ecommerce, payments and forms
analytics, tag manager and advertising accounts
backup platform and remote storage
shared secrets, API keys and webhooks.

Look for new administrators, changed DNS, unknown scheduled tasks, modified plugins or themes, new files, altered payment destinations, form-recipient changes, injected scripts, unexpected redirects and unusual API activity. The official WordPress hacked-site FAQ advises site owners to scan their local environment as well as the website, change access credentials and update software after a compromise.

Rotate credentials in a deliberate order

Changing the WordPress password alone is insufficient if the attacker controls email or hosting. From a known-clean device:

secure the primary identity and email accounts
secure registrar, DNS, CDN, cloud and hosting accounts
revoke active sessions, app passwords and recovery methods
rotate privileged application, database, SFTP/SSH and deployment credentials
rotate exposed API keys, salts, webhook secrets and service tokens
reset user credentials where evidence and risk require it
enforce multi-factor authentication on supported privileged services.

Avoid rotating a secret without updating every legitimate consumer, or the response can create a second outage. Log each change, owner and dependent system.

Decide whether to take the service offline

Use a simple test:

Known malicious customer impact? Remove the affected function immediately.
Privileged access still uncontrolled? Isolate the application or account.
Evidence that content is altered but containment works at the edge? Keep only the proven-safe functions available.
No clear scope and high-consequence data or payments? Prefer controlled unavailability to uncertain exposure.

An outage is visible. A compromised payment, login or lead flow can be less visible and more harmful.

Hours 4–12: assess data impact and remove the cause

Assess the information, not just the files

A malware scan does not answer whether personal information was accessed or disclosed. The privacy assessment should consider what information the site stored, processed or transmitted; which systems were reachable; whether data was exfiltrated, altered or made unavailable; and the likely harm to individuals.

Under Australia’s Notifiable Data Breaches scheme, an eligible data breach generally involves unauthorised access to or disclosure of personal information, or loss likely to lead to that access or disclosure, where serious harm is likely and remedial action has not prevented that outcome. The OAIC’s NDB scheme guidance says a suspected eligible breach must be assessed expeditiously and reasonable steps should be completed within 30 days. Thirty days is a maximum assessment period, not permission to delay containment or a notice that is already required.

Legal and privacy advisers should determine applicability, serious-harm analysis, notification and wording. Consider contractual notices to payment providers, clients, insurers or government customers separately from the Privacy Act.

Choose clean rebuild or targeted remediation

There are two broad paths:

Rebuild from a known-good state. Provision a clean environment, deploy trusted code and content, restore only validated data, patch the entry point, rotate secrets and test before switching traffic. This often gives stronger assurance when privileged access or file integrity is uncertain.

Targeted remediation. Remove confirmed malicious artefacts, repair changed files and configuration, patch the root cause and validate the environment. This may suit a tightly scoped incident with reliable evidence, but it risks leaving persistence behind if scope is wrong.

Do not restore yesterday’s backup merely because it predates the alert. The compromise may be older, and the backup may contain the vulnerable component or attacker persistence. Validate restore points, scan them safely and close the entry path before production use.

Eradication can include:

removing unauthorised accounts, files, jobs and database entries
reinstalling WordPress core, plugins and themes from trusted sources
updating supported software and replacing abandoned components
correcting permissions and access controls
removing unused plugins, themes and services
fixing vulnerable custom code or configuration
rotating secrets and invalidating sessions
inspecting related sites that share credentials, hosting or code.

Hours 12–24: recover in stages and communicate accurately

Validate the service as a business system

Technical cleanliness is necessary but not sufficient. Before full reopening, test:

domain, TLS, CDN and security headers
public pages and redirects
login, password reset and account changes
forms, file uploads and notification recipients
search, cart, checkout, payment and refunds
pricing, tax, freight, inventory and promotions
CRM, ERP and email integrations
analytics and tag behaviour
administrator roles and privileged actions
backups, alerts, logs and monitoring.

Use test accounts and controlled transactions. Reconcile orders, leads, payments and fulfilment across the incident window. An attacker may alter a destination address or webhook while leaving the visible site apparently normal.

Restore traffic progressively where the architecture allows it. Watch WAF events, authentication, outbound requests, file changes, errors and business transaction counts. Define who can halt the recovery if suspicious activity returns.

Communicate what is known, unknown and being done

Internal staff need a concise script so they do not speculate. Customer messaging should explain service impact and practical protective steps when appropriate, without making unsupported claims about attribution or scope.

Do not say “no data was accessed” because a scan found no malware. Do not call an event “sophisticated” without evidence. Do not promise that a restored site is completely secure. State what has been confirmed, what remains under assessment, what customers should do and where updates will appear.

The OAIC recommends including roles, escalation thresholds and communication procedures in a data-breach response plan. The incident is not the time to discover who may approve a public statement.

Common actions that make a compromise worse

Deleting the malicious file immediately: this can destroy timestamps or evidence without removing persistence.
Restoring over production: this can overwrite logs and reintroduce the vulnerable component.
Resetting only WordPress passwords: broader control points may remain compromised.
Using the same possibly infected laptop: stolen browser sessions or credentials can undo the response.
Announcing a cause too early: early indicators are hypotheses, not attribution.
Leaving checkout live while investigating payment-page changes: availability should not outrank customer harm.
Assuming the host or security plugin owns the whole response: responsibilities span infrastructure, application, privacy, business and communications.
Turning every service back on at once: staged recovery makes faults and recurrence easier to detect.

What to prepare before the next incident

Within days of recovery, hold a blameless review. Confirm the entry point and timeline as far as evidence allows, document what worked, close adjacent weaknesses and assign dated improvements.

Minimum preparation should include:

named incident and deputy leads
an out-of-band contact list
asset, integration and privileged-access register
tested backups with recovery objectives
provider escalation and insurance details
central logs with appropriate retention
multi-factor authentication and least privilege
patch and component ownership
prepared holding-page and communication templates
an annual tabletop exercise.

ASD’s Essential Eight includes patching, multi-factor authentication, restricting administrative privileges and regular backups as complementary mitigations. ASD also cautions that the baseline does not mitigate every cyber threat, so controls should match the organisation’s environment and risk.

Frequently asked questions

Should we take the hacked website offline immediately?

Take affected functions offline when visitors, transactions or data may be at risk, or when privileged control is uncertain. A qualified incident lead may keep proven-safe functions available behind containment controls. Preserve evidence before destructive changes where that does not prolong harm.

Can we restore the most recent backup and move on?

Not safely without validation. The backup may already be compromised or may contain the same vulnerable code. Preserve the current environment, identify the likely entry point, validate the restore point, patch the cause, rotate secrets and test the rebuilt service.

Who should change the passwords?

The authorised owners of identity, email, registrar, hosting, cloud and application accounts should coordinate a sequenced reset from a clean device. Revoke sessions and recovery methods as well as changing passwords, and track dependent APIs and services.

Does a hacked website automatically mean a reportable data breach?

No. The facts, information involved, likelihood of serious harm and effectiveness of remedial action matter. Australian organisations should obtain privacy or legal advice promptly and follow the OAIC assessment process where the NDB scheme may apply.

Should we contact the attacker or pay a ransom?

Do not engage or pay based on an unsolicited demand. Escalate to the incident lead, insurer, legal adviser, specialist responders and relevant authorities. Decisions can have legal, operational and sanctions implications and require expert advice.

Is a malware scan enough to declare the site clean?

No. A scan detects what its checks can recognise. Recovery assurance also needs log review, account and configuration inspection, secret rotation, trusted-file comparison, root-cause remediation, business-journey testing and continued monitoring.

What should we tell customers in the first day?

Communicate verified service impacts and immediate protective actions. Separate known facts from matters still being assessed. Legal, privacy and communications owners should approve the message and update it as evidence develops.

Who is responsible if our agency does not host the website?

Responsibility remains shared and explicit. The client normally holds the hosting contract, account authority and business decisions; the host controls infrastructure; a website partner can support application remediation; specialists handle forensics; and legal/privacy advisers assess notification. One incident commander coordinates them.

How Emote can help

Emote can help clients understand a website’s application architecture, integrations and customer journeys, implement approved remediation, build a clean replacement environment and validate restored functionality in coordination with the client’s host, cyber specialists and advisers. Where scope, evidence, integrations or recovery architecture are unresolved, that work should begin with a paid Full Website Discovery. It is not a free security audit or forensic investigation.

Emote’s website support and maintenance services can be scoped around application updates, testing and agreed escalation paths once the site is stable.

If you need help planning or implementing the website recovery work, book a meeting with Emote to discuss the current situation and next step.