Amadey Threat Analysis and Detections

The Amadey Trojan Stealer, an active and prominent malware, first emerged on the cybersecurity landscape in 2018 and has maintained a persistent botnet infrastructure ever since. Several campaigns have used this malware, like the previous Splunk Threat Research blog related to RedLine loader, the multi-stage attack distribution article from McAfee in May 2023 and the campaign where it uses N-day vulnerabilities to deliver Amadey malware noted in March 2023 by DarkTrace.

The emergence and increasing prevalence of Malware as a Service (MaaS) has become a notable trend within the current cyber threat landscape. MaaS has gained popularity as a common tool in the arsenal of threat actors, enabling them to conduct and facilitate widespread cyberattack campaigns.

Malware as a Service refers to a model where cybercriminals offer malware-related services or resources for rent or purchase to other malicious actors. This approach provides several advantages to both skilled and novice attackers.

Amadey is among the prevalent forms of malware that utilize MaaS to deliver multiple malwares, updated copies of itself, and various Amadey plugins or attacks designed for information theft. The figure below illustrates a basic diagram of how Amadey attempts to compromise systems and download several malwares or its plugins for data collection and exfiltration.

This blog post provides a deep dive analysis of this threat, including:

  1. Amadey Anti-Sandbox
  2. Its Persistence mechanism
  3. Its Defense Evasion in terms of file and directory permission modification
  4. C2 communication
  5. Data collection

In the following section, we explore Amadey Tactics, techniques and its capabilities to compromise a targeted host or system.


This Trojan Stealer begins its code by running a function responsible for decoding strings related to the folder name and file name that will be used to check the file path of its running process. If the running process is in

 %temp%\{decrypted_folder_name}\{decrypted_filename}  e.g. (%temp\a9e2a16078\oneext.exe)

it will continue the execution. If the file location doesn’t match, Amadey will terminate its process.

This malware uses two layers of encoding algorithms to its string to evade detection and make the static analysis even harder. The first layer of encoding is a customized encoding followed by a Base64 algorithm.

Figure 1 is the code screenshot of this malware comparing the file path of its running process if it is matched to the decoded file path initialized in its code.

Figure 1: File Path Comparison

It also creates a mutex using CreateMutexA() API to make sure only one instance of its malware process is running on the compromised or targeted host.

Figure 2: CreateMutexA Code


Similar to other malware strains, Amadey employs multiple persistence mechanisms to ensure its survival and automatic execution upon system reboot. Figure 3 is the Amadey registry strings Splunk decoded that are related to its persistence mechanism.

Figure 3: Registry Run Keys

In addition to leveraging the commonly targeted 'Run' and 'RunOnce' registry keys, Amadey modifies the 'startup' value within the 'User Shell Folders' keys, enabling it to automatically execute its malicious drop file upon system reboot.

Figure 4: User Shell Folder Registry

Amadey also creates scheduled tasks as part of its persistence and privilege escalation mechanism. If the permissions on the scheduled task creation are misconfigured, Amadey can take advantage of this to create a scheduled task that runs with higher privileges. 

Figure 5 shows a screenshot of Amadey schedule task (metado.exe) in Attack Range during our testing.

Figure 5: Amadey Schedule tasks

Defense Evasion (File And Directory Permission)

Amadey employs a technique utilizing cacls.exe to modify file and directory permissions or attributes, effectively bypassing access control lists (ACLs) and gaining access to protected files. By configuring read-only access permissions specifically for the active current user on the compromised host, it prevents the user from deleting the dropped copy of itself, ensuring its persistence on the system and as part of its defense mechanism.

The code block below is a simple way to simulate this technique which also available in Atomic Red Team GitHub repo e.g. (T1546.008)

cmd.exe /k echo Y| cacls “{folder_path_you_want_to_have_read_access_only}” /P “Administrator:R

Figure 6 shows the “File Access Denied” when we tried to delete the dropped copy of this Trojan Stealer during testing.

Figure 6: Read Only Permission


Amadey exhibits the capability of remote signing PowerShell scripts, which allows for the unhindered execution of locally created scripts. This technique was observed in the Amadey campaign that disseminated the downloaded LockBit ransomware payload in the form of PowerShell code. To execute the LockBit ransomware PowerShell script, Amadey leverages the RemoteSigned execution policy, ensuring that the script is allowed to run without restrictions. During our analysis, we discovered that the renamed function "mw_init_powershell_cmd()" decodes the command line for remote signing, as shown in Figure 7.

Figure 7: Remote Signing

Command and Control

Amadey will execute 2 threads to establish communication and download payloads/plugins from its command and control (C2) server. This concurrent execution mechanism enables efficient data exchange and retrieval between Amadey and its C2 infrastructure.

Figure 8 shows the Amadey code screenshot that collects system information on the compromised host like OS version, user name, computer name, Domain name and if the current active user is admin or not.

Figure 8: System Information

Amadey compiles the gathered information into a string format and proceeds to send it to its command and control (C2) server. This process involves formatting the data in a structured string to ensure seamless communication with the C2 infrastructure. The figure 9 shows the clear text POST HTTP packet of Amadey to its C2 server to send the formatted system information of the compromised host.

Figure 9: HTTP POST Data

The table below outlines the description of each tag in the HTTP POST data that the Amadey Trojan Stealer attempts to send to its command and control (C2) server. This table provides a detailed breakdown of the tags and their respective meanings in the context of the data being sent.


Tag Value Description
id 236678810173 Compromised host id
vs 3.83 Amadey build version
sd 6286bc Amadey ID
os 2 Windows Server 2016
bi 1 X64 bit architecture
ar 1 Admin privilege
pc AR-WIN-2 Computer Name
un Administrator User Name
dm -unicode- Domain Name
av 13 AV installed (Windefender)
lv 0 GetTaskContent
og 1 Set to 1

Data Collection And Exfiltration (.DLL Plugins)

Amadey attempts to download two specific .dll plugins, namely, "clip64.dll" and "cred64.dll," onto the compromised host. These plugins play a crucial role in collecting sensitive information. To execute these plugins, Amadey utilizes the Windows operating system's rundll32.exe utility, passing the "Main" export name parameter as part of the execution process.

Figure 10.1: Amadey plugins

Figure 10.2: Rundll32 Execution

The clip64.dll plugin plays a pivotal role in the Amadey Trojan's operations. The primary function is to gather clipboard data from the compromised host and transmit it to the designated command and control (C2) server. This is achieved by leveraging the Windows API function GetClipboardData().

Figure 10.3: GetClipBoardData

The cred64.dll plugin, on the other hand, focuses on acquiring sensitive information, specifically browser credentials. It targets a variety of browsers such as Chrome, Opera, Sputniklab, Chromium, Comodo, Vivaldi, Orbitum, CocCoc, Chedot, and CentBrowser. By accessing the user profile files associated with these browsers, as shown in Figure 11.1, the plugin aims to crack or decrypt the stored credentials within the compromised host's browsers.

Figure 11.1: Cred64.dll

Figure 11.2 illustrates a simplified diagram showcasing the functionality of the cred64.dll plugin in its attempt to crack or decrypt passwords stored within the Chrome browser. This process involves accessing specific Chrome profile files, namely "local state" and "login data." By interacting with these files, the plugin aims to retrieve and decrypt the stored passwords.

Figure 11.2: Decrypt Chrome Password

The versatility and adaptability of Amadey are deeply concerning, demonstrated by its widespread utilization of MaaS, anti-sandbox techniques, persistence mechanisms, defense evasion, and advanced data collection capabilities. This Trojan is emblematic of the evolving threats that are pervasive today, using innovative techniques to evade detection and inflict damage. As our detailed investigation shows, Amadey effectively bypasses access control lists, executes remote signed PowerShell scripts, collects system information, and communicates with its C2 server to achieve its malicious objectives.

Additionally, it's worth highlighting the critical role of its .dll plugins in data exfiltration. The "clip64.dll" and "cred64.dll" plugins serve as crucial tools in collecting sensitive data from compromised hosts, further underlining the multifaceted nature of this threat. 

In the subsequent section, we provide the IOCs related to Amadey, followed by the curated detections from Splunk. This further equips security analysts to detect and combat this ever-persistent threat.


Hashes Description
617f4082c320c24f27f69d146aae6973a3cb818860ab196cf2800ff16518c2bc Amadey
89d30f7ba7b2af7f519d2fe066700fae723643e25b1859f32c60618956651710 Amadey
3d5d48ea2b6f76af583e541602950d89b8d96a13654469df3bc58dcddf879e9d cred64.dll
015d60486e75035f83ea454e87afb38d11ec39643c33b07f61a40343078ee4f5 clip64.dll


The Splunk Threat Research Team has curated relevant detections and tagged them to the Amadey Trojan Stealer Analytic Story to help security analysts detect adversaries leveraging the Amadey malware. 

This release used and considered the relevant data endpoint telemetry sources such as:

  • Process Execution & Command Line Logging
  • Windows Security Event ID 4663, Sysmon, or any Common Information Model compliant EDR technology
  • Windows Security Event Log
  • Windows System Event Log
  • Windows PowerShell Script Block Logging 

As an example, the analytic Windows Files and Dirs Access Rights Modification Via Icacls identifies a potential adversary that changes the security permission of a specific file or directory.

| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes 
  where Processes.process_name IN( "icacls.exe", "cacls.exe","xcacls.exe")
  AND Processes.process IN ("*:R*", "*:W*", "*:F*", "*:C*",, "*:N*","*/P*", "*/E*") by Processes.parent_process_name Processes.parent_process Processes.process_name Processes.process Processes.process_guid Processes.dest Processes.user 
  | `drop_dm_object_name(Processes)` 
  | `security_content_ctime(firstTime)`
  | `security_content_ctime(lastTime)` 

Figure 12: File and Directory Permission Modification

The Registry Keys Used For Persistence analytic was updated to detect the registry modification of Amadey to “User Shell Folders” for its persistence mechanism.

Figure 13: Persistence

Overall, the Amadey Trojan Stealer analytic story introduces 11 detections across MITRE ATT&CK techniques. 


Non-hunting detections associated with this analytic story create entries in the Splunk Enterprise Security risk index by default and can be used seamlessly with risk notables and the Risk Notable Playbook Pack. Additionally, the Automated Enrichment playbook pack also works well with the output of any of these analytics.

Playbook Description
Automated Enrichment Moves the event status to open and then launches the Dispatch playbooks for Reputation Analysis, Attribute Lookup, and Related Tickets.
Identifier Reputation Analysis Dispatch Detects available indicators and routes them to indicator reputation analysis playbooks. The output of the analysis will update any artifacts, tasks, and indicator tags.
Attribute Lookup Dispatch Detects available entities and routes them to attribute lookup playbooks. The output of the playbooks will create new artifacts for any technologies that return information.
Related Ticket Search Dispatch Detects available indicators and routes them to dispatch related ticket search playbooks. The output of the analysis will update any artifacts, tasks, and indicator tags.

Why Should You Care?

This blog enables security analysts, blue teamers and Splunk customers to identify Amadey Trojan Stealer malware by helping the community discover Amadey tactics, techniques and procedures that are being used by several threat actors and adversaries. By understanding its behaviors, we were able to generate telemetry and datasets to develop and test Splunk detections designed to defend and respond against this threat.

Learn More

You can find the latest content about security analytic stories on GitHub and in Splunkbase. Splunk Security Essentials also has all these detections available via push update. 

For a full list of security content, check out the release notes on Splunk Docs.


Any feedback or requests? Feel free to put in an issue on GitHub and we’ll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions If you need an invitation to our Splunk user groups on Slack.


We would like to thank Teoderick Contreras for authoring this post and the entire Splunk Threat Research Team for their contributions: Michael Haag, Mauricio Velazco, Lou Stella, Bhavin Patel, Rod Soto, Eric McGinnis, and Patrick Bareiss.


The Splunk Threat Research Team is an active part of a customer’s overall defense strategy by enhancing Splunk security offerings with verified research and security content such as use cases, detection searches, and playbooks. We help security teams around the globe strengthen operations by providing tactical guidance and insights to detect, investigate and respond against the latest threats. The Splunk Threat Research Team focuses on understanding how threats, actors, and vulnerabilities work, and the team replicates attacks which are stored as datasets in the Attack Data repository

Our goal is to provide security teams with research they can leverage in their day to day operations and to become the industry standard for SIEM detections. We are a team of industry-recognized experts who are encouraged to improve the security industry by sharing our work with the community via conference talks, open-sourcing projects, and writing white papers or blogs. You will also find us presenting our research at conferences such as Defcon, Blackhat, RSA, and many more.

Read more Splunk Security Content