---
{
  "title": "Automated Collection",
  "summary": "Automated collection repeatedly gathers internal information according to rules or triggers.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1119"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1119: Automated Collection",
      "url": "https://attack.mitre.org/techniques/T1119"
    }
  ],
  "editorialVersion": 2
}
---

## Repeated gathering changes the scale

Automated collection uses programs, scripts, application features, or service workflows to gather information repeatedly according to rules or triggers. In an intrusion, automation can collect a broad dataset faster or more consistently than manual browsing. The mechanism may be local, network-based, or implemented through cloud APIs.

Automation itself is normal. Backups, indexing, reporting, synchronization, and business data pipelines all gather information. The security question is whether the actor, scope, purpose, and destination match an authorized workflow.

## A recurring query crosses an unexpected scope

In a fictional academy, a service identity begins reading records from several unrelated departments at regular intervals. The pattern resembles an automated job, but the identity normally serves only one reporting function. The analyst checks the job configuration, identity permissions, query or file-access records, schedule, and resulting output.

The regular timing is a clue to mechanism, not proof of malicious intent. A newly approved organization-wide report could explain the expanded scope. The team looks for the owner, deployment history, and permission change that authorized the behavior.

If no legitimate workflow explains it, the investigation examines how the automation was created and whether its output was staged or transferred. Successful reads establish collection of the corresponding information only to the extent supported by the service's event semantics.

## Inspect the selection rule

Automation often selects data by path, type, date, query criteria, or an application-defined scope. Understanding that rule helps estimate what could have been collected and which resources deserve review. A sample output may not represent every item processed by the job.

Look for retries, overlapping runs, and changes to the selection criteria. These details can explain unexpectedly high counts without necessarily indicating a larger dataset. Conversely, a low event count may hide bulk operations if one request returns many records.

[[data-from-information-repositories]] and [[data-from-cloud-storage]] describe sources an automated workflow might use. [[data-staged]] helps distinguish collection from preparation for transfer.

## Interrupt the workflow deliberately

Containment might disable the job, restrict the identity, or block the output path. Coordinate with service owners because the same infrastructure may support essential reporting. Preserve configuration and activity records before removal when practical, and address the authority that allowed the unauthorized scope.

For practice, compare a normal nightly report with a fictional job that adds unrelated datasets and a new output destination. Identify the evidence needed to explain the change, the business owner who should validate it, and the conditions for safe restoration. Report confirmed reads separately from assumptions about later exfiltration.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[incident-response]]
- [[command-and-scripting-interpreter]]
- [[file-and-directory-discovery]]
- [[lateral-tool-transfer]]
- [[cloud-service-dashboard]]