Threat Profile: Red BerryMiner

Red BerryMiner


This report analyses the modus operandi, TTPs, infrastructure, and tools used by a threat group named by SCILabs as Red BerryMiner, which exploits vulnerabilities in servers of various organizations exposed on the Internet to infect them with the Mirai malware families, ShellBot, and predominantly the crypto-miner XMRig.


The initial access vector of this adversary is primarily the exploitation of Internet-exposed server vulnerabilities, predominantly the vulnerability registered with the identifier CVE-2023-3722(CVSS:3.0 – 9.8), which affects the Avaya Aura Device web application Services.

SCILabs identified in its own and public investigations that Red BerryMiner exploits other vulnerabilities like the one registered with the identifiers CVE-2018-20062(CVSS:3.0 – 9.8) and CVE-2022-22965(CVSS:3.0 – 9.8) to install malware such as Mirai and XMRig.

Based on the SCILabs telemetry study, we observed that Red BerryMiner directs its attacks to organizations in different countries (without targeting a specific sector) to use the compromised infrastructure for crypto-mining activities. According to our research, Red BerryMiner could operate as early as February 2023.

Region of operation

According to the evidence collected by SCILabs, the countries where activity related to Red BerryMiner attacks has been observed are Mexico, the United States, Spain, Russia, and South Africa.

Figure 1. Red BerryMiner operating region, identified so far by SCILabs.

SCILabs identified part of the Red BerryMiner infrastructure used as a malware repository by this threat actor geolocated in some countries around the world, highlighting the Netherlands. Due to its IP address it belongs to the infrastructure of Alsycon B.V. Therefore, it is hypothesized with a low level of confidence that the operators behind Red BerryMiner are located mainly in that country.

Figure 2. Red BerryMiner domains registration regions

Figure 3. Domain information download[.]asyncfox[.]xyz used by Red BerryMiner

The following figure shows a timeline with the most relevant Red BerryMiner activity according to the events observed and analyzed by SCILabs since February 2023.

Figure 4. Red BerryMiner campaigns timeline

Who can it affect?

According to SCILabs telemetry, the leading affected organizations are those that use or have public services on the Internet with unmitigated vulnerabilities. The most exploited vulnerabilities by Red BerryMiner are the following:

# Technology Vulnerability Criticality Level Description
1  Avaya Aura Device Services


CVSS:3.0 – 9.8 CRITICAL Operating system command injection vulnerability in the Avaya Aura Device Services web application could allow remote code execution as a user of the web server via a malicious uploaded file. This issue affects Avaya Aura Device Services version and earlier.
2 ThinkPHP


CVSS:3.0 – 9.8 CRITICAL Allows remote attackers to execute arbitrary PHP code via crafted use of the filter parameter.
3 Spring Shell CVE-2022-22965 CVSS:3.0 – 9.8 CRITICAL

A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e., the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.

Table 1. Exploited vulnerabilities by Red BerryMiner

How can it affect an organization?

The main risk associated with this threat group is that they tend to exploit vulnerabilities in technology commonly used by all types of organizations to distribute the XMRig crypto-miner and integrate the victim devices into the Mirai Botnet network. This can cause severe consequences on an organization’s infrastructure. Furthermore, known for its DDoS attacks, Mirai can cause massive disruptions to services and systems, damaging reputation and causing financial losses. On the other hand, XMRig consumes resources from compromised systems to mine cryptocurrencies, leading to a slowdown in operations, increased energy costs, and potential additional security breaches.


First campaign identified by SCILabs

During the first attack analyzed by SCILabs identified in July, which affected a government sector organization, the use of different droppers developed with PHP to download a shell script and the ShellBot malware was identified. The downloaded shell script is named and it aims to deploy two additional scripts and the XMRig crypto mining software. One of the scripts is responsible for terminating specific processes, and the other collects SSH keys, hosts, and users to perform lateral movement within the affected organization’s network.


sh script Droppers

  • First variant of the PHP dropper:
    • It downloads a file with curl or wget from the URLs hxxp[:]//178[.]62[.]44[.]152/start[.]sh or hxxp[:]//45[.]81[.] 243[.]128/start[.]sh, stored in /tmp under the name sh. It uses the -k option to allow connections over HTTPS without validating SSL certificates.
    • When the download is complete, it runs the file /tmp/ using bash.

