Detecting T1119 Automated collection

How T1119 automated collection hides inside normal scripted activity

Automated collection (T1119) is the use of scripts or tools to gather data of interest in bulk and on repeat, so the activity looks like a scheduled job rather than a person searching. For a SOC lead, the difficulty is that this behavior often matches work the business already runs. Collection (TA0009) is the ATT&CK tactic where an adversary gathers data toward its goal, and automated collection is one technique within it. This page targets Enterprise ATT&CK version 20.0, released on 2026-10-13. Mappings should name that version, because later releases can rename, deprecate or revoke techniques and the detection content tied to them.

In intrusions, this pattern usually appears once an attacker already holds a foothold and wants to pull large volumes from file shares, document repositories, mailboxes, cloud object storage or databases with little manual effort. The collection often runs under an account that already has read access, from a host that already reaches those systems, which is why it can pass access reviews. Backups, inventory scans, reporting jobs and synchronization tools perform the same kinds of reads against the same kinds of data. The useful signal is a read pattern that is new, unowned or out of cadence, not simply a large read.

Start with three decisions: who owns each recurring read job, which service accounts run them, and whether each job has a documented source, destination and schedule. Then look for jobs whose script or binary was created or modified recently, jobs that read far more directories than their stated purpose requires, and output written to unfamiliar staging locations. Ask your backup, reporting and inventory vendors which of their processes read broadly and what process and file telemetry those processes generate, since that baseline defines what counts as an anomaly. Build and verify that baseline in your own environment before relying on any default threshold.

Which telemetry reveals automated collection and which tool collects it

This table maps each telemetry source to what it sees during T1119 Automated collection and to the open-source collector that can gather it. Read each row as a question: what does this source record, and what would it miss? The main takeaway is that no single source covers automated collection end to end, so the detection depends on combining endpoint, file, network and cloud control-plane records.

Telemetry source	What it sees for T1119	Open-source collector	Blind spots to confirm
Process Creation (DC0032)	Launch of scripts or interpreters that enumerate and copy files in bulk, including repeated short-lived child processes on one host	Sysmon for Linux or auditd on Linux, Wazuh agent for ingestion	Scripts run inside an already-trusted interpreter may not create new process events; confirm command line capture is enabled
File Access (DC0055)	Read activity across many files or directories in a short window, often from a single process	auditd file watch rules on Linux, Wazuh file integrity and audit ingestion, Velociraptor hunts	High event volume; confirm which directories are watched and the retention period in your environment
File Creation (DC0039)	Creation of new collection directories, staging copies or output files written in a burst	Wazuh file integrity monitoring, Velociraptor file collection artifacts	Collection that streams output over a network may create no local file; pair with network telemetry
Command Execution (DC0064)	Shell or command sessions that run recursive search, copy or archive operations against target paths	Wazuh command monitoring, Velociraptor for endpoint command history where available	Interactive activity in some shells may not be logged; confirm shell history and logging policy
Network Traffic Content (DC0085)	Bulk transfer of collected content to an external destination, visible in unencrypted or metadata-level records	Zeek for protocol and file metadata, Suricata alerts via Security Onion	Encrypted payloads reveal volume and destination but not content; confirm TLS visibility design
IaaS control-plane audit logs	Mass object listing, snapshot or storage read calls by an unusual identity or service principal	Ingest into Wazuh or Security Onion through the cloud provider's log export; confirm the provider and log types in your account	Read-only API calls may be logged at a different level or retention than write events; confirm per provider
Office Suite audit logs	Bulk mailbox, document or file download actions by one account in a short period	Ingest through the suite's audit export into Wazuh or a SIEM; confirm available event types with the vendor	Logging depth and retention depend on license tier and configuration; confirm before relying on them

Detection logic for bulk, repetitive collection

T1119 Automated collection is hard to spot because each individual file read looks ordinary. The detections below look at patterns over time instead: how many objects a process touches, where data ends up, which accounts behave differently, and how cloud APIs are queried before bulk reads begin. Thresholds must come from your own baseline, and each idea needs a documented list of known benign jobs to suppress.

Non-standard process reading many directories

Count distinct directories and files read per process over a rolling window, grouped by host and user. Alert when a process outside your inventory of expected readers, such as a script interpreter or a newly launched binary, opens files across far more directories than it has done historically. Set the threshold per host class, since file servers and developer workstations have very different normal ranges. Use process creation and file access telemetry together so the reader's parent chain is visible. Expected false positives include backup agents, antivirus scanners, search indexers, eDiscovery collectors and inventory tools, which should be allowlisted by hash, signer and parent process rather than by name alone.

