New Abuse of the ClickOnce Technology, Part 1: The Inner Workings of ClickOnce Application Deployment

1. Executive summary

CrowdStrike has published Part 1 of a two-part series documenting abuse of Microsoft's ClickOnce deployment technology. ClickOnce is a Microsoft framework that allows developers to package and distribute applications that run, install, and auto-update without administrative privileges. The blog establishes that ClickOnce's user-friendly design — single-click deployment, no elevation required, publisher signature handling — is being leveraged by threat actors as a malware distribution vector. Part 1 covers the technology's internals; Part 2 (referenced but not yet reviewed in this advisory) will cover weaponization techniques, a previously undisclosed abuse method, and detection guidance. No specific CVEs, malware families, named threat actors, or indicators of compromise are disclosed in the source material reviewed. The bottom-line risk to EMEA financial services is that any environment running Windows endpoints with ClickOnce-enabled applications (a near-universal condition in Microsoft-centric estates) inherits a delivery vector that bypasses UAC, may evade traditional application-control assumptions, and is now publicly documented as abusable.

2. Regulatory framing

DORA Art. 17, 18, 19, 24, 29, 30 and NIS2 Art. 23 are not directly engaged by the facts disclosed in this item, but may become engaged if a ClickOnce-delivered payload causes a reportable ICT-related incident.

3. Technical analysis & attack chain

What the source confirms

The source material is limited to a high-level description of ClickOnce's design and a forward-reference to Part 2. The following facts are confirmed from the source:

• Technology: ClickOnce is a Microsoft deployment technology that packages applications for distribution, execution, and optional installation.
• Privilege model: ClickOnce-deployed applications run without requiring administrative privileges — a core design feature that also makes the technology attractive to threat actors.
• Update mechanism: ClickOnce supports automatic updates of deployed applications.
• Distribution model: Deployment files (.application manifests and associated payloads) are hosted by the publisher and downloaded by the user; the OS prompts for confirmation only if the publisher's signature cannot be verified.
• Signature handling: Publisher signature verification is performed by the OS prior to deployment; unsigned or untrusted publishers trigger a user confirmation prompt.
• No specific CVE, vulnerability, malware sample, C2 infrastructure, or threat-actor attribution is disclosed in the reviewed source.

Attack chain (as inferable from the source)

Because Part 1 focuses on internals rather than observed intrusions, the attack chain below reflects the abuse surface described by CrowdStrike, not a confirmed incident:

1. Delivery: A user is directed (via phishing link, malvertising, or compromised legitimate site) to download a ClickOnce deployment file (.application manifest) hosted on an attacker-controlled or attacker-compromised web server.
2. User interaction: The user clicks the deployment file. The OS launches the ClickOnce bootstrapper (dfshim.dll / ClickOnce subsystem) without requiring elevation.
3. Signature handling: If the publisher signature is untrusted or absent, the OS displays a confirmation prompt. The user must click through for the deployment to proceed — this is the social-engineering hinge.
4. Deployment: The ClickOnce runtime fetches the referenced payload from the manifest's deployment URL, extracts it to a per-user ClickOnce application cache (typically under %LocalAppData%\Apps\2.0\... or the ClickOnce cache), and executes it.
5. Persistence (potential): Because ClickOnce supports auto-update, a malicious deployment can re-fetch updated payloads on each launch, providing a low-friction persistence and update channel without writing to Run keys or scheduled tasks in the traditional sense.
6. Execution context: The payload runs in the context of the logged-in user — no UAC bypass is required because ClickOnce's design explicitly avoids elevation.

Caveats and unconfirmed claims

• The source states CrowdStrike will disclose "what we believe to be a previously unknown abuse" in Part 2, which is not covered by this advisory. Any specific weaponisation technique, named actor, or novel detection signature is therefore not yet confirmed in the material reviewed.
• The blog references a live talk at REcon 2026 (Montreal, 19 June 2026); technical content delivered at the conference but not yet published may contain additional indicators not captured here.
• No MITRE ATT&CK technique IDs, malware hashes, C2 domains, or actor names are provided in the source. Any attribution to a specific threat actor is unconfirmed.

