# ClickForClickOnce - Generate Configurable Clickonce Payloads | Debjeet Banerjee

### Overview In this Tool Shed presentation, Debjeet Banerjee ("DB"), a malware developer for Black Hills Information Security (BHIS), introduces **ClickForClickOnce**, an open-source framework designed to automate the creation of configurable Microsoft ClickOnce payloads for penetration testing and red teaming. Historically, ClickOnce was used by organizations to distribute self-updating Windows applications with minimal user interaction via a link. For red teams, it offers an effective initial access vector requiring just two user clicks (Open and Run), leaves no artifacts in standard browser download directories, avoids SmartScreen blocks typically seen on EXEs or DLLs, and experiences comparatively fewer detections. However, manual ClickOnce payload creation via Visual Studio on Windows is time-consuming and difficult to automate under engagement deadlines. ClickForClickOnce solves this by offering an automated web interface packaged via Docker.

### Key Topics - **Architecture and Interface:** ClickForClickOnce runs in a Docker container using a Caddy web server (serving static content and zipping artifacts) and a FastAPI backend to handle build configurations. A simple web UI allows operators to build customized payloads without wrestling with complex tool setup or dependencies. - **Configurable Payload Options:** - *Naming:* Tailoring the application display name (e.g., matching a target organization's IT tooling) to make execution prompts believable. - *Size Inflation:* Artificially inflating file size (typically to 200–300 MB) to bypass or delay immediate EDR scanning. The tool inflates the text section up to ~10 MB (to avoid excessive entropy spikes) and appends random data in resource files for the remainder. - *AppDomain Injection:* Running payloads under Microsoft-signed binaries (such as TzSync, PowerShell ISE, ServiceHub, or powershell.exe) to execute shellcode without forced DLL injection. - *Configurable Actions:* Chaining actions including shellcode execution (configurable in `program.cs`, with a default 8-minute delay to counter EDR inspection of read-write-execute memory allocations), dropping files to disk, and executing OS commands (supporting environment variables).

### Technical Details & EDR Detections - **Execution Chain:** Delivering a `.application` file prompts the user to open and run it. The browser invokes Windows ClickOnce handler `dfsvc.exe`. - **EDR Test Results:** Field testing showed strong success with zero detections against Microsoft Defender (MD), SentinelOne, and Sophos. In contrast, CrowdStrike Falcon and Cylance regularly detect the process. The speaker highlighted that detections are rarely triggered by the payload itself; rather, `dfsvc.exe` triggers a call to `rundll32.exe`, which EDRs flag or block outright before shell execution. When shells are established, subsequent beacons are sometimes blocked due to network indicators. Banerjee observed that post-CrowdStrike-outage shifts have pushed EDR focus heavily toward network behavior, domain fronting, and URL/CDN reputation (such as burned Dev Tunnels). - **Browser & Formats:** While modern browsers handle `.application` files, older browsers can utilize `.appref-ms` files, which can also be embedded in documents.

### Takeaways & Defensive Considerations - **Detection Strategies:** Defenders can identify malicious ClickOnce usage by detecting signed binaries (like `powershell_ise.exe`) executing from user AppData directories instead of `System32`. Monitoring for `.exe.config` files associated with AppDomain injection, unusual DLL sideloads, and unexpected `dfsvc.exe` spawning of `rundll32.exe` provides reliable detection opportunities. - **Application Allowlisting:** Although AppLocker can challenge ClickOnce execution, operators can bypass restrictions by using generated artifacts (`.exe.config` and payload DLLs) combined with environment variables to force AppDomain injection when whitelisted executables launch.