What does an EDR stream show when an intruder runs discovery inside a long-lived allow-listed process?

## The scenario A long-lived, allow-listed service process on a Linux server fleet — a web daemon, an application server, a job runner — is where an intruder is operating. They are not dropping tooling. They are enumerating the host, reading what the process can already reach, and reaching out. Nothing lands on disk. A candidate who has only ever triaged malware alerts assumes there is nothing to look at. There is. ## Surface 1 — module and shared-object loads The sensor records objects mapped into a process's address space. On Linux that means shared objects: the ones loaded at start-up, and any loaded later. The signal is not the load itself — every process maps libraries — it is a **long-lived process mapping something it has never mapped before**, especially from a world-writable path, and especially at a time nothing was deployed. What a load event proves is narrow and you must say so: the sensor observed that object mapped into that process. It does not prove what the code did, and legitimate loaders map objects for entirely ordinary reasons. On its own it is an artefact. Next to a burst of children and three connections in the same second, it is the start of a chain. ## Surface 2 — sub-second children with their command lines Discovery has to ask the kernel questions, and the easy way is to spawn something. Those children may live for forty milliseconds. They are invisible to anyone looking at the box afterwards, and they never appear in a process listing that a human runs. They are in the EDR stream anyway, because execution events are recorded at exec, with the argument vector as it was at exec. The part people get wrong: the children's parent has often already exited by the time you look, and they assume that breaks the tree. It does not. The sensor records the parent's identity **at the child's creation** and stores the edge. The graph is written down, not derived later from live process state. On the host itself the same orphaned child would show a parent of `1` after reparenting, and PIDs get recycled; the sensor's own process identifiers do not. Read the command lines as a set, not one at a time. Account, group and sudo enumeration, host and network identity, mounted filesystems, credential file reads — several of those inside two seconds, from a service account that has never spawned a shell in the retained window, is a far stronger statement than any single line. ## Surface 3 — outbound connection events The sensor ties sockets to the process that opened them. That gives you something a passive network view cannot: **process attribution**. You know it was that daemon, not merely that host. And the direction of the claim matters. A connection event proves a socket was opened to that endpoint at that time. It does not prove what was sent — the event carries no payload — so what you actually reason over is destination, timing, regularity and, where the sensor records it, volume. "Bytes moved" and "data was stolen" are different claims and only the first is in the record. ## What is missing, and saying so No file write. No new executable. No hash to look up, no sample to submit, no persistence artefact yet. If your instinct is to conclude "nothing happened" from that absence, you have inverted the evidence: the absence of a disk artefact is evidence about **how** they worked, not about **whether** they worked. The genuine blind area is different and worth naming aloud: activity that stays inside the process — reading memory it already holds, using a connection it already owns, without exec, without a new mapping — produces no sensor event. The stream shows you the boundary crossings. It does not show you the inside of a process. ## Putting it together A defensible reading is a chain with times: object mapped at T; four short-lived children at T+0.8s with enumeration command lines; outbound connection from the same process at T+4s. Each link individually is weak; the sequence, the process, and the fact that this daemon has done none of it before are the argument. State each link's limit as you go, and mark the ones you could not establish rather than filling them in.