Collection burst followed by staging

Look for a sequence rather than a single event: a spike in file reads, followed within a short window by file creation in one new location, often a temporary or single-directory target. Correlate the file creation events with the earlier read burst on the same host. Tune the time window and the minimum file count to the typical size of your reporting and backup jobs. Reporting jobs, nightly exports and migration tools commonly produce this exact pattern, so record their schedules and output paths in your allowlist and review them each change window.

Service account scripted access outside baseline

Service accounts usually run the same jobs at the same times from the same hosts. Build a baseline of their access volume, source hosts, and active hours, then alert on deviations such as a service account reading far more objects than usual or running interactively. Repetitive, scripted access often shows up as a steady, machine-paced cadence. Inventory tools, scheduled reports and backup agents are the most common benign sources, and eDiscovery exports can appear as sudden legitimate spikes during legal holds, so coordinate with those owners before tuning.

IaaS enumeration followed by mass object reads

In cloud environments, watch for a discovery phase of list and describe calls across storage buckets, volumes or databases, followed by a large number of object read or snapshot read calls from the same identity. Build thresholds per account and per identity type, and log the ratio of list calls to read calls, which tends to be more informative than raw volume. Cloud inventory tools, configuration scanners and backup services produce similar enumeration, so maintain an allowlist of their identities and confirm with your cloud provider's audit log documentation which events your environment records.

How to validate the automated collection detection

This sequence proves that the T1119 detections fire on a benign, agreed collection pattern, shows what analysts see when they do, and produces a repeatable record of coverage against the ATT&CK version the team targets.

Agree scope with the system owner
The detection owner and the owner of the target system (for example, the Linux server team or the IaaS platform team) agree in writing which hosts, accounts, and time windows are in scope, who can stop the test, and which production alerts must be suppressed or tagged. Scope also covers data handling: the test uses synthetic or non-sensitive files only. The step is done when the owner signs off on the scope document and the stop conditions are known to everyone on the test channel.
Define the benign collection pattern
The team writes down, in plain language, the collection pattern it will emulate: for example, a scheduled job that gathers a set of harmless files from a set of directories into one staging location, the way a backup or reporting script would. The pattern is mapped to the data components in scope, such as Process Creation, File Access and File Creation, and to the Automated Collection technique in the ATT&CK version the team targets. The step closes when the pattern is reviewed by a second analyst and recorded in the test plan.
Set expected alert names before testing
Before running anything, the detection engineer lists the rule or analytic names that should fire, the severity each one should carry, and the fields an analyst needs to triage the alert, such as host, user, parent process, and affected paths. Writing expectations first prevents the team from judging the result after the fact. The step is complete when the expectations sit in the test record and the on-call analyst has read them.
Run the emulation in the range
The emulation runs in a private cyber range or a lab cloned from production configuration, never against live business data. The operator follows the written pattern, starts a timer at the moment the activity begins, and logs each step with a timestamp so the activity can be matched to telemetry later. The step is done when the run ends, the test artifacts are removed, and the start and end times are captured in the record.
Measure time to alert and fields present
The analyst compares the event timestamps in the SIEM, such as Wazuh or Security Onion, against the logged start time to measure time to alert. For each alert that fired, they check whether the expected fields are populated and whether the alert names match the expectations. Missing alerts, late alerts, and alerts without usable context are recorded as separate findings. The step closes when every expected alert is marked as fired, late, partial, or absent.
Tune rules and record the changes
The detection engineer reviews false positives from the same benign pattern, for example backup jobs or reporting tools, and adjusts thresholds, allow lists, or the scope of the rule. Each change is recorded with its reason, the ATT&CK version it maps to, and the expected effect on noise. Tuning should not remove the rule's ability to fire on the emulated pattern. The step is done when the change log is approved by the detection owner.
Confirm coverage against the targeted ATT&CK version
The team checks that the rules tested still map to the right technique, sub-technique, and data components in the ATT&CK version the organization targets. Because releases can rename, deprecate, or revoke techniques, the check uses the STIX data for that version rather than memory or older documentation. Any mapping that no longer matches is flagged for update. The step closes with a coverage table tied to the version number and the test date.
Re-run the test after every rule change
Each time a rule is added, edited, or retired, the same emulation is run again in the range and the results are compared with the previous baseline. The team confirms that time to alert and fields present have not regressed and that the tuning did not silence the detection. The step is complete when the re-run record is filed with the coverage table, giving auditors and the detection owner one traceable history.

