T1127.002: ClickOnce
Adversaries may use ClickOnce applications (.appref-ms and .application files) to proxy execution of code through a trusted Windows utility.[1] ClickOnce is a deployment that enables a user to create self-updating Windows-based .NET applications (i.e, .XBAP, .EXE, or .DLL) that install and run from a file share or web page with minimal user interaction. The application launches as a child process of DFSVC.EXE, which is responsible for installing, launching, and updating the application.[2]
Because ClickOnce applications receive only limited permissions, they do not require administrative permissions to install.[3] As such, adversaries may abuse ClickOnce to proxy execution of malicious code without needing to escalate privileges.
ClickOnce may be abused in a number of ways. For example, an adversary may rely on User Execution. When a user visits a malicious website, the .NET malware is disguised as legitimate software and a ClickOnce popup is displayed for installation.[4]
Adversaries may also abuse ClickOnce to execute malware via a Rundll32 script using the command `rundll32.exe dfshim.dll,ShOpenVerbApplication1`.[5]
Additionally, an adversary can move the ClickOnce application file to a remote user’s startup folder for continued malicious code deployment (i.e., Registry Run Keys / Startup Folder).[1][6]
Analyst context for executives and security teams
ClickOnce matters because it can let code run through a trusted Windows deployment mechanism with minimal user interaction and without administrative installation rights. For leaders, the risk is not just “malware execution”; it is whether the organization can distinguish legitimate self-updating .NET application use from abuse that blends into normal Windows behavior.
Executive priority
Prioritize this where Windows users can launch ClickOnce applications from web pages or file shares, especially in environments that rely on browser-based software delivery or lightweight user-installed applications. The key business question is whether web access controls, software trust policy, and SOC telemetry provide enough evidence to prove what was launched, from where, by whom, and whether persistence was attempted through startup locations.
Technical view
This is a Windows sub-technique under Trusted Developer Utilities Proxy Execution, associated with stealth and execution. Validate visibility around ClickOnce file types such as .appref-ms and .application, DFSVC.EXE launching applications, and related proxy execution patterns involving trusted Windows components. Because ATT&CK provides no official detection text for this object, use the related DET0191 behavior-chain strategy as direction: correlate user-driven launch context, web or file-share origin, process ancestry, application install/update behavior, and any follow-on persistence such as startup folder placement.
Likely telemetry
- Windows process creation telemetry, including parent/child relationships involving DFSVC.EXE
- Command-line telemetry for trusted Windows utilities associated with ClickOnce launch behavior
- File creation and execution events for .appref-ms and .application files
- Browser, web proxy, or secure web gateway logs showing access to ClickOnce delivery locations
- File share access logs where ClickOnce applications may be launched from network locations
Detection direction
- Build behavior-chain detections rather than relying on a single binary name, because ClickOnce has legitimate administrative and business uses.
- Baseline legitimate ClickOnce usage by department, application source, signer, and hosting location before treating all DFSVC.EXE activity as suspicious.
- Correlate ClickOnce launch events with recent web visits, downloads, file-share access, and user execution activity.
- Review child processes and post-launch behavior for unusual network activity, unexpected payload locations, or persistence attempts.
- Tune false positives for approved internal ClickOnce applications and documented software deployment workflows.
Mitigation priorities
- Restrict web-based content using URL filtering, download restrictions, and controls over access to untrusted ClickOnce delivery locations.
- Disable or remove ClickOnce-related capability where the business does not require it, using change control to avoid disrupting legitimate applications.
- Apply code-signing and software trust controls so only authorized and trusted software sources are permitted where feasible.
- Harden monitoring around startup folders and related persistence locations because the ATT&CK description notes ClickOnce application files may be moved there for continued deployment.
- Document approved ClickOnce applications and owners so SOC and incident response teams can quickly separate expected business use from suspicious execution.
Analyst notes and limits
The supplied ATT&CK object is a sub-technique of T1127 Trusted Developer Utilities Proxy Execution and is limited to Windows. The strongest defensive value is in validating whether ClickOnce is expected in the environment and whether telemetry can connect user action, source location, trusted utility execution, and follow-on persistence.
ATT&CK does not provide official detection guidance for this object in the supplied fields. This take relies on the official description, external references, and listed relationships, including DET0191 and mitigations M1021, M1042, and M1045. Local software inventory, proxy policy, endpoint logging depth, and approved application deployment practices are required to assess actual risk and coverage.
ClickOnce
Adversaries may use ClickOnce applications (.appref-ms and .application files) to proxy execution of code through a trusted Windows utility.[1] ClickOnce is a deployment that enables a user to create self-updating Windows-based .NET applications (i.e, .XBAP, .EXE, or .DLL) that install and run from a file share or web page with minimal user interaction. The application launches as a child process of DFSVC.EXE, which is responsible for installing, launching, and updating the application.[2]
Because ClickOnce applications receive only limited permissions, they do not require administrative permissions to install.[3] As such, adversaries may abuse ClickOnce to proxy execution of malicious code without needing to escalate privileges.
ClickOnce may be abused in a number of ways. For example, an adversary may rely on User Execution. When a user visits a malicious website, the .NET malware is disguised as legitimate software and a ClickOnce popup is displayed for installation.[4]
Adversaries may also abuse ClickOnce to execute malware via a Rundll32 script using the command `rundll32.exe dfshim.dll,ShOpenVerbApplication1`.[5]
Additionally, an adversary can move the ClickOnce application file to a remote user’s startup folder for continued malicious code deployment (i.e., Registry Run Keys / Startup Folder).[1][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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1127 | Trusted Developer Utilities Proxy Execution | This object subtechnique of Trusted Developer Utilities Proxy Execution. |
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 | 02cbe4371d0e… |
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]
Burke/CISA ClickOnce BlackHat
William Joseph Burke III. (2019, August 7). CLICKONCE AND YOU’RE IN: When .appref-ms abuse is operating as intended. Retrieved September 9, 2024.
Open source URL -
[2]
SpectorOps Medium ClickOnce
Nick Powers. (2023, June 7). Less SmartScreen More Caffeine: (Ab)Using ClickOnce for Trusted Code Execution. Retrieved September 9, 2024.
Open source URL -
[3]
Microsoft Learn ClickOnce
Microsoft. (2023, September 14). ClickOnce security and deployment. Retrieved September 9, 2024.
Open source URL -
[4]
NetSPI ClickOnce
Ryan Gandrud. (2015, March 23). All You Need Is One – A ClickOnce Love Story. Retrieved September 9, 2024.
Open source URL -
[5]
LOLBAS /Dfsvc.exe
LOLBAS. (n.d.). /Dfsvc.exe. Retrieved September 9, 2024.
Open source URL -
[6]
Burke/CISA ClickOnce Paper
William J. Burke IV. (n.d.). Appref-ms Abuse for Code Execution & C2. Retrieved September 9, 2024.
Open source URL -
[7]
mitre-attack T1127.002Open 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.