# Persistence Mechanism Installation (EDR Graph)

- **Severity:** High
- **Signature ID:** `d12c1b8c-4ee7-5548-947b-a1627bdc98dc-p`
- **MITRE ATLAS:** AML.T0053 (AI Agent Tool Invocation), AML.T0050 (Command and Scripting Interpreter)
- **OWASP:** ASI07 (Unsafe Autonomous Code Execution), LLM06 (Excessive Agency)

## Summary

This detection watches for files being written to the specific system locations that let a program run automatically, such as at startup or on a schedule. Attackers use these locations to make sure their malicious code survives a reboot or keeps running without further action.

## How the attack works

An attacker who has already gained code execution on a machine wants their access to survive a reboot or logout. To do this they write a file into a location the operating system automatically executes: a cron job, a launchd plist (macOS), a systemd unit, or a shell profile script like .bashrc or .profile. The rule watches low-level file write activity captured by an EDR or syscall monitor and flags any write into these known persistence paths. It runs on a short interval (every 30 seconds) so the write is caught close to when it happens.

## Why it matters

If missed, an attacker keeps a foothold on the machine indefinitely, surviving reboots, credential rotations, and casual cleanup, which extends the time they have to move laterally or exfiltrate data.

## What you can do

- Restrict write access to cron directories, systemd unit paths, launchd LaunchAgents/LaunchDaemons folders, and shell profile files to admin accounts only.
- Review any unexpected new entries in crontabs, systemd services, launchd plists, or shell startup files as soon as they are flagged.
- Baseline what persistence entries are expected on your systems so new or unauthorized ones stand out.
- Treat this as one signal among others — it only detects the file write step, not how the attacker got initial access or what they did afterward.

---
Source: https://www.netzilo.com/threats/persistence-periodic