Where IaaS, Linux, macOS and Office Suite visibility differs

Automated collection is hard to see in the same way on every platform, so the first decision is to treat visibility as a per-platform question rather than a single control you either have or lack. On Linux and macOS, the strongest signals are host-level: process creation records that show which tools ran and under which account, and file access and file creation events on directories that hold sensitive data or on the output locations where collected material tends to appear. These depend on the audit subsystem or endpoint agent being configured for the paths and event types that matter to you, and on the events being forwarded to Wazuh or your SIEM. Confirm which rules are loaded, whether file access auditing covers the directories your data owners care about, and how much host activity is retained before it rolls off.

On IaaS, the picture shifts from the guest operating system to the control plane and object storage. Automated collection against cloud workloads often shows up first as unusual API calls, snapshot or disk actions, or bulk object reads, which only appear if the provider's management and data access logs are enabled for the relevant accounts, regions and storage services. Many providers do not record every data access event by default, and some log classes carry extra cost or a separate retention setting, so you should confirm, for each account, which log types are on, how long they are kept, and whether they are delivered to your SIEM rather than sitting in the provider console.

In Office Suite tenants, collection is usually visible only through audit logs for mailbox, file and sharing activity, and these are often the least complete source in a hybrid estate. Ask the tenant administrator whether unified audit logging is enabled, which record types are included in your license tier, how long the tenant keeps them, and whether an export pipeline feeds them into your detection platform. Document the answers per platform in a visibility matrix, mark any gap as an accepted risk or a remediation item, and rehearse the detection in your cyber range against each platform so you learn where the logs stop before an adversary does.

Mitigations that limit what automated collection can gather

Automated collection succeeds when scripts can reach readable data and nobody notices the bulk reads. The cards below pair preventive controls that shrink what a script can usefully take with an evidentiary control that records who collected what. Each one must be confirmed against your own architecture before you rely on it.

Encrypt sensitive information at rest

Mitigation Encrypt Sensitive Information (M1041) reduces how much readable data a collection script can reach from a compromised account or host. Data encrypted at the storage layer, with keys held outside the workload that reads it, forces a collector to also obtain key access before the content is useful. Check which stores hold regulated or sensitive data, whether encryption covers backups and replicas, and whether the application decrypts broadly for every service account. Encryption helps only when the key boundary is separate from the data consumer.

Remote data storage for sensitive files

Remote Data Storage is the mitigation of keeping sensitive content in a controlled central location instead of on endpoints and servers where scripts sweep local directories. When documents and exports live in a managed repository, collection logic has fewer local paths to search and more central access points to watch. Confirm which directories still hold copies of sensitive files, whether sync clients mirror those files to endpoints, and whether central access is restricted to named roles.

Audit logging that makes bulk reads visible

Audit (M1047) does not stop a script, but it creates the record that lets you find one. Enable file access, file creation and process creation logging on hosts and repositories that hold sensitive data, then forward those events to your SIEM such as Wazuh or Security Onion. Confirm that log sources are complete, time-synchronized and retained long enough for investigations. This is an evidentiary control, so validate it with the detection tests in your cyber range.

Least-privilege service accounts

Automated collection often runs under a service or automation account with broader read access than its job requires. Review which accounts can enumerate and read sensitive stores, separate read paths for reporting from those for transactional workloads, and remove standing access that is no longer used. Check whether these accounts have interactive logon rights and whether their activity is attributable in your logs. This is a preventive control that shrinks what one compromised identity can gather.

Data loss prevention on egress paths

Data Loss Prevention (M1057) addresses what happens after a script gathers content and tries to move it out. Policies that flag bulk sensitive-data transfers to unmanaged destinations give you a second chance to catch collection that succeeded locally. Confirm which channels DLP inspects, including cloud sync, email and web uploads, and test policies against realistic but synthetic data. DLP coverage varies by product, so confirm its capabilities with the vendor before you assume them.

Triage and response when an automated collection alert fires