Figure 5. PHP dropper

  • Second variant of the PHP dropper:
    • It downloads a file with curl or wget from the URL hxxp[:]//45[.]81[.]243[.]128/start[.]sh, which is stored in /tmp with the name sh. It uses the -k option to allow connections over HTTPS without validating SSL certificates.
    • Upon download completion, grant it execute permissions using the chmod +x
    • It runs the downloaded file, with the ‘.’ command indicating that it should be run in the current context.

Figure 6. Code of the second variant of the script Dropper for, and XMRig scripts

The artifact is intended to download the XMRig software and two additional scripts; its operation is explained in general terms below.

  • The dropper performs several processes checks, validating its name or the CPU consumption of that process, and then kills them using the kill -9
  • With the curl and wget commands, it downloads the following files:
    • xmrig-6.19.2-linux-static-x64.tar.gz: from URL hxxp[:]//45[.]81[.]243[.]128/xmrig-6[.]19[.]2 -linux-static-x64[.]tar[.]gz is a compressed file containing the XMRig crypto-miner. The file is stored in /tmp/$file_name.tar.gz.
    • from the URL hxxp[:]//45[.]81[.]243[.]128/kill[.]sh, which aims to kill specific processes on the system. The file is stored in /tmp/
    • from the URL hxxp[:]//45[.]81[.]243[.]128/ssh[.]sh, which aims to collect SSH keys, hosts, and users to try to connect to computers additional information on the organization’s internal network. The file is stored in /tmp/
  • The dropper grants read, write, and execute permissions to all files downloaded with the “chmod 777” command and execute them in the background.

Figure 7. script

Dropper for ShellBot

This script aims to download a version of the ShellBot, AKA PerlBot malware. The operation of the dropper is explained below.

  • The dropper uses the system() function for command execution and changes the directory to /tmp using the cd command.
  • With the curl utility, it downloads the contents of a remote file located at 85[.]239[.]33[.]32/ruby, and uses the -s option to activate silent mode so it does not show information or progress in the console. The download result is then processed and executed by the Perl interpreter.
  • As with curl, the script attempts to download and execute the remote file using the wget

Figure 8. ShellBot dropper

The following image illustrates the droppers identified in this attack and their respective payload.

Figure 9. Droppers’ execution flow

Process manipulation and lateral movement

Once the script is downloaded and executed, the additional shell scripts are deployed for manipulating processes and performing lateral movement within the internal network. Below is a general description of how it works:

This script searches and terminates various processes, deletes files, and checks if a running process is related to XMRig; if it does not find it, it performs a series of actions to download and execute the file. Its operation is explained below.

  • A series of commands are performed within the while loop to stop processes, delete files, and other actions.
  • The killall and pkill commands are used to kill the following processes: kdevtmpfsi, kinsing, xmrig, xmr, qwer, system, /tmp/.ssh/, kthreaddk, kwolker, mini, kacpi_notifyd, vim, mym, network, .libs, javase, libexec, system y

Figure 10. script fragment

  • The script uses the rm command and the -rf option to remove the following directories and files:
    • /usr/lib/vmware-vsphere-ui/server/postgres
    • /usr/lib/vmware-vsphere-ui/server/
    • /usr/lib/vmware-vsphere-ui/server/
    • /usr/lib/vmware-vsphere-ui/server/
    • $HOME/postgres
    • $HOME/
    • $HOME/

Figure 11. script fragment

  • Then it looks for processes containing specific text strings to kill those processes with the kill -9 command; and for processes using more than 40% of the CPU.

Figure 12.

  • It performs a series of validations to verify if there is a process related to XMRig; if not, proceeds to download it from the URL hxxp[:]//45[.]81[.]243[.]128/xmrig-6[ .]19[.]2-linux-static-x64[.]tar[.]gz using the curl or wget The file is stored in /tmp/log_rotari2.tar.gz.
  • The file is unzipped and executed with a series of arguments to define the algorithm and the URL of the mining server; then, it redirects the output to /dev/null to discard it, and runs the process in the background.

Figure 13. script fragment

This script looks for SSH keys and hosts in various directories and configuration files to iterate over user, host, and SSH key combinations and establish a connection. This artifact aims to infect more computers on the organization’s internal network.

  • The script performs several validations in search of directories and files containing SSH keys and host names stored in different variables. Existing users are also collected.
  • Various text transformations are performed to format and organize user information, SSH keys, and host names.
  • A loop is started to grant permissions, establish SSH connections to remote hosts, and execute a file downloaded from the URL hxxp[:]//45[.]81[.]243[.]128/start[.]sh in the directory /tmp on remote hosts.

Figure 14. script

WebShells and Backdoors script

Different PHP scripts that served as web shells and backdoors for the attackers were also identified during the investigation.


This artifact is a WebShell that aims to execute the code that is provided in an HTTP request through the $_POST argument.

Figure 15. Obfuscated script info.php

Figure 16. Deobfuscated script info.php


This script is a WebShell designed to decode and execute base64 data using the eval function. Below is a general explanation of how the script works.

  • It defines a function called Decrypt that takes a parameter called $data. This function is used to decrypt data.
  • Within the function, an encryption key is defined in the variable $key with the value “e45e329feb5d925b“, as well as the variable $bs, which is assigned the value of two concatenated strings that result in “base64_decode“.
  • The result of the function defined in $bs is assigned to the variable $after passing the parameter $data.
  • In the “for” loop, it is iterated over each character of the string $after. In each iteration an XOR operation is performed between the current character and the corresponding character of the key using the expression $key[$i+1&15]. The result is returned as the return value of the Decrypt
  • The $post variable is assigned by calling the previously defined function, passing the content of a POST request received through php://input as a parameter.
  • Finally, the “eval” function executes the contents of the $post

Figure 17. avayabing.php


This artifact is a WebShell that processes a POST request, decoding the base64 content and an XOR operation. The result is executed with the “eval” function. Below is a general explanation of how the script works.

  • Receives the error parameter value sent via a POST request and assigns it to the variable $a.
  • Uses the base64_decode() function to decode the content of the variable $a; the result is stored in $string.
  • Unpacks the variable $string with the unpack() function; the “C*” specifier indicates that the data is unsigned integers, and the result is stored in $arr as an array.
  • Starts a “for” loop that iterates over each number in the array $arr. In each iteration, it performs an XOR operation between the current element of $arr and the result of the expression (($i-1)%256); the % operator is used to ensure that the value of ($i-1) stays within the range 0 to 255. Then, the result is converted to a character using the chr() function, and concatenated to the value of the $str
  • Finally, it uses the “eval” function to execute the contents of the $str

Figure 18. avayadirini.php


This script can be used as a backdoor on a server, performs different configurations to allow opening remote URLs, and defines a function to retrieve custom HTTP request headers. Depending on the value of the “Cz” header in the HTTP request, it performs different actions, such as establishing a connection to a remote server, terminating the established connection, and retrieving data from the attacker’s server to decode and save it in the session.

The first block of code performs configurations and definitions necessary for handling remote URLs, error reporting, and obtaining HTTP request headers.

Figure 19. avayatunnel.php (I)

The second block of code sets the script execution time limit to 0 (unlimited), gets the HTTP request headers, defines character strings for encryption/decryption, and processes the header to get a command and split it into relevant parts.

Figure 20. avayatunnel.php (II)

The third block of code evaluates the value of the variable $cmd using a switch sentence; in the first case, it establishes a connection (Reverse Shell) with a specific target; the target and the port are obtained from the decoding and manipulation of a header HTTP specifies. If the connection is not established correctly, non-blocking options are configured, and a session is started to store information related to the execution and communication with the socket.

Figure 21. avayatunnel.php (III)

The fourth block of code controls bidirectional communication over a socket that reads data from the write buffer, sends it through the socket, checks if the write was successful, and ends the loop if an error occurs.

Figure 22. avayatunnel.php (IV)

The fifth block of code is responsible for reading data from a socket in blocks and accumulating it in the $_SESSION[$readbuf] read buffer during each iteration of the loop. Additionally, it checks if the read was successful and ends the loop if an error occurs.

Figure 23. avayatunnel.php (V)

The sixth block of code is responsible for cleaning and eliminating the variables $_SESSION[$run], $_SESSION[$readbuf], and $_SESSION[$writebuf], ending with the execution of the reverse Shell established in the previous case.

