Ravindra BagaleCourses & study guides Track your progress

Guides

How to Check If My Linux Server Was Hacked (Safe Checks)

By , Cyber Security trainer LinkedIn Published: Last updated:

Start with read-only checks on your server: recent logins (last -a), unexpected users (getent passwd), listening ports (ss -tulpn), new cron jobs, and recently changed binaries. Document everything. If you confirm a breach, isolate, rotate keys, and rebuild from a clean image when needed.

Quick answer

last -a | head
sudo journalctl -u sshd --since "7 days ago" | grep Accepted
sudo ss -tulpn
sudo ls -lt /etc/cron.* /var/spool/cron 2>/dev/null | head

Why a careful checklist?

Panic deletes evidence. A short, ordered checklist keeps you safe and useful. Hannah in Toronto and Rahul in Satara both use the same first five commands.

What are you proving?

You want unexpected access (logins/keys), unexpected presence (processes/ports), or unexpected persistence (cron/systemd).

How do I check step by step?

  1. Optional but smart: create an EBS / disk snapshot.
  2. Logins: 
    last -a | head
sudo journalctl -u sshd --since "7 days ago" | grep -i Accepted
    ec2-user pts/0 ... still logged in  103.60.210.132
Accepted publickey for ec2-user from 103.60.210.132

    What it means: These successes match a known admin IP in this sample. Unknown IPs need urgent review.

  3. Users with login shells: 
    getent passwd | awk -F: '$7 !~ /nologin|false/ {print}'

    What it means: Lists accounts that can get a shell. Remove strangers.

  4. Listeners: 
    sudo ss -tulpn

    What it means: Unknown listeners (crypto miners often use odd high ports) are red flags.

  5. Persistence points: 
    sudo crontab -l; ls -la /etc/cron.d /etc/cron.daily 2>/dev/null
sudo cat /root/.ssh/authorized_keys 2>/dev/null

    What it means: New cron lines or SSH keys you did not place are classic persistence.

  6. Recently changed binaries (example): 
    sudo find /usr/bin /usr/sbin -type f -mtime -2 2>/dev/null | head

    What it means: Binaries modified in the last two days deserve an explanation (patches vs tampering).

  7. If you confirm compromise: isolate network, rotate all secrets, rebuild from a known-good image, then harden (SSH keys, Fail2ban, fewer open ports).

For website files and CMS symptoms, also use the Is my website hacked? tool.

Ravindra Bagale's Tip

Do not run random "cleaner" scripts from the internet on a suspect host. They can destroy evidence or be malware. Snapshot the disk first if the cloud allows it. Then investigate.

Quick quiz: check what you learned

  1. Which command lists recent interactive logins?

    1. last -a for recent logins
    2. sha256sum on /etc/hosts only
    3. ping 8.8.8.8 for connectivity
    4. curl example.com for HTTP check
    Show answer

    A. last reads wtmp; look for unknown users or IPs.

  2. If you confirm a compromise, the safe recovery path is:

    1. Rotate secrets and rebuild from a clean image
    2. Only change the desktop wallpaper theme
    3. Turn off logging to hide the trail
    4. Share the host publicly on the internet
    Show answer

    A. Assume secrets leaked; rebuild from trusted image.

Learn it properly

This guide is the short path. These pages go deeper, with labs:

Frequently asked questions

How do I check if my Linux server was hacked?

Review logins, users, ports, cron, SSH keys and recent file changes. Use the commands in this guide.

What is a strong sign of compromise?

Successful login you do not recognise, new root SSH key, unknown listening port, or cron calling a strange script.

Should I delete files immediately?

Prefer snapshot and notes first. Deleting can remove evidence.

Website-only checklist?

Use /cyber/tools/is-my-website-hacked/ for web-focused steps.

Related lessons?

26.x privilege escalation defence; 31.x IR; 32.x hardening.