AWS Lightsail malware removal for UK sites

A Lightsail instance is a full Linux server that you manage, not managed WordPress hosting. If an attacker gets code execution through WordPress, they are running on a real server, where they can add cron jobs, drop binaries in /tmp, start processes and, if they escalate privileges, add users and SSH keys. A WordPress-only clean-up often misses all of that, which is why the infection returns.

Lightsail WordPress blueprints are built on Bitnami, so files live under /opt/bitnami rather than /var/www. Knowing that layout up front saves time during an incident; our guide to hacked WordPress on Lightsail walks through it step by step.

Take a manual snapshot so you preserve evidence, restrict SSH to your own IP address in the Lightsail firewall, change the WordPress admin, database and AWS passwords from a clean device, and turn on multi-factor authentication for the AWS account. Do this before you start cleaning.

1. Snapshot the instance. A snapshot is evidence and a fallback, not a clean backup: restoring it restores the infection.
2. Restrict the firewall. Limit SSH (TCP 22) to your IP and close any port you did not open yourself. Remember a reverse shell connects outbound, so this alone does not stop it.
3. Rotate credentials from a clean device. WordPress admins, the database, SSH keys and the AWS console.
4. Do not delete files yet. Evidence on the server tells us how the attacker got in.
5. Call for help. 01932 593642 or start emergency triage.

We check the WordPress site and the server underneath it, then tell you what to review on the AWS side. The server checks are done by our scan engine over SSH; the AWS checks are ones we guide you through, because they live in your account.

If you are comfortable on the command line, this read-only check shows PHP files that should not exist in uploads:

# PHP files in uploads (should be empty)
sudo find /opt/bitnami/wordpress/wp-content/uploads -name "*.php"
# Processes with established outbound connections
sudo ss -tpn state established

We break persistence first, then quarantine malicious files, reinstall WordPress core, plugins and themes from official sources, clean the database, rotate the salts and credentials, and restart the services so no malicious code stays loaded. Then we find the entry point, harden the server and rescan.

1. Break persistence. Malicious cron entries, services and processes go first.
2. Quarantine payloads with file hashes recorded as evidence.
3. Restore known-good code and clean injected content from the database.
4. Find the way in from the access logs, usually a vulnerable plugin or a stolen login.
5. Harden and monitor with Harden playbooks and 24/7 monitoring.

You receive a technical report and a plain-English summary you can share with clients, insurers or, where needed, when considering whether a breach needs reporting.

If the attacker only touched WordPress, a thorough clean-up and hardening is usually enough. After a root-level compromise, the safest end state is often a fresh instance from a clean blueprint with verified content migrated across, because you cannot fully trust a system the attacker controlled. Snapshots make this straightforward, and a static IP can be moved to the new instance.

We advise on which applies once we have seen the evidence. Unlimited removal covers clean-ups on every plan; fair use applies to full instance rebuilds, which we scope with you. For the root-compromise case in more depth, see server malware removal.