Under the shellcode of the ‘Operation Duck Hunt’. Analysis of the FBI’s ducks killer.

INTRODUCTION

The “Duck Hunt” operation refers to a specific operation called “Operation Duck Hunt” that disrupted the Qakbot botnet. The Qakbot botnet was a sophisticated network of compromised computers that was used to distribute malware, steal sensitive information, and carry out other malicious activities.

The operation to disrupt the Qakbot botnet was carried out law enforcement agencies. It involved identifying and targeting the infrastructure that supported the botnet, such as command and control servers and domains used by the botnet operators. By disrupting these critical components, the operation aimed to disable the botnet and prevent it from carrying out further malicious activities.

The “Duck Hunt” operation was likely named after the popular video game “Duck Hunt,” where players use a light gun to shoot ducks that appear on the screen. The name might have been chosen to symbolize the effort to track down and disable the Qakbot botnet, similar to shooting down ducks in the game.

INSIGHTS

FBI infiltrated the Qakbot‘s infrastructure and administrators’ servers and, long story short, created and delivered to infected computers a custom Qakbot module that acted as a removal tool. This module has been delivered to QakBot’s victims through a shellcode (sha256:7cdee5a583eacf24b1f142413aabb4e556ccf4ef3a4764ad084c1526cc90e117). Quickly explained, the shellcode unpacks a custom DLL (details of which have not been formally communicated) designed to terminate the running Qakbot process on the host.

This shellcode, in origin, appears like the following:

From this payload I managed to extract the original DLL after making it executable. By observing the dynamic execution of this executable, I placed several BPs at the end of the unpacking instructions and then performed a memory dump at 02A0000 in order to recover the payload. The following is the FBI’s ‘Duck Hunt’ DLL as it appears on memory dump:

QAKBOT TERMINATOR

In this section I’m going to provide a technical description about it’s possibile to observed by analyzing this DLL. The DLL appears to have been compiled on 2023-08-16 giving us a good idea of the timing around the operation. To start, we can start to note the DLL main payload at sub_10001000.

It retrieves the handle of the current process using GetCurrentProcess() and tries to open the process token with OpenProcessToken. If the process token was successfully opened, it attempts to retrieve token information using GetTokenInformation.

If the token information is successfully retrieved, it uses LookupAccountSidW to look up the account name associated with the security identifier (SID) obtained from the token. It then calls two subroutines (sub_10001720 and sub_100015D0). On sub_10001720 the DLL calls the functions GetComputerNameW and GetVolumeInformationW.

There, after to have modified the data pointed to Dst by appending the computer name and volume serial number, these information are concatenated using lstrcatW.

The returning value is a bitwise negation of the concatenated strings passed later to sub_100015D0. Both these subs appear to be used to generate the lpName parameter for the following CreateMutexA call.

At this point the DLL provide for the termination of QakBot agent infection the system by sending the command QPCMD_BOT_SHUTDOWN through a named pipe. The library generates a name for the named pipe that the QakBot core is going to poll.

This malstrain uses named pipes to communicate to its other process running on the targeted host. The following figure shows a code snippet of a recent QakBot sample where it goes creates named pipes to read and send data.

CONCLUSIONS

The analyzed DLL appears to be quite simple considering its behavior.
It’s basically designed to create a local mutex and send the message to force the disinstallation of running QakBot instances. Although simple, this DLL is very effective in performing the expected operations.

OBSERVABLES

CATEGORYTYPEVALUE
PAYLOADSHA256855eb5481f77dde5ad8fa6e9d953d4aebc280dddf9461144b16ed62817cc5071
PAYLOADSHA1c08d4094bf7b89a7badc945fcb48d6cc168afaae
PAYLOADMD554d681fafc6d8b5b1e5ba156bbb4e332
PAYLOADSHA2567cdee5a583eacf24b1f142413aabb4e556ccf4ef3a4764ad084c1526cc90e117
PAYLOADSHA1a4f444d92447cff4215bed38acfd48614c178ef9
PAYLOADMD5db92062f94839dc8f0e94ef6c14b113a

Introducing CertiLeaks: An Intelligence-based layer of security for digital signatures

WHAT’S THIS ?

CertiLeaks provides a list of Cert Hashes of leaked certificates (acquired from dark / deep web channels) that can potentially be used to sign malware. It is important to note that these fingerprints are not acquired through a reactive approach, such as analyzing a malware stream, but through a proactive one by acquiring them from dark / deep web channels and other sources. The advantage is that with a reactive approach we will always be destined to arrive late (since inevitably the certificate in question has already been used to sign malicious payloads) while with a proactive one we can get to have a stream of fingerprints belonging to certificates that, in best case scenario, will be used to sign malware in the future.

