A website hosting account compromise investigation should begin with evidence, not hurried cleanup. A broken website, unfamiliar page, or hosting alert may indicate an intrusion, but it may also come from a failed update, an abused plugin, or a billing or DNS mistake.
This guide explains a safe review process for small businesses and property operators. It covers evidence preservation, hosting access, unexpected users, altered files, scheduled tasks, credentials, and recovery. If the site handles payments, personal data, bookings, or regulated information, involve qualified incident responders early.
Start a website hosting account compromise investigation with containment
Containment limits further damage while preserving useful information. Avoid deleting suspicious files, restoring an old backup, or changing every password before recording what happened. Those actions can destroy evidence and make the timeline harder to understand.
- Record the alert, discovery time, affected domain, and visible symptoms.
- Save screenshots of unusual pages, redirects, error messages, and hosting warnings.
- Note who discovered the issue and which accounts or devices they used.
- Restrict unnecessary administrative access if the hosting provider supports temporary suspension.
- Keep the site online only when business needs and safety allow it.
Ask the hosting provider to preserve relevant access, authentication, file, and control-panel logs. Log availability varies by provider and plan. Request the retention period, time zone, and export format before relying on those records.
Do not open unknown files on a normal work computer. Preserve copies in a protected location, and calculate file hashes if your responder has the tools and process to use them. A hash is a digital fingerprint that helps show whether a file changed later.
Review the hosting account and its access history
The hosting control panel often connects several services. One login may reach websites, databases, mailboxes, backups, DNS settings, and billing details. Therefore, review the account as a whole rather than focusing only on the website.
Check recent logins, source IP addresses, login times, failed attempts, password resets, MFA changes, API tokens, and support contacts. Compare those events with staff schedules, approved maintenance, VPN use, and known service providers. An unfamiliar IP address is a clue, not proof. Mobile networks, VPNs, and shared business connections can make attribution difficult.
List every active access path, including:
- Hosting control-panel users and delegated administrators.
- FTP, SFTP, SSH, database, and deployment accounts.
- WordPress administrators and application passwords.
- API keys, webhooks, backup integrations, and monitoring tools.
- Registrar, DNS, CDN, analytics, and email accounts linked to the site.
Check whether the attacker changed recovery addresses, phone numbers, MFA devices, trusted sessions, or notification settings. Review billing and domain records too. A hosting compromise can support later domain takeover or convincing phishing messages.
For related email access checks, see what to do after an email account compromise. Keep website and email findings connected, but do not assume that one compromised account proves the other was breached.
Find unexpected users, permissions, and credentials
Unexpected users are one of the clearest account-level warning signs. Look for new control-panel administrators, FTP users, SSH keys, database accounts, WordPress administrators, and application passwords. Record each account before disabling it when practical.
Review the creation date, last login, assigned permissions, and owner for each identity. A legitimate developer account may be unfamiliar to the business owner, so verify it with the hosting company or provider. Do not trust a display name alone.
Remove access only after preserving the relevant details. Then rotate credentials in a controlled order:
- Secure the hosting control panel and registrar account first.
- Change privileged access from a known-clean device.
- Revoke active sessions, API tokens, SSH keys, and application passwords.
- Rotate database, SFTP, FTP, deployment, and backup credentials.
- Change WordPress administrator passwords and review administrator accounts.
- Reset linked email credentials when they could expose recovery or notifications.
Use unique passwords and MFA wherever the service supports it. CISA provides practical security guidance for passwords, MFA, and account protection. Never send new credentials through ordinary email or store them in a shared document.
Inspect altered files and website behavior
A useful website hosting account compromise investigation compares current content with a known-good baseline. That baseline may come from a clean backup, a deployment repository, the hosting provider, or an unmodified staging copy.
Prioritize recently modified files, unfamiliar scripts, new administrator paths, and files in upload directories. Review web roots, configuration files, plugin and theme directories, temporary folders, and user-writable locations. Search for unexpected redirects, hidden iframes, injected JavaScript, encoded content, and new server rules.
File timestamps can help build a timeline, but they are not conclusive. Attackers can change timestamps, and routine processes can rewrite files. Compare several signals:
- File modification and creation records, where available.
- Version-control or deployment history.
- Web server requests and authentication logs.
- Database changes, including new users and altered options.
- Hosting backup dates and malware-scanner results.
For WordPress, inspect administrator accounts, active plugins, themes, uploads, scheduled actions, and unfamiliar options. Review official guidance about the WordPress REST API if an integration or unexpected publishing activity appears in the logs. The API itself is not evidence of compromise; investigate authentication and behavior around it.
Do not assume that replacing visible website files removes the attacker. Backdoors may exist in less obvious directories, database content, scheduled tasks, or another account.
Check scheduled tasks and persistence
Attackers often seek persistence, which means a way to return after a password change. Scheduled tasks deserve careful review because they can run quietly and recreate deleted files.
Check hosting cron jobs, server cron directories, task schedulers, deployment hooks, WordPress scheduled actions, and provider-specific automation. Record the command, owner, schedule, working directory, and creation or modification time. Look for commands that download code, contact an unfamiliar domain, execute files from temporary folders, or use unusual interpreters.
Do not delete a task solely because its command looks unfamiliar. A backup, cache, monitoring, or deployment process may use a complex command. Confirm its owner and purpose first, then disable or remove it through a documented change.
Review WordPress scheduled tasks and WP-Cron behavior when the site uses WordPress. That article addresses normal task failures; a compromise review must also ask whether a task was added or altered without approval.
Build a timeline and separate cause from symptoms
Good analysis turns scattered records into a timeline. Start with the earliest trusted event, then mark the first suspicious login, file change, user creation, redirect, alert, and containment action. Include time zones for every source.
Compare the timeline with approved changes, plugin updates, developer work, domain edits, and hosting maintenance. A website hosting account compromise investigation may reveal several symptoms from one root cause. For example, a new administrator could create altered pages, redirects, and outbound spam.
At the same time, avoid overclaiming. A malware scan finding shows a suspicious pattern, not necessarily the full entry path. A failed login shows an attempt, not successful access. Your conclusion should distinguish confirmed facts, strong indicators, and unresolved questions.
Maintain a simple evidence register with the source, collection time, person who collected it, file name, and storage location. Limit access to that register. Incident details can contain usernames, IP addresses, URLs, and sensitive business information.
Remediate the compromise safely
Remediation should remove the entry point and persistence, not just the visible symptom. First decide whether to clean the existing environment or rebuild it. Rebuilding from trusted sources is often easier to validate, but it still requires credential rotation and review of connected services.
Before making destructive changes, confirm that you have:
- Preserved copies of relevant logs and suspicious files.
- Known-good backups or clean sources for the website and database.
- Use a tested rollback plan and schedule a maintenance window.
- Maintain a complete inventory of accounts, integrations, and DNS dependencies.
- Assign a person responsible for approving each change.
Then remove unauthorized users, revoke tokens, replace compromised credentials, update supported software, and eliminate malicious files or tasks. Apply least privilege, which means each account receives only the access it needs. Disable unused protocols and accounts, and restrict administrative access where the host permits it.
Restore only from a backup with a known date and trustworthy origin. Scan and inspect it before connecting it to production. If the website depends on a database, preserve the current database before replacing it. For connection-related symptoms after recovery, consult this guide to checking a WordPress database connection error.
Validate recovery and prevent a repeat
A completed website hosting account compromise investigation should end with verification. Test the public site, administration, forms, checkout, booking flows, redirects, uploads, integrations, email notifications, backups, and monitoring. Check from more than one network when practical.
Review fresh logs for unexpected logins, file changes, scheduled tasks, outbound requests, and new users. Confirm that MFA works for administrators and that recovery details belong to the business. Verify that the registrar, DNS, CDN, hosting, and email accounts have consistent ownership.
Document the likely entry point, affected assets, actions taken, unresolved risks, and follow-up dates. If personal information or payment data may have been exposed, obtain legal and regulatory advice before making public statements. Notification duties depend on the facts and applicable law.
Use the NIST Cybersecurity Framework as a practical structure for identifying assets, protecting access, detecting changes, responding to incidents, and recovering services. Schedule periodic access reviews, maintain clean backups, and keep a change record for hosting work.
When to get professional help
A suspected compromise deserves professional assistance when logs are incomplete, the attacker may still have access, multiple systems are involved, or the site handles sensitive data. Tech Rescue Ops LLC can help organize evidence, review hosting and website access, coordinate safe remediation, and document recovery steps without rushing into destructive changes.