The first decision is whether the alert reflects a sanctioned process or an unexplained collection job. Start by identifying the process owner, the account that launched it, and the parent process that started it, then match the activity against a change record or an approved backup, reporting, or inventory job. Check the job scheduler and configuration management records for the host, since many legitimate tools sweep file shares, databases, or cloud buckets on a fixed cadence. If the collection matches a documented job with the expected account, schedule, and target paths, close the alert with that evidence attached and record any tuning needed to reduce repeat noise. If nothing in the change record or scheduler explains the activity, treat it as a potential incident and move on to scoping.

Scope the affected data stores and accounts before changing anything. Identify which directories, file shares, database exports, mailboxes, or cloud storage containers the process touched, and whether the same account accessed them on other hosts in the same window. For IaaS workloads, review cloud audit logs for storage reads, snapshot creation, and API calls made by the same identity, and confirm which resources the identity is permitted to reach. Preserve evidence first: export the relevant host telemetry, the cloud control plane audit trail, and any archive or staging files the process created, with hashes recorded, before you stop the process or disable the account. Retention windows for these logs vary by platform, so confirm them with your cloud provider and your own logging configuration now.

If the activity is unexplained, contain the narrowest thing that stops collection: suspend the account's access to the affected stores, block the process or its service, or isolate the host, in that order of preference where business impact allows. Escalate to incident response with a written timeline covering the alert, the owner checks performed, the data scope, the containment actions and their times, and who approved each step. Keep the record for later review, including the detection rule and ATT&CK version it matched, the analyst decisions, and any follow-up such as credential rotation or a review of MITRE ATT&CK technique guidance for T1119. Feed confirmed outcomes back into detection tuning so that the next alert on the same job is faster to resolve.

Rehearsing automated collection detection in a private cyber range

The host tab uses a private range with a small set of Linux and macOS endpoints enrolled in the agreed telemetry pipeline, with an open-source SIEM and endpoint agent collecting process creation and file activity. The range should mirror the production build of each operating system, including the audit configuration and the directories that hold business data. Confirm the exact agent and rule versions with your own platform team before the exercise, because the rules you test must target the ATT&CK version you have mapped.

Benign injects: Scheduled backup jobs, build tools that read and write large working directories, and administrators running routine archive utilities. These establish the normal baseline that analysts must learn to separate from suspicious activity.
Suspicious injects: Scripted staging of many files from several sensitive directories into a single working location within a short window, planned by the red or purple team and described only in the rehearsal plan.
Good detection: The alert fires on the agreed telemetry, the analyst completes triage within the window your team has agreed in writing, and the host's relevant file and process records are preserved with a documented chain of custody.
Debrief items: Whether the alert named the correct host and user, whether benign backup jobs created noise that needs tuning, and whether any collection path escaped the audit scope.

After the exercise, check that every inject maps to a logged event and that the evidence package can be reproduced by someone who did not run the scenario.

Questions SOC leads ask about detecting automated collection

How do we separate backup jobs from T1119 automated collection activity?

Start by treating scheduled backup and sync jobs as known, named behaviors rather than anonymous automation. Build an inventory of approved jobs with their service accounts, source paths, destinations, schedules and parent processes, then alert on automated collection that falls outside that inventory. Key on what is unusual for the job rather than on the act of copying files: a backup job that reads a new directory tree, runs under an interactive user account, or writes to an unfamiliar destination deserves review. Validate the allowlist in the cyber range by running your approved jobs and a simulated collection script side by side, then confirm that only the simulated activity raises an alert.

Which fields should we keep in Process Creation and File Access logs for tuning?

Keep the fields that let you explain a finding quickly: timestamp, host, user and account type, parent and child process with full command line, working directory, process hash, and the file paths read and written. For File Access and File Creation, retain the path, the accessing process, the count of files touched within a time window, and the destination directory. Enrich with asset owner and environment tags so that an alert on a build server is judged differently from one on a finance workstation. Keep the volume manageable by filtering known-good system paths at collection time, but record the filter rules so auditors and analysts know what was excluded.

How often should we revalidate T1119 detections after an ATT&CK version change?

Revalidate whenever your target ATT&CK version changes, and check the release notes for each update before you adopt it. MITRE publishes ATT&CK releases with notes on changes to techniques, detection strategies and data components, and the current series includes v18 (October 28, 2025), v19 (April 28, 2026) and v20 (October 13, 2026). Record the version each detection maps to, because releases can rename, deprecate or revoke techniques. Schedule a review after each release you adopt, and rerun the cyber range scenario to confirm that the detection still fires on the same telemetry. Ask your team to confirm the cadence they can sustain before committing to it.

