Has Your Business Website Been Hacked? Warning Signs and Next Steps

TL;DR: Get the right people involved and keep a record

If your website behaves unexpectedly or your provider reports suspicious activity, contact the team responsible for it now. Record what you noticed and when, appoint one contact to coordinate the response, and ask the provider to contain the problem while preserving evidence. You do not need to investigate the server yourself. A security flaw does not automatically mean a successful attack, and a normal-looking website does not prove that everything is safe.

Warning signs you might notice

• Visitors are redirected to unfamiliar websites, or your pages show content you did not approve.
• Payment instructions, bank details or checkout pages change unexpectedly.
• You receive alerts about new administrator accounts, unusual sign-ins or changes nobody recognises.
• Customers report suspicious messages or activity connected to your website.
• Your hosting provider, browser or security service flags the site.

These are reasons to investigate, not proof of one specific cause. A broken deployment or legitimate change can sometimes explain an alert. A quiet or working website can also conceal unauthorised access.

Your first actions as the owner

Contact your hosting provider, website agency or internal IT lead through a trusted channel. Agree who is coordinating the incident and when you will receive the next update. Tell them which websites, shops and connected applications matter most to your business.

Keep screenshots, alert messages, customer reports and the time you first noticed the problem. Do not publish sensitive evidence. Ask the technical team to preserve the relevant records before cleaning up. Avoid deleting files, restoring a backup or ordering an unplanned reboot on your own; these actions can remove useful evidence.

If harm is ongoing, ask the responsible team to contain it immediately and explain whether temporary restrictions are needed. For example, changed checkout details may require a prompt decision about accepting orders. Agree how customers and staff will be kept informed.

A message you can send to your provider

We noticed the following unexpected activity: [describe what happened and when]. Please investigate whether there was unauthorised access to our website or connected systems. Preserve relevant evidence, recommend immediate containment, and tell us which services and data may be affected. Please distinguish confirmed findings from suspicions and unknowns. Confirm who is coordinating the response, the next update time and the conditions for safely returning to normal operation. If PHP2Shell is relevant, confirm the update status separately.

Ask for answers that support business decisions

• What is confirmed, what is suspected and what remains unknown?
• Which websites, accounts, customer information and connected services are in scope?
• Is the activity contained, and what restrictions remain necessary?
• What must happen before normal service resumes, and how will the result be checked?
• Who owns each next action, and when will we receive an update?

A useful report explains what was examined and its limits. “No signs found in the available logs” is different from proving that nobody gained access. If customer or business information may be involved, bring the responsible privacy, legal and management contacts into the assessment so they can determine the necessary communications.

Updating the software and investigating the incident are separate jobs

For PHP2Shell, ask the provider to confirm that the security updates are installed and in use. If an attacker had already entered, updating alone does not remove that access or explain what happened. Recovery may require a rebuild from a trusted source, replacement of exposed credentials and checks of restored data. The technical team should explain the chosen approach and the remaining uncertainty.

Need help understanding the provider's response?

Contact Farland Technology GmbH to discuss the situation and the support you need. Share your website addresses, a short timeline and your provider's written findings. Do not send passwords or customer records through the contact form. Use the Request proposal link below to start the conversation.

Technical appendix: Initial Ubuntu triage for your IT team

This section is for an authorised administrator or incident responder. It supports initial triage, not a full forensic examination. Coordinate containment and evidence collection first. Keep output private and preserve protected copies off the suspected host.

Review the relevant time window

date -u

sudo journalctl --utc --since '2026-10-20 00:00:00 UTC' --no-pager

Adjust the start time to before the earliest suspected access. Include rotated web, application and authentication logs and external provider, CDN and audit records. The journal alone is incomplete, and some request data may never have been recorded.

Compare changes with a trusted deployment

sudo find /var/www/your-app -xdev -type f -mtime -7 -print

Replace the path and time window. Check code, uploads, configuration, database changes and checkout scripts against a known-good release stored elsewhere. File dates can be forged and legitimate deployments change files too. Do not execute suspicious scripts.

Correlate processes, connections and persistent access

ps -eo user,pid,ppid,lstart,args --forest

sudo ss -tpn

These are snapshots, not historical proof. Corroborate unusual web-worker activity with external records and legitimate jobs. Review accounts, SSH keys, scheduled tasks, systemd services, application jobs and cloud tokens. If integrity cannot be established, plan a patched rebuild, validate backups and revoke exposed access after containment. Local tools may be unreliable on a compromised host.

Sources and review date

Published 21 October 2026. Last reviewed 22 October 2026.

• NCSC incident response planning: https://www.ncsc.gov.uk/collection/incident-management/cyber-incident-response-processes
• CISA logging guidance: https://www.cisa.gov/audiences/small-and-medium-businesses/secure-your-business/use-logging-on-business-systems
• NSA and ASD web shell detection guidance: https://media.defense.gov/2020/Jun/09/2002313081/-1/-1/0/CSI-DETECT-AND-PREVENT-WEB-SHELL-MALWARE-20200422.PDF
• Elastic web server process investigation: https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/linux/persistence_webserver_suspicious_command_execution
• CISA incident response playbooks: https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf