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.

Anti-Sandbox

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}

Persistence

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}

Execution

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.

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.

IOC

Detections

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. 

Playbooks

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.

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.

Feedback

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.

Contributors

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.