AWS Lightsail WordPress Hacked? How to Contain and Clean It

First, take a manual snapshot of the Lightsail instance so you preserve evidence. Then restrict the instance firewall so SSH is only open to your IP, change the WordPress admin, database and AWS console passwords from a clean device, and enable multi-factor authentication on the AWS account. Only then start cleaning.

A Lightsail WordPress instance is a full Linux virtual server, not managed hosting. That matters because an attacker who gets code execution through WordPress is 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 frequently misses those.

Create a manual instance snapshot from the Lightsail console before making changes. A snapshot preserves the disk as it was at the time of compromise, so you can examine it later or rebuild from it. Do not treat it as a clean backup: it contains the malware, and restoring it restores the infection.

1. Snapshot now. In the Lightsail console, open the instance, go to Snapshots and create a manual snapshot. Name it clearly, for example acme-prod-01-compromised-2026-09-03.
2. Check automatic snapshots. If automatic snapshots are enabled, look at older ones. A snapshot from before the infection began can help you compare files, but confirm the infection date before trusting it.
3. Consider a forensic copy. You can create a new instance from the compromised snapshot and investigate that copy, leaving production untouched and reachable only from your IP.

Snapshots also support the safest end state after a serious compromise: a fresh instance from a clean blueprint, with verified content migrated across.

In the Lightsail console, open the instance's Networking tab and edit the IPv4 and IPv6 firewall rules. Restrict SSH (TCP 22) to your own IP address, keep HTTP and HTTPS open only if the site must stay online, and remove any other open ports you did not add yourself.

When you restrict SSH to specific IPs, Lightsail offers an option to keep its browser-based SSH working. Leave it enabled if you rely on the console's SSH button. Remember that the firewall controls inbound traffic only: a reverse shell connects outbound, so you still need to find and kill it on the server.

On current Lightsail WordPress blueprints, which are built on Bitnami, WordPress lives in /opt/bitnami/wordpress, with wp-config.php in that directory. Older instances use /opt/bitnami/apps/wordpress/htdocs. Apache configuration and logs sit under /opt/bitnami/apache, and the default SSH user is bitnami. Knowing the layout first saves time during an incident.

# Confirm which layout this instance uses
ls -d /opt/bitnami/wordpress /opt/bitnami/apps/wordpress/htdocs 2>/dev/null
/opt/bitnami/wordpress
# PHP files in uploads (should be empty)
sudo find /opt/bitnami/wordpress/wp-content/uploads -name "*.php"
/opt/bitnami/wordpress/wp-content/uploads/2026/08/wp-info.php
# Recently modified PHP anywhere in WordPress
sudo find /opt/bitnami/wordpress -name "*.php" -mtime -10 -printf "%TY-%Tm-%Td %p\n" | sort
# Requests to the suspicious file in the Apache access log
sudo grep "wp-info.php" /opt/bitnami/apache/logs/access_log
203.0.113.88 - - [28/Aug/2026:03:42:17 +0000] "POST /wp-content/uploads/2026/08/wp-info.php HTTP/1.1" 200 312

The access log is how you find the first request to the webshell, which dates the compromise and often points to the vulnerable plugin that let the attacker in. Also check wp-config.php for unexpected code at the top of the file and compare it against a known-good copy.

Check the instance for persistence outside WordPress: crontabs for the bitnami and daemon users and root, systemd services, running processes with outbound connections, SSH keys in every authorized_keys file, and executables in /tmp and /dev/shm. These survive a WordPress reinstall.

# Crontabs for the users that matter on Bitnami
for u in root bitnami daemon; do echo "== $u"; sudo crontab -l -u $u 2>/dev/null; done
* * * * * /tmp/.cache/upd >/dev/null 2>&1
# Processes with established outbound connections
sudo ss -tpn state established
ESTAB 0 0 172.26.3.14:48122 198.51.100.61:443 users:(("upd",pid=2211,fd=3))
# SSH keys: compare with the key you downloaded from Lightsail
cat /home/bitnami/.ssh/authorized_keys
# Services added recently
ls -lt /etc/systemd/system/*.service | head

If you find a process like that, record its details, stop it, remove its cron entry and binary, and then look for how it got root or daemon access. Our guide to why malware keeps coming back explains the common persistence patterns in depth.

Clean WordPress on Lightsail by removing persistence first, then quarantining malicious files, reinstalling WordPress core, plugins and themes from official sources, removing rogue administrators and injected database content, rotating the salts and database password in wp-config.php, and restarting the Bitnami services so no malicious code stays loaded in memory.

Bitnami instances include WP-CLI, which makes the core and user checks quick. Run it as a user with access to the WordPress directory, typically with sudo:

# Compare core files against official checksums
cd /opt/bitnami/wordpress
sudo wp core verify-checksums --allow-root
Warning: File doesn't verify against checksum: wp-includes/load-helper.php
# List administrators and look for accounts you did not create
sudo wp user list --role=administrator --fields=ID,user_login,user_registered --allow-root
1   admin_acme        2025-11-02 10:14:07
7   wp_sys_support    2026-08-28 03:44:51
# Reinstall core without touching wp-content, then refresh salts
sudo wp core download --force --skip-content --allow-root
sudo wp config shuffle-salts --allow-root
# Restart Apache and PHP-FPM so nothing stays in memory
sudo /opt/bitnami/ctlscript.sh restart

Note that the rogue administrator above was registered within two minutes of the webshell request in the access log, which ties the two together and confirms the timeline. Delete that account, reassign its content if any, and check wp-content/mu-plugins for code that hides users. The Bitnami initial credentials file in /home/bitnami/bitnami_credentials should also be treated as exposed if the attacker had shell access: change the WordPress and database passwords it lists.

Replace plugins and themes with fresh copies rather than editing infected ones, and remove any you do not use. Our WordPress malware removal guide covers the database clean-up in more depth.

Clean the instance if the compromise is confined to WordPress files and the database. Rebuild onto a fresh Lightsail instance if there is evidence of root access, rogue users, modified system binaries or kernel-level tampering. On Lightsail, rebuilding is quick, so it is often the safer choice after a serious compromise.

1. Create a fresh instance from the current WordPress blueprint in the same region.
2. Migrate content, not code. Export the database, clean it, and copy only uploads (with PHP files removed). Reinstall plugins and themes from official sources.
3. Move the static IP to the new instance so DNS does not need to change.
4. Harden before going live. Firewall rules as above, SSH keys only, PHP blocked in uploads, admin accounts audited.
5. Keep the old snapshot for evidence, then delete the compromised instance once you no longer need it.

PatientZero investigates hacked AWS and Lightsail servers end to end: we connect over SSH, run a Forensic scan and Malware sweep, and either clean in place or rebuild and verify. Every plan includes unlimited malware removal, so if something returns we clean it again. See server malware removal, WordPress malware removal or, if it is urgent, emergency help.