How attackers use software deployment tools to execute at scale
For a SOC lead, the core problem with T1072 Software deployment tools is that the malicious activity looks like routine change. Centrally managed deployment tools, such as configuration management, endpoint management and patching platforms, already run code on large numbers of hosts under a privileged identity. An adversary who controls one of these tools, or the account that drives it, can execute instructions on many systems through a path that existing allow lists and administrator habits already permit. In practice, the signal is rarely the tool's binary, which is expected on the estate. The signal is the deployment action and its scope: who created or changed a job, what payload or script it carried, which hosts it targeted, and whether that breadth matches the change record.
ATT&CK places T1072 under the Execution tactic (TA0002), which is about running adversary-controlled code or instructions on a system. This page maps to Enterprise ATT&CK version 20.0. Detection mappings should be rechecked whenever ATT&CK releases change, because releases can rename, deprecate or revoke techniques and detection strategies. Confirm the current version and the data component references against the MITRE ATT&CK updates page before you freeze a detection library. Your own rule inventory should record the version it targets so that a later release does not silently change what your alerts cover.
Decide early which deployment platforms count as in scope for this technique and who owns their administrative accounts. Ask each platform owner to confirm three things: where job creation and approval events are logged, whether those logs reach your SIEM with the originating user and target host list intact, and how long they are retained. Gaps in any of these answers will limit the detections in the sections that follow. Treat deployment tool administrators as a privileged population for the purposes of User Account Management and Privileged Account Management, and make sure their activity is reviewed on a schedule that matches the risk of the estate.
Which telemetry reveals T1072 and which open-source tool collects it
This table maps the ATT&CK data components most often referenced for Execution techniques to the platforms in scope for T1072, with the signal to look for and a suggested open-source collector for each. Read each row as a starting point: the deployment tool a client uses (for example, its configuration management or package pipeline) determines which events are actually generated, so confirm coverage in the client's own environment before relying on a row.
| Data component | Linux and macOS hosts | Network devices | SaaS and audit logs |
|---|---|---|---|
| Process Creation (DC0032) | Signal: a deployment agent or push tool spawning remote shells or package installs outside its normal schedule. Collector: Wazuh or Velociraptor process telemetry. | Signal: not usually available as process events. Confirm whether the device exports configuration or command accounting logs. | Not applicable. Look for the equivalent job or runner execution record in the SaaS platform. |
| Command Execution (DC0064) | Signal: deployment commands run with elevated rights by an account that does not normally administer the host. Collector: Wazuh command monitoring or Velociraptor artifacts that capture command lines. | Signal: configuration pushes or scripted commands issued through a management controller. Collector: device syslog forwarded to Wazuh or Security Onion, if the vendor supports it. | Signal: scripts or jobs executed by a pipeline runner against production scopes. Collector: vendor audit logs forwarded to a SIEM. |
| Application Log Content (DC0038) | Signal: entries from the deployment tool's own logs showing unexpected targets, playbooks or inventory changes. Collector: Wazuh log collection of the tool's log files. | Signal: configuration change records and failed or successful management sessions. Collector: syslog to Wazuh or Security Onion. | Signal: deployment, release or job-run events showing a new target, a changed template or an out-of-window run. Collector: SaaS audit log export to Wazuh or a SIEM. |
| Network Connection Creation (DC0082) | Signal: hosts opening management or repository connections to unfamiliar endpoints, or fan-out connections across many hosts in a short window. Collector: Zeek connection logs or Suricata flow records. | Signal: management sessions from unexpected source addresses or protocols. Collector: Zeek or Suricata on the management network segment. | Signal: API calls from new source networks or service identities. Collector: SaaS audit logs correlated with network telemetry where available. |
| File Creation (DC0039) | Signal: new or modified deployment packages, scripts or inventory files in staging directories. Collector: Wazuh file integrity monitoring or Velociraptor file hunts. | Signal: configuration file or image uploads that the change process did not record. Collector: device backup comparison and syslog, to be confirmed per vendor. | Not usually applicable. Look for artifact uploads or modified pipeline definitions in the platform's change history. |
| Network Traffic Content (DC0085) | Signal: payload content in deployment traffic that does not match the approved package sources. Collector: Zeek or Suricata with TLS metadata; full content inspection depends on policy and encryption. | Signal: unexpected configuration blobs or commands in management traffic. Collector: Suricata or Zeek only where traffic is visible, which must be confirmed. | Usually not visible because SaaS traffic is encrypted. Rely on audit logs and identity telemetry instead. |
What abnormal deployment activity looks like on each platform
Deployment tools are legitimate administration software, so the detection question is rarely whether a tool ran but whether this run matches how the client's own pipeline normally behaves. On Linux and macOS hosts, review the identity that launched the deployment agent or configuration run, the host group or inventory segment it touched, the hour it ran, and whether a change record covers it. A configuration push from the automation service account at 02:00 to a production database group with no open change ticket is the pattern worth escalating, while the same push during a scheduled window tied to an approved change is routine. On network devices and SaaS administration consoles, the equivalent fields are the administrator or API principal, the device or tenant scope, the source address, and whether the change was requested through the normal workflow. Confirm with your network and SaaS owners which of these fields your devices and consoles actually record, because some platforms log the operation but not the scope it applied to.
Baselining the client's own deployment pipeline is the prerequisite for every rule in this section. Before any alert is tuned, export a representative period of deployment activity from the orchestration server, configuration management controller, device management platform and SaaS audit logs, then record the normal operators, service accounts, target groups, run windows and change-ticket linkage for each. Agree with the platform owners which runs are expected to be unticketed, such as emergency patching or automated drift correction, and document them as named exceptions rather than silent gaps. Expect the baseline to surface service accounts used by more than one team and deployments that run outside business hours on a schedule, and decide in advance how each will be classified. Re-run the baseline after each major pipeline change, because a new deployment job or a renamed target group will otherwise look like an anomaly. The output of this work is a short, reviewed list of expected patterns per platform, and that list is what your detections should be measured against, not a vendor default.
Detection ideas for T1072 with tuning thresholds and false positives
These five detection ideas target the same behavior from different angles: a deployment tool pushing change to systems in a way the environment does not expect. Each idea pairs a logic statement with a tuning approach and the benign activity most likely to trigger it. Map them against the ATT&CK version your team targets (Enterprise ATT&CK 20.0) and validate thresholds against your own change calendar before alerting.
Deployments outside change windows
Alert when a deployment job, configuration push or package distribution event from a tool such as a configuration manager or CI/CD server runs outside the approved change calendar. The logic depends on Process Creation and Command Execution events paired with the deployment server's job log. Tune by loading the change calendar as a lookup and allowing a short grace period for jobs that start just before a window closes. Expect false positives from emergency patches, on-call hotfixes and scheduled jobs that the calendar never recorded. Confirm with the change board that every recurring job appears in the calendar before enabling the rule.
Deployments from unexpected identities
Alert when a deployment tool runs under an account or service identity that has never initiated a deployment to the target host group. The logic compares the initiating principal against a baseline of approved deployers per environment, using Application Log Content from the tool and authentication events from the directory. Tune by building the baseline over a period that includes at least one full release cycle, then review new identities weekly. Typical false positives include newly onboarded automation accounts, service accounts rotated during maintenance and engineers covering for a colleague on leave.
Fan-out far above host baseline
Alert when a single deployment job reaches a host count well above the historical median for that job, or when one principal targets hosts across more environments than usual. The logic counts distinct target hosts per job and per initiator over a sliding window using Network Connection Creation and deployment agent logs. Tune thresholds per job rather than globally, because a monthly operating system patch can legitimately reach the whole fleet. Common false positives include fleet-wide security patches, inventory refreshes and disaster recovery drills, so keep a registry of those events and suppress them by job name, not by initiator.
Jobs created or edited by non-owners
Alert when a deployment job, playbook or pipeline definition is created or modified by a user who is not listed as an owner of that job. The logic relies on Application Log Content from the deployment platform's audit trail and compares the editor against the owner field in the job metadata. Tune by alerting only on changes to job targets, commands or variables, and ignoring cosmetic edits such as descriptions. False positives come from peer reviews where a second engineer merges a change, from ownership transfers that were never recorded and from bulk edits made by platform administrators during migrations.
New SaaS deployment integrations
Alert when an administrator in a SaaS platform adds a new deployment integration, webhook, app connection or service principal that can push changes to other systems. The logic reads the platform's admin audit events and flags creation events that grant deployment scopes to a principal not present in the approved integration register. Tune by setting the register as the allowlist and reviewing scope grants, not only creation. False positives include onboarding of approved vendors, new team tooling and vendor-initiated reauthorization, so confirm the audit event names your platform emits before relying on this rule.
How to validate that T1072 detections fire
This sequence proves, in a lab or private cyber range, that the T1072 Software Deployment Tools detections fire on the telemetry a real change would produce, and that the evidence is kept with the detection record. It runs only against test identities and test endpoints agreed with the change owner.
Agree scope and change ownership
Before any test, the security engineer and the owner of the client's deployment tooling agree in writing which deployment tool, which target group and which test identity will be used, and who approves the window. The scope names the ATT&CK version the detection mappings target, since ATT&CK releases can rename or deprecate techniques. The step closes when the change owner signs the scope and the test identity is confirmed as separate from any production administrator account.
Map expected telemetry before testing
The detection engineer writes down, for each deployment tool in scope, which data components should record the activity, such as Process Creation (DC0032), Command Execution (DC0064), Application Log Content (DC0038) and Network Connection Creation (DC0082). For each one, the team records the log source, the expected fields and the rule or analytic that should match. The step closes when this expectation sheet is reviewed by someone other than its author, so that gaps are found before the test rather than during it.
Run a benign deployment under a test identity
Using the client's own deployment tooling, an operator runs a harmless, pre-approved deployment, such as pushing a version-tagged test package to a small set of lab hosts, under the agreed test identity. The operator logs the start and end time of each action so timestamps can be compared with the logs later. The step closes when the deployment completes as planned and the operator records the exact actions taken, without any attempt to bypass controls.
Confirm each detection logs the expected events
The detection engineer searches the SIEM, for example Wazuh or Security Onion, for the events from the deployment window and checks them against the expectation sheet. Each expected event should appear with the right host, identity and fields, and each detection should either fire or be recorded as a gap. The step closes with a table showing, for every data source and rule, whether the event was present, parsed correctly and matched.
Record time to alert and alert fidelity
For each fired alert, the team measures the time between the first logged action and the alert being generated, and reviews whether the alert describes the deployment accurately or is noisy. The analyst notes false positives caused by legitimate administrators and the tuning needed. The step closes when time to alert and a fidelity assessment are written against each detection, so that the next run can show whether the figures improved.
Retain evidence in the detection record
The team stores the scope agreement, the expectation sheet, the exported log excerpts, the alert records and the fidelity notes in the detection record for the rule version under test. Sensitive values are masked according to the client's data handling policy. The step closes when the record links each detection to its evidence and to the ATT&CK version used, so that an internal reviewer or independent auditor can trace the result.
Roll back test artifacts and close the window
The operator removes the test package, the test identity's temporary access and any configuration changed during the run, returning the lab or range to its baseline state. The team then checks that the rollback itself was logged and that no test artifact remains on any host. The step closes when the change owner confirms the rollback in writing and the window is closed in the change system.
Triage steps when a deployment detection fires
The first decision is whether the deployment was authorized, and it should be made within the first few minutes using three checks: match the event to an approved change record, identify the initiating identity, and confirm which hosts the deployment actually touched. Start by comparing the timestamp and target scope of the alert against the change calendar and the deployment tool's own job history. An approved job with a matching ticket, a named operator and the expected host group usually closes the alert as authorized, after which the analyst records the closure reason. Where the initiating identity is a service account, confirm that the account belongs to the deployment platform and that its last password or key rotation is consistent with your standard, since a service account that is used interactively is a common indicator of misuse. Ask the platform owner to confirm, in writing, what a normal run looks like for that tool, so that the next alert can be triaged against a known baseline.
Scope the hosts before deciding anything else. Count the systems that received the deployment, separate production from non-production, and note any that are outside the expected inventory group, because an unexpected target is the strongest signal that a legitimate tool is being used for an unauthorized purpose. Then look for follow-on activity on those hosts during the same window: new scheduled jobs, new or modified accounts, changes to SSH authorized keys or sudo rules, new outbound connections to destinations that are not on the platform's known list, and any credential access by the initiating identity. Unexpected follow-on activity moves the case to escalation. Escalate immediately when the deployment is unauthorized, targets production hosts outside the approved scope, or shows persistence or credential access. Freeze the deployment tool's pipeline or job scheduler, revoke the initiating credential, and preserve the deployment logs and the configuration state before any cleanup, so that the investigation keeps its evidence. Confirm with your incident response plan and your change manager who has authority to freeze the pipeline, and rehearse that decision in your cyber range before it is needed.
Controls that limit who can deploy software and to where
Deployment tools are only dangerous when someone without a legitimate reason can use them. The controls below narrow who can start a deployment, which accounts and devices the tools can reach, and how every action is recorded, so that a misuse stands out in the logs.
Scope user accounts to deployment roles
Map each person and team to the specific deployment platforms, environments and targets they need, using ATT&CK mitigation User Account Management (M1018) as the control frame. Remove standing access to production targets from accounts that only build or test. Review group membership on a set schedule and after every role change, since stale memberships are a common reason a deployment tool becomes reachable from an unexpected account. Confirm that your deployment platform can express these scopes natively or through your identity provider.
Restrict privileged deployment accounts
Under Privileged Account Management (M1026), limit administrative rights on deployment servers, configuration management controllers and network device management planes to a small named group. Require separate privileged credentials for administration, kept apart from everyday accounts. Check where deployment credentials are stored and who can read them, because a deployment pipeline with broad secrets gives an attacker the same reach as the tool itself.
Separate authors from approvers
Require that the person who writes or changes a deployment package, playbook or pipeline definition is not the same person who approves it for production. Enforce this in the tool itself with approval gates rather than in policy documents alone. Test the control by attempting a self-approved change in a non-production environment and confirming that the platform blocks it and logs the attempt.
Scope service accounts to single targets
Give each deployment job its own service account, limited to the hosts, containers, cloud projects or device groups it manages. Avoid shared service accounts that span environments. Record which account performs each action so that an anomalous deployment can be traced to a specific job. Ask your deployment vendor or open-source project maintainers to confirm which permissions their service accounts require before you narrow them.
Restrict network device administration
Where deployment tools push configuration to switches, routers or firewalls, place management interfaces on a dedicated administration network and allow only approved controllers to connect. Apply the privileged account controls above to device credentials, and require change tickets that match the deployment job. Review which device configuration pushes are permitted outside maintenance windows.
Audit every deployment action
Under Audit (M1047), make sure deployment platforms write logs for logins, job creation, approvals, configuration changes and target selection, and forward them to your central analytics platform. Without these records, the detections described elsewhere on this page cannot attribute a deployment to an account. Confirm retention periods with your compliance team, since the vendor default may not match your obligations.
Rehearsing T1072 detection and response in a private cyber range
Build the range as a small fleet of Linux and macOS hosts enrolled in the same configuration management and endpoint telemetry pipeline used in production, with a central log collector and an agent that forwards process creation and command execution events. Use synthetic inventory, dummy service accounts and a dedicated deployment tool installed on a jump host, so that every event originates inside the range. The goal is to confirm that process creation and command execution records from deployment tooling reach the SIEM with enough fields (user, parent process, target host, timestamp) to attribute each action.
- Benign deployment bursts: Schedule routine package and configuration pushes across the fleet at normal business hours, then measure whether analysts can tell them apart from unauthorized pushes by change ticket reference.
- Off-hours runs: Trigger a deployment at an unusual hour from a legitimate account, and confirm that the time-of-day rule fires and routes to the on-call queue.
- New deployment accounts: Create a service account that has never run a deployment and use it once, so that the first-seen account alert and the account lifecycle record can be checked together.
- Attribution gaps: Remove the change reference from one burst and verify that the detection still produces a case with the host, user and command summary.
- Response check: Require the responder to confirm the deployment owner, pause the job, and document whether the host state matches the approved change.
Check that alerts for a push include the account, source host and target scope, and that the response playbook names who can approve a rollback.
Build the range with a lab of virtual or spare network devices managed through a central controller or deployment server, plus an out-of-band syslog or API log collector. Keep management traffic on a separate lab segment and use synthetic configurations and dummy credentials. The aim is to see whether configuration pushes and firmware deployments appear as application log content with the deploying identity, the device set affected and the change outcome, which is often the only record available for these platforms.
- Batch configuration pushes: Run a scripted change across several devices in one window, and check that the log shows each device, the change identifier and any failures.
- Firmware staging outside the window: Stage an image update during a closed change window and verify that the mismatch with the approved calendar raises an alert.
- Shared administrator credentials: Use a single shared login for one deployment, then confirm the team flags it as a control gap and traces the actor through the controller's audit trail.
- Partial failure handling: Force several devices to reject a push and verify that the alert distinguishes failed deployments from successful ones.
- Response check: Test whether responders can freeze further pushes from the controller, export the change history, and compare running configuration with the approved baseline.
Confirm with each vendor which management interfaces log deployments and at what detail, because log content differs widely between platforms.
Build the range as a test tenant of the SaaS deployment or endpoint management service, with synthetic groups, policies and deployment packages, and an audit log export to the SIEM. Use a non-production identity provider configuration so that role changes and sign-ins are recorded in the same test environment. The exercise tests whether administrative deployment actions produce audit events that name the actor, the policy or package affected, and the target scope, and whether those events arrive in time to matter.
- Benign policy rollouts: Publish an approved software package to a test group and verify that the audit event matches the change record.
- Off-hours publication: Push a package to all test devices outside working hours from an administrator account, and confirm that the alert reaches the right queue.
- New administrator role: Assign deployment rights to a new account, then check whether the role change alert fires before the first deployment.
- Scope expansion: Widen a deployment from a pilot group to all devices and confirm that the change in scope is logged and detected.
- Response check: Require responders to revoke the deployment role, disable the publishing token, and confirm in the audit log that no further packages were published.
Ask the vendor which audit events are exported, what retention applies to them, and whether deployment actions are logged with the target scope.
Questions SOC leads ask about detecting T1072
How do I separate authorized software deployments from abuse?
Start with a written inventory of approved deployment tools, the accounts allowed to run them, and the change records that should precede each run. Alert on deployment tool execution that has no matching change ticket, runs outside the approved maintenance window, targets hosts outside the deployment group, or comes from an account that has never used the tool before. Process Creation (DC0032) and Application Log Content (DC0038) carry most of the signal, so enrich those events with the change ID or pipeline run ID from your deployment system. Expect false positives in the first weeks, and tune allowlists by named service account and approved target group so that a compromised account cannot hide behind a broad host exception.
What should I check when deployment tools run as root?
Treat root-level deployment tooling as privileged activity that needs its own control set. Confirm which account the tool runs under, whether it uses sudo or a privileged agent, and whether that privilege is needed for every task it performs. Apply Privileged Account Management (M1026) to restrict who can invoke the tool with elevated rights, and User Account Management (M1018) to remove standing root access from people who only need to trigger deployments. Log privilege elevation and sudo usage alongside the tool's own execution events, so a single run can be traced from requester to change record to host. Where the vendor supports it, scope privilege to specific playbooks or modules, and confirm that behavior in your own environment before relying on it.
How do I cover SaaS deployment consoles in detection?
SaaS deployment consoles produce no host process events, so detection depends on their audit and application logs. Forward the console's administrative audit log to your SIEM, then alert on new deployment pipelines or jobs, changes to pipeline definitions, new or altered credentials and tokens, and deployments to production targets from unfamiliar identities. The relevant data component is Application Log Content (DC0038), and the signal is usually a configuration change followed by a run. Confirm which audit events your specific console exposes, how long it retains them, and how quickly exports arrive, because these details vary by product and plan. Pair the console logs with identity provider sign-in events so each deployment can be tied to the person or service principal behind it.
How often should I re-baseline deployment tool activity?
Re-baseline on a fixed schedule and after any event that changes what normal looks like: a new deployment tool, a new pipeline, a team reorganization, an infrastructure migration, or a major tool upgrade. Choose the interval based on how often your deployment estate changes, and record the decision in your detection runbook. Each review should compare recent execution counts by tool, host group and service account against the approved inventory, then retire stale allowlist entries. Keep the previous baseline so you can explain why an alert threshold changed. The right cadence depends on your own change volume, so ask your operations team to review change records before setting it.
How do I keep T1072 detections current across ATT&CK versions?
Name the ATT&CK version in every detection record, and read the release notes before each upgrade. ATT&CK v18 was released on October 28, 2025, and replaced technique-level detections with detection strategies and analytics, identified by DET IDs. Later releases include v19 on April 28, 2026 and v20 on October 13, 2026. Releases can rename, deprecate or revoke techniques, so a rule mapped to T1072 today may need a new reference later. Review the MITRE ATT&CK updates page for each release, then compare the enterprise STIX bundle for the version you target. Store the mapping in version-controlled content so auditors can see which ATT&CK version each rule used on a given date.
How do I test T1072 detections without disrupting production?
Run detection tests in a private cyber range or staging environment that mirrors your logging pipeline, deployment tools and identity setup, then confirm the same events reach your SIEM in the same format they use in production. Use a dedicated test service account and a marked test change ID so every test event is labeled and easy to filter out of dashboards. Exercise the approved deployment path and the out-of-policy cases your rules target, such as a run with no change record or a run from an unexpected host, and record whether each alert fired and how long it took. Before any production validation, agree on a window and a rollback plan with the operations team, and keep the written test plan in the detection repository.
Official ATT&CK references for T1072 mappings
Before you build or tune any detection for T1072, confirm the technique definition against the official MITRE sources, because detection mappings are only as current as the version they target. Start with the Execution tactic page (TA0002), which defines the tactic as the adversary trying to run malicious code or instructions on a system, and then read the T1072 technique page itself. Record the ATT&CK version you tested against in your detection documentation, since MITRE can rename, deprecate or revoke techniques between releases. The MITRE ATT&CK tactic page for Execution is the natural starting point for this check.
For machine-readable confirmation, use the Enterprise 20.0 STIX 2.1 bundle in the mitre-attack/attack-stix-data repository. Search that bundle for the T1072 object and its relationships, then check which data components, detection strategies and mitigations are linked to it, including User Account Management and Privileged Account Management. Your detection engineers should load the same bundle version that your Wazuh, Sigma or Security Onion rule metadata references, so that a rule does not silently drift from the technique it claims to cover. Keep a copy of the bundle hash in your change record. The attack-stix-data repository explains how the bundles are organized by domain and version.
Finally, review the ATT&CK updates page on a fixed schedule, and assign an owner to read each release note. Confirm whether T1072 or its detection strategies changed in the release you are moving to, and whether your Sigma rules, Wazuh decoders and cyber range scenarios need review. Ask your DeployOpen or internal team to document this cadence as part of the detection lifecycle, so auditors can see how mappings are kept current.
How DeployOpen builds T1072 detections and range exercises
DeployOpen approaches T1072 Software deployment tools as a written, fixed-scope engagement inside the client's own environment. Detection content is built on the platforms and telemetry the client actually runs, then validated in a private cyber range before handover.
How we scope
- Inventory which deployment tools, configuration managers and SaaS admin consoles can push software or commands in your estate.
- Agree in writing which platforms are in scope, such as Linux, macOS, network devices and SaaS tenants.
- Confirm which telemetry sources exist today, including process creation, command execution and application log content.
How we build
- Map detection logic for T1072 to the ATT&CK version you target, recording the version in every rule.
- Build open-source detections in Wazuh, Sigma and Security Onion for the telemetry your platforms really produce.
- Test the User Account Management and Privileged Account Management mitigations against the accounts that can run deployment jobs.
How we hand over
- Deliver rule logic, data source mappings, and tuning notes with the reasons each alert fires.
- Document the response steps for a suspicious deployment job, including who approves rollback and evidence capture.
- Run a cyber range exercise with your analysts and record gaps, false positives and follow-up actions.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Re-validate detections when ATT&CK releases rename, deprecate or revoke related techniques or sub-techniques.
- Ask any partner to confirm support scope, response expectations and retainer terms in writing before work starts.
