In this article, the Cynet Research team reveals a highly complex attack that runs for only 13 seconds by using several malwares and different tactics. From our analysis, the threat that we discovered within our investigation is name the “ClipBanker” trojan.
The attack flow contains several stages of LOLBins (Living Off the Land) abuse, masquerading, persistency, enumeration techniques, credential thieving, fileless attacks, and finally banking trojan activities.
This attack is also using Fileless techniques in order to evade from security detections. Fileless attack has been a growing threat since 2017 and require highly sophisticated detection and prevention tools to detect and block. The most common Windows tools used in “Fileless” attacks are PowerShell, JS, VBA and WMI. PowerShell is a highly popular tool used for Fileless attack, because PowerShell commands can be executed natively on Windows without writing data to disk.
The ClipBanker Trojan is known as an information stealer and spy trojan, it aims to steal and record any type of sensitive information from the infected environment such as browser history, cookies, Outlook data, Skype, Telegram, or cryptocurrency wallet account addresses. The main goal of this threat is to steal confidential information.
The ClipBanker uses PowerShell commands for executing malicious activities. The thing that made the ClipBanker unique is its ability to record various banking actions of the user and manipulate them for its own benefit.
The distribution method of the ClipBanker is through phishing emails or through social media posts that lure users to download malicious content.
Cynet 360 is protecting your assets against this type of exploit.
The attack flow that is described below contains several known MITRE tactics and techniques.
The strategic goal of the attacker is to steal information. However, in order to do it, the attacker must go through several steps to complete his malicious activity and successfully gain access to the sensitive data from the compromised environment.
In this case, the attacker begins with trying to gain Initial Access (TA0001) to the victim’s environment, in order to gain an initial foothold on the victim machine. Then, they will use several tactics such as Execution (TA0002), in order to execute the malicious code, and Persistency (TA0003), in order to gain persistency on the victim system.
The attackers will often need to gain access to the victim’s system in order to keep the malicious activity going and to gain access to sensitive information from the infected environment. Such sensitive information includes browser history, cookies, Outlook data, Skype, Telegram, or cryptocurrency wallet account addresses. The attackers will then need to accomplish the Collection (TA0009) tactic. This means that the attacker will need to use a Defense Evasion (TA0005) tactics to bypass security application systems from detecting the malicious activity. In order to establish a connection, the attacker will also use a Command and Control (TA0011) tactics to receive instruction commands from a remote server and keep preforming the attack flow.
13 SECONDS ATTACK FLOW:
Attack started at 7:47:43.000 PM:
First Trojan Downloader:
Cynet 360 platform has detected a Trojan Downloader. A downloader is a program that downloads another malware component from the network by connecting to a Command and Control server.
The Trojan Downloader was detected as a child process of RegAsm.exe binary. RegAsm is the Assembly Registration tool that reads the metadata within an assembly and adds the necessary entries to the registry, which allows COM clients to create .NET Framework classes transparently (Microsoft Developer Network). RegAsm (LOLBin) can be used to perform malicious actions such as PE file execution in order to bypass security applications.
As you can see in the screenshot below – Cynet has detected EguiProxy.exe (the Trojan Downloader) that was launched by RegAsm.exe (LOLBin):
- First Downloader: EguiProxy.exe
- MD5: f70428c34a100f9b3a6dbe58aea05def
- SHA-1: 9dd57f78f6f488bc7e96b592a7201040049f4933
- SHA-256: 4a471f05c7624238ef374bbf3af4eeb2abc20f87579ecdbeefea61356e23ae69
Second Trojan Downloader:
Then, the Trojan Downloader downloads another malware from “hxxp://bzqopgtera[.]xyz/” that will be used as an Injector/Downloader and will execute a new malware from \AppData\Local\Temp\ directory:
- Second Downloader: 1849226900.exe
- MD5: e5e13f095613837ff741cf9fb2b68eb0
- SHA-1: e7b63fbd6dc176fa29e208dc1de083c882a6ef01
- Sha256: 1f0ddf5088ac75862fe1d1c4f11f9c39645eee1e4acc938a1f66f14dfc5d5288
The second downloader also initiated a network communication to the same Command and Control server as mentioned above (the same C&C of the first downloader).
The main purpose of this second trojan is to execute a malicious PowerShell command by running CMD.exe. It is worth mentioning that the cmd.exe instance was executed from syswow64 directory. This kind of activity is similar with many other malicious activities the Cynet Research has investigated recently. The CMD instance had run with /c argument (which allows the CMD to run and terminate immediately thereafter) in order to execute the malicious PowerShell command described below.
The PowerShell command had ran with the following parameters:
- -w 1 – WindowStyle Hidden, hide the PowerShell window.
- -e – EncodedCommand, allow to encode the command with base 64 format.
After decoding the malicious PowerShell base64 command, we have figured that the attack switched from file-based attack to a Fileless attack. In the screenshot below, you may see that the command contains two interesting parts:
- The first part of the PowerShell command is the $thdTask variable, which contains another base64 string. After encoding the base 64 command, we got the following command:
The above command is using “System.Net.WebClient” and “DownloadString” to initiate network connectivity to gitlab.com (hxxps://gitlab[.]com/UL9gbzuP37/rt/snippets/1956305/raw) and to download the cs.exe file to \temp\ directory.
When trying to access the malicious URL, we saw that it contains a large base64 string, as you can see below:
After decoding the base64 string, we have figured that the base64 string is basically a PE file (an MZ file) that will be downloaded to $env:temp (environment variable of the TEMP directory C:\Users\user\AppData\Local\Tem) the payload as “cs.exe”:
- [IO.File]::WriteAllBytes(“$env:temp\cs.exe”, [Convert]::FromBase64String($base64string))
Finally, the payload executes by start-process command.
- start-process “$env:temp\cs.exe”
In order to understand the malicious purpose of this payload we have to deep dive and analyze it by static and dynamic analysis.
- The second part of the command sets a new value to the “HKCU\Sofatwarte\cr” registry key – which is further described in the technical analysis
After downloading and investigating the cs.exe (the payload we extracted above), we have concluded that this payload is the said Trojan Banker that aims to steal banking data from infected machines.
The Trojan Banker’s static metadata and history (from VirusTotal.com)
From the static analysis of the cs.exe payload we have found some hints about the malicious activity and basic functionality that it will soon execute and use on the compromised environment.
The following screenshot of the malicious file can show that the sections of the files are not packed or
encrypted. We can also see the assembly code and start figuring out the malicious context and purpose of this Trojan Banker:
The first step in understanding the functionality of the payload, then will be to check the imports and
the API calls that have been used by the payload.
The main functions that we discovered are:
- CreateProcess: this function allows the attacker to create a new process and its primary thread. The new process runs in the security context of calling the process. Most of the time, the attackers will use this API call to execute the malicious process:
- CreateDirectory: this function allows the attacker to create a new directory. If the underlying file system supports security on files and directories, the function applies a specified security descriptor to the new directory. Usually, the attackers will use this API call to create the directory where the
malicious component will be stored in order to gain persistency on the victim’s host.
- WriteFile: this function allows the attacker to write data to the specified file or input/output (I/O) device. Usually, the adversaries will use this API call to create (write) a malicious file component. It also can be used for persistency and post-exploitation methods.
- GetCommandLine: this function allows the attacker to retrieve the command-line string for the current process. Attackers use this API call to execute (run command line) malicious code. It can also be used for Fileless and post-exploitation methods.
All the above-mentioned API calls are associated with Kerenel32.dll. This DLL exports functions
that relate to filesystem operations, hardware, and processes.
The next interesting functionality that is used by the below API functions implies that the attacker may have the ability to hook, record, and steal the clipboard data which can contains sensitive information (usernames, passwords, etc.). The attacker used USER.DLL to perform a keyboard monitoring (keylogging).
The final API function that we have covered in this section is the GetUserName function that can be used by the attacker for enumeration and discovering actions.
After discovering and understanding the functionality of the cs.exe payload, we have exported the strings from the payload. The stings are good indicators for the malicious actions that the malware will perform, which will eventually lead us to new hints about the attack stages of the Trojan Banker:
The main stings we have investigated are the following:
- Creation of a new file (hysvc.exe) in the ProgamData directory (this file is created by using WinAPI).
- Manipulation of the StartUp directory (can be used for persistence).
- Execution of CMD.
- Creation of Scheduled Task (can be used for Persistence) to run the new hysvc.exe file.
- Creation of LNK file that is linked to the new hysvc.exe file.
- Execution of a base64 PowerShell command.
In order to understand the above-mentioned strings, we looked at the assembly code by using IDA.
The first block containing an interesting offset that was discovered and analyzed is the aCProgramdataHy that is associated with the new payload that will be created in the ProgamData directory.
The second block showed a few other interesting offsets:
The aCMDCTimeoutT4 offset contains a CMD command line that run a “timeout /t 4” that pauses the command processor for 4 seconds before launching the CMD process again. This defense evasion technique is being used to prevent any detection by security application and traditional Anti-Virus vendors.
The aCMDSchtaskFC offset contains another CMD command line that will run a “schtasks” for creating a
scheduled task on the compromised host. The name of the schedule task will be “GoogleChromUpdateTask” (/tn – taskname ) and the task is scheduled to run hysvc.exe every 1 hour (/sc – schedule).
The aMKlinkCProgram offset contains a “mklink” command that will create a link (.LNK) file in the StartUp
directory that will be linked to the hysvc.exe file.
The aPowershellW1Ex offset contains a base64 PowerShell command that will be executed by the main payload (cs.exe).
After preforming a static analysis and code analysis we wil know move to execute the cs.exe payload and preform a Dynamic/Behavior analysis.
Once we launched the payload, we immediately saw the following process tree:
As we learned from the static analysis, the CreateProcess API function will execute a CMD instance
and create a scheduled task:
- CMD Timeout command:
- schtasks command:
In order to gain persistency on the compromised host the attacker created a schedule task in the Task Scheduler. Moreover, the attacker tried to masquerade it with a legitimate name of “GoogleChromUpdateTask” as we can see in the screenshot below:
The task information shows that it run the file every 3 hours:
The CreateFile and CreateDirectory functions create a new payload (hysvc.exe) in the PrgramData directory:
After checking the hash of the new hysvc.exe payload, we have found that it is the same file as the original cs.exe payload. Thus, the initial trojan just copied itself to a new location:
After creating the second payload (hysvc.exe) and a scheduled task to run this payload, the initial payload (cs.exe) is launching PowerShell in order to run an encoded malicious command:
The decoded command, as shown above, has used a Com-Object of “Wscript.Shell” to create a shortcut file
(LNK) in the StartUp directory which is linked to the hysvc.exe payload. This is basically an attempt to use a second persistence technique for the payload to run every time the victim reboots the compromised
machine, by automatically executing the LNK file from the startup:
- “AppData\Romming\Microsoft\Windows\Start Menu\Programs\StartUp”
The LNK file is linked to the trojan Banker (hysvc.exe) which is now located in the ProgramData directory.
Memory context of the payload:
After we finished the investigation and analyzed the trojan banker, we can go back to the second part of the first PowerShell Command.
The second part of the command sets a new value to the “HKCU\Sofatwarte\cr” registry key that related
to the $thTask variable which contains the binary of the trojan Banker that we have analyzed above.
It also creates a scheduled task with CMD instance and named it “Update Shell”. The task will execute the PowerShell command in base 64 format.
After decoding the base 64 command, we have figured that it will invoke the “HKCU\Sofatwarte\cr” value
which means that the trojan Banker’s binary (hysvc.exe) will be executed by the PowerShell command directly from the registry:
In parallel, the downloader “1849226900.exe” which was responsible for downloading the main payload (cs.exe), executes another CMD instance in order to execute an additional PowerShell command:
After decoding the PowerShell command, we discovered the following:
The first part is the $K variable that contains a base 64 command.
After decoding the command, we see that it launchs a pure fileless attack that run from the PowerShell virtual memory. The command initiates network communication to the following URL: “hxxps://asq.d6shiiwz[.]pw/win/ins/checking[.]ps1” in order to invoke the content of the “checking.ps1” script. This activity happened by the IEX (Invoke-Expression) cmdlet that executes the content of the PS1 file by using the DownladString method.
Unfortunately, the URL nolonger exists and when we have tried to access the URL, we get no response:
In order to verify that the malicious URL does not exist, we have tried to run a CURL command. In some of the cases attacker can fake the HTML page to show no response, while there is active communication to the malicious domain.
In the second part of the PowerShell command, it sets a new value in the “HKCU:\Sofatware” registry key. The value name is “kumi” and it contains the $k variable, which means it will execute the malicious PS1 script content.
Furthermore, it will create a schedule task named: “OneDrive SyncTask”. The task will execute a PowerShell command.
In order to understand what the purpose of the command, we have decoded the base 64 command:
The command simply executes by the IEX cmdlet the kumi value which contain the malicious PS1 script.
Attack ended at 7:47:56.000 PM (13 seconds after it executed)
INDICATORS OF COMPROMISE
|Registry||HKCU:\Sofatware (value – Kumi)|
|Schedule Task||OneDrive SyncTask|
The Cynet Research Team has analyzed and investigated different threats and malware using various tools and techniques. Cynet’s seasoned security experts are familiar with the newest attacks vectors and techniques that exist in the wild.
Cynet 360 customers are fully protected from these kinds of threats and have full visibility over their protected assets. Cynet has various behavioral and heuristics capabilities designed to detect and prevent advanced threats like the one described in this report.
The Cynet 360 solution gives our customers the ability to control and manage cyber security incidents, to perform forensic analysis on infected environments, and to run remote actions on the infected hosts in order to mitigate the threat. On top of that, we have our CyOps team which is monitoring our customers’ environments 24/7/365.
Contact Cynet CyOps
(Cynet Security Operations Center)
The Cynet CyOps available to clients for any issues 24/7, questions or comments related to Cynet 360. For additional information, you may contact us directly at:
Phone (US): +1-347-474-0048
Phone (EU): +44-203-290-9051
Phone (IL): +972-72-336-9736
CyOps Email: [email protected]