Figure 24. avayatunnel.php (VI)

The seventh block of code is responsible for sending HTTP responses based on the execution status of the loop. If the loop is still running, specific headers are sent, and the base64 encoded content of the read buffer is printed; if the loop has stopped, a particular header indicates the status.

Figure 25. avayatunnel.php (VII)

The eighth block of code is responsible for handling POST requests, storing the content in the session’s write buffer if the execution loop is running, and sending specific HTTP responses depending on the state of the execution loop and the content of the POST request.

Figure 26. avayatunnel.php (VIII)

The last block of code is executed when no match is found in the previous cases. In that case, the session is closed, and a message is displayed before completing the execution of the script.

Figure 27. avayatunnel.php (IX)

XMRig and ShellBot

As mentioned, a compressed XMRig software file is downloaded using the script, and another dropper is responsible for downloading the ShellBot malware. The purpose of these artifacts is explained in general terms below.


The xmrig-6.19.2-linux-static-x64.tar.gz archive contains the open-source software XMRig, designed for cryptocurrency mining.

An attacker can use the computing power provided by infected computers. A well-known example is the case of the 8220 Gang group, which uses a customized version of this software (PwnRig); SCILabs documented this threat group in report ID TP2304-086.


The downloaded version of the ShellBot, AKA PerlBot malware, is LiGhT’s Modded Perlbot v2; this threat mainly affects Linux servers with weak SSH credentials. ShellBot is a malware developed in Perl that uses the Internet Relay Chat (IRC) protocol to communicate with a remote server through IRP over TCP. This variant offers a variety of commands to carry out DDoS attacks using HTTP TCP protocols and UDP, as well as commands that allow control of infected systems so they can be used in other attacks.

Listed below are the commands used by this threat:

Command Description
help Help menu for the explanation of each command.
flooding Commands specifically designed to perform IRC Flooding.
irc Commands related to IRC control IRC.
ddos Commands for DDoS attacks include TCP, UDP, HTTP, and SQL Flooding.
news Consult security web pages (packetstorm and wilw0rm).
hacking Different commands to perform scans or attacks (multiscan, socks5, logcleaner, nmap)
extras Install additional scripts (install-syn Syn.c and install-50x 50x.c )

Table 2. Commands description

Figure 28. ShellBot source code


The second campaign identified by SCILabs

The second attack registered by SCILabs during September similarly affected a government sector organization. Different droppers were also identified downloading the shell script, which had already been observed in the first campaign, as well as files responsible for downloading a Reverse Shell and the Mirai malware.


sh dropper

It is essential to mention that different PHP scripts were identified to download the artifact, with slight variations in its code, so SCILabs has the hypothesis that the attackers tried other scripts to download this file.

First variant:

  • This script is designed to download a file with wget from the URL hxxp[:]//45[.]81[.]243[.]128/start[.]sh. Upon completion of the download, it runs the downloaded content with the bash command interpreter.

Figure 29. First variant source code

Second variant:

  • The script is designed to download a file with curl or wget from the URLs hxxp[:]//178[.]62[.]44[.]152/start[.]sh or hxxp[:]//45[. ]81[.]243[.]128/start[.]sh, which is stored in the /tmp folder. When the download is complete, the file can be executed using bash.

Figure 30. Second variant source code

Third variant:

  • Like the second variant, this artifact performs the same actions, but in this case, it also grants execution permissions to the file downloaded with the chmod +x command.

Figure 31. 2PeF5b7j96MgewoFOWEXzEpo1fz.php script

QkflHwJE0s file dropper of type

The artifact aims to download a file from the URL hxxp[:]//84[.]54[.]50[.]110[:]8080/QkflHwJE0s, which is ELF type and a reverse shell, then grants execution permissions and runs it in the background.

Figure 32. Dropper of ELF file

Mirai dropper

This script aims to download the Mirai malware. The file is named x86 and it is downloaded from the URL hxxp[:]//45[.]90[.]161[.]122/bins/x86. It grants read, write, and execute permissions to all files in the current directory with the chmod 777 * command, and executes the x86 file with the test argument.

Figure 33. Mirai dropper

The following image illustrates the droppers identified in this attack and their respective payload.

