Interactive Linux Host Triage Exercise

This destroys the most valuable evidence on the host. As Section 0.3 covered, a reboot wipes memory, running processes, and live network state, the exact layers that would show you what is connecting out and why. You never reboot a host you intend to investigate until volatile evidence is captured. Severing the connection can come later, after you have seen it.

This is the volatility-aware first move. The alert is about a network connection, which is top-layer, fast-decaying evidence (Section 0.3), so you capture it before it closes. Reading the connections tied to their owning processes (Section 0.4) tells you immediately which process is beaconing out and where, the single most useful fact at this moment.

The logs matter, but this is analysis, and analysis can wait while volatile evidence cannot. Starting in the on-disk logs while a live malicious connection is open lets that connection close before you ever capture it. Collect the fast-decaying evidence first (Section 0.3), then read the durable logs.

This is eradication before analysis, the anti-pattern from Section 0.7. You do not yet know what is here, deleting files destroys evidence, alerts an active attacker, and almost certainly misses footholds you have not found. You investigate fully before you remove anything.

A web server receives inbound connections to serve pages; a process under its account making persistent outbound connections to an unknown external address is backwards from that role (Section 0.2). The account being www-data is not reassuring here, it is the tell that the web application was the entry point.

Restarting the service kills the very process you need to examine and the connection you need to trace, destroying volatile evidence, and assumes a benign cause you have not established. The www-data ownership points to compromise through the web application, not a software bug to be cleared by a restart.

Correct. A web account beaconing out points to the web application as the way in (Section 0.2). Reading /proc/<pid>/exe, cmdline, and the parent process (Section 0.4) tells you what is actually running, whether the binary was deleted, and what spawned it, confirming the compromise and giving you the next leads.

The opposite: www-data is an unprivileged service account, not root. At this point the attacker has code execution as a low-privileged user (Section 0.2, Stage 1). Whether they have escalated to root is a separate question you answer by checking the authentication log and process details, not one the www-data ownership settles.

Correct. The foothold is one stage; the questions that govern the response are how far it went (Section 0.8, scope accuracy) and whether they are still able to return. You check the authentication log for escalation (Section 0.5), the first-look persistence locations (Section 0.6), and any outbound connections to internal hosts that would signal lateral movement. Scope before containment.

This is stopping at the first finding, the anti-pattern from Sections 0.2 and 0.6. The beaconing process is the foothold; the escalation, persistence, and any lateral movement are still unexamined. Removing one process while leaving a planted cron job or SSH key means the attacker walks straight back in.

Resource usage might matter for a cryptominer's business impact, but it is not what governs the response to a confirmed intrusion. The decisive unknowns are how far the attacker got and whether they can return (Section 0.8), not how much CPU the process consumes.

As Section 0.1 covered, living-off-the-land intrusions often involve no malware an AV signature would match, and the binary here was already deleted. Chasing a signature is the wrong instinct; the response is governed by scope and persistence, which you establish from the host's own evidence.