When an EDR auto-isolates a host on a malware verdict, what does isolation actually stop and what keeps running?
answer
- network quarantine, not power-off
- one channel stays open
- containment is not eradication
- stolen credentials still work elsewhere
- the adversary sees the silence
basics
~20 sIsolation blocks the host's network traffic except the EDR agent's own channel to its console. The machine stays powered on, its processes keep running, and any credentials already stolen from it still work everywhere else.
solid answer
~50 sEDR containment is a network action applied at the host: the agent drops traffic in both directions except a narrow allow-list, almost always its own link back to the management console. So the beacon dies, lateral movement out of that host stops, and an exfiltration in flight from it stops. What does not stop is the machine itself. Processes keep running, a local user at the keyboard keeps working, and persistence - run keys, a service, a scheduled task, an implanted SSH key - is untouched, because containment stops damage while eradication removes the mechanism. Nothing the adversary already took is affected: passwords, Kerberos tickets, session cookies and refresh tokens work from any other machine. And it is loud - the operator sees the host go dark, and you lose your own live view of what they do next.
go deeper
Be ready to state plainly that isolation is a network block applied by the agent, that the machine keeps running, and that the EDR's own channel stays open so responders can still work on the host.
Explain the mechanics: what is on the allow-list, why persistence and local processes are untouched, and why containment and eradication are separate phases rather than one action.
Show the judgment: name what isolation costs you - the outage, the tipped-off adversary, the loss of live network visibility - and say what identity actions have to accompany it before you call anything contained.
Own the exchange rate. Argue when machine-speed containment is worth an unread verdict and an outage, and make sure the organisation knows it has bought a stopped beacon, not a removed intruder.
### The action, precisely Every major EDR ships a containment action called something like *isolate*, *contain* or *network quarantine*. Mechanically it is a local network policy pushed down to the agent: traffic is dropped in both directions with a narrow allow-list, and that allow-list nearly always contains the agent's own channel to its management console (plus whatever name resolution that channel needs). Most products let you add exceptions, such as a forensic collector or a jump host. Everything below follows from that one sentence. It is a **network** action, enforced **on the host**, and it leaves the host **running**. ### What stops - **The command-and-control channel.** The implant's beacon fails. - **Lateral movement out of that host** - SMB, WinRM, RDP, SSH to its neighbours. - **Exfiltration in progress from that host.** - **Everything legitimate the host was doing.** A build agent stops building; a laptop stops presenting; a database server stops serving. When containment is fired by a rule rather than by a person, this cost is paid before anyone has read the alert. ### What keeps running - **The machine.** Isolation is not a kill. Processes continue, scheduled tasks fire, an encryptor keeps encrypting local disk. If your rule fired on ransomware, network isolation does not save the local files. - **The user, locally.** Somebody at the keyboard can still work, delete things, or reboot the box. That is why contacting the person is part of containment rather than an afterthought. - **Persistence.** Run keys, services, scheduled tasks, a WMI event subscription, an added SSH key - all still there, all armed for the moment isolation is lifted. **Containment stops damage; eradication removes the mechanism.** They are different phases, and performing the first does not perform the second. - **Everything already taken.** Credentials, Kerberos tickets, browser session cookies, OAuth refresh tokens and copied data have left the building and are usable from anywhere. A host action cannot undo an identity compromise; only identity actions can, and even those need explicit session and token revocation rather than a password change alone. - **Other footholds.** Isolation is scoped to one host. If the adversary sits on three, you contained one and told them about it. ### The two costs juniors miss First, **you tip the adversary off**. A disappearing host is unambiguous. They may burn the access you found and fall back to an implant on a host you have not found, or trigger destructive behaviour on the way out. Second, **you freeze your own understanding along with the damage**. Live network observation of that host ends at the moment of isolation. You keep host telemetry over the agent channel, but the question you most want answered - where were they going next - stops generating evidence. ### Why isolate rather than power off The order of volatility ranks CPU registers and cache above RAM, RAM above network state, and all of those above disk. Powering the host off destroys everything above disk. Isolation keeps the host alive so that a memory image and live process state can still be collected over the agent's channel - noting that a memory image of a running machine has no single point in time, since it is captured while the system continues to change. ### Confirming it actually took effect The response platform's action log records that isolation was requested; the agent still checking in from the isolated host shows the policy is applied and the management channel survived. Absence of that host's flow records at the network egress point corroborates it, but only weakly: a flow record proves bytes moved, and its absence can equally mean a broken collector. ### Why this matters for automated containment When a rule fires this action with no human in the loop, the whole exchange is made at machine speed: you buy a stopped beacon and pay with an outage, a tipped-off adversary and a narrowed view - on the strength of a verdict nobody has read yet. Knowing exactly what the action does and does not buy is what makes it possible to argue about which hosts should be exposed to it.
- Does isolating the host stop the adversary using credentials they harvested on it?No. Passwords, Kerberos tickets, session cookies and OAuth refresh tokens taken from that host are replayed from anywhere else, including from outside your network into cloud and SaaS. Only identity actions help, and they must include explicit session and token revocation - a password reset on its own leaves an issued ticket or refresh token working until it expires.
- Why not power the machine off instead of isolating it?Powering off destroys everything above disk in the order of volatility - registers, cache, RAM and network state - which is where injected code, decrypted payloads and live connections live. It also does not stop credential reuse elsewhere. Isolation keeps the host alive so memory and process state can still be collected over the agent channel.
- How do you confirm the isolation actually applied?Two positives and one weak corroboration: the action log entry showing the request, and the agent still checking in from the host, which proves the policy landed and the management channel survived. The host's flow records disappearing at the egress point supports it, but absence of flow records can equally mean a broken collector.
It is like cutting the phone line to a room rather than clearing the room. Whoever is inside is still inside, still busy, and now knows something is wrong.
saying these in an interview costs you the question
- Says isolation removes the malware from the host
- Thinks isolation logs the user out or disables their account
- Assumes the host is powered off, so memory evidence is gone
- Believes containment ends the incident
- Claims the adversary cannot tell the host was contained