INTRODUCTION

A signed executable, often known as a digitally signed executable, is a type of computer program or application file that has been authenticated and verified by a digital signature. This digital signature is generated using a cryptographic process and is issued by a trusted entity known as a certificate authority (CA).

When software developers create an executable file, they can choose to digitally sign it with their keys. This process involves applying a unique cryptographic hash to the file and then encrypting that hash with the developer’s private key. This encrypted hash, along with the developer’s public key and other relevant information, is then bundled together to create a digital signature.

Once the digital signature is attached to the executable file, users who attempt to run or install the software can verify its authenticity. This verification is typically done by the operating system or security software that checks the digital signature against the public key associated with the developer’s private key. If the signature is valid and the file has not been tampered since signing, the software is considered trustworthy, and users can be confident that it comes from the identified developer and more generally from a trusted source.

The primary purpose of digitally signing executables is to ensure the integrity and authenticity of software. It helps prevent the distribution and execution of malicious or tampered applications, as users can trust that the signed software has not been altered by unauthorized parties.

Digital signatures play a crucial role in software distribution, especially in the context of operating systems and application marketplaces. They provide a layer of security and help users make informed decisions about the trustworthiness of the software they are installing on their devices.

RISKS RESULTING FROM LEAKED CERTIFICATES

When attackers gain access to a leaked or stolen certificate, they can exploit it to sign malware and perform malicious activities with a higher degree of success.

Generally speaking, an attack involving a stolen / leaked certificate can be similar to the following:

Acquiring the Certificate: Hackers may obtain a legitimate code signing certificate through various means. This can include hacking into a software development company’s servers, compromising the systems of individual developers or purchasing / finding stolen or leaked certificates from underground marketplaces.

Tampering with Malware: Once the hackers have a valid certificate, they can create or obtain malicious software (malware) that they intend to distribute to unsuspecting users.

Signing the Malware: The hackers use the stolen certificate to digitally sign the malware they want to distribute. By doing so, they give the malicious code an high degree of legitimacy and trustworthiness. The digital signature falsely implies that the malware comes from a reputable source, like the original software developer.

The potential benefits for attackers of code signing are:

Evading Security Measures: Digital signatures are used by various security solutions to verify the authenticity of executable files. By signing the malware with a legitimate certificate, the malicious software can potentially bypass security checks and appear harmless to some security software.

Increasing Distribution Success: By leveraging a signed executable, the hackers can increase the chances of their malware being successfully installed and executed on target systems. Many operating systems and antivirus solutions tend to trust signed files much more than unsigned ones, making it easier for the malware to propagate.

Maintaining Persistence: Some malware variants use valid certificates to maintain persistence on infected systems. The malware may use the trusted certificate to update itself or establish connections to command-and-control servers without raising suspicion from security measures.

Launching Supply Chain Attacks: In some cases, hackers may exploit the stolen certificate to compromise the software supply chain. They may insert the signed malware into software updates or distributions, potentially affecting a large number of users who trust the signed software.

and many more…

To mitigate the risks associated with stolen or leaked certificates, certificate authorities and software developers must implement robust security measures to protect their private keys and certificates.

THE ROLE OF CYBER THREAT INTELLIGENCE IN MITIGATING THE RISK OF LEAKED CERTIFICATES

Cyber Threat Intelligence (CTI) can play a crucial role in mitigating the risk of stolen / leaked certificates by providing valuable insights, early warnings, and proactive measures to organizations and security teams.

However, to the best of my knowledge, there are currently no freely available sources that can provide a proactively acquired feed of fingerprints of leaked certificates, and this is where CertiLeaks comes into play; this is how it works:

Dark Web and Underground Markets: CTI teams usually actively monitor dark web forums and underground markets where stolen certificates are traded / shared. By identifying the presence of these certificates early on, they can alert relevant parties to take appropriate action. In this case the acquired certificate is sent to an automatic processing queue.

Processing Queue: The obtained certificates are included in an automated processing queue which includes different activities among which trying to sign executables with them.

Thumbprint Extraction: The thumbprint is extracted for each of the certificates with which it was actually possible to sign artifacts arbitrarily.

Feed sharing: For the open feed, the list on my personal GitHub repository is updated at regular intervals via password protected archives.

HOW TO USE CERTILEAKS

