The Website Was Changed Overnight: How to Investigate Unauthorised Website Modifications
You open your business website in the morning and immediately notice something is wrong.
The homepage looks different. A page has disappeared. New links have appeared in the navigation menu. Your contact details have changed, or an unfamiliar administrator account has been added.
Nobody on your team approved the changes.
At first, it might look like a technical mistake or a failed website update. But when the changes cannot be explained, a more serious possibility needs to be considered: someone may have accessed the website without authorisation.
Unauthorised website modifications can affect much more than appearance. They may expose customer information, redirect visitors, damage search visibility, alter business communications or provide an attacker with continued access.
The challenge is working out what changed, when it happened, how it happened and whether the website is still exposed.
This guide explains how to investigate unexplained website changes, preserve useful evidence and reduce the risk of another incident.
1. What Counts as an Unauthorised Website Modification?
An unauthorised website modification is a change to a website, its content, configuration or associated systems that was not approved by the organisation or its authorised administrators.
It can affect almost any part of a website.
Examples include:
- Changes to homepage text, images or navigation
- New pages or unfamiliar links
- Altered contact information or payment instructions
- Unexpected administrator accounts
- Modified website files or database records
- Unapproved scripts or tracking code
- Changes to redirects or website configuration
- Altered product descriptions or prices
- Unauthorised changes to customer-facing forms
Not every unexpected change is evidence of hacking. A plugin update, automated deployment, content management error or hosting issue may explain some modifications.
The important question is whether the change can be linked to an authorised action.
When no legitimate explanation exists, the organisation should preserve relevant records and investigate before assuming the incident is harmless.
2. Why Would Someone Change a Business Website?
There are several possible motives behind unauthorised website modifications.
Brand impersonation and reputational damage
An attacker may change website content to publish misleading information, display offensive material or make a legitimate business appear untrustworthy.
Even a short-lived incident can affect customer confidence.
Payment diversion
A fraudulent modification may change payment instructions, bank details, checkout destinations or contact information.
This can create direct financial risk, particularly for businesses that accept online payments or publish payment instructions.
Search engine manipulation
Some website compromises involve unexpected pages, links or redirects designed to influence search-engine visibility.
The website owner may not immediately notice the changes, especially if they affect pages that are rarely visited.
Customer information exposure
Unauthorised modifications may be connected to broader access to website databases, forms or administrative systems.
An investigation may need to establish whether customer information was viewed, changed or exposed. The presence of an unauthorised modification alone does not prove that data was stolen.
Continued access
Some changes may be intended to preserve access to the website or its hosting environment.
For example, an attacker who has gained administrative access may create additional accounts or alter permissions. This possibility makes it important to examine more than the visible page changes.
3. Seven Signs That Someone May Have Changed Your Website Without Permission
A website owner should pay attention to changes that cannot be explained by normal business activity.
1. Unfamiliar content appears
New text, images, links or pages appear without an approved content update.
2. Existing pages have been altered
Product details, prices, service descriptions or contact information change unexpectedly.
3. Unknown administrator accounts appear
The website’s user list contains accounts that nobody recognises or can explain.
4. Website files have changed unexpectedly
Files show modification times or content differences that do not correspond to documented updates.
5. Visitors are sent somewhere unexpected
The website redirects users to unfamiliar pages or displays content that the administrator cannot reproduce.
6. Search results show unfamiliar pages
Search engines display titles, descriptions or URLs that the organisation did not intentionally publish.
7. Administrative activity looks unusual
Available records show unfamiliar logins, permission changes, content updates or other events requiring investigation.
These signs are indicators, not proof. Each should be compared with legitimate maintenance, software updates, publishing activity and hosting configuration.
4. What to Do First When You Discover an Unauthorised Change
The first response can influence how much useful evidence remains available.
Avoid immediately deleting everything that looks suspicious. A rushed cleanup may remove information needed to understand the incident.
Instead, take a controlled approach.
Record the visible changes
Capture the affected pages, URLs, dates and times.
Record what the website looked like before the change if you have approved backups, screenshots or version history.
Make a note of who discovered the issue and what they observed.
Contact your website developer or hosting provider
If an external developer or hosting provider manages the website, notify them promptly.
Ask whether they can preserve relevant logs, backups, deployment records and account activity information.
Make sure the organisation understands which systems are managed internally and which are controlled by external providers.
Protect administrative accounts
Review access to the content management system, hosting account, domain registrar and connected services.
Where appropriate, secure accounts, revoke suspicious sessions and remove access that is confirmed to be unauthorised.
For a potentially serious incident, coordinate security changes with an appropriately qualified professional so that important evidence is not inadvertently destroyed.
Preserve relevant records
Keep copies of the original website content, available logs, backups, suspicious files and relevant communications.
Document any changes made during the response, including who authorised them and when.
Assess the impact
Consider whether the incident affected only website content or whether it may have involved customer data, payment systems, email accounts or other business services.
If personal information or regulated data may have been exposed, obtain appropriate legal and privacy advice about notification obligations.
5. How to Investigate Who Changed the Website
Identifying the account or process responsible for a modification is often more complicated than looking at the latest file date.
A proper investigation should bring together several sources of evidence.
Review content management system activity
Many content management systems maintain information about users, roles, published content and revisions.
Where available, examine:
- Administrator accounts
- User-role changes
- Content revision history
- Login records
- Plugin and theme changes
- Relevant administrative actions
The available history depends on the platform and how it was configured.
A content revision may identify an account associated with a change, but that does not necessarily establish which individual was operating the account.
Examine website file changes
Website files can provide important information about what was modified.
Depending on the platform, investigators may compare current files with trusted backups or known-good versions.
The review may identify:
- Changed website templates
- Modified configuration files
- Unexpected scripts
- Unfamiliar files
- Changes to plugins or themes
- Differences between deployed and approved versions
File timestamps can help establish a sequence of events, but they are not definitive proof of when or by whom a change was made. System operations, migrations and file copying can affect timestamps.
Review hosting and server logs
Hosting records may provide information about requests, authentication events, file operations and other server activity.
Relevant records depend on the provider and the logging configuration.
An investigation may examine activity around the time the modification was discovered and compare it with normal administrative behaviour.
Examine database records
Many websites store content, settings, user information and configuration data in a database.
Unexpected changes to database records may help explain modifications that are not obvious from the website’s visible files.
The review should be performed carefully, with appropriate access and evidence-preservation procedures.
Review third-party integrations
A website may depend on external services for analytics, advertising, forms, payments, authentication or content delivery.
If a connected service or account has been compromised or misconfigured, the visible change may originate outside the main website installation.
The investigation should identify which external services are involved and whether their activity can be reviewed.
6. Can You Find Out Exactly When a Website Was Changed?
Sometimes, but the answer depends on the records available.
Potential sources of timing information include:
- Content management system revision history
- Hosting access logs
- Server error logs
- File modification records
- Database backups
- Deployment and version-control history
- Security monitoring alerts
- Emails or notifications about administrative activity
Combining these sources may help establish a timeline.
For example, an organisation may have a backup from Monday, a website change notification from Tuesday and a suspicious administrator login recorded on Wednesday.
These records can help narrow down the period in which an unauthorised change occurred.
However, a precise timeline is not always possible. Logs may be incomplete, clocks may use different time zones, and some platforms retain records for only a limited period.
A responsible report should explain the available timing evidence and any uncertainty.
7. Why a Backup Alone May Not Solve the Problem
Restoring a backup can be an important recovery option, but it does not automatically resolve every aspect of a website incident.
There are several reasons.
The backup may already contain the unwanted changes. If the compromise happened before the backup was created, restoring it may reintroduce the same issue.
The access route may remain open. Restoring website files does not necessarily secure compromised administrator accounts, hosting credentials or connected services.
Some evidence may be lost. Replacing affected files or databases before preserving relevant records may make it harder to establish what happened.
Recent legitimate data may be affected. Restoring an older version may remove valid customer orders, form submissions or content updates.
A recovery plan should therefore consider both the website’s operational needs and the investigation requirements.
Where appropriate, preserve a copy of the affected environment before remediation, then use a verified clean backup and secure the associated accounts and systems.
8. How to Prevent Unauthorised Website Changes
Once the immediate incident has been addressed, the organisation should review the controls that protect website administration.
Useful measures include:
Multifactor authentication: Require additional authentication for administrator, hosting and domain registrar accounts.
Individual user accounts: Avoid shared administrator credentials wherever possible. Individual accounts improve accountability.
Least-privilege access: Give users only the permissions needed for their responsibilities.
Regular access reviews: Remove former staff, contractors and unused accounts.
Software maintenance: Keep the content management system, plugins, themes and server components appropriately updated.
Change approval: Establish a process for approving significant website changes.
Version control: Where appropriate, maintain a record of approved code changes and deployments.
Reliable backups: Keep protected backups and periodically test restoration.
Security monitoring: Review important account, file and configuration changes.
Third-party access management: Regularly check which external developers, agencies and services can modify the website.
These controls make it easier to identify unexpected activity and reduce the opportunities for unauthorised changes.
9. What Evidence Should Be Preserved?
If a website modification may be part of a security incident or business dispute, evidence should be handled carefully.
Depending on the incident, relevant records may include:
- Screenshots and copies of affected pages
- Original website files
- Database exports or relevant records
- Content revision history
- Hosting and server logs
- Administrator account records
- File modification information
- Backup copies
- Deployment records
- Emails and messages discussing the changes
- Communications with developers or hosting providers
Record where each item came from, when it was collected and who handled it.
Avoid altering original evidence unnecessarily. Where technical examination is required, work from appropriate copies and document the process.
Cyb3rsect’s guide to digital evidence preservation provides further guidance on protecting relevant records.
10. What Should a Website Modification Investigation Report Include?
A useful investigation report should explain the incident in a way that business owners, technical staff and authorised advisers can understand.
Depending on the agreed scope and available records, it may include:
- Incident summary: What was reported and when it was discovered.
- Investigation scope: Which websites, accounts, files and records were examined.
- Modification details: What changed and which records support the finding.
- Timeline: Relevant events and the limitations of the available timestamps.
- Account activity: Relevant user accounts, permissions and access records.
- Technical findings: File, database, configuration and hosting observations.
- Unresolved questions: Information that could not be verified.
- Recommendations: Remediation and security improvements.
The report should distinguish between an identified modification, evidence of unauthorised access and attribution to a particular person.
Those are separate conclusions and should not be treated as interchangeable.
For further guidance, see what a professional digital forensic report should contain.
11. How Cyb3rsect Can Help With Website Investigations
When a business discovers unexplained website changes, it may need more than a visual review or a standard malware scan.
Cyb3rsect focuses on digital investigations, evidence analysis and structured reporting.
Depending on the agreed scope, the client’s authority and the records available, an engagement may involve:
- Reviewing relevant website and hosting records
- Examining supplied files and configuration information
- Reviewing available account and administrative activity
- Organising evidence of suspicious modifications
- Developing a timeline of reported events
- Documenting findings and technical limitations
- Preparing a structured investigation report
The website owner or authorised representative must provide appropriate permission for any examination of the relevant systems.
The investigation should define what can be examined and what information is available before conclusions are reached.
Cyb3rsect does not assume that every unexpected change is a cyberattack or promise that every incident can be attributed to a specific individual. The aim is to establish what the evidence supports and identify reasonable next steps.
Businesses can visit Cyb3rsect to learn more about digital investigations and evidence analysis.
Conclusion: Investigate the Change Before You Erase the Evidence
An unexplained website modification may be a simple technical mistake—or it may be the visible sign of a wider security incident.
The difference cannot always be determined from the homepage or a single security scan.
A careful investigation examines the relevant accounts, website files, database records, hosting activity and available change history. It also considers legitimate explanations and documents where the evidence is incomplete.
If your website has changed without authorisation, preserve the available records, secure affected access and establish what happened before treating the incident as resolved.
A website can be restored. Understanding how it was changed is what helps prevent the same problem from happening again.
