Amadey Exploiting Self-Hosted GitLab to Distribute StealC

By Rahul Sharma · December 18, 2025

Executive summary

Amadey is a malware loader that has been active since 2018, primarily used to distribute second-stage payloads and infostealers. While Amadey has been previously known to distribute payloads through GitHub, we recently discovered a new campaign leveraging an exploited self-hosted GitLab instance to deliver the StealC infostealer.

This analysis reveals how threat actors are hijacking abandoned, self-hosted GitLab servers to create a legitimate-looking payload distribution infrastructure. The use of a long-standing domain with valid TLS certificates provides an effective evasion technique against traditional security controls.

Key findings:

• Amadey loader exploiting compromised self-hosted GitLab infrastructure for payload delivery
• Custom Base64 encoding and RC4 encryption for string obfuscation and C2 communication
• Multi-process execution model for parallel payload deployment
• Clipper plugin for cryptocurrency wallet address swapping
• StealC infostealer as the final payload targeting browser credentials

GitLab infrastructure exploitation

The Amadey loader was observed pulling payloads from a self-hosted GitLab instance on the long-standing domain bzctoons.net. A quick WHOIS lookup reveals that this domain was first registered in 2003. The main domain and the GitLab subdomain (gitlab.bzctoons.net) run on different IP addresses.

The user account that uploaded the repository is several years old, but the malicious repository was created only a few days ago, specifically to host additional payloads for Amadey.

Overall, the domain appears to belong to a small-scale organization hosting GitLab with multiple users. Evidence suggests that either the user account or the entire infrastructure has been compromised.

Technical analysis

Infection flow diagram

The following diagram illustrates the actual process tree observed during Amadey execution:

As shown in the process tree, Yfgfwb.exe (the Amadey loader) spawns multiple child processes to perform different malicious activities in parallel: 

rundll32.exe - Loads the clip64.dll plugin for additional functionality
powershell.exe - Expands archived payloads using Expand-Archive
x64_protect.exe - The StealC infostealer payload that performs credential theft from browsers (chrome.exe, msedge.exe) 
cmd.exe - Handles persistence by killing, renaming, and restarting the malware from Appdata

Initial execution and environment setup

Mutex protection

The Amadey loader (Yfgfwb.exe) first checks for an existing mutex to prevent multiple instances from running simultaneously. If no mutex exists, it creates one to ensure exclusive execution. The mutex name is stored in plain text within the .rdata section.

Mutex details:

Self-copy and relocation

The AppData folder name and the file name are hardcoded into the binary but stored in encrypted form. If the malware is not already running from its designated location, it drops a copy of itself and executes from there. 

Finally, it terminates the current running instance to re-launch itself from AppData: 

Environment configuration:

String encryption and decryption

String storage

The malware stores all critical strings in the .rdata section in encrypted form. However, the mutex name, decryption key, and the Amadey botnet ID are stored in plain text within the .rdata section. The decryption key is used to decrypt all other encrypted strings.

Key information:

Custom Base64 implementation

Amadey uses a modified Base64 algorithm for string decryption with a custom character set.

The malware implements its Base64 variant by replacing the standard character set with a custom one:

Standard Base64:

Amadey custom Base64:

Decryption results

All encrypted strings can be decoded using the custom decryption algorithm. The following example shows successfully decoded strings:

IDAPython string decryption script

To assist with analysis, the following IDAPython script can automatically decrypt Amadey's encrypted strings:

Antivirus detection

Amadey attempts to identify installed security software to tailor its behavior accordingly. It checks for the following products and assigns a numeric code:

Command and Control communication

The malware communicates with its Command and Control (C2) server using plain HTTP requests. Once initialized, Amadey decrypts its C2 server configuration to establish communication with the command server.

C2 configuration

C&C Server: 91.92.243.129/0gjSy4hf3/index.php
Bot ID: 0702f
Protocol: HTTP
Purpose: Send system information and receive commands

C2 command flow

Communication encryption

Before sending system information data, Amadey encrypts it using the RC4 algorithm with the mutex value as the encryption key. This provides a simple obfuscation layer for C2 communications.

C2 communication protocol

The initial beacon contains extensive system profiling data sent as encrypted body parameters. Below is a breakdown of the captured traffic parameters:

The data after the r= parameter is encrypted using the mutex value as the RC4 key. Below is an example of the decrypted data structure:

Screenshot exfiltration

The following example shows Amadey uploading a screenshot of the infected system. The image itself is transmitted unencrypted.

Plugin loading

Amadey supports various plugins as extensions. In this case, it requests clip64.dll from the C2 server.

This plugin is loaded via rundll32.exe and functions as a clipper module responsible for swapping copied cryptocurrency wallet addresses with the threat actor's addresses.

Payload execution

After establishing C2 communication, Amadey awaits commands and executes various malicious operations. 

Command execution capabilities

Amadey maintains an extensive command handler with switch-case logic for processing C2 commands. Its capabilities include: 

Downloading and executing DLL plugins 

Deploying third-party payloads 

Process injection 

System reconnaissance 

StealC payload delivery

The C2 server provides a URL to download the StealC infostealer: 

This ZIP archive is downloaded and extracted to:

After execution, the StealC component starts communicating with its own C2 at

Persistence mechanisms

Amadey establishes persistence on the infected system through multiple methods:

Scheduled Task: Creates a task to run at user login with highest privileges
Job File: Creates C:\Windows\Tasks\Yfgfwb.job for task scheduling

This final operational phase demonstrates Amadey's role as a sophisticated loader, delivering additional malicious components (such as StealC) based on instructions from the command and control infrastructure.

Conclusion

Threat actors continue to abuse legitimate platforms for malware distribution, with Amadey operators now exploiting abandoned self-hosted GitLab instances alongside previously documented GitHub abuse. By leveraging trusted infrastructure, these campaigns effectively evade traditional security controls. Amadey remains a persistent threat since 2018, demonstrating effective loader capabilities through its modular plugin system, custom obfuscation techniques, and multi-stage payload delivery.

Organizations should regularly audit self-hosted development infrastructure like GitLab and GitHub instances, disable inactive accounts, enforce the access control, and monitor for unusual file downloads from DevOps platforms. Behavioral detection for process chains involving rundll32 and PowerShell can help identify loader activity, while network segmentation can limit the impact of compromised development servers.

At Trellix, we have multiple levels of protection against Amadey. With the evolving threat landscape, we remain committed to keeping our customers safe.

Indicators of compromise (IOCs)

File hashes

Network indicators

Other system artifacts

Appendix A - Trellix detection signatures

Trellix EDR Detections

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