Abusing Microsoft ClickOnce as an Initial Access Primitive

TL’DR

ClickOnce was built for frictionless app deployment; attackers use it as frictionless initial access. A user click triggers dfsvc.exe, which fetches and runs payloads from attacker-controlled manifests with minimal scrutiny from email gateways, allowlists, or endpoint controls.

From Manifest to Execution

A ClickOnce application is launched through a .application manifest hosted over HTTP or HTTPS. Once a user clicks the file, the operating system takes over:

  • The manifest is parsed by the ClickOnce runtime
  • dfsvc.exe (Deployment Framework Service) handles installation and execution
  • Referenced binaries are pulled from the remote location defined in the manifest
  • The application launches in the user context

This flow bypasses traditional installer frameworks and script interpreters. Execution occurs through a signed Windows component, with network access and file writes that are expected by design—ideal from an attacker’s perspective.

Why ClickOnce Works So Well for Adversaries

User-Initiated by Design

  • ClickOnce executes only after a user action. No exploit or elevation is required. Payloads run because the platform was designed to do exactly that, removing entire classes of “forced execution” detections.

Trusted Execution Flow

  • Execution is mediated by dfsvc.exe under the Microsoft .NET framework directories. Because it is a signed, legitimate binary, it is often implicitly trusted by application control policies. Many environments trust the launcher without inspecting what it launches.

Flexible and Disposable Infrastructure

  • Manifests are simple XML and can reference binaries hosted on commodity cloud platforms or short-lived domains. Once a delivery pipeline is built, it is easily reused and rotated.

Reduced Security Friction

  • .application files are small, human-readable, and frequently treated as low-risk content by email and web gateways. In practice, they often generate fewer warnings than direct executable downloads, yielding a signed-looking execution path without a signed payload.

How ClickOnce Is Used in Real Campaigns

Multiple threat actors (espionage and financially motivated) deliver .application files via phishing, masquerading as project documentation, regulatory filings, internal dashboards, or software updates. When opened, the manifest triggers outbound requests from dfsvc.exe to attacker infrastructure, retrieves binaries, and executes them as a “deployed application.”

In several cases, ClickOnce is used purely as a loader: the initial manifest stays static while secondary payloads rotate dynamically, letting attackers update implants without changing the lure.

Where Defenses Break Down

Application Control Blind Spots

  • Allowlists often trust dfsvc.exe but do not track its child processes. ClickOnce binaries typically live under %LOCALAPPDATA%\\Apps\\2.0\\ with obfuscated subfolders, making lineage and attribution difficult.

Email and Web Filtering Gaps

  • Because .application files are XML, they are frequently treated as documents, not executable launchers. Hosting manifests on reputable cloud platforms further reduces reputation-based blocking.

Detection Bias

  • Defensive focus remains on macros, script interpreters, and obvious LOLBins. ClickOnce sits outside these categories, making it attractive for low-noise initial access.

ClickOnce as a Reusable Execution Primitive

ClickOnce is dangerous because it is durable. Once attackers invest in a ClickOnce delivery pipeline, they gain a reusable execution primitive that:

  • Scales across campaigns and targets
  • Separates delivery from payload logic
  • Operates within legitimate enterprise workflows

It mirrors historical abuse of HTA files and Office macros—except ClickOnce currently receives far less scrutiny.

Defensive Considerations

Treat ClickOnce as part of your attack surface:

  • Monitor dfsvc.exe child processes for unexpected binaries
  • Inspect outbound connections initiated by ClickOnce activity
  • Treat .application files as executable launchers in email/web gateways
  • Restrict or disable ClickOnce where not operationally required
  • Do not conflate user-initiated execution with user-approved behavior

Closing Thoughts

ClickOnce is not a vulnerability. It is a feature whose trust assumptions no longer match modern threat models. As long as it provides a frictionless path from link-click to code execution, adversaries will continue to abuse it. The challenge is not patching ClickOnce, but recognizing and instrumenting the execution chain.

References