Figure 34. Droppers identified in this campaign


During this investigation, PHP scripts were also identified to obtain information about the user and the system so SCILabs could confidently ensure these scripts were used during the recognition phase.

User privileges

Several PHP scripts that use the system() function to execute the id command, which displays information about the current user and the group to which they belong, were identified. This code could be used to validate the user’s permissions.

Figure 35. Script code to obtain user information

System information

This script uses the system() function to execute the uname -a command, and to display information about the system kernel and hardware architecture. This command could be used to determine what types of scripts and executables to use during the attack.

Figure 36. Script code to obtain system information

WebShells and Scripts

PHP scripts that served as a backdoor WebShell for the adversary were identified, as in the first attack observed by SCILabs.


This script allows an attacker to send arbitrary code in an HTTP request via the “123” parameter and execute it using the eval() function.

Figure 37. Script 730.php


Like the previous script, an attacker can send arbitrary code in an HTTP request via the “cmd” parameter and execute it using the eval() function.

Figure 38. Script  jquery.php


This artifact is designed to receive obfuscated data through a POST request; this data is decrypted depending on whether the OpenSSL extension is loaded. If it is loaded, the AES-128 algorithm and the key defined in the $key variable are used, otherwise they are decrypted using the base64_decode() function. Finally, the decrypted content is executed using the eval() function.

Figure 39. WebShell 2U2NOwQKCiHp5k0zwjTcIXwECOg.php


This artifact corresponds to a WebShell generated with the Weevely tool , and its objective is to decrypt and execute arbitrary code received through a POST request.

Figure 40. WebShell 7e9e344d962070a5a4b7d7926c919ced.php

Figure 41. WebShell 7e9e344d962070a5a4b7d7926c919ced.php

Reverse Shell

Additionally, in this investigation, the use of a PHP script and an ELF-type executable was also observed, which aimed to establish a Reverse Shell towards the IP address 84[.]54[.]50[.]110.

Scripts PHP

During the investigation, different scripts that aim to initiate a Reverse Shell towards the IP address 84[.]54[.]50[.]110 on port 9000 were identified.

Figure 42. Reverse Shell

Archivo ELF

The artifact downloaded by one of the scripts is an ELF-type file that aims to establish a Metasploit Reverse Shell towards the IP address 84[.]54[.]50[.]110 through port 4444.

Figure 43. Reverse Shell (ELF File)

XMRIG y Mirai

In this second attack recorded by SCILabs, the attempt to download the XMRig software was also identified as downloading the Mirai malware, which can add the infected computer to a botnet.


During the investigation, SCILabs identified several HTTP request records that contain Base64 obfuscated source code. Once this string is decoded, the attempt to download the XMRig software can be observed.

One of the logs aims to kill any process whose name contains .foxm using the pkill -9 command, then it downloads an artifact from the URL hxxp[:]//download[.]asyncfox[.]xyz/download/xmrig[. ]x86_64, renames it to .foxm, grants execution permissions with the chmod +x command, and executes it.

Additionally, this request exploits a known ThinkPHP vulnerability, allowing a remote attacker to execute arbitrary PHP code by manipulating the “filter” parameter

Figure 44. Obfuscated source code

Figure 45. Registration of the request with the deobfuscated code

When deobfuscating the code from another record, it performs the same activities as the code explained above, only changing the download URL, which in this case is hxxp[:]//185[.]225[.]75[. ]242/download/xmrig[.]x86_64.

Additionally, this request attempts to exploit the vulnerability known as Spring4Shell, which allows an attacker to perform remote code execution (RCE).

Figure 46. Registration of the request with the obfuscated code

Figure 47. Registration of the request with the deobfuscated code


The downloaded artifact named x86 belongs to the Mirai malware family; this threat aims to add the compromised device to its botnet. This botnet is commonly used to launch DDoS attacks.

Additionally, a script called proxy_xml.php, published on Github by Zounar, was also identified. It allows all HTTP/HTTPS requests to be forwarded to another server.

Documented campaign on an open source identified by SCILabs

