MITRE ATT&CK T1072 Software Deployment Tools: Detecting and Containing Fleet-Wide Admin Abuse

The tools that let one administrator patch, configure or wipe every device in the estate give the same reach to anyone who takes over that administrator's account. MITRE ATT&CK T1072 Software Deployment Tools covers adversaries using centralised software suites such as Microsoft Configuration Manager (SCCM), Microsoft Intune, AWS Systems Manager, Azure Arc, Altiris, HBSS and GCP Deployment Manager to execute commands and move laterally. In ATT&CK v20 it sits in two tactics, Execution (TA0002) and Lateral Movement (TA0008), covers Windows, Linux, macOS, network devices and SaaS, and has no sub-techniques. This guide is for detection engineers, endpoint and cloud platform owners and identity teams: it explains the technique at the level of the ATT&CK description, then concentrates on detection logic, log sources, approval controls and response. It contains no attack procedures. For platform hardening, see the Microsoft Configuration Manager Security Guide and the Microsoft Intune Guide.

Key takeaways

• It is an identity problem first. T1072 needs no exploit: a valid administrator account, a service principal with device management permissions or an agent registered to the wrong account is enough.
• The blast radius is the whole fleet. ATT&CK notes access can give remote code execution on all connected systems, including effects such as wiping every endpoint, which is what happened at Stryker in March 2026.
• Detect the console, not only the endpoint. ATT&CK detection strategy DET0223 pairs endpoint process telemetry with the management platform's own logs, such as SCCM and Intune logs, CloudTrail SendCommand and Jamf remote command events.
• Two-person approval is the strongest single control. Intune Multi Admin Approval and the Configuration Manager setting "Script authors require additional script approver" stop one compromised account from pushing scripts or wipes alone.
• Cloud and on-premises are now one path. ATT&CK records that Intune and Global Administrators can run scripts as SYSTEM on Entra-joined on-premises devices, so a cloud identity compromise becomes an endpoint compromise.

How the attack works

