Breaking Down the Casbaneiro Infection Chain

Background

In 2018, the Casbaneiro banking Trojan (also referred to as Metamorfo) surfaced in mass MalSpam campaigns targeting Latin America. The primary objective, based on built-in functions, was to record keystrokes and harvest user credentials for financial websites.

To this day, the campaign is still very active with the target objective of financial gain. The threat actors behind the campaign utilize a variety of techniques to avoid detection and execute malicious code on compromised assets. A high-level visual representation of the multi-stage infection chain, depicted in Figure 1, has been derived from incidents investigated and mitigated by Sygnia’s Incident Response Team.

Initial access & propagation

The infection begins with a malicious email written in Spanish emphasizing the urgent need for reviewing a PDF attachment (“Comprobante_Fiscal_Digital.pdf”). These attachments typically contain an invoice with a web link to a URL which claims to contain further details.

Once a user has accessed the website, they are prompted to download a zip archive containing a malicious “.cmd” script. Clicking the script initiates a series of commands hidden from view, and will trigger the download of additional scripts and binaries from one of many selected malicious domains.

As with many similar incidents, the adversary utilizes a “living-off-the-land” approach, using common binaries and scripts, most notably PowerShell, in order to carry out a variety of tasks. The threat actors use variables that include non-standard characters, strings encoded in Base64 UTF-16LE (Unicode), and which operate in memory during execution, all in an attempt to avoid detection and hamper reverse-engineering.

A series of system discovery commands leveraging PowerShell and Windows Management Instrumentation (WMI) are carried out on the victim host, in order to fingerprint the system. This includes the collection of basic information such as the language, AntiVirus software, operating system version, CPU and hostname:

• $lang = Get-Culture
• { $AntivirusProduct = Get-WmiObject -Namespace “root\SecurityCenter2” -Query
  “SELECT * FROM AntiVirusProduct” @psboundparameters
• $winds = (Get-WmiObject -class Win32_OperatingSystem).Caption
• $env:PROCESSOR_ARCHITECTURE
• $env:computername

As with most MalSpam campaigns, we would expect to see an increased number of malicious emails received from external domains. However, of particular interest in our analysis, we have observed the threat actors installing Outlook Messaging Application Program Interface (MAPI) via PowerShell to harvest email addresses/contacts, which are then exfiltrated via HTTP POST requests to a command and control (C2) server. One function that is dedicated to checking data received into a variable follows the relevant email address format using the regular expression:
^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$))

The objective at the end of the process is to leverage the compromised host to send thousands of incidents of MalSpam internally to unsuspecting employees of the organization. This adds credibility to the email sent, as there are no obvious anomalies in the email headers (suspicious external domains), which would typically trigger email security solutions to act and mitigate. The emails include the same PDF attachment used to compromise the previous victim hosts, and so the chain is executed once more.

Staging bundled malware, persistence & execution

The setup of the malware involves multiple scripts and legitimate binaries that are downloaded as part of the previous stages. During one of the infection stages, a zip file is dropped into the directory “\Users\Public\”, in order to stage one of two bundles.

A “.cmd” script with a filename matching the victim hostname is used to randomly generate a directory on the root of volume “C:\” following the naming format of the folder as “_<6 letters + 1 number>_<capital letter>”. This can be translated into a regular expression for the purposes of identification:

_{1}[A-Za-z]{6}[0-9]_[A-Z]{1}

The next phase in the infection chain is the execution of the banking Trojan malware on the victim host. This is achieved by one of two methods, whilst evading detection. The aforementioned naming convention is used with Execution Method 1 to rename the bundled encrypted binaries. The only exemption to this is Execution Method 2 where only the folder directory and non-DLL recognized binaries are renamed due to the technique leveraged during execution, which we will explore further shortly.

In order to execute the binaries and scripts, shortcut “.lnk” files are created, and masquerade as symbolic links to Internet Explorer, when in fact they point towards the malicious files. The shortcuts are first used to execute the “.cmd” scripts used for renaming the folder and next for executing AutoIt to trigger the start of the execution chain.

Whenever the Windows operating system starts, the legitimate application is launched, thus providing a persistence mechanism. It should be noted that Sygnia did observe deletion of the “.lnk” files on some occasions, post-execution. This is likely because every time the scripts are run, a new randomly named folder directory is generated, anda significant amount of abnormal folder names would be visible and may raise concern amongst users if spotted.

Execution Method 1

The first method of execution involves utilizing a legitimate signed AutoIt PE binary, in order to execute an encrypted AutoIt script. An encrypted AutoIt script is used to export a malicious function from the third bundled binary, which is the encrypted Trojan. As the process is invoked under a trusted application, the actions subsequently taken may seem legitimate.

As depicted in Figure 6, three binaries are present in the first bundle: AutoIt (“exe.png”), an encrypted AutoIt script (“1”) and the encrypted Trojan (“m”). As previously mentioned, these binaries are renamed post-creation by the “.cmd” script following the naming convention. By reviewing the script binary in a HEX editor, it’s possible to obtain metadata such as the versioning, creation time, and the MD5 hash value of the password used to encrypt the script via the Jos van der Zande AutoIt3 Obfuscator.

