Long Duration Operations

Operations

A multi-month engagement is an access-management problem before it is an offensive one. Every mechanism that keeps access alive outlives the person who deployed it, so the work that separates a professional long-duration operation from an incident is the register that says what was deployed, who approved it, and how it comes out.

Persistence needs its own initialled authorization

The base rules of engagement authorize activity inside a window; they do not authorize persistence. Each mechanism needs separately initialled approval naming the host, the technique, the approving executive, and the removal procedure — and a documented removal step that a second operator can execute without you. An engagement that ends with an implant nobody can find is indistinguishable from a real intrusion, and the client has to treat it as one.

Persistence Authorization and Removal Runbook

Agree the removal procedure before the first mechanism is deployed, not at the end. The register below is the artefact most engagements are missing: it turns "we think we removed everything" into a checklist with an owner per line, and it is what the client's defenders will cross-reference when they review telemetry after the debrief.

persistence-register.yaml

# Persistence register - approved mechanisms only

approval:
  annex_id: RT-2026-014-P
  initialled_by: primary authoriser (CISO)      # not the engagement lead
  countersigned_by: client security owner
  approved_window: 2026-02-01 .. 2026-05-31
  clause: "no mechanism survives the closing window"

mechanisms:
  - id: P-01
    host: WKS-FIN-014 (asset list entry A-118)
    technique: scheduled task, user context, daily 09:10 UTC
    purpose: re-entry after documented host rebuild
    detection_expected: T1053.005 telemetry, Sysmon 1 + 11
    removal:
      command: schtasks /delete /tn "OneDriveSyncHelper" /f
      verify: schtasks /query /tn "OneDriveSyncHelper"  ->  not found
      evidence: command output hash, screenshot, UTC timestamp
    rollback_owner: operator-2 (second operator, not the deployer)

  - id: P-02
    host: APP-SRV-03 (asset list entry A-204)
    technique: service binary, disabled until re-entry needed
    removal: sc delete <service>, then confirm the binary path is empty
    rollback_owner: operator-1

closeout:
  - every P-xx ticked off with evidence attached
  - client security owner signs the removal certificate
  - telemetry window reviewed for anything the register does not explain
  - any surviving artefact escalated to the stop authority immediately

Before deployment

Mechanism named in the initialled annex, with host and asset-list ID.
Removal command written down and tested on a lab host.
Second operator assigned as rollback owner.
Expected detection written next to the technique, so the debrief can score it.
Data the mechanism touches limited to approved test accounts and canary records.

At closeout

Every register line removed with evidence, not by assertion.
Removal certificate signed by the client security owner.
Telemetry reviewed for artefacts the register cannot explain.
Test accounts, domains, and certificates torn down with the infrastructure annex.
Anything unresolved escalated to stop authority the same day.

Persistence Strategies and What They Cost

Redundancy is the usual argument for several mechanisms per host. It is also the reason engagements lose track of what they left behind, so treat each mechanism as a cost: one more thing to remove, one more thing to explain in the report, one more artefact the defenders have to keep hunting after you leave.

Multiple beacons: several command channels with different transports, each recorded with its own register line and kill switch.
Diversified mechanisms: a scheduled task, a service, and a user-level startup entry behave differently under EDR and under a rebuild — register all three, or deploy one and accept the recovery cost.
Backup access: a secondary approved test account or a documented credential path is easier to remove than a dormant implant and easier to explain to the client.
Dormant mechanisms: triggers that activate on a date only work if someone is watching that date. If the engagement may end early, the dormant line in the register is the one that gets missed.
Nothing that survives the window: no mechanism may be left in place after closeout, including the ones deployed "in case we come back".

Operational burnout

Long engagements risk operator fatigue and mistakes. Rotate team members, keep the operation log current enough that a fresh operator can take over mid-week, and enforce rest periods — a tired operator is the most reliable way to lose track of a register line.

Managing Detection Risk Over Time

The longer an engagement runs, the more chances the defenders have to notice. Reduce the number of chances rather than trying to be cleverer than the detection stack:

Low and slow: fewer actions, spread across the approved activity hours rather than concentrated in one night.
Infrastructure rotation: retire domains and redirectors on a schedule agreed in the infrastructure annex, and record the retirement so old indicators stop being investigated.
Avoid patterns: vary beacon intervals and access methods within what the annex allows; a fixed interval is a signature.
Read the defenders' signal: track detections, new EDR coverage, and response activity, and report them as engagement findings rather than treating them as obstacles.
Deconfliction stays live: the longer the engagement, the more likely a responder meets your activity cold. The deconfliction channel from the rules of engagement must stay staffed for the whole window.

What the client should be able to read at the end

A long-duration report is credible when it lists the access that existed, the detections that fired or did not, and the removal evidence for every line. The narrative of the intrusion is the interesting part; the register is the part that lets the client sleep.

Covert Operations

Noise discipline and evidence handling for the actions a long engagement repeats.

Red Team Infrastructure

Inventory, logging, and the teardown runbook that the persistence register plugs into.

Rules of Engagement

Stop authority, deconfliction, and the annex that has to initial persistence approval.

C2 Frameworks

Maintained comparison of Sliver, Havoc, and Mythic for the command channel itself.