Persistence Installation

Most agent compromise is ephemeral — it lasts only as long as the current session — so an attacker who can drive an agent's shell, file-write, or install tools will convert that transient access into durable footholds using ordinary OS persistence primitives (cron, systemd/init services, `authorized_keys`, shell rc files, scheduled tasks, browser extensions). The trust boundary violated is that the agent runs with enough host privilege to modify boot/login/scheduling configuration, and there is typically no integrity gate that distinguishes a legitimate setup action from planting a backdoor. Because each of these operations is individually a normal admin task, they do not look anomalous in isolation; the agent simply does what its tools allow.

• File-integrity monitoring on persistence locations: crontab, systemd units, authorized_keys, shell rc files, scheduled tasks, browser extension dirs
• Alert on new local user/account creation and privilege grants performed by an automated session
• Detect new outbound long-lived connections (reverse shells, periodic beacons) from agent hosts
• Flag any agent write to boot/login/scheduling configuration as high severity

Persistence is usually preceded by T11-AT-002 (code/shell execution) or T11-AT-001 (drive-by download) for the initial foothold and by T11-AT-008 (harvested keys feeding the authorized_keys implant). It is the durability layer that keeps T11-AT-010 lateral movement and T11-AT-011 exfiltration alive after the entry vector is closed, and a boot service / hot-script backdoor (T11-AP-009E/T11-AP-009J) overlaps T11-AT-013 supply chain and T11-AT-015 replication when the persisted artifact spreads.