Once decrypted and decompiled, the script contains multiple functions which focus on cryptography primarily for the objective of decrypting the Trojan. During the decryption process, a new decrypted binary with a specific file extension is created in the current working directory and then a DllCall is made to invoke the function “F0x000102030405060708090A0B0C0D0E0F” that is exported from the malicious decrypted dynamic link library (DLL) binary, resulting in execution. 

The file extensions of the decrypted payload were hardcoded and could be any of the following, .ai, .ia, .db, .a1, .bc, .iaa. However, these were typically used to masquerade the decrypted payload (i.e. .db, an SQLite database extension).

Execution Method 2

The second method of execution uses a different version of the archive “m.zip” bundle. As depicted in Figure 6, three binaries are present in the bundle; a legitimate Oracle Java Platform SE 8 PE (“exe.png”), a legitimate Microsoft Visual Studio 2010 (“MSVCR100.dll”) and a malicious dynamic link library (DLL) masquerading as a legitimate file (“jli.dll”) commonly used in conjunction with the Oracle Java (“kinit.exe”) file.

A review of the import functions required by the Oracle Java application, as depicted in Figure 12, confirms the requirement for a supposing (“jli.dll”) binary developed by Oracle to be present.

On closer inspection of the (“jli.dll”) binary, it does not appear to have been developed by Oracle, based on a review of static properties, as depicted in Figure 13. However, the binary does have export function names which are expected and required by the Java application.

This is significant, as the adversary intends to facilitate DLL search order hijacking by placing the malicious DLL file in the same directory as the legitimate Oracle Java application. This will then be used for DLL side-loading the malicious payload, resulting in execution.

Sygnia was able to identify numerous different payloads, compiled and deployed by the adversary from December 2021 through February 2022. Some were packed via “VMProtect” and unpacked into memory upon execution, whilst others were encrypted and only decrypted upon execution. All of the DLL files were written in Pascal, compiled by “borlanddelphi”, and were found to contain Portuguese language strings throughout. Additional embedded functions were found to be obfuscated to hamper reverse-engineering. What was consistent was the use of the magic string “Staticdata” as the software product reference in the file properties. This could be utilized to identify any decrypted payloads on hosts, which may not be known to AntiVirus signature databases.

Following further analysis of multiple malware binaries, once initially executed, the malware harvests information including the hostname, operating system version and AntiVirus software installed. This data is then exfiltrated to a hardcoded command and control (C2) server via port 80 (HTTP), and the malware awaits further commands.

Full reverse-engineering details are beyond the scope of content for this report. Functions were observed to facilitate recording keystrokes from the compromised host. Whilst the malware currently has no known links to facilitate access to other threat actors, operating under a strict regime, this could lead to more nefarious activities and therefore effective mitigation should be deployed at the earliest opportunity.

To learn more about Sygnia’s Incident Response services click here.

If you are currently impacted by a cyber incident, or are seeking guidance, please contact us or call our 24/7 hotline +1-877-686-86

Appendices

YARA Rules

Indicators of Compromise 

Domains & IPs

File Hashes

MITRE ATT&CK® TTPs

Initial Access:

1. T1566 – Phishing
   1. T1566.001 – Phishing: Spearphishing Attachment
   2. T1566.002 – Phishing: Spearphishing Link
   Execution:
   
2. T1204 – User Execution
   1. T1204.002 – Malicious File
3. T1059 – Command and Scripting Interpreter
   1. T1059.001 – PowerShell
   2. T1059.003 – Windows Command Shell
4. T1574 – Hijack Execution Flow
   1. T1574.001 – DLL Search Order Hijacking
   2. T1574.002 – DLL Side-Loading
5. T1129 – Shared Modules
6. T1047 – Windows Management Instrumentation 
   
   Persistence:
7. T1547 – Boot or Logon Autostart Execution
   1. T1547.009 – Shortcut Modification
   Defense Evasion:
   
8.  T1140 – Deobfuscate/Decode Files or Information
9. T1036 – Masquerading
   1. T1036.005 – Match Legitimate Name or Location
   2. T1036.007 – Double File Extension
10. T1027 – Obfuscated Files or Information
    1. T1027.002 – Software Packing
    Credential Access:
    
11. T1056 – Input Capture
    1. T1056.001 – Keylogging
    2. T1056.002 – GUI Input Capture
    Discovery:
    
12. T1518 – Software Discovery
    1. T1518.001 – Security Software Discovery
13. T1033 – System Owner/User Discovery
14. T1082 – System Information Discovery
    
    Collection:
    
15. T1115 – Clipboard Data 
16. T1119 – Automated Collection
    
    Command & Control:
    
17. T1102 – Web Service
    
    1. T1102.003 – One-Way Communication
    Exfiltration: 
    
18. T1041 – Exfiltration Over C2 Channel
19. T1071 – Application Layer Protocol
    1. T1071.001 – Web Protocols

If you are currently impacted by a cyber incident, or are seeking guidance, please contact us or call our 24/7 hotline +1-877-686-86

This blog post and any information or recommendation contained herein has been prepared for general informational purposes and is not intended to be used as a substitute for professional consultation on facts and circumstances specific to any entity. While we have made attempts to ensure the information contained herein has been obtained from reliable sources and to perform rigorous analysis, this advisory is based on initial rapid study, and needs to be treated accordingly. Sygnia is not responsible for any errors or omissions, or for the results obtained from the use of this blog post. This blog post is provided on an as-is basis, and without warranties of any kind.