ATT&CK describes T1072 as gaining access to "centralized software suites installed within an enterprise" and using them for command execution and lateral movement. The technique replaced the revoked T1017 Application Deployment Software. It is related to, but distinct from, T1651 Cloud Administration Command (running commands on cloud instances through the provider's agent) and T1219 Remote Access Tools (interactive remote control software). The deciding feature of T1072 is that the adversary uses the organisation's own fleet management plane.

ATT&CK v20 lists ten groups using the technique, including Sandworm Team, Salt Typhoon, Mustang Panda, APT32, ShinyHunters, Medusa Group and VOID MANTICORE, and the Wiper malware (S0041). The mix shows the two main motives: quiet espionage at scale and destructive effect.

Where it shows up

• Destructive attacks: mass wipe or encryption pushed from the management console, which is faster and harder to stop than self-spreading malware. See the Wiper Malware Guide.
• Ransomware staging: deployment tools used to distribute an encryptor to every server at once after domain or tenant compromise.
• Agent hijack: Mitiga's advisory, cited by ATT&CK, shows the AWS SSM Agent can be re-registered to another AWS account, run as a parallel process or proxied, turning an Amazon-signed, often allowlisted binary into a remote access channel.
• Hybrid pivot: an Entra ID administrator compromise that reaches on-premises devices through Intune or co-managed Configuration Manager.
• Managed service providers: a provider's management platform reaches many customers, which is why the RMM Tool Security Guide and the Managed Service Provider Risk Assessment Guide treat provider consoles as tier 0.

Detection

ATT&CK v20 detection strategy DET0223 "Detection of Adversary Abuse of Software Deployment Tools" has five analytics, one per platform. They share one idea: a legitimate deployment platform executing something outside its normal operator, scope or time window.

High-value detections to build first

1. Mass destructive action: alert on any Intune wipe, retire or delete count above a small threshold (for example more than five devices in ten minutes) and on any bulk device action outside a change ticket.
2. New privileged role before deployment: correlate a new Global Administrator, Intune Administrator or Configuration Manager Full Administrator assignment with script, app or device actions by the same principal within 24 hours. This is ATT&CK T1098.003 Additional Cloud Roles followed by T1072.
3. Script approval anomalies: Configuration Manager scripts approved by their author, approved outside working hours, or run against "All Systems"; changes to the hierarchy setting that requires a separate approver.
4. Unexpected operators: CloudTrail SendCommand or StartSession from principals, source IPs or accounts not on the automation allowlist, and SendCommand targeting many instances with the document AWS-RunShellScript or AWS-RunPowerShellScript.
5. Agent tampering: following Mitiga's guidance, more than one amazon-ssm-agent process, a second instance data directory under /var/lib/amazon/ssm/ or C:\ProgramData\Amazon\SSM\InstanceData\, registration arguments outside provisioning, or proxy variables on the agent process.
6. Endpoint child processes: the management agent (for example the Configuration Manager client or Intune Management Extension) spawning shells that then make outbound connections or touch credential stores.

Measuring it

• Approval coverage: percentage of destructive and script deployment actions protected by two-person approval (target 100% for wipe and scripts).
• Standing privilege: number of accounts holding permanent fleet-wide deployment rights; trend down towards break-glass only.
• Log completeness: share of deployment platforms whose audit logs reach the SIEM with under 15 minutes latency.
• Time to contain: minutes from first anomalous deployment to suspended admin session in exercises.
• Agent integrity: managed nodes whose agent registration matches the owning account, measured daily.

Prevention and hardening

ATT&CK lists ten mitigations for T1072, led by M1026 Privileged Account Management, M1018 User Account Management, M1032 Multi-factor Authentication, M1030 Network Segmentation and M1015 Active Directory Configuration. Translated into platform settings:

• Intune Multi Admin Approval: create access policies under Tenant administration, Multi Admin Approval for the Device actions (wipe, retire, delete), Scripts, Apps and Role-based access control profile types. Microsoft notes approvers cannot approve their own requests and requests expire after three days. Protect the Role policy type last, after checking RBAC assignments, because it can lock out RBAC changes.
• Configuration Manager Run Scripts: keep "Script authors require additional script approver" enabled (Hierarchy Settings, General tab); Microsoft calls self-approval a lab-only setting. Split Script Authors, Script Approvers and Script Runners into separate roles and use security scopes.
• Scoped roles: use Intune scope tags and Configuration Manager security scopes so help desk roles cannot target the whole fleet; keep tenant-wide deployment rights to a handful of just-in-time roles.
• Restrict command sources: for Systems Manager, use VPC endpoints with endpoint policies and condition keys limiting commands to your own account or organisation, as Mitiga recommends, and stop treating the agent binary as automatically trusted in EDR allowlists.
• Admin workstation and network path: management consoles reachable only from privileged access workstations, with Conditional Access requiring phishing-resistant MFA. See the Conditional Access Guide.
• Recoverability: M1029 Remote Data Storage is on the ATT&CK list because a fleet wipe is a recovery problem: keep offline images, rebuild runbooks and a management plane you can restore independently.

Where identity fits

Every T1072 path starts with an identity that the deployment platform trusts. Four types need governance:

Non-human identities matter because they are often excluded from MFA and approval workflows: an app registration with device management permission can act without a human session at all. See the MITRE ATT&CK T1078 Valid Accounts Guide and the Azure RBAC and Service Principals Guide.

Responding to suspected abuse

1. Stop the push: cancel pending deployments and script runs, pause scheduled deployments and disable the suspect admin and service principal sign-ins. Revoke refresh tokens for affected Entra ID accounts.
2. Preserve evidence: export Intune audit logs, Configuration Manager status messages and Script Status, CloudTrail events for Systems Manager, and controller job logs before retention or cleanup tasks remove them (Configuration Manager's Delete Aged Client Operations task removes script status data).
3. Scope the reach: list every device targeted, every role assignment changed in the window and every new admin or app credential.
4. Restore from a clean plane: rebuild trust in the management tenant (break-glass accounts, reset admin credentials, review MAA and RBAC policies) before reusing it to redeploy. See the Break-Glass Account Guide.
5. Recover devices: follow the Wiper Attack Response Playbook if destructive actions ran.

Lessons from incidents

In March 2026, Stryker suffered a global disruption after an attacker compromised an administrator account in its Microsoft environment, created a new Global Administrator and issued Intune remote wipe commands to enrolled devices; a source cited by BleepingComputer put the number near 80,000, and personal devices enrolled in Intune were also wiped. No wiper malware was needed on the endpoints. See the Stryker Intune wipe breach analysis. The controls that would have changed the outcome map directly to this guide: Multi Admin Approval on device actions, an alert on new Global Administrator assignment, and no standing tenant-wide roles.

Common failure patterns

• Deployment platforms outside tier 0: the Configuration Manager site server or Intune admin roles are treated as IT tooling, not as equivalent to domain or tenant administration.
• Self-approval left on: the Run Scripts approver requirement is cleared during testing and never restored.
• Allowlisted agents: EDR exclusions for management agents hide the child processes that DET0223 relies on.
• Logs never collected: Intune audit logs and CloudTrail data events are not forwarded, so the console side of the attack is invisible.
• Personal devices enrolled with full wipe: BYOD enrolled as fully managed, as the Stryker case showed, extends the blast radius beyond corporate assets.
• Forgotten automation identities: old service principals with device management permissions and no owner.

Framework mapping

Practitioner checklist

• Inventory every software deployment, MDM, configuration management and fleet agent platform, and classify each as tier 0.
• Enable Intune Multi Admin Approval for device actions, scripts and apps, and keep the Configuration Manager separate script approver setting on.
• Remove standing tenant-wide deployment rights; use just-in-time activation with phishing-resistant MFA.
• Forward Intune audit logs, Configuration Manager status messages, CloudTrail Systems Manager events and controller logs to the SIEM.
• Build the DET0223 analytics for your platforms plus a bulk device action alert and a new-admin-then-deploy correlation.
• Review EDR exclusions for management agents and restrict Systems Manager commands to your own accounts.
• Inventory service principals and agent registrations with deployment permissions and remove unowned ones.
• Exercise a "rogue mass deployment" scenario, including how fast you can stop pending pushes.

Standards and references

• MITRE ATT&CK: Software Deployment Tools (T1072)
• MITRE ATT&CK: Cloud Administration Command (T1651)
• Microsoft Learn: Use Multi Admin Approval in Intune
• Microsoft Learn: Create and run PowerShell scripts from the Configuration Manager console
• AWS: Logging AWS Systems Manager API calls with AWS CloudTrail
• Mitiga: Security Advisory, Abusing the SSM Agent as a Remote Access Trojan
• MITRE D3FEND: Administrative Network Activity Analysis
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Microsoft Configuration Manager Security Guide · Microsoft Intune Guide · AWS Systems Manager Security Guide · Lateral Movement Guide · ITDR Guide