4. Mitigation & containment

The source material does not provide vendor patches, specific registry keys, or named configuration changes. The mitigations below are derived from the design facts confirmed in the source and standard hardening practice for ClickOnce.

P1 — within 24 hours

• Restrict ClickOnce launch vectors at the endpoint. Use AppLocker or Windows Defender Application Control (WDAC) policies to block dfshim.dll-invoked ClickOnce launches from non-trusted publishers. A starter WDAC rule should deny execution of any ClickOnce deployment whose publisher is not in an explicit allow-list.
• Block outbound traffic from ClickOnce-launched processes to non-trusted origins at the network egress proxy. ClickOnce fetches payloads from the deployment URL specified in the .application manifest; restrict this to allow-listed vendor origins.
• Audit existing ClickOnce deployments in the environment. Inventory all ClickOnce-deployed applications currently present in user profiles (%LocalAppData%\Apps\2.0\ and %LocalAppData%\Apps\2.0\...) and identify their publisher certificates and deployment origins.

P2 — within 72 hours

• Enforce publisher-signature policy. Configure Group Policy to require a valid Authenticode signature from a trusted publisher for any ClickOnce deployment. Unsigned or untrusted-publisher deployments should be blocked or require explicit admin approval.
• Add ClickOnce bootstrapper process telemetry to SIEM. Ensure process-creation logging captures dfshim.dll invocations, the resulting child process tree, and the source URL of the .application manifest.
• User awareness brief. Brief helpdesk and end users that ClickOnce deployment prompts may appear from web links; instruct them to treat any unexpected ClickOnce prompt as suspicious and to report rather than click through.

P3 — within 7 days

• Review and document ClickOnce usage across the estate as part of ICT third-party risk assessment (DORA Art. 28 scope). Identify business-critical applications delivered via ClickOnce and assess concentration risk against Microsoft as the underlying platform vendor.
• Update incident response playbooks to include ClickOnce-delivered payloads as a recognised initial-access vector; ensure forensic procedures cover extraction of ClickOnce cache contents and .application manifest URLs.

5. Indicators of compromise

No indicators of compromise are available in the source material.

No indicators of compromise available in the source material.

6. Detection

Insufficient indicators to author detection rules.

The source material describes ClickOnce's design and announces forthcoming abuse research in Part 2, but provides no specific strings, file paths, registry keys, mutex names, command-line flags, scheduled-task names, or behavioural indicators that can be used to construct a YARA or Sigma rule. A detection rule will be re-evaluated once Part 2 of the CrowdStrike series is published and reviewed.

7. Sources

• CrowdStrike — New Abuse of the ClickOnce Technology, Part 1: The Inner Workings of ClickOnce Application Deployment — https://www.crowdstrike.com/en-us/blog/new-abuse-of-the-clickonce-technology-part-one/ — 18 June 2026
• CrowdStrike — New Abuse of the ClickOnce Technology, Part 2: Stop Threat Actors from Clicking Once and Staying Forever — https://www.crowdstrike.com/en-us/blog/new-abuse-of-the-clickonce-technology-part-two/ — referenced, not yet reviewed

8. Adverse Trace position

Severity: Moderate (provisional). ClickOnce is a near-universal component of Windows estates and its abuse as a malware delivery vector is now publicly documented. The lack of a required CVE patch, combined with the technology's design intent to bypass UAC and its support for auto-updating payloads, elevates the risk profile for any environment that has not explicitly restricted ClickOnce execution. No specific CVE score, CISA-KEV listing, or named threat-actor attribution is available in the source material; severity is therefore provisional and will be reassessed when Part 2 of the CrowdStrike series is published. Client impact: financial entities should immediately audit ClickOnce usage, restrict the technology via application control, and prepare for Part 2 to potentially disclose a previously unknown abuse technique. Next steps: Adverse Trace will issue an updated advisory (AT-2026-06-19-128 v1.1) upon publication and review of Part 2, incorporating any disclosed IOCs, detection signatures, and actor attribution. Clients requiring interim guidance on WDAC/AppLocker policy authoring for ClickOnce should engage their Adverse Trace account manager.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.