Check your server for a break-in

Use this after a security hole in software you run, such as a vulnerable PHP version, or when something on your server looks wrong. The checks below look for the most common traces. They cannot prove that a server is clean: someone who got full control can hide their tracks. If you find something, go to the last section.

Run the commands as a user with sudo. Write down what you find, with the time, before you change anything.

Look for unknown or recently changed PHP files#

Attackers often leave a small PHP file (a web shell) in a folder the web server can write to, such as an upload folder or a cache folder.

1. List PHP files in your web folders that changed in the last 14 days:

   Copier

   sudo find /var/www -type f -name '*.php' -ctime -14 -ls
   

   -ctime looks at when the file itself last changed on disk, which is harder to fake than the date shown by ls. An update of your software also changes files, so compare with when you last updated.

2. Look for PHP files in places where only uploads or cache should be. For example, for a Laravel app such as the Pterodactyl Panel:

   Copier

   sudo find /var/www -type f -name '*.php' \( -path '*/storage/*' -o -path '*/uploads/*' -o -path '*/public/*' \) -ctime -30 -ls
   

   In a Laravel app, public normally holds only index.php as PHP, and compiled views in storage/framework/views are normal.

3. Search for code that is often used in web shells:

   Copier

   sudo grep -rlE 'eval\(base64_decode|eval\(gzinflate|eval\(\$_(POST|GET|REQUEST)|assert\(\$_(POST|GET|REQUEST)' /var/www
   

   This finds suspicious patterns, not proof. Libraries in vendor or node_modules can match for harmless reasons. Look at every file it finds.

4. Check temporary folders, where attackers often put programs:

   Copier

   sudo ls -la /tmp /var/tmp /dev/shm
   

Look for strange processes#

1. List what runs under the web server's user (on Debian and Ubuntu usually www-data; also check nginx or apache on other systems):

   Copier

   ps -u www-data -o pid,ppid,lstart,cmd
   

   Normally you only see php-fpm workers (and the web server itself). A shell (sh, bash), perl, python, nc, curl, wget or a program in /tmp or /dev/shm running as www-data is a strong warning sign.

2. Look for programs whose file has been deleted while they still run, a common trick:

   Copier

   sudo ls -l /proc/*/exe 2>/dev/null | grep deleted
   

   Right after a package update, normal services can show up here until they are restarted. Anything you do not recognise is worth a closer look.

3. Look at the busiest processes with top or htop. A process you do not know that uses a lot of CPU is often a cryptocurrency miner.

Look for new users and sudo rights#

1. Users with ID 0 have root rights. Only root should be listed:

   Copier

   awk -F: '$3 == 0 {print $1}' /etc/passwd
   

2. Normal user accounts (ID 1000 and up). Check that you know each one:

   Copier

   awk -F: '$3 >= 1000 {print $1, $6, $7}' /etc/passwd
   

3. Who has sudo rights:

   Copier

   getent group sudo
   sudo ls -la /etc/sudoers.d/
   

4. The web server's user should not be able to log in. Its shell should be /usr/sbin/nologin or /bin/false:

   Copier

   getent passwd www-data
   

Check the SSH keys that may log in#

A new line in an authorized_keys file lets someone log in again later, even after you change passwords.

sudo find / -xdev \( -name authorized_keys -o -name authorized_keys2 \) -ls

Read each file you find and check that you know every key in it:

sudo cat /root/.ssh/authorized_keys

Pay special attention to an .ssh folder in the home folder of www-data, which is /var/www on Debian and Ubuntu. Check also /etc/ssh/sshd_config and /etc/ssh/sshd_config.d/ for an AuthorizedKeysFile line you did not add.

Check cron jobs and timers#

Attackers often add a scheduled task that downloads their program again after you delete it.

sudo cat /etc/crontab
sudo ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly
sudo ls -la /var/spool/cron/crontabs
sudo crontab -l -u root
sudo crontab -l -u www-data
systemctl list-timers --all

Also look for systemd services that were added recently:

sudo find /etc/systemd/system -type f -ctime -30 -ls

And check that /etc/ld.so.preload does not exist. On a normal server it is not there; if it is, it can be used to load a program into every other program:

ls -la /etc/ld.so.preload

Check which ports are open#

1. Programs that listen for connections:

   Copier

   sudo ss -tulpn
   

   Check that you know every program and port. A program that listens under www-data, or a high port you did not open, is suspicious. On a Pterodactyl node, Wings listens on its own ports (8080 or 8443, and 2022 for SFTP) and Docker on the ports of your game servers; that is normal.

2. Connections that are open right now:

   Copier

   sudo ss -tnp
   

Check who logged in#

1. Recent logins:

   Copier

   last -a | head -n 30
   

   On some newer releases last is missing or empty; use the next command instead.

2. Successful SSH logins from the log:

   Copier

   sudo journalctl -u ssh --since "30 days ago" | grep 'Accepted'
   

   On systems that write /var/log/auth.log, this works too:

   Copier

   sudo grep 'Accepted' /var/log/auth.log
   

   On Debian and Ubuntu the service is called ssh; on some other systems it is sshd. Check that every login comes from you, from a place and at a time you recognise.

3. The web server's access log can show requests to a file you did not create. For NGINX:

   Copier

   sudo grep -E 'POST .*\.php' /var/log/nginx/access.log | tail -n 50
   

Check installed files against the packages#

On Debian and Ubuntu, dpkg can compare installed files with what the packages put there:

sudo dpkg --verify

Each line is a file that differs. Configuration files you edited yourself show up too (marked with c). A changed program in /usr/bin or /usr/sbin is a serious warning sign. Someone with root rights can also change the list dpkg compares with, so a clean result is not a guarantee.

If you find something#

Do not just delete the file and carry on. A web shell or a strange process is usually not the only thing an attacker left behind, and it does not tell you what else they took.

1. Isolate the server. Take it off the network, or close every port except SSH from your own IP address. If your provider offers snapshots, make one first: it keeps the evidence.
2. Assume every secret on the server is known. From another, clean computer, change:
   • the passwords of every user on the server, and remove SSH keys you did not add;
   • database passwords, and the passwords in the .env or configuration files of your apps;
   • API keys and tokens stored on the server (payment providers, mail, DNS, cloud storage);
   • for a Pterodactyl Panel: the passwords of administrators, the keys under Application API, and the node key under Nodes, your node, Settings, Reset Daemon Master Key.
3. Reinstall from a clean source. Install the operating system again, install your software from its official source, and copy back only your data, not programs or scripts from the old server.
4. Restore data from a backup made before the break-in. A backup made after it may contain the attacker's files. Check the restored data before you go online again.
5. Close the hole they came through before the server is reachable again: update the software (for PHP, see PHP2Shell: patch CVE-2026-109618 and CVE-2026-109619) and secure SSH.
6. Find out whether you must report it. If personal data of other people was on the server, the law may require you to report the breach. Under the GDPR in the EU, that is a report to your data protection authority within 72 hours of finding out, unless the breach is unlikely to put people at risk.