SCILabs identified a public investigation that documented the exploitation of a remote code execution (RCE) vulnerability on an Avaya Aura Device Services device during February to load several PHP-type WebShells, which were stored in the PhoneBackup directory. In addition to these scripts, requests were observed with curl or wget towards the IP address 178[.]62[.]44[.]152 for the download of Shell-type scripts. This IP address and the name of some of the artifacts were also observed in attacks documented by SCILabs.

Figure 48. script download

In this investigation, it was also observed that some devices attempted to download the XMRig crypto-mining software, and the device also had a Mirai malware infection, which are characteristics observed in the attacks documented by SCILabs.

Figure 49. XMRig Download

Artifacts recovered from a public investigation

During monitoring and threat hunting in the search of campaigns or artifacts that were related to the infrastructure observed in the attacks documented by SCILabs, artifacts stored at IP address 45[.]81[.]243[.]128 were recovered. It is essential to mention that this malware repository was exposed in July when the first attack recorded by SCILabs occurred.

Figure 50. Artifacts stored in 45[.]81[.]243[.]128

In the same way as the artifacts observed in the two attacks documented by SCILabs, some are responsible for downloading scripts or additional malware, others for managing processes, or searching for SSH keys and hosts to infect more computers within the network, and even scripts that have the objective of establishing a reverse shell. The operation of the artifacts is explained in general terms in the next page.


logotate_bsd file dropper

The objective of the artifact is to download the achievement_bsd file, which is the XMRig software. Below, its operation is explained in general terms.

  • It performs several process checks, validating its name or the CPU consumption of that process, and then kills them using the kill -9
  • With the curl command, it downloads a file from the URL hxxp[:]//45[.]81[.]243[.]128/logrotate_bsd.
  • Grants read, write, and execute permissions to the downloaded file with the chmod 777 command, and runs it in the background.

Figure 51.

sh: xmirgARM file dropper

Like the previous one, this script aims to download the XMRig software, grant read, write, and execute permissions, and then run it in the background.

Figure 52.

sh: Dropper for,, and XMRig scripts

The script is the same that was observed in the campaigns documented by SCILabs: its objective is to download the XMRig crypto-miner and the additional scripts, and, which are responsible for managing the processes and carrying out lateral movements within the internal network.

sh: Dropper for and XMRig

The script is very similar to the artifact’s main objective, which is to download the XMRig crypto-miner and the additional The script is used to manage processes on the infected computer.

Figure 53.

The following image illustrates the droppers recovered from the exposed malware repository and their respective payloads.

Figure 54. Droppers recovered from exposed malware repository

Scripts for Process Management and Lateral Movement

As in the attacks documented by SCILabs, the and scripts are responsible for terminating specific processes, searching for SSH keys and hosts in various directories, and configuring files to infect more computers on the internal network.

Reverse Shell

The script executes a Perl language expression to establish a connection to IP address 84[.]54[.]50[.]110 on port 9000. If the connection is successful, it executes an interactive shell.

Figure 55.

Throughout this investigation, SCILabs identified two additional artifacts. As of now, their role in the attack chain remains uncertain. However, given their alignment with Red BerryMiner’s modus operandi, it is very likely that they are also part of the arsenal of this threat group. Below, we present a brief description of these artifacts:


The gigolo-ng_agent_0.3.3_Linux_64bit.tar.gz archive contains the Ligolo-ng tool, which is used by pen-testers to establish tunnels over a reverse TCP/TLS connection.

This Python file implements a basic web server.

Figure 56.

Overlaps between Campaigns identified by SCILabs and the campaign documented on a public site (key indicators)

The following tables compare the campaigns identified by SCILabs and the ones documented in a public investigation. This exercise was carried out to confirm that the adversary behind these attacks was the same.

Table 3. Overlaps between Red BerryMiner campaigns

Attack Flow

General attack flow in Red BerryMiner campaigns observed by SCILabs:

Figure 57. Red BerryMiner Attack Flow

Technical Summary

  • Red BerryMiner exploits vulnerabilities in servers exposed on the Internet to start its infection process, mainly the CVE-2023-3722 vulnerability that affects the Avaya Aura Device Services web application.
  • Based on the evidence found, Red BerryMiner can exploit the vulnerabilities CVE-2018-20062 (ThinkPHP) and CVE-2022-22965 (Spring Shell) to download artifacts to the compromised device.
  • Among the artifacts used by this group of threats are PHP and bash scripts that aim to download additional artifacts, obtain user and system information, establish a reverse shell WebShell/Backdoor capability, manage the processes of the infected system, and collect SSH keys and hosts to infect more computers on the internal network.
  • The goal of Red BerryMiner is to install the XMRig software to carry out crypto-mining activities and infect the compromised computers with malware such as Mirai or ShellBot, allowing it to integrate these devices into a Bonet.

