Your EDR console records a token-authenticated agent uninstall on a production Linux host. How do you decide whether an adversary did it?

## What tamper protection actually buys Tamper protection is the set of controls that stop a local administrator from casually turning the sensor off: the service cannot be stopped, the driver or kernel module cannot be unloaded, the files cannot be deleted, and uninstall requires a secret, typically a per-host or per-tenant token issued by the management console, or an action performed in the console itself. What it does not stop is worth naming precisely, because interviewers probe it: - Someone who holds the token, or who can act in the console, can remove the sensor cleanly and the removal will look authenticated. - It does not stop the layer beneath: booting alternative media, mounting the disk from the hypervisor, or restoring a snapshot. - It does not stop starving the sensor of connectivity by blocking its cloud endpoints at the host firewall, DNS or egress proxy, which leaves an installed but mute agent. - It does not extend to hosts that never had an agent. So the uninstall record is a strong signal precisely because it is rare and privileged, and a weak proof of authorisation because a secret can be stolen. ## Where the token could have come from Work this list explicitly: - A console administrator account, which means the identity story moves to the console's own authentication (was MFA used, from where, at what hour). - An API key or service credential held by automation: MDM, configuration management, or an imaging pipeline that removes agents as a build step. These keys sit in repositories and CI variables and are a favourite target. - An exported per-host token sitting in a spreadsheet, wiki page or ticket from the last time a desktop engineer needed one. - Local recovery of a token cached on the host, if the product stores one. Each of those is a different incident with a different blast radius. A stolen console API key is worse than a single host's token, because it can remove agents everywhere. ## Evidence that outlives the agent The sensor's own telemetry stops at removal, and the last minutes before it are the most valuable data you have: the process tree that spawned the uninstaller, the parent shell, the session it came from. Pull that from the console before anything else, because retention and the removed host's record may not be kept as long as you assume. Off the sensor, on a Linux host: - `auditd` records syscalls according to its rules, and `execve` is the execution record. If the rules were in place, the uninstall command line is there with its uid, session and parent. - Package-manager history (`dpkg`, `rpm`, `yum` or `dnf` transaction logs) records removal of the sensor package with a timestamp. - Service manager records show the unit stopping and being removed. - `sudo` and authentication logs show who obtained privilege and from which source address; a successful authentication proves a credential was accepted, not that the named human was present. - Shell history is suggestive and trivially forged; treat it as a lead, never as proof. On a Windows host the equivalents are Service Control Manager entries in the System log for service installation and state changes, process-creation events (which carry the command line only if audit policy was configured to include it), the Application log's installer entries, and event ID 1102 in the Security log if someone cleared it, which is itself a finding. ## The order of your own moves The common mistake is to reinstall the agent immediately to "restore visibility". That is the wrong first move: reinstalling writes to the host, changes state you may want, and gives you a sensor with no history, which then reports a comfortable green while telling you nothing about the previous month. Sequence it instead: 1. Decide containment using something that does not depend on the agent: a switch port, a NAC quarantine, a cloud security group, or a firewall rule. Your usual one-click isolate button went away with the sensor. 2. Preserve what is volatile before it ages out, respecting the order of volatility: memory and running network state before disk. A memory image has no single point in time, so record when you started and finished. 3. Establish authorisation: change record, ticket, the console audit trail, and a direct conversation with the named operator rather than an assumption about them. 4. Only then rebuild or reinstall, and expect the fresh agent to be blind to everything before it. ## The benign ending is common, and it is not a non-event Most of these turn out to be a desktop engineer reimaging a machine, an automation job doing exactly what it was written to do, or a migration between endpoint products where somebody removed the old sensor first. That is a benign true positive: the detection was correct, the activity was real, and the conclusion is not malicious. The right output is still a change to the process, because an uninstall path that nobody can attribute within minutes is an uninstall path an adversary can use with confidence.