skip to content

What can a live host's socket table prove that a disk image of the same host never can?

level: middleimportance: should knowfreq 56%

answer

  1. kernel state, not a file on disk
  2. the join between network and host views
  3. peer address plus owning process
  4. no payload, no volume, no attribution
  5. layer 2 only reaches the gateway

basics

~20 s

It proves which peer address a running process was connected to at the moment of capture, and in which direction the connection opened. A disk image never holds the kernel's connection table, which dies with the kernel.

solid answer

~50 s

The socket table is the kernel's list of current connections, and captured with owning-process information it links a peer address and port to a PID, its binary and its command line. That mapping lives only while the connection is open: it is not journaled, not written to disk, and cannot be reconstructed from an image taken afterwards. On a Linux server carrying an in-memory-only implant, it is often the only proof this host talked to that peer at all. What it does not give you is content. An ESTABLISHED entry to an address on port 443 proves a socket was open between that process and that address at capture time; it does not prove data was exfiltrated, and it does not identify who operates the address, since a CDN edge fronts thousands of tenants. It is the strongest answer to which process and which peer, and no answer at all to what crossed it.

code

text · 10 lines
text
# socket table (TCP, with owning process)
State  Recv-Q Send-Q  Local Address:Port    Peer Address:Port    Process
ESTAB  0      0       10.4.12.30:52344      203.0.113.45:443     pid=2417 ("appsvc")
ESTAB  0      0       10.4.12.30:22         10.4.9.8:60122       pid=1180 ("sshd")
LISTEN 0      128     0.0.0.0:8080          0.0.0.0:*            pid=2417 ("appsvc")
...
# neighbour (ARP) cache
10.4.9.8    dev eth0 lladdr 00:16:3e:7a:2c:91 REACHABLE
10.4.12.1   dev eth0 lladdr aa:bb:cc:00:11:22 REACHABLE   # default gateway
...

go deeper

for a junior

Know that connections live in kernel memory and are not written anywhere on disk, so a socket entry disappears when the connection closes or the machine restarts.

for a middle

Explain the fields and what each supports: local versus peer port for direction, the owning process for the host-to-network join, and why none of it implies content or volume.

for a senior

Show that you capture it before anything that could drop the session, and that you state conclusions in the right direction: a connection existed, not that data left or that the peer is the adversary.

for a principal

Be ready to argue what standing telemetry would have made this snapshot unnecessary on a tier with no sensor, and what you accept when funding that tier is refused.

## The artefact Every open TCP connection on a running host exists as a kernel structure: a local address and port, a peer address and port, a connection state, send and receive queue depths, and a link back to the process holding the file descriptor. Captured live, that gives you a five-tuple bound to a PID, which in turn is bound to an executable path, a command line, a parent process and a start time. None of it is on disk. The kernel does not journal its connection table, and no ordinary Linux system writes a record when a socket opens or closes. So an image of the same host, taken half an hour later or after a reboot, contains the binary, the service unit that started it, and whatever the audit daemon happened to record about the execution, but contains no representation of the connection. ## What it answers that nothing else does On a Linux application-server tier with no endpoint sensor deployed, this matters more than it sounds. There is no agent keeping a rolling process-to-network history. Flow records from the network may show that traffic went from that host's address to a peer, but flow records identify a host, not a process; they cannot tell you which of the eleven processes on the box owned the conversation. The socket table is the join between the network view and the host view, and it exists for exactly as long as the connection does. So the questions it uniquely answers are: - Which peer address and port is this host connected to right now? - Which process, started from which path, with which command line, holds that connection? - Was the connection opened outbound by this host, or accepted inbound? The local port tells you: a connection whose local side is an ephemeral high port and whose peer side is 443 was opened outbound; one whose local side is a listening service port was accepted. - What else is that same process holding open, and is it listening on anything? ## What it does not prove, and this is the part interviews turn on **It carries no payload.** An ESTABLISHED socket is a statement about kernel state, not about content. It does not show a single byte that crossed the connection. Even the queue depths only say how much is buffered at this instant, not how much has flowed. If you want volume you need flow records; if you want content you need a capture, and over TLS you would still only see the handshake metadata. **The peer address is not the adversary.** Command and control fronted through a large content-delivery network resolves to an edge address shared by an enormous number of legitimate tenants. Enriching that address with ownership tells you who runs the edge, not who rented it. Treating the peer address as attribution is a classic wrong turn. **An open socket is not a verdict.** A long-lived outbound TLS connection from an application server is what most application servers do all day. The socket table gives you the fact; the judgment about whether the process holding it belongs there comes from elsewhere. **Layer 2 stops at the gateway.** The neighbour (ARP) cache is often captured alongside the socket table and is genuinely useful, but only for on-link peers. For a remote peer, the hardware address you will find in the cache belongs to your default gateway, because that is the next hop. It is not the peer's, and there is no sense in which the cache could hold the peer's hardware address across a routed path. ## Consequences for how you capture Because the mapping dies with the connection, two ordinary events destroy it without anyone touching the host: the process exits, or the peer closes the connection. A third destroys it deliberately: rebooting, powering off, or in some environments isolating the host so the session drops. That is why the socket table, with owning-process information, is among the first things a responder takes on a host believed to be actively used by an intruder, ahead of anything on disk. And because it is a single point-in-time snapshot, one capture shows you one instant. Taking it twice, a few minutes apart, is cheap and turns a snapshot into a small amount of behaviour: a connection that reappears to the same peer after being torn down looks different from one that was open once.

  • In that capture, what does the neighbour cache tell you about the peer at 203.0.113.45?
    Nothing about that peer's hardware address. It is off-link, so traffic to it goes via the default gateway and the only hardware address involved is the gateway's. The cache is informative for the on-link peer at 10.4.9.8, whose hardware address may help you identify the machine that opened the inbound session.
  • How do you tell from a socket entry whether the connection was opened outbound or accepted inbound?
    Compare the local port to the service ports the process listens on. An ephemeral local port against a well-known peer port means the host opened it; a local well-known port with an ephemeral peer port means the host accepted it. That distinction matters, because an implant that dials out defeats inbound filtering entirely.
  • The connection dropped while you were preparing to capture. What is still recoverable?
    The process, if it is still running: its path, command line, parent and remaining descriptors. The peer address is gone unless something else recorded it, such as flow records from the network or a proxy, and those identify the host rather than the process. That is the whole argument for taking the socket table first.

saying these in an interview costs you the question

  • Claims an established socket proves data was exfiltrated
  • Treats the peer IP as identifying the adversary
  • Expects to recover the connection table from a disk image
  • Says the ARP cache holds the remote peer's MAC address
  • Assumes any long-lived outbound TLS connection is malicious

context

resolving links…