OneClik: A ClickOnce-Based APT Campaign Targeting Energy, Oil and Gas Infrastructure

By Nico Paulo Yturriaga and Pham Duy Phuc · June 24, 2025

The Trellix Advanced Research Center has uncovered a sophisticated APT malware campaign that we’ve dubbed OneClik. It specifically targets the energy, oil, and gas sector through phishing attacks and the exploitation of Microsoft ClickOnce. The campaign exhibits characteristics aligned with Chinese-affiliated threat actors, though attribution remains cautious. Its methods reflect a broader shift toward “living off the land” tactics, blending malicious operations within cloud and enterprise tooling to evade traditional detection mechanisms.

This stealthy operation unfolds across three distinct variants (v1a,BPI-MDM, andv1d), each using a .NET-based loader ("OneClikNet") to deploy a sophisticated Golanguage backdoor ("RunnerBeacon") that communicates with threat actor infrastructure hidden behind legitimate AWS cloud services [3] (CloudFront, API Gateway, Lambda). This makes network-based detection nearly impossible without decryption or deep behavioral analysis.

Our analysis reveals how this campaign has progressively evolved with advanced evasion tactics and C2 obfuscation across each variant. Key findings include abuse of ClickOnce [1] to proxy execution, early injection via .NET AppDomainManager hijacking [2], and anti-analysis measures (anti-debugging loops and sandbox detection).

ClickOnce abuse background

ClickOnce is a Microsoft .NET deployment technology that allows self-updating applications to install and run from remote sources. Although intended for ease of deployment, adversaries can abuse ClickOnce for stealthy code execution [1].

ClickOnce apps launch under the Deployment Service (dfsvc.exe), enabling attackers to proxy execution of malicious payloads through this trusted host. Because ClickOnce applications run with user-level privileges (no user account control required), they offer an appealing delivery mechanism for threat actors aiming to avoid privilege escalation.

In OneClik, attackers sent emails with links to a fake “hardware analysis” site. Visiting the site led to a ClickOnce manifest (an .application file)—cloaked as a legitimate tool—silently downloading and executing. Once launched, the ClickOnce loader injects malicious code via .NET configuration tampering.

Specifically, the loader uses AppDomainManager hijacking (T1574.014) by crafting the .exe.config settings to load a remote malicious DLL at CLR startup [2]. This technique (“AppDomainManager injection”) causes the legitimate .NET executable (e.g.ZSATray.exe, umt.exe or ied.exe) to load an attacker-controlled assembly instead of its normal dependencies. With the loader in place, payload execution proceeds under dfsvc.exe, blending with benign ClickOnce activities.

Infection chain and technical analysis

The OneClik campaign’s infection chain unfolds in stages (Figure 1). In the v1a variant, the victim visited a phishing link from an email (e.g. analysis.html on an Azure Blob Storage) fetched [victim]_Hardware_Analysis_Tool.application. This launched [victim]_Hardware_Analysis_Tool.exe under dfsvc.exe, which in turn loaded a sidecar binary via compiled ClickOnce manifest (cdf-ms) hijack.

That legitimate binary (ZSATray.exe) was then run with a tempered .config. This secondary stage downloaded a .NET DLL and an encrypted shellcode (download temp.dat and fav.ico base64 blob respectively) into memory, eventually injecting a Golang based backdoor (the RunnerBeacon).

In addition to remote malicious DLL side load in v1a and v1d, the loader employs AppDomainManager hijacking by embedding <appDomainManagerAssembly> and <appDomainManagerType> entries in its .config (Code 2), pointing to a local malicious DLL in the archive (e.g. x64\history.tlb) in BPI-MDM. This causes the CLR to load the attacker DLL at startup, enabling code execution before the legitimate application runs.

.NET Loader / Stager Behavior: The initial loader (OneClikNet) is a .NET executable that implements a modular approach for both configuration and payload acquisition. It enumerates on how to obtain the victim ID through four methods: (i) downloading from a C2 server, (ii) reading from a local file, (iii) generating a SHA256 hash of a hardcoded string, or (iv) creating a machine-specific identifier by hashing the victim's computer name combined with a hardcoded string. Similarly, the payload (omnol variable in Code 3) can be obtained through one of three methods: (i) downloading from C2, (ii) reading from a local file, or (iii) using an embedded payload in the binary. This flexible design allows the attacker to adapt multiple methods based on the target environment, while the machine-specific identifier option suggests specific targeting capabilities.

• To obtain the subsequent payload, it decrypts a base64-encoded blob using a hardcoded AES-128-CBC key/IV. Code 4 shows that the encrypted shellcode required a custom pre-processing (certain characters swapped before base64 decode).

Thereafter, it performs a brute-force initialization vector (iv) derivation for AES decryption by iterating through a large number range (1,000,000 to 99,999,999 in Code 5), generating SHA256 hashes of each number, using the hash output to create AES iv, and then attempting decryption until it finds a match with an expected value (bytes2). 

This is done to avoid hardcoding the iv inside the binary, to prevent detection or automated config extraction. However, the decryption key and IV were trivial (e.g., In v1a variant: IV = SHA256(“1000000”), key = d49b78f7dff032f0…). Once decrypted, a dynamic .NET module is created containing x64 shellcode. This module is loaded into a new thread and executed via a small assembly trampoline (Code 6).

The loader executes x64 shellcode is uncommon, by exploiting internal CLR mechanisms, while avoiding traditional methods like P/Invoke. This approach involves creating a dynamic module, crafting a trampoline (jmpCode) to redirect execution, and utilizing .NET's reflection capabilities to manipulate function pointers. Specifically, it leverages internal methods such as System.StubHelpers.StubHelpers.GetNDirectTarget and System.StubHelpers.MngdRefCustomMarshaler.CreateMarshaler to read and write arbitrary memory locations. By doing so, the loader achieves stealthy execution of unmanaged code without invoking standard APIs. This sophisticated technique is detailed in [4].

• Evasion Techniques: Across three variants, multiple anti-analysis techniques were deployed. In v1a, the loader relocates loaded modules (e.g. ntdll.dll, kernel32.dll, etc.) in memory to evade detection, and patches ETW by truncating the EtwEventWrite/NtTraceEvent functions (replacing by a xor rax,rax; retn). It also hides its window via GetConsoleWindow/ShowWindow(SW_HIDE).

In the BPI-MDM variant, significant additions appear. The .NET loader spins up a dedicated thread that periodically checks for debuggers. This loop calls managed and native checks (Debugger.IsAttached, CheckRemoteDebuggerPresent, and NtQueryInformationProcess(debugport 7) and exits if any debugger is found. Such anti-debugging is a known evasive tactic (ATT&CK T1622 [5]).

In the v1d variant, we observed more environment checks. The malicious DLL loaded by AppDomainManager performs sandbox/VM fingerprinting. It calls NetGetJoinInformation and NetGetAadJoinInformation to check if the host machine is domain-joined or Azure AD-joined. If neither check passes (typical for sandboxes), the malware terminates without executing. It also queries physical memory via GlobalMemoryStatusEx, aborting if total RAM is below 8 GB (to avoid common low-resource analysis VMs). Finally, v1d deletes its own .config file after loading, hampering forensic analysis.

• Stager/Shellcode Analysis: The stager in v1a is a compact x64 shellcode. It first resolves essential Windows APIs at runtime (via GetProcAddress and LoadLibraryA). Key APIs include memory management (ZwAllocateVirtualMemory, NtProtectVirtualMemory, NtFreeVirtualMemory) and threading functions, writes the final payload, and spawns threads. The shellcode carries an embedded RC4 key (FD DA 75 5E B4 98 45 BD A6 0B 84 D3 C9 B4 C0 CD). After decrypting and zlib-decompressing the payload, it launches the Go-based backdoor into the target process. 
• Beacon (Go backdoor) Analysis: RunnerBeacon is a Golang-implemented backdoor whose C2 protocol encrypts all traffic with RC4 and serializes data using MessagePack. Each message comprises a fixed header (plaintext length and type ID) and an RC4-encrypted body (MessagePack payload). The initial beacon packet (BeaconData) carries system metadata (hostname, PID, OS/platform identifiers, etc.) along with dynamic status fields (we observed flags like “integrity” and “upstream” keys). The implant includes anti-analysis features such as an “obfuscate_and_sleep” routine and randomized “jitter” in beacon intervals to evade detection. Communications are highly versatile: RunnerBeacon can talk over HTTP(s), WebSockets, raw TCP and even SMB named-pipes. Notably, decompiled code imports the vmihailenco/msgpack library for (un)marshaling and gorilla/websocket for WebSocket handling.

• RunnerBeacon uses a modular message protocol. A 1-byte message type precedes each payload to denote the structure: type 0=BeaconData, 1=BeaconResp; 2=FileRequest, 3=FileResponse; 4=CommandRequest, 5=CommandResponse; 6=StageRequest, 7=StageResponse; 8=SOCKSRequest, 9=SOCKSResponse; 10=FileUpload; 0xB=NoOP; 0xC=CompressedStageRequest, 0xD=CompressedStageResponse; 0xE=OOBSOCKSRequest, 0xF=OOBSOCKSResponse. (For example, FileUpload uses a messaging_FileUpload struct, and SOCKSRequests are used for proxying data.) This extensible design lets the backdoor add capabilities simply by new MessagePack structs. RunnerBeacon also checks for custom commands such as: exit (terminate), ival (callback interval modifications), stop (stop a task) and lists_tasks (enumerate running tasks). 

The C2 server sends a CommandRequest (MessagePack JSON), which the implant unmarshals and passes to the appropriate handler. Supported high-level commands include: executing shell commands (via CreateProcessW with pipes); enumerating processes; file operations (directory listing, upload, download); network tasks such as port scanning across specified hosts/ports; and proxying (establishing a SOCKS5 tunnel). 

Advanced operations are also implemented: for example, it can stage and execute shellcode in a remote process (process injection) and perform token manipulation or impersonation to escalate privileges. Debug source-code symbol strings also revealed a username “runneradmin”, leading us to dub this implant “RunnerBeacon”, though that identifier isn’t exposed in the network protocol.

• RunnerBeacon’s design (Figure 4) closely parallels known Go-based Cobalt Strike beacons (e.g. the Geacon/Geacon plus/Geacon Pro family). Like Geacon, the set of commands (shell, process enumeration, file I/O, proxying, etc.) and use of cross-protocol C2 are very similar. These structural and functional similarities suggest RunnerBeacon may be an evolved fork or privately modified variant of Geacon, tailored for stealthier, and cloud-friendly operations.

Campaign infrastructure

The campaign’s C2 infrastructure leverages legitimate AWS services for obfuscation. In v1a, the beacon contacted a CloudFront distribution domain (dyydej4wei7fq.cloudfront[.]net) and an API Gateway endpoint (b2zei88b61.execute-api.eu-west-2[.]amazonaws.com), making the communications look like normal cloud usage and blends C2 into benign CDN traffic. CloudFront domains are often allowlisted in enterprise networks, hiding the attacker’s endpoint and IP.

In the v1d stage, AWS abuse evolved further. The beacon’s config pointed to an AWS Lambda function URL (.lambda-url.us-east-1.on.aws) as the HTTP callback address. The payload’s C2 flow (Figure 2) thus ran entirely through AWS-managed domains. Such use of AWS services (CloudFront, API Gateway, Lambda, S3, etc.) for C2 has been documented in recent research. By “hiding in the cloud,” attackers exploit the high trust and availability of AWS: defenders must decrypt SSL or denylist entire AWS domains to notice this traffic, which is often impractical. Network analysis showed normal TLS to the AWS domains, resembling typical HTTPS calls, making signature-based detection hard.

Evolution (Comparative Features)

The three samples show a clear progression of capabilities (Table 3). v1a was the simplest: it used a static AES key/IV for payload decryption and minimal sandbox checks (window hiding, ETW patch) but no explicit anti-debugging loops. BPI-MDM introduced a persistent debugger-check thread while loading the second stager from local rather than remote endpoint. v1d added robust environment checks (domain/Azure AD and memory-size) and deleted its config files. All stages used .NET AppDomain hijacking. Notably, the C2 architecture also advanced: v1a beaconed to CloudFront/API Gateway, whereas v1d switched to a Lambda-backed endpoint.

Threat intelligence attribution

We also identified a variant of the RunnerBeacon loader in a Middle Eastern oil and gas sector in September 2023. This unique variant shares over 99% code similarity with OneClik’s RunnerBeacon component, although the delivery vector for that infection remains unknown. This prolonged presence indicates that the campaign is a long-term persistence effort, specifically targeting the energy sector (v1a and v1d variants). Notably, OneClik’s’s use of a .NET-based loader, AppDomainManager hijacking, and in-memory decryption echoes techniques reported in Chinese APT operations. The following points summarize the major TTPs overlaps:

1. AppDomainManager Hijacking: Both OneClik and campaigns such as Earth Baxia [6], AhnLab’s MSC file abuse case [7], and TGSoft's GrimResource [8] reporting use .NET AppDomainManager hijack to load malicious DLLs at CLR runtime.
2. Encrypted Payload Deployment:  Base64-encoded and AES-encrypted shellcode loading via .NET loader is consistently used across ClickOne and Chinese APT-linked activity above.
3. Beacon-Like Backdoors: All campaigns ultimately deploy in-memory payloads with Cobalt Strike–style communication, using modular command sets and staging.
4. Cloud Infrastructure Abuse: [6]’s infrastructure included Alibaba cloud servers. In [7], the attack retrieved components from AWS S3 and an Alibaba/Aliyun endpoint. These patterns suggest a shared preference for cloud-based staging.

Despite the strong overlap in techniques, we emphasize a cautious attribution stance. We assess a possible with low-confidence link between OneClik and Chinese threat actors such as APT41. In the absence of “smoking gun” indicators, we refrain from definitively attributing OneClik to any specific threat actor or nation. 

However, understanding these overlaps is critically important for defenders. These TTPs tend to persist across campaigns, even as threat actors evolve their tooling or obfuscate their identities. By recognizing and mapping the TTPs of this campaign—such as ClickOne abuse, .NET AppDomainManager hijacking, cloud-based staging, and Golang beacons—defenders can proactively harden systems, improve detection logic, and prioritize controls against clusters of behavior known to be effective in the wild.

Trellix detection

Key behaviors: ATT&CK Techniques

Indicators of Compromise (IoCs)

A comprehensive list of IoCs is provided below. Table 1 lists filenames (with SHA256) and URLs found in each sample’s staging chain. Table 2 lists C2 endpoints and config parameters. (All IPs resolved to AWS ranges.)

References

[1] MITRE ATT&CK®, "Trusted Developer Utilities Proxy Execution: ClickOnce, Sub-technique T1127.002 - Enterprise," [Online]. Available: https://attack.mitre.org/techniques/T1127/002/.

[2] MITRE ATT&CK®, "Hijack Execution Flow: AppDomainManager, Sub-technique T1574.014," [Online]. Available: https://attack.mitre.org/techniques/T1574/014/.

[3] B. Caudill, "Hiding in the Cloud: Cobalt Strike Beacon C2 using Amazon APIs," Rhino Security Labs, [Online]. Available: https://rhinosecuritylabs.com/aws/hiding-cloudcobalt-strike-beacon-c2-using-amazon-apis/.

[4] A. Chester, "Weird Ways to Run Unmanaged Code in .NET," xpnsec, [Online]. Available: https://blog.xpnsec.com/weird-ways-to-execute-dotnet/.

[5] MITRE ATT&CK®, "Debugger Evasion, Technique T1622," [Online]. Available: https://attack.mitre.org/techniques/T1622/.

[6] C. T. P. L. S. L. P. C. Ted Lee, "Earth Baxia Uses Spear-Phishing and GeoServer Exploit to Target APAC," TrendMicro, 09 2024. [Online]. Available: https://www.trendmicro.com/en_us/research/24/i/earth-baxia-spear-phishing-and-geoserver-exploit.html.

[7] ahnlab, "Distribution of MSC File Exploiting Amazon Service," 8 2024. [Online]. Available: https://asec.ahnlab.com/en/82707/.

[8] tgsoft, "Chinese APT abuses MSC files with GrimResource vulnerability," 2024. [Online]. Available: https://www.tgsoft.it/news/news_archivio.asp?id=1568&lang=eng.

Discover the latest cybersecurity research from the Trellix Advanced Research Center: https://www.trellix.com/advanced-research-center/