T1127: Trusted Developer Utilities Proxy Execution
Adversaries may take advantage of trusted developer utilities to proxy execution of malicious payloads. There are many utilities used for software development related tasks that can be used to execute code in various forms to assist in development, debugging, and reverse engineering.[1][2][3][4] These utilities may often be signed with legitimate certificates that allow them to execute on a system and proxy execution of malicious code through a trusted process that effectively bypasses application control solutions.
Smart App Control is a feature of Windows that blocks applications it considers potentially malicious from running by verifying unsigned applications against a known safe list from a Microsoft cloud service before executing them.[5] However, adversaries may leverage "reputation hijacking" to abuse an operating system’s trust of safe, signed applications that support the execution of arbitrary code. By leveraging Trusted Developer Utilities Proxy Execution to run their malicious code, adversaries may bypass Smart App Control protections.[6]
Analyst context for executives and security teams
Trusted Developer Utilities Proxy Execution matters because legitimate Windows developer and debugging tools can become the process that runs unwanted code. For leaders, the risk is not simply “malware execution”; it is that signed, trusted utilities may weaken confidence in application control and Smart App Control decisions, especially on systems where developer tooling is broadly available.
Executive priority
Prioritize this where Windows endpoints rely on application control, signed-binary trust, or Smart App Control as a major prevention layer. Ask whether developer utilities are actually needed on production and user endpoints, whether allowed-tool policies are role-based, and whether the SOC can explain suspicious execution chains involving build, debugging, or deployment utilities. This is also relevant to audit evidence: controls should show not only that application control exists, but that trusted utilities capable of proxy execution are governed and monitored.
Technical view
ATT&CK lists this as a Windows execution and stealth technique with no official detection text. Defenders should validate behavior-chain detection around trusted developer utilities launching or loading unusual payloads, scripts, project files, or child processes. Relationship context includes DET0172, a behavior-chain, platform-aware detection strategy for this technique, and sub-techniques for MSBuild, ClickOnce, and JamPlus, so coverage should be tested at both the parent technique level and those specific utility families. Focus on whether trusted signed utilities are being used outside expected developer workflows, from unusual paths, with unusual command lines, or in chains involving downloads or application-control bypass attempts.
Likely telemetry
- Windows process creation events with command line, image path, parent process, child process, user, and host context
- Application control or execution-prevention logs, including allow/block decisions for signed utilities and launched content
- Code-signing, file reputation, or Smart App Control-related decision evidence where available
- File creation and execution evidence for project, deployment, script, or payload files associated with developer utilities
- Web proxy, browser download, and URL filtering logs for downloaded utilities or payloads, aligned to the Restrict Web-Based Content mitigation relationship
Detection direction
- Because MITRE provides no official detection text, validate detections through local behavior baselines rather than relying on static tool names alone.
- Tune for suspicious chains: trusted developer utility execution followed by unexpected payload execution, child processes, script interpretation, or activity outside known developer systems.
- Separate legitimate developer activity from suspicious use by using role, device group, software inventory, normal working directories, and expected parent processes.
- Include the named sub-technique areas in testing: MSBuild, ClickOnce, and JamPlus, while also allowing for other trusted developer utilities referenced by the parent technique.
- Review false positives from software builds, debugging, Visual Studio workflows, deployment systems, and IT automation before escalating broadly.
Mitigation priorities
- Start by inventorying where developer, build, debugging, and deployment utilities are installed on Windows systems and whether they are needed for the user or server role.
- Use execution prevention controls, including application control and script blocking, to restrict unauthorized code execution and reduce reliance on certificate trust alone.
- Disable or remove unnecessary developer utilities, legacy software, or features from endpoints where they are not required.
- Restrict web-based content and unsafe downloads to reduce delivery paths for files or payloads that may later be proxied through trusted utilities.
- Maintain exception governance for developer systems so legitimate engineering workflows continue while production and standard user endpoints remain tighter controlled.
Analyst notes and limits
This technique is materially important because it sits at the intersection of execution, stealth, application control, and trust decisions. The strongest defensive value comes from proving whether trusted utilities can execute arbitrary content in the local environment and whether telemetry preserves the full process chain needed for investigation.
The supplied ATT&CK object does not provide official detection logic, procedure examples, or adversary relationships. Recommendations are therefore limited to the Windows platform, execution/stealth tactics, listed mitigations, sub-technique relationships, and external-reference themes. Local software inventory, business role context, and endpoint telemetry are required to determine exposure and detection quality.
Trusted Developer Utilities Proxy Execution
Adversaries may take advantage of trusted developer utilities to proxy execution of malicious payloads. There are many utilities used for software development related tasks that can be used to execute code in various forms to assist in development, debugging, and reverse engineering.[1][2][3][4] These utilities may often be signed with legitimate certificates that allow them to execute on a system and proxy execution of malicious code through a trusted process that effectively bypasses application control solutions.
Smart App Control is a feature of Windows that blocks applications it considers potentially malicious from running by verifying unsigned applications against a known safe list from a Microsoft cloud service before executing them.[5] However, adversaries may leverage "reputation hijacking" to abuse an operating system’s trust of safe, signed applications that support the execution of arbitrary code. By leveraging Trusted Developer Utilities Proxy Execution to run their malicious code, adversaries may bypass Smart App Control protections.[6]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 4f3f805c5db8… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
engima0x3 DNX Bypass
Nelson, M. (2017, November 17). Bypassing Application Whitelisting By Using dnx.exe. Retrieved May 25, 2017.
Open source URL -
[2]
engima0x3 RCSI Bypass
Nelson, M. (2016, November 21). Bypassing Application Whitelisting By Using rcsi.exe. Retrieved May 26, 2017.
Open source URL -
[3]
Exploit Monday WinDbg
Graeber, M. (2016, August 15). Bypassing Application Whitelisting by using WinDbg/CDB as a Shellcode Runner. Retrieved November 17, 2024.
Open source URL -
[4]
LOLBAS Tracker
LOLBAS. (n.d.). Tracker.exe. Retrieved July 31, 2019.
Open source URL -
[5]
Microsoft Smart App Control
Microsoft. (n.d.). Smart App Control Frequently Asked Questions. Retrieved April 4, 2025.
Open source URL -
[6]
Elastic Security Labs
Joe Desimone. (2024, August 5). Dismantling Smart App Control. Retrieved March 21, 2025.
Open source URL -
[7]
mitre-attack T1127Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.