How should we handle service accounts that legitimately run collection jobs?

Do not exclude service accounts wholesale, because compromised service accounts are a common route to automated collection. Instead, bind each approved job to a named account, record the expected host, schedule and file scope, and alert when the account runs outside those bounds. Review account permissions with User Account Management in mind, and confirm that service accounts cannot be used interactively. Rotate credentials according to your own policy and log every authentication that uses the account. Test the rule in the range by using a service account for an approved job and then for an out-of-scope collection pattern.

What evidence do auditors typically ask for when reviewing this detection?

Auditors generally look for evidence that the control exists, works and is maintained. Prepare the detection logic with its ATT&CK version and data component references, the log sources and retention settings, the allowlist of approved jobs with owners and review dates, and records of alert triage. Include results from cyber range exercises showing that the detection fired on simulated collection and stayed quiet on approved backups. Evidence for the mitigations, such as Encrypt Sensitive Information and Remote Data Storage, should show how sensitive data is protected at rest and in transit. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue the actual conclusions, so confirm the required format with your auditor early.

Can our own SOC team run this detection without an outside partner?

Many SOC teams can run this detection internally if they already collect Process Creation and File Access telemetry and have analysts who can read it. The work that tends to need the most time is building and maintaining the allowlist of approved jobs, tuning thresholds per environment, and rehearsing the scenario after each ATT&CK update. Decide whether your team has capacity for those recurring tasks. If not, an implementation partner can work from a written scope covering platforms, data sources, deliverables and timelines, and ongoing support can be arranged as a retainer. Ask any partner to show how the detection is documented and handed over so that your team can operate it after the engagement ends.

Primary sources for T1119 and the Collection tactic

Start with the MITRE ATT&CK tactic page for Collection (TA0009), which defines the tactic as the adversary trying to gather data of interest to its goal. For T1119 Automated collection, that definition frames the question your detections must answer: which data stores, staging locations and collection tools in your environment are worth watching, and which activity on them is unexpected for the roles that touch them. Record the ATT&CK version you are mapping against in every detection document, since the technique's sub-techniques, data components and mitigations can change between releases. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, so confirm which one your team is working from before you write anything.

Next, read the ATT&CK updates page and the release notes for each version your mappings cover. Releases can rename, deprecate or revoke techniques, and v18 replaced the detections on technique pages with detection strategies and analytics. Any rule written against an older detection text should be reviewed against the current strategy before it is trusted. Confirm with your own SOC lead or detection engineer which release your SIEM content library is pinned to, because a silent mismatch there is a common cause of coverage gaps.

For the full structured data, download the enterprise-attack 20.0 STIX bundle from the mitre-attack/attack-stix-data repository. It lists the data components, mitigations and sub-techniques linked to T1119, which lets you script a coverage check against your telemetry. Before you write any Sigma or Wazuh rule, open the live T1119 technique page on attack.mitre.org and read its current detection strategies and analytics, then confirm the data components they name are the ones your sensors actually collect.

How DeployOpen builds T1119 detections and range exercises

DeployOpen works on T1119 Automated collection as a fixed-scope engagement inside the client's own environment, with the scope agreed in writing before any work starts. The work covers detection content, validation in a private cyber range and the documentation a security team needs to run it after handover.

How we scope

Confirm which platforms are in scope for T1119, such as IaaS, Linux, macOS and Office Suite, and which are excluded.
Inventory the telemetry you already collect for Process Creation, File Creation and File Access on those platforms.
Record the Enterprise ATT&CK version the detection mapping will target and agree how version changes will be handled.

How we build

Write detection logic in open-source formats such as Sigma rules, mapped to the relevant ATT&CK detection strategies for T1119.
Configure collection and parsing in your existing open-source stack, such as Wazuh, Security Onion or Zeek, where those tools fit your environment.
Map the Encrypt Sensitive Information and Remote Data Storage mitigations to controls you already operate, and note any gaps.

How we hand over

Validate each detection in a private cyber range and record which telemetry was present and which was missing.
Deliver written runbooks covering triage, containment and evidence preservation for T1119 alerts.
Hand over detection content, configuration and test results so your own team can maintain and extend them.

How we support

Offer ongoing support, upgrades and continuous testing for T1119 detections as a retainer, scoped separately.
Review detection performance after each ATT&CK release that renames, deprecates or revokes related content.
Rehearse detection and response with your team in a cyber range on a schedule agreed in the written scope.

T1119 Automated collection