A root-owned systemd timer runs a script hourly on a Linux server — which ATT&CK tactic is it?

## The artefact A timer plus its service unit, in the root-owned unit directory. There is nothing exotic here; it is what a scheduled job on a Linux server fleet looks like. ## Three accounts of the same bytes **Account one — Persistence.** An operator holds one identity's worth of access: a valid interactive account, obtained some time earlier. Reboots and session timeouts cost them that foothold. A timer in the root unit path re-establishes execution on its own schedule and after every boot, with no need to authenticate again. What the act bought was *continuity of access*. Tactic: Persistence. **Account two — Privilege Escalation.** The same file, written by a principal that is not root — or, more commonly, the unit is untouched and the operator simply rewrites `/opt/ops/bin/rollup.sh`, because that path is writable by a deployment account they control. The unit runs it as root. What the act bought was *a context with rights they did not hold*. Tactic: Privilege Escalation. Nothing about durability was the point; the schedule is merely the delivery mechanism. **Account three — no tactic.** An administrator wrote it, during a maintenance window, to roll up metrics hourly. There is no adversary, so there is no goal to name and no column applies. This case is the one people forget exists, and it is the majority case on any real fleet. ## Why the artefact cannot settle it A tactic names the adversary's goal for an action. Goals are facts about a plan. Files record actions. No amount of care reading the file recovers the plan, because the plan was never written into it. The unit is the same object in all three accounts down to the byte. One trap sits right in the syntax. `Persistent=true` in a `[Timer]` section is a **scheduling catch-up option**: if the machine was off when the timer should have fired, run the job at next boot. It is not the Persistence tactic, it has no adversarial meaning, and it appears on a great many ordinary units. A candidate who points at that keyword as evidence has demonstrated exactly the error the question is testing for. ## What actually settles it The classifying question is *what did this buy that the writer did not already have?* Applied here: | Fact you would need | What it decides | |---|---| | Which account wrote the unit, and what rights it already held | root writing a root unit gains nothing, so Privilege Escalation is out | | Whether the invoked script or its directory is writable by a non-root principal | if yes, a root-executed path is reachable from a lower context, which is the escalation | | Whether the operator already had durable access by other means | if they did, continuity was not what this bought, so Persistence is out | | Whether the job was requested, and by whom | a job with an owner and a purpose is not an adversary's act at all | Notice that none of those facts is in the file. They are facts about the estate and about the sequence of events around the file. ## Why this matters beyond the classification The classification drives the remedy, and the two goals have completely different remedies. Removing the Persistence goal means removing the ability to place *any* root-scheduled work, because the goal has many carriers and blocking one moves the operator to the next. Removing the Privilege Escalation goal means ensuring nothing a lower-privileged principal can write is executed in a root context — a narrower fix with no substitute available to the operator. Assign the wrong tactic and you will implement the wrong one of those two, then report the problem as solved. ## The wrong answer *'It is Persistence — a timer survives reboot, so it is a persistence technique.'* Two errors are stacked in one sentence: reading the goal off the mechanism, and assuming a technique lives in one column. `T1053` sits in three columns precisely because the same scheduling primitive serves three different goals, and the third account above shows it can serve none.