Diamond Model

Figure 58. Diamond model


The following TTP matrix based on the MITER PRE-ATT&CK Framework was obtained from the analysis of the different Red BerryMiner campaigns.

Table 4. PRE-ATT&CK Matrix


The following TTP matrix based on the MITRE Framework was obtained from analyzing the different Red BerryMiner campaigns.

Table 5.  MITRE ATT&CK matrix


Red BerryMiner exhibits distinct characteristics marked by the deployment of the XMRig crypto-miner and additional malware such as the Mirai Botnet and ShellBot in addition to the use of languages such as PHP and Bash. Moreover, it takes advantage of “living-off-the-land” techniques to download additional malicious artifacts and install backdoors and reverse shells. This represents a challenge, particularly in Latin America (LATAM), where cybersecurity maturity varies significantly between organizations. A Red BerryMiner attack can not only result in additional operational costs but also expose organizations to data security breaches, which can lead to legal and compliance consequences and damage to corporate reputation.

The threat landscape in Latin America is constantly evolving. Attackers continually refine their methods to exploit emerging vulnerabilities and employ more sophisticated evasion and persistence techniques, so organizations need to be aware of the modus operandi of this type of threat group. Based on SCILabs telemetry, we consider that for the remainder of the year, we will continue to observe Red BerryMiner campaigns exploiting the vulnerabilities mentioned in this document and adding others to its arsenal to strengthen its Bot network and abuse the infrastructure of organizations to carry out crypto-mining activities.

Based on our research, SCILabs makes the following recommendations.

  • The vulnerability CVE-2023-3722, reported in this document, affects all versions of Avaya Aura Device Services and earlier, so it is suggested to update to the version recommended by the manufacturer, considering the implications.
  • Periodically perform offline backups of information considered critical or essential for the operation and continuity of the business.
  • Keep all the organization’s computer equipment updated to the latest version of the operating system.
  • Ensure all existing applications are kept up-to-date with the most stable versions following manufacturers’ recommendations.
  • Apply critical patches to the systems. Otherwise, implement a shielding system at the hypervisor level that allows the implementation of virtual patches to immediately mitigate the vulnerability without incurring the risk of altering or directly damaging the operating system and impacting the operation.
  • Implement a file integrity agent to alert and block any attempted manipulation of selected files within the security policies defined to protect critical business processes.
  • Evaluate the perimeter firewall configuration to generate allowlists that include only legitimate ports and services used by applications related to the operation and management of administrators.
  • Implement a permanent monitoring for all network communications involving critical servers to your operations to get alerts for any deviations from the defined and authorized rules by the corresponding information security area.
  • Review the application tasks configured in the Linux Cron service to identify any suspicious tasks that could be scheduled for execution, particularly related to the TTPs or IoCs provided in this report.
  • Implement an application firewall (WAF) or, if they have one, evaluate its configuration according to the manufacturer’s best practices and apply them in the short term.
  • Integrate security policies at all levels of the organization that consider using EDR systems with high research capabilities, always keeping them updated and correctly configured under the best practices issued by the manufacturers.
  • Create strong password policies and apply the principle of least privilege for all users within the organization, consider disabling “admin” or “root” users, and create custom and limited roles for different types of system administrators, according to their specific functions.
  • Do not use default passwords, as they represent a high security risk. Set strong, unique passwords for each system and server using a complex mix of uppercase and lowercase letters, numbers, and symbols: ideally, passwords should be at least 12 characters long. Additionally, implement a regular password change policy and consider using multi-factor authentication to add an extra layer of security.
  • To identify possible WebShell infections in the /tmp/ directory, perform a focused search for suspicious files with .php or .sh extensions. Examine these files for typical webshell commands such as exec, shell_exec, passthru, system, and base64_decode, along with networking tools such as wget or curl.
  • Consider the commitment indicators contained in this document.