We can propose an example of an executable originally signed with a valid (now already revoked) certificate.

The executable in question, corresponding to SHA256 84C9CBC01241D4B52453C467A28AB9190C1B87F0B7AC31CEB21E079FA919288B, has been originally signed with a leaked certificate owned by Hangil IT Co., Ltd having 28F9A8E7601F5338BF6E194151A718608C0124A8 as thumprint.

At the time of detection, this malware had an extremely low detection rate probably due to the fact that it presented a valid certificate:

History of detection rates. Source: VirusTotal

However CertiLeaks provides a list of hashes of leaked certificates, (called thumbprints), that are used as unique identifiers.

If an hash is listed under the CertiLeaks repo, the corresponding certificate has already been used (at least by me :]) to sign artifacts arbitrarily and therefore should not be trusted.

To verify that an executable does not report a fingerprint included in CertiLeaks, you can use YARA with the following syntax:

rule CertiLeaks_CompromisedCert_82938_92833 {
   meta:
      author = "Emanuele De Lucia"
      description = "Detects an executable signed with a leaked certificate"
      hash1 = "84c9cbc01241d4b52453c467a28ab9190c1b87f0b7ac31ceb21e079fa919288b"
   condition:
       for any i in (0 .. pe.number_of_signatures) : (  
         pe.signatures[i].thumbprint == "28f9a8e7601f5338bf6e194151a718608c0124a8"
      )
}

The service, for now, is offered as it is and is based on a visibility which by its nature must be considered limited. CertiLeaks is to be considered a pilot service. Therefore it could be suspended, withdrawn and the information relating to it removed at any time without notice. CertiLeaks may share data and information late (or not at all) with respect to the corresponding commercial service

LIMITATIONS & NOTES

The service is offered as it is and is based on a visibility which by its nature must be considered not exhaustive. Please note that CertiLeaks is a pilot service. Therefore it could be suspended, withdrawn and the information relating to it removed at any time without notice. CertiLeaks may share data and information late or not at all with respect to corresponding commercial services in which I am actively involved. The process does not check the status of the certificates it processes.

DATA FEED

Feed of fingerprints of leaked certificates are updated at regular intervals and can be found here

Please note that the archive is password protected to prevent the information contained in the feed can accidentally harm the reputation of potentially involved companies and institutions. Password can be shared with trusted third parties by emailing me at [email protected]

Rhysida: An old / new threat in the ransomware landscape

rhysida

Introduction

Rhysida is a relatively new ransomware group operating as a R-a-a-S (Ransomware-as-a-Service) provider. The corresponding ransomware has the particularity of making use of LibTomCrypt, a cryptographic library that allows attackers to leverage on robust encryption methods and a fast development. Rhysida appears to be written in C++ and compiled via MinGW; the payloads I’ve found are quite bulky in size (± 1.20 MB) probably due to the linked libraries. As already reported, in fact, this ransomware includes open-source crypto library LibTomCrypt which is able to provide support for the implementation of various cryptographic functions and, more generally, to allow the ransomware to work through effective cryptographic methods. It is also possible that the authors of Rhysida also appreciated the fact that LibTomCrypt is written in C and therefore can be easily integrated.

Insights

Rhysida ransomware looks like a piece of malware with a rather easy logic and in some cases not very optimized in its code (in several cases some constructs are immediately repeated in the code presenting the same logical conditions). Upon its execution, the ransomware initializes several structures and acquires information about the machine it is working on.

Interestingly, the Rhysida variant under analysis seems designed to work on the basis of two parameters potentially specified at startup: directory and is_self_remove

directory (-d) is used to specify the directory to encrypt (alternatively the ransomware will encrypt all logical drives from A to Z) while is_self_remove (-sr) is used to ensure the ransomware removes itself after the encryption process is complete. To successfully perform this action, Rhysida relies on the following PowerShell command

The ransomware encrypts the files using Chacha20 and RSA 4096 to encrypt the ChaCha20 key. The construct where the cryptographic process is launched could represent a good opportunity to write a hunting rule:

rule Rhysida_Ransomware_87234_98244 {
meta:
author = "Emanuele De Lucia"
hash1 = "250e81eeb4df4649ccb13e271ae3f80d44995b2f8ffca7a2c5e1c738546c2ab1"
hash2 = "a864282fea5a536510ae86c77ce46f7827687783628e4f2ceb5bf2c41b8cd3c6"
hash3 = "d5c2f87033a5baeeb1b5b681f2c4a156ff1c05ccd1bfdaf6eae019fc4d5320ee"
tlp = "white"
score = 80
strings:
$ = { 48 8B 40 [1] 0F B6 00 84 C0 75 [1] B9 [4] E8 [4] 48 89 85 [4] C7 85 [8] EB [1] 8B 95 [4] 48 8B 85 [4] 41 89 D0 48 8D 15 [4] 48 89 C1 E8 [4] 48 8B 85 [4] 48 89 C1 E8 [4] 83 85 [5] 83 BD [5] 7E [1] 48 8B 85 [4] 48 89 C1 E8 ?? ?? ?? ?? }
condition:
any of them
}

The setBG() function is responsible to change the system wallpaper by executing a series of commands like reported following:

Finally, the following are the file type extensions that the ransomware does not encrypt:

.bat, .bin, .cab, .cmd, .com, .cur, .diagcab, .diagcfg, .diagpkg, .drv, .dll, .exe, .hlp, .hta, .ico, .lnk, .msi, .ocx, .ps1, .psm1 , .scr, .sys, .ini, .db, .url, .iso, .cab, .thumdb.

while the following shows the folders that Rhysida excludes from encryption:

\$Recycle.bin, \Documents and Settings, \PerfLogs, \Program Files, \Program Files (x86), \ProgramData, \Recovery, \System Volume Information, \Boot and \Windows.

Once the encryption is done successfully, the extension of the files changes to .rhysida.

Initial Access

Rhysida represents a relatively new threat in the ransomware landscape and for this reason, information regarding its propagation methods is rather limited; however, it is possible to hypothesize that, at least in part, the Rhysida‘s affiliates rely on IAB (Initial Access Broker) from which to buy RDP / VPN accesses and then deliver the ransomware once the internal domain controller is reached. Other techniques potentially used to deliver Rhysida ransomware include password-spraying attacks, phishing and direct compromise by affiliates using known vulnerabilities and the installation of commodity malware.

Attribution and Victimology

Rhysida seems to be a totally new trend in the ransomware threat landscape. However, some aspects point to the group’s need to develop their own ransomware quickly (such as using LibTomCrypt) as well as being confident that the file encryption solution was robust enough from the outset. All this (and other aspects still under analysis) suggest that Rhysida could in fact be a rebrand of an already known cartel and not a totally new group. This option is also enhanced by the fact that the group seems to be focused on specific sectors to be targeted, such as academic / educational (which could be very close to a group with already tested techniques).

Conclusions

In this post I have analyzed a new ransomware variant known as Rhysida. It is relatively new in the ransomware threat landscape. Although there is a public tendency to consider Rhysida as a totally new threat, some of its aspects (especially in the ecosystem that surrounds it) suggest a possible rebrand in progress by a group already in business. Rhysida appears to be targeting primarily academic/educational entities and analysis of its code suggests the need for rapid development as well as a sufficiently robust solution.

Indicators of Compromise

CategoryTypeValue
PAYLOADSHA256d5c2f87033a5baeeb1b5b681f2c4a156ff1c05ccd1bfdaf6eae019fc4d5320ee
PAYLOADSHA256a864282fea5a536510ae86c77ce46f7827687783628e4f2ceb5bf2c41b8cd3c6
PAYLOADSHA256250e81eeb4df4649ccb13e271ae3f80d44995b2f8ffca7a2c5e1c738546c2ab1

Understanding the magnitude of the 3CXDesktopApp phenomenon

INTRODUCTION

On March 29, 2023, CrowdStrike posted a blog sharing details about a supply chain attack involving a software called 3CXDesktopApp. On the same day, SentinelOne also shared details in relation to the same event. 3CXDesktopApp is a multi-platform application for desktops (Linux, MacOS, and Windows) that allows users to interact via chat, messaging, video, and voice.

The 3CXDesktopApp supply-chain attack started when a threat actor (which CrowdStrike identified to have links with the Lazarus Group) was able to embed arbitrary code into the official build of the software causing individuals and organizations fall victims of a global-scale campaign by downloading and running the 3CXDesktopApp installer from the developer’s website. Both Microsoft Windows and MacOS users were targeted as both the Windows and Mac versions were compromised.

On a Windows system, the MSI installer (3CXDesktopApp-18.12.416.msi, 3CXDesktopApp-18.12.407.msi) is designed to extract several files and to execute the file 3CXDesktopApp.exe which in turn loads a malicious library file named ffmpeg.dll (corresponding to the MD5 hashes 74bc2d0b6680faa1a5a76b27e5479cbc and 27b134af30f4a86f177db2f2555fe01d).

THE KILL-CHAIN

The DLL appeared to be originally compiled on Nov. 12, 2022, suggesting a long-term preparation of the attack. ffmpeg.dll was the first file on which I focused my attention. Within it I noted the function named dllmain_dispatch that appears as a custom implementation wrapping the standard DllMain function (basically called by the operating system when a DLL is loaded or unloaded). The function checks if the reason of the call is DLL_PROCESS_ATTACH or DLL_PROCESS_DETACH it calls the function sub_18004E250

sub_18004E250 is a wrapper of sub_18004DE60. The latter is basically designed to :

  1. create a new event named “AVMonitorRefreshEvent

2. search and load another malicious component named d3dcompiler_47.dll

3. Identify within it an encrypted payload having 0xC3FAEDFE as marker

4. Decrypt the payload-RC4-stream using the key 3jB(2bsG#@c7

5. Use the VirtualProtect() function to alter the memory access permissions

The decrypted payload appears to act as another loader that is designed to wait for certain amount of days before contacting a GitHub repository retrieving .ICO files having encrypted C&C strings within them.

The final payload appears to be a stealer able to extract and data from popular web browsers. This one, at time of writing, is not in my availability.

MAGNITUDE OF THE EVENT

In the threat intelligence vertical, global telemetries are often used to assess the impact of a given campaign on a global scale; In this regard I have a certain degree of visibility (always considered partial and never complete) on the global diffusion of certain hashes as well as on the malicious network infrastructures they use. As already mentioned, the first files I focused on was the ffmpeg.dll one and the corrisponding hashes (74bc2d0b6680faa1a5a76b27e5479cbc and 27b134af30f4a86f177db2f2555fe01d). According to my visibility, the malicious toolset has been first observed on March 27, 2023 in Belgium, United States, Germany, Netherlands, Turkey and Israel impacting above all the Manifacturing, Industry, Finance, Hospitality and the Technology sectors (the latter at lower percentages). However, this data is to be considered not very indicative of the start of this campaign as the first detection signatures were massively released on that day. In fact researchers at Unit42 confirm the observation of SmoothOperator-linked artifacts as early as March 09, 2023. Map is derived by signature-based detections:

From my side, there is instead a very different situation if we instead consider telemetry based on malicious network infrastructures. SmoothOperator campaign leveraged on different domain names as Command and Control. They can be easily retrieved from the blog posts already reported above from CrowdStrike, SentinelOne and Unit42.

For example, if we considered the domain name msstorageazure[.]com, according to my visibility, it’s possibile to observe the first SmoothOperator-linked request to this domain starting on Feb. 10, 2023 (not necessarily indicating an active infection, but gives an idea of the time span of activity). Global resolution telemetries over this domain, up to March 29, 2023, confirms the Countries reported previously as potentially impacted, adding Spain, Canada, Portugal, Brazil, Austria, Switzerland, India, Thailand, Sweden and Australia.

The resolution telemetries (we are referring to devices that have communicated with malicious network infrastructures) for the domain akamaitechcloudservices[.]com add also Italy to the countries potentially impacted as on Feb. 17, 2023 resolution requests from this Country have been observed, referring at least to the Industrial and Manufacturing sectors.

According to the visibility I can dispose of, the final map of the proportions of this event is as follows:

Note that the maps refer to telemetry data which does not necessarily indicate an active infection in progress but an entity that has communicated with an infrastructure controlled by the threat actor. They are from before March 29, 2023.

CONCLUSIONS

3CXDesktopApp is a very used software and for this reason the SmoothOperator campaign received a lot of attention from the cyber security community. The potential damage caused by this supply-chain attack is very extensive and the effect of a compromise can be serious including the theft of data and sensitive information.

ALPHV / BLACKCAT: THREAT ASSESSMENT AND PROFILE

BlackCat / ALPHV is known for high-profile attacks like those conducted against the italian luxury brand Moncler, the aviation company Swissport and more recently against GSE (Gestore Servizi Energetici SpA). The ransomware payload includes a lot of advanced features and is able to support a wide range of offensive operations and to impact different environment . It’s command-line driven and human-operated with the ability to use different encryption routines, spread between devices, and kill hypervisors. The collective appeared in early December 2021 announcing the start of its activities in DDW (Deep / Dark Web) forum. It’s a group very well integrated in the criminal community and among its affiliates there are probably a lot of experienced individuals in the panorama of ransomware operations as coming from cartels that over the time have dismantled their activities. In this regard, it is quite probable that the collective has, at least in part, benefited from the closure of the Conti cartel as some former elements of the latter have certainly chosen to join the BlackCat / ALPHV project, probably maintaining accesses, tools, victims matrix and visibility acquired within the previous “brand“.

BlackCat / ALPHV R-a-a-S model consists of multiple players:

  • Access Broker (Engaged to provide first access to victim networks)
  • RaaS Operators (Responsible for the development of tools and infrastructures to support the cartel)
  • RaaS Affiliates (Responsible for operations within the affected networks. They deploy the ransomware payload, exfiltrate data and move laterally; usually not in this order ;])

Since this collective is therefore based on a plethora of different affiliates (as common with others similar criminal organizations), the ways in which a BlackCat / ALPHV payload could impact an infrastructure vary greatly depending on the affiliate who delivered it. Initial access methods may also differ; some intrusions, for example, have seen the exploitation of leaked credentials, misconfigured or vulnerable VPN concentrators, exposed RDP services, or Exchange server vulnerabilities.

PAYLOAD OVERVIEW

As already said, BlackCat / Alphv is one of the first ransomware developed in the RUST programming language (by using this language problably the attackers tried to increase the chances to remain undetected and, by leveraging this programming language, operators are able to easily compile it against various operating system architectures.) Based on some personal considerations deriving from the analysis of some samples, I can say that it was written by very experienced malware developers. This malware can impact Windows / Linux devices and VMWare instances and has been developed with extensive capabilities, including self-propagation ones configurable by the attackers in order to align with the variables of the environment in which it operates. It’s based on a combination of Salsa20/AES and RSA in order to perform the cryptographic operations. This malware family quickly has achieved high levels of notoriety for its sophistication and innovation but also because the operators of the RaaS allowed the affiliates to withhold very high percentage for each ransomware payment (up to 90%). The combination of a payload written from scratch in an uncommon language as well as aggressive “market” offers (and very advantageous for affiliates) have allowed this project to immediately carve out a good slice of users.

VICTIMOLOGY

BlackCat / APLHV victims  include organizations operating in at least the following sectors:

  • Technology
  • Industry
  • Transportation
  • Pharmaceutical
  • Energy
  • Telco
  • Automotive
  • Retail

Usually the gang adopts a rather aggressive approach in handling the information stolen from victims and in relations with them; this is likely to increase the chances of obtaining the required payments. The ransoms usually run in the millions of dollars, but the gang has often accepted payments far less than initially requested.

RECRUITMENT AND AFFILIATION PROCEDURES

BlackCat / Alphv has been observed to look for affiliates and pentesters via well-known cybercrime forums. Affiliates, as already stated, can keep up to the 90% of the ransom payment, while the rest goes to the BlackCat/Alphv operators. Every affiliates and collaborators are interviewed (sometime more than once) and vetted before being accepted into the collective. If the affiliate is accepted, it is granted a login to a Tor-based control panel that hosts the affiliate’s space. This TOR-based web portal is completely written in Russian and is used by operators to share update, announcements, tips, tutorial about how to use the BlackCat / Alphv ransomware and information relating to the victims with the affiliates.

GEOGRAPHICAL DISTRIBUTION

It is not easy to pinpoint the geographic distribution of BlackCat / Alphv affiliates. Some of them have been observed to distribute other payloads in parallel (such as, for example, Hive) and therefore do not have an exclusive affiliation. However, most of them are believed to operate from Russia and Eastern Europe. The project, as far as the origins are concerned, was born from a rib of what was ReVil (dismantled by an FSB raids in early 2022). However, it is interesting to note how the former ReVil‘s operators have tried to move away from it in building the new BlackCat / Aphv, avoiding making some mistakes of the past, creating a new ransomware from scratch and encouraging policies aimed at solving the some common problems that are affecting these cartels, such as that the ever-increasing detection capabilities of common attack tools the affiliates are used to rely on such as Mimikatz and CobaltStrike.

CONCLUSIONS

BlackCat is an sophisticated ransomware cartel that can count on an highly customized and personalized payload. By using the RUST programming operators are able to compile it easily against various operating system architectures which facilitates the group’s ability to switch between victims and adapt the payload against different environment. BlackCat/Alphv operates under a R-a-a-S model and uses multiple extortion techniques. It is composed of several affiliates, some of which have been observed delivering payloads other than BlackCat / Alphv’s, such as, for example, Hive. Some of these affiliates have previous experience with others groups, such as BlackMatter and Conti.