How do you sweep 300 Linux servers for persistence when a third have no EDR agent?

## The problem: partial sensor coverage during an eradication sweep You are inside an incident. You know the mechanisms this intruder plants because you recovered them from the hosts you did investigate. You now need to answer a fleet-wide question — where else does this exist — across 300 servers, a third of which have no endpoint agent to query. Waiting to install agents everywhere is not an answer while an intruder still holds access. ## The substitute source: declared state A configuration-managed fleet carries a second, independent description of what each host should look like. A Puppet no-op run or an Ansible check-mode run with diff reports, per resource, where the machine differs from the catalogue. Package-manager verification adds a second baseline: files installed from packages have known hashes, sizes, modes and owners recorded in the package database, and verification reports every file that no longer matches. Neither source needs security tooling on the host. That is the point — during eradication you are looking for a *difference from intended state*, and configuration management is a machine-readable statement of intended state that already exists. ## What you sweep for Translate the mechanisms you recovered into locations, and sweep for the class rather than the exact string, because a competent adversary varies file names: - `~/.ssh/authorized_keys` for **every** account with a shell, including root and service accounts, and the `AuthorizedKeysFile` path if `sshd_config` was changed to point somewhere else. - `/etc/systemd/system` and the user unit directories: a `.timer` unit paired with a `.service` unit gives an adversary cron-like execution that looks like ordinary platform plumbing. - `/etc/cron.d`, `/etc/cron.*` and per-user crontabs. - Package hooks: a drop-in under `/etc/apt/apt.conf.d/` carrying a `DPkg::Post-Invoke` command runs on every package operation on that host, which is a durable and low-traffic trigger. - `/etc/ld.so.preload` and additions to PAM configuration, both of which give execution inside legitimate processes. - Shell profile and rc files for accounts an operator actually logs into. On the Windows jump host in the same estate the equivalent lives somewhere a file sweep cannot reach: a WMI event subscription is a `__EventFilter`, a consumer and a `__FilterToConsumerBinding` registered in the CIM repository under `root\subscription`. You enumerate that namespace; no file diff will show it. ## Triaging the output Drift reports are noisy — operators make emergency changes, and every fleet has them. Two filters cut the volume fast. First, rarity: on hosts built from one image and one catalogue, an artefact present on one host and absent on the other 299 identical ones deserves attention that a difference present everywhere does not. Second, the mechanism class: an unexpected file in `/var/log` is drift, while an unexpected timer unit or a new key in `authorized_keys` is drift in a location whose only purpose is execution or access. ## What this method structurally cannot see Say these before an interviewer asks, because the honest boundary is what the question is testing: - **Unmanaged paths.** Configuration management reports on resources in the catalogue. A file dropped into a directory the tool does not manage, or into a managed directory without recursive purging enabled, produces no drift at all. - **Content it does not check byte-for-byte.** A resource declared only to exist can be modified without the tool noticing. - **The agent itself.** You are asking software running on a possibly-compromised host to describe that host. Root-level access is enough to make the answer whatever the adversary wants; the same is true of package verification, since the package database is a file on the same disk. - **Anything not on disk.** An implant living only in the memory of a running process, or persistence achieved through an interface the tool does not model — a scheduler, an orchestrator, an identity provider — leaves no file to differ. ## Hosts with no report are not clean hosts The most dangerous line in a sweep is the summary. If 113 hosts report zero differences and 187 produce no report because their agent has not checked in for two weeks, you have swept 113 hosts. Those 187 go on the unswept list, get collected out of band, and are treated as unknown in the eradication decision. An agent that stopped reporting during the intrusion window is itself a finding worth chasing rather than a scheduling annoyance.