Overview

SonicWall Capture Labs threat researchers have been tracking a Telegram bot malware capable of silently stealing cryptocurrency.  The malware is a cryptocurrency clipboard hijacker and keylogger written in C (GCC/MinGW, native 64-bit PE). It replaces wallet addresses copied to the clipboard with attacker-controlled addresses across 23 coin types, logs keystrokes, and exfiltrates everything exclusively via the Telegram bot API — no custom C2 domain required. On first run it installs three persistent copies of itself under names that impersonate legitimate Windows processes, registers three independent persistence mechanisms (Run key, COM CLSID hijack, WMI subscription), and spawns a watchdog thread to reinstate any that are removed. Live analysis confirmed the C2 channel is active.

Infection Cycle

Stage 1 — API Resolution

On launch, the binary performs no imports from its .idata section beyond the minimum loader bootstrap. Instead, it walks the PEB InLoadOrderModuleList at gs:[0x60] to enumerate loaded modules and resolves every required function via a custom WCHAR-based hash. The hash function uses the FNV-1a initial constant (0x811c9dc5) with a modified mixing step applied per wide character. Each resolved function pointer is stored in a table in the .data section. If any function pointer fails to resolve (returns NULL), the process exits immediately.

The binary resolves functions from at multiple DLL’s that cover file I/O, registry operations, clipboard access, keyboard hooking, WMI command execution, COM object creation, and HTTP communication.

Stage 2 — Anti-Analysis Gates

After API resolution, the binary passes through four sequential anti-analysis checks before reaching any payload logic. Any single failure causes an immediate clean exit (code 0).

The first check reads PEB.BeingDebugged directly from gs:[0x60]+0x2 — any attached user-mode debugger causes an immediate exit before any API calls are made.

The second check is a timing attack. The binary records a timestamp, sleeps for 480 ms, then measures elapsed time. If elapsed time is less than 400 ms — as happens when a sandbox or emulator accelerates execution — the process exits:

The third check calls function: is_hosted_in_loader, which inspects the process environment for signs of an analysis host — checking parent process, desktop session context, and shell environment. The fourth check creates a mutex named koxatppp (generated by a constant-seed LCG with seed 0x7a3b9c1d) and exits if the mutex already exists, preventing a second instance from running.

Stage 3 — Install-vs-Run Decision

After anti-analysis gates pass, the binary checks whether it is running from its expected install path. If the current image path does not match the installed location, the binary proceeds to install itself; if the path matches and all persistence markers are verified, it proceeds directly to the C2 and clipboard polling loop. This path decision prevents a double-install and allows the binary to serve as both the dropper and the persistent payload.

Installation & Persistence

When running for the first time, the binary installs a copy of itself to three locations on disk and registers three independent persistence mechanisms. The install directory names are designed to appear as legitimate Windows subsystem folders.

Disk Locations

All three copies are written via CopyFileW during initial installation. The persistent payload is launched from the primary copy. The install directory names are chosen to appear as legitimate Windows subsystem folders.

• %APPDATA%\Microsoft\Windows\RuntimeBroker\RuntimeBroker.exe — primary copy; this is the process that runs persistently
• %LOCALAPPDATA%\Microsoft\Windows\Security\Health\HealthService.exe — secondary copy
• %APPDATA%\Microsoft\Windows\SearchIndex\SearchIndexer.exe — tertiary copy

Registry & Persistence Mechanisms

Three independent persistence mechanisms are registered on first install, ensuring the implant survives removal of any single one.

Registry Run key: A value named SecurityHealth is written to HKCU\Software\Microsoft\Windows\CurrentVersion\Run pointing to the primary copy. This causes the payload to launch at every user login.

COM CLSID hijack: The malware writes to HKCU\Software\Classes\CLSID\{42aedc87-2188-41fd-b9a3-0c966feab317}\LocalServer32 (and InprocServer32). CLSID {42aedc87…} is a legitimate Windows system class registered in HKLM (the Windows sensor/permissions framework). Because it is absent from HKCU by default, writing a user-hive entry overrides the system registration without requiring elevation — any activation of this COM class will load the malware instead.

WMI subscription: Three sequential wmic.exe calls create a CommandLineEventConsumer and __EventFilter both named WinSysUpdateConsumer, bound together under \root\subscription. The filter query is SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System', which fires approximately every 60 seconds. This persistence mechanism survives Run key and COM entry removal and requires no user interaction to trigger.

Persistence Verification and Self-Repair

After initial install, the persist_verify_and_restore function and the watchdog_entry thread together provide continuous self-repair:

• Both disk copies are verified on each watchdog cycle; missing copies are written from the in-memory binary image via persist_install_from_memory.
• The Run key value is checked; if absent or pointing to the wrong path, it is reinstated.
• The COM CLSID key is checked via comhijack_check; reinstated by comhijack_install if removed.
• The WMI subscription is checked via wmi_check; reinstated by wmi_install if absent.

Behavioral Capabilities

Clipboard Hijacker (Crypto Clipper)

The clipboard_poll_entry function runs in a dedicated thread and continuously monitors the Windows clipboard via OpenClipboard and GetClipboardData. It uses RegisterRawInputDevices to receive raw input notifications for efficient change detection. Dynamic analysis confirmed the polling loop runs at approximately 3.5-second intervals, checking both CF_UNICODETEXT (format 13) and CF_TEXT (format 1) on each cycle. When a clipboard change event fires, the content is inspected against wallet address patterns for 23 cryptocurrency types:

BTC • ETH • SOL • XMR • LTC • TRC20 • TON • DOGE • XRP • BCH • DASH • ADA • ATOM • DOT • NEAR • APT • FIL • ALGO • AVAX • SEI • INJ • OSMO • KAVA

The is_base58 function validates Base58-encoded addresses (used by BTC, XMR, and similar coins). On a match, the clipboard content is replaced with an attacker-controlled wallet address for the detected coin type. The replacement event is exfiltrated to the Telegram bot in the following format:

All 23 replacement wallet addresses were recovered from .rdata (XOR key 0x5a, 24 × 128-byte slots; one slot for AVAX was left empty by the attacker):

Dynamic analysis confirmed the detection and replacement sequence. An ETH address was placed in the clipboard during a live run; the implant detected it within one 3.5-second polling cycle and replaced it silently. The full exfiltration request and server response captured during that event are shown below.

Keylogger

The binary installs a global Windows message hook via SetWindowsHookExA / SetWindowsHookExW and supplements it with raw input capture via RegisterRawInputDevices and GetRawInputData. Keystroke state is polled via GetKeyState, GetAsyncKeyState, and GetKeyboardState. Active window context is captured alongside keystrokes using GetForegroundWindow and GetWindowTextW, allowing keylog output to be annotated with the window title at the time of each keystroke. CallNextHookEx is called to maintain a transparent hook chain that does not disrupt normal keyboard input delivery. 

The following output from dynamic analysis shows the clipboard polling loop observed during the live run:

Victim Profiling

On first install, the binary collects basic victim information and sends an install notification to the Telegram bot:

• External IP address: resolved via HTTPS GET to https://api.ipify.org; response read into a 63-byte buffer
• Computer name: GetComputerNameA / GetComputerNameW
• Username: GetUserNameA / GetUserNameW

The install notification is sent as a Telegram message with the format <b>[INSTALLED]</b> followed by the collected victim fields. Dynamic analysis revealed the full sequence — IP lookup, profiling calls, and Telegram notification — all firing in order:

C2 Communication

All C2 communication uses the Telegram bot API over HTTPS via wininet.dll, with User-Agent: Mozilla/5.0. Requests go to https://api.telegram.org/bot{token}/sendMessage with parameters chat_id, text, and parse_mode=HTML. The bot token (8804363226:AAGNSudXh6Q4-VFi74ICRLSMuFNOreW-7ms) and chat ID (8870420313) are XOR-encoded in .rdata with key 0x5a and were recovered by static analysis. External IP is resolved first via https://api.ipify.org.

The TLS plaintext was captured in full at the BCrypt layer — BCryptEncrypt intercepted outbound data before encryption, BCryptDecrypt intercepted inbound data after decryption.

Execution flow

Executed on Windows 11 22H2 via a scheduled task under the interactive user session (session ID 1). Interactive session required — non-interactive runs crashed with STATUS_DLL_INIT_FAILED during COM/shell32 initialization. The observed execution trace is shown below.

Indicators of Compromise

Files

Registry

Network

Sonicwall Protection

SonicWall Capture Labs protects against this threat via the following signature:

• GAV: Teleclip.STL (Trojan)

This threat is also detected by SonicWall Capture ATP with RTDMI™, SonicWall Endpoint Security, and the Capture Client endpoint solution.