Defending Against ClickOnce Abuse for Persistence and Initial Access

Microsoft ClickOnce technology, designed to simplify the deployment and updating of Windows applications, is increasingly targeted by adversaries for initial access and long-term stealth. According to CrowdStrike, this legitimate feature allows users to install applications by clicking a link in a web browser or opening a Phishing email attachment, often bypassing traditional security measures that focus on standard installers.

Technical Analysis of ClickOnce Abuse

ClickOnce applications rely on two primary XML files: the deployment manifest (.application) and the application manifest (.exe.manifest). When a user interacts with a ClickOnce link, the dfshim.dll library facilitates the download and execution of these manifests via the dfsvc.exe process.

Adversaries exploit this by crafting malicious manifests that point to an external C2 server. Because ClickOnce is a native Windows feature, the initial execution often appears benign to legacy antivirus solutions. Furthermore, the technology includes a built-in trust prompt. If an application is not signed by a trusted certificate, the user is presented with a warning. However, threat actors often use stolen or low-cost code-signing certificates to lend an air of legitimacy to the prompt, increasing the likelihood of successful social engineering.

ClickOnce Deployment Manifest Persistence Strategies

One of the most effective TTP sets involves ClickOnce deployment manifest persistence. Unlike traditional software that installs to C:\Program Files, ClickOnce applications are installed in the user’s %LOCALAPPDATA%\Apps\2.0 directory. This per-user installation does not require Privilege Escalation, making it an attractive target for actors seeking to maintain a foothold without triggering UAC prompts.

Persistence is often achieved by abusing the automatic update feature. The deployment manifest can be configured to check for updates before the application starts. By pointing this update location to an attacker-controlled server, the adversary can swap the benign executable for a malicious payload at any time, effectively turning a legitimate tool into a persistent backdoor.

Detection and Mitigation Strategies

To protect the environment, the SOC must understand how to detect ClickOnce exploit attempts by monitoring specific process behaviors and network connections.

Monitoring and Logging

Detection should focus on the activities of dfsvc.exe and dfshim.dll. Security teams should monitor for:

• dfsvc.exe making unusual outbound network connections to unknown or newly registered domains.
• Unexpected file creation within the %LOCALAPPDATA%\Apps\2.0 subdirectories.
• ClickOnce installations initiated from uncommon parent processes, such as outlook.exe or winword.exe.

Integrating these observations into a SIEM or EDR platform can help identify anomalies. Using the MITRE ATT&CK framework, these activities typically map to techniques like T1547.001 (Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder) and T1204.002 (User Execution: Malicious File).

Preventing Unauthorized Installations

The most effective way to eliminate this attack surface is to disable ClickOnce trust prompt via GPO for untrusted zones. Administrators can navigate to the registry or use administrative templates to define the behavior of the ClickOnce Trust Manager.

Key mitigation steps include:

• Restricting ClickOnce installations to the ‘Local Intranet’ or ‘Trusted Sites’ zones.
• Setting the ‘Internet’ and ‘Untrusted Sites’ zones to ‘Disabled’ for ClickOnce deployment.
• Implementing Windows Defender Application Control (WDAC) or AppLocker to restrict execution to signed, authorized applications.

By proactively managing these settings, organizations can significantly reduce the risk of a successful IoC appearing due to ClickOnce abuse.