Linux Internals interview questions

No. The whole 127.0.0.0/8 range is reserved for loopback, so 127.0.0.2, 127.1.1.1, and so on all resolve to the local host. This matters for SSRF and allow-list bypasses — an attacker may use 127.0.0.2 or other encodings to dodge a naive 'block 127.0.0.1' check — and for binding multiple local services. (In IPv6, loopback is the single address ::1.)

A gap in local logs during an incident can mean cleared or tampered logs, a common anti-forensics step, so don't treat absence of logs as absence of activity. Cross-check against centralized/forwarded logs, EDR and network data that the attacker likely couldn't alter, and record the integrity gap as a finding. Assuming the server was idle trusts evidence the attacker may control, treating the gap as proof nothing happened is exactly the conclusion they want, and deleting more logs destroys what's left. Corroborate with independent telemetry instead.

Linux persistence hides in scheduled execution and startup paths: cron and systemd timers/units, added SSH authorized_keys, modified shell rc files and profile scripts, and trojanized service binaries or preloaded libraries. Check those systematically. Browser history and wallpaper settings aren't persistence mechanisms, and rebooting won't remove anything that re-establishes itself on boot — it just restarts it. The whole point of persistence is to survive reboots, so a reboot proves nothing.

A SUID-root binary executes with root privileges, and if it's world-writable an attacker can replace or modify it to run arbitrary code as root — a classic local privilege-escalation path. Remove the SUID bit, correct ownership and permissions, and investigate how the misconfiguration appeared, since it may indicate compromise. Encrypting the file leaves the executable path intact, and renaming it just moves the problem without removing the escalation. Neither addresses the root cause.

Order of volatility ranks evidence by how fast it vanishes, so you collect the most fragile first. Roughly: CPU registers/cache, then RAM and running state (processes, network connections, ARP), then temporary/swap files, then disk, then remote logging and monitoring data, and finally archival media and backups. You also work on forensic copies, hash them, and keep a chain of custody so evidence stays admissible.

On Windows, local account hashes (NTLM) live in the SAM hive under C:\Windows\System32\config\SAM, protected while the OS runs; live credentials sit in LSASS memory, and domain hashes are in NTDS.dit on a domain controller. On Linux, hashes are in /etc/shadow (readable only by root), while /etc/passwd holds account metadata. Attackers steal these to crack passwords offline or pass-the-hash.

Start with a full TCP port scan, then enumerate every open service in depth — banners, versions, default creds, anonymous access, and web content — before touching any exploit. Most boxes fall to thorough enumeration, not clever exploits, which is the core of the 'try harder' mindset.

Enumerate systematically: check sudo -l, SUID/SGID binaries, cron jobs, the kernel and OS version, writable files in privileged paths, capabilities, and stored credentials. Tools like LinPEAS automate the sweep, but you still verify each finding against GTFOBins or a known technique.

Map the exact service and version, search Exploit-DB or searchsploit for a matching PoC, then read the code line by line before running it — fix the target IP, port, and reverse-shell address, regenerate any shellcode, and understand what it does so it cannot backfire on you.

Spawn a pseudo-terminal (commonly python -c 'import pty; pty.spawn("/bin/bash")'), background it with Ctrl-Z, run stty raw -echo on your local side, foreground it, and reset TERM and the rows/columns. That gives you a full TTY with job control, tab completion, and working editors.

Enumerate first: current privileges, sudo rights, SUID/SGID binaries, cron jobs, writable files in PATH, kernel version, and stored credentials. Then exploit the easiest reliable path — often a misconfigured sudo rule or a SUID GTFOBin — before reaching for a kernel exploit.

A bind shell opens a listening port on the target and waits for you to connect to it. A reverse shell makes the target connect outbound to a listener you control. Reverse shells usually win because outbound traffic bypasses inbound firewall rules and NAT.

Reduce attack surface (remove unused packages/services), enforce key-only SSH with no root login, keep the system patched, run a default-deny firewall exposing only needed ports, apply least privilege via sudo and file permissions, enable auditd and centralized logging, and add integrity monitoring plus MAC like SELinux or AppArmor.