Investigating a breached Linux server, where do you look for attacker persistence?

Persistence is how an attacker keeps access after the initial foothold — and on Linux it lives in a well-known set of places: anything the system runs automatically on a schedule, at boot, or at login. A competent responder works through that list methodically rather than chasing whatever is most visible.

Where to actually look

• Scheduled execution: user and system crontabs, /etc/cron.*, and especially systemd timers and units (systemctl list-timers, unit files in /etc/systemd/system and ~/.config/systemd/user).
• SSH access: added keys in ~/.ssh/authorized_keys for every user, including service accounts; an attacker key here is a quiet, durable backdoor.
• Shell startup files: ~/.bashrc, ~/.bash_profile, ~/.profile, /etc/profile.d/* — code dropped here runs on every interactive login.
• Trojanized binaries and libraries: modified service binaries, LD_PRELOAD//etc/ld.so.preload hijacks, and tampered shared objects that load into legitimate processes.

Cross-reference these against a known-good baseline, file MAC times, and package-manager integrity checks.

Why the distractors are wrong

• Browser history is user activity, not a persistence mechanism. It might give context, but it won't re-launch the attacker's code.
• Wallpaper settings are cosmetic and irrelevant to server persistence.
• "A reboot clears persistence" is exactly backwards. The defining property of persistence is that it survives a reboot — cron, systemd, and rc files all re-trigger on boot or login. Rebooting just kicks off the malicious code again and may destroy volatile evidence in the process.

What the interviewer is probing

Whether you have a real mental map of Linux autostart surfaces and approach a compromised host systematically, rather than poking at whatever GUI artifact is handy. The reboot distractor specifically tests whether you understand what "persistence" even means.