Software deployment tools exist so that one administrator can run code on thousands of machines. That is exactly why attackers want them. MITRE ATT&CK tracks the abuse of these suites as T1072, Software Deployment Tools, and files it under two tactics: execution and lateral movement.
The technique applies to Linux, macOS, Windows, network devices and SaaS. MITRE's examples of affected solutions include SCCM, HBSS, Altiris, AWS Systems Manager, Microsoft Intune, Azure Arc and GCP Deployment Manager. These systems may also be wired into CI/CD pipelines, which is where this topic meets software supply chain security.
How attackers use it
MITRE describes the core idea plainly. If an adversary gains access to network-wide or enterprise-wide endpoint management software, they may be able to achieve remote code execution on every connected system. That access can be used to move laterally, gather information, or cause a specific effect. MITRE's own example of the last case is wiping the hard drives on all endpoints.
A few details from the MITRE page are worth knowing:
- SaaS-based configuration management services may allow broad cloud administration commands on cloud-hosted instances, and also the execution of arbitrary commands on on-premises endpoints.
- Microsoft Configuration Manager lets Global or Intune Administrators run scripts as SYSTEM on on-premises devices joined to Entra ID. A cloud admin account can therefore reach into the datacenter.
- Such services may use web protocols to talk back to adversary-owned infrastructure.
- Network infrastructure devices may have configuration management tools that can be abused in a similar way.
The permissions needed vary. Sometimes local credentials on the third-party system are enough. Sometimes specific domain credentials are required, or an administrative account. The practical lesson is that the console and its accounts are a high-value target, not just the endpoints it manages.
How to detect it
MITRE's detection strategy for this technique (DET0223) has one analytic per platform family. Read them as a checklist of what to collect:
- Windows with SCCM or Intune: remote push execution spawning scripts or binaries from SYSTEM context or from unusual consoles. MITRE gives the example of cmtrace.exe launching PowerShell or cmd.exe.
- Linux orchestration with Puppet, Chef, Ansible or shell scripts: remote scripts or binaries executing outside maintenance windows, or on nodes that are not managed.
- macOS with JAMF, Munki or custom MDM agents: execution outside baseline, or JAMF launching new Terminal or osascript processes from remote command payloads.
- Cloud-native tools such as SSM Run Command or Intune: script execution on endpoints that originates outside expected org IDs, admin groups or maintenance windows.
- Network device management such as FortiManager or Cisco Prime: reboots or config pushes made by abnormal accounts or from abnormal IP addresses.
The common thread is context. Deployment tools run code all day, so the question is not whether a command ran but whether it matches a change window, an approved package and a known administrator. Process creation logs on endpoints, audit logs from the management console, and cloud control plane logs are the main sources.
A useful habit is to keep a short list of who may push software, from where and when. Any push that does not match that list is worth a human look.
How to reduce the risk
MITRE lists these mitigations. In plain steps:
- Limit who can use the system. Grant access to deployment systems only to a limited number of authorized administrators (Privileged Account Management).
- Require multi-factor authentication and firewalls for critical network systems, so the console is isolated from ordinary user traffic (Multi-factor Authentication, Network Segmentation).
- Use group policy to isolate critical systems and keep admin accounts separated by privilege (Active Directory Configuration, User Account Management).
- Make credentials unique. Accounts that can reach deployment systems should not be reused anywhere else in the network (Password Policies).
- Keep third-party access traceable. Accounts used by vendors should map to one vendor, should not be shared across vendors, and should be reviewed regularly, with a record of when access is removed (User Account Management).
- Patch the deployment system itself, so that a privilege escalation flaw does not hand over the console (Update Software).
- Restrict which third-party management suites are installed in the first place (Limit Software Installation).
- If the system can deploy only signed binaries, keep the trusted signing certificates off the deployment server, on a system that is not remotely reachable or is tightly controlled (Remote Data Storage).
- Set a strict approval policy for using deployment systems, and make sure staff know it (User Training).
Check your own environment
Start with an inventory and a few questions:
- List every deployment or management tool in use, including SaaS ones and the ones owned by other teams. Who administers each?
- Which accounts can push code to all endpoints? Does each have MFA, and is each one used nowhere else?
- Which vendors have standing access? Is there a ticket behind each account?
- Are management console logs forwarded to your log store, and are push events alerted on outside change windows?
- Does any CI/CD runner hold credentials that can call a management API?
On a Windows host, one read-only way to see recent process creation, if Sysmon is installed, is to query its operational log for event ID 1:
wevtutil qe Microsoft-Windows-Sysmon/Operational /q:"*[System[(EventID=1)]]" /c:20 /rd:true /f:text
Review the parent process of anything launched by your management agent.
Try it yourself
Deployment pipelines are where a bad change reaches production fastest. This demo shows a production gate in action.
Click through it at your own pace, or open it full screen.
Quick check
Why does MITRE treat access to a deployment console as more serious than access to one endpoint?
Because the console can run commands on every system it manages. MITRE notes that access may enable remote code execution on all connected systems.
Name two mitigations that protect the signing material used by a deployment system.
MITRE's Remote Data Storage mitigation says to keep trusted signing certificates off the deployment system, on a system that cannot be accessed remotely or is tightly controlled. Limiting administrator access to the system supports this.
Sources
- MITRE ATT&CK, T1072 Software Deployment Tools: https://attack.mitre.org/techniques/T1072/
