Trusted Developer Utilities Proxy Execution (T1127) is a technique under stealth and execution in MITRE ATT&CK. MITRE lists Windows.
Developer tools are built to run code. Many are signed by their vendor. That combination is exactly what an attacker wants: a trusted binary doing the running.
How attackers use it
MITRE describes taking advantage of trusted developer utilities to proxy execution of malicious payloads. Many utilities for building, debugging and reverse engineering can execute code in various forms. They are often signed with legitimate certificates, so they can run on a system and execute malicious code through a trusted process, bypassing application control.
MITRE also covers Smart App Control, a Windows feature that blocks apps it considers potentially malicious by checking unsigned apps against a known safe list from a cloud service. Adversaries may use reputation hijacking, abusing the trust given to safe, signed apps that can execute arbitrary code. Using a developer utility this way may bypass Smart App Control.
How to detect it
MITRE's strategy is a behavior chain for Windows. The analytic looks for a trusted, signed developer utility run in a non-developer context that:
- spawns suspicious children such as powershell.exe, cmd.exe, rundll32.exe, regsvr32.exe or wscript.exe,
- loads unsigned or user-writable DLLs,
- writes and then runs a new executable from user-writable paths, or
- immediately makes outbound network connections.
Context is the point. On a build server, msbuild.exe doing build work is normal. On an accountant's laptop, it is not. Process creation logs with parent, command line and path are the foundation, plus image load and network events.
How to reduce the risk
MITRE lists three mitigations:
- Disable or remove a feature or program. Specific developer utilities may be unnecessary in your environment and should be removed if unused.
- Execution prevention. Block or restrict certain developer utilities if they are not required.
- Restrict web-based content. Consider disabling software installation or execution from the internet through developer utilities.
Keep developer tooling on developer and build machines only, and keep it off standard user images.
Check your own environment
- Which machines have compilers, build tools and debuggers installed, and do they need them?
- Does application control block those tools elsewhere?
- Do you alert on a developer utility with an unusual parent or child?
# Windows (PowerShell): look for MSBuild on this machine (read-only)
Get-Command msbuild.exe -ErrorAction SilentlyContinue
Working through your tool inventory
The family of utilities MITRE covers is broad, and it changes as vendors ship new tools. A practical way to handle that is to start from an inventory, not from a list of names.
- List the developer, debugging and build tools present on each class of machine: developer laptops, build servers, standard user desktops and servers.
- For each class, decide which tools are required. Anything not required is a candidate for removal or a block.
- Apply application control on the classes that have no need. Keep the allow rules narrow on the classes that do.
- For the machines that keep the tools, alert on use outside normal context, such as a build tool launched by an office application or a browser.
Specific sub-techniques, such as MSBuild (T1127.001), get their own detail in this series. The same logic applies to all of them.
Quick check
Why do these utilities bypass application control?
They are signed by a trusted vendor, so controls that allow them will let them run attacker code.
What is the simplest mitigation?
Remove or block developer utilities on systems that do not need them.
Sources
- MITRE ATT&CK, Trusted Developer Utilities Proxy Execution (T1127)
