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.


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.


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.


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.


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.


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.

Reverse and Hunt: Between the jumps of ArguePatch

ARGUEPATCH is a patched version of a legitimate component of the Hex-Rays IDA Pro software. In detail it’s the remote IDA debugger server named win32_remote.exe and it’s basically designed to act as a loader by reading and decrypting an encrypted payload written to disk (CaddyWiper). It has been used against Ukrainian targets in destructive attacks and it’s believed to be linked with the Russian threat actor known as Sandworm (aka BlackEnergy).At the time of writing several Caddywiper-related analyzes can already be found on the net but none seem to delve into what happens in its loader. Having worked on this malware family in order to hunt for similar samples I decided to share a quick analysis that led to the creation of a hunting YARA rule.


This piece of malware it is not complex in its logic; The loader expects to be launched with two parameters from the command line. The first represents the decryption key and the second the path of the payload on the disk. Immediatly after the execution smong the first interesting things it goes to dynamically resolve the shell32.CommandLineToArgW and kernel32.GetCommandLine API functions.

It calls the latter in order to retrieve the parameters with which the executable has been launched and shell32.CommandLineToArgW in order to parse the command line string and get an array of pointers to the command line arguments. The next operation of interest is the resolving of kernel32.ReadFile and kernel32.GetFileSize API functions in order retrieve and work on the encrypted CaddyWiper payload written on the disk (

Below the image as this payload appears in its original encrypted form

As said the primary job of such malware is reading, decrypting and executing the CaddyWiper payload. Regarding this task it’s possibile to observe the execution on 00471B04. Here one byte from the input key (JRIBDFIMCQAKVBBP) is used to decrypt the payload as reported above.

As result a decrypted payload as shown following can be observed

At this point we land on real CaddyWiper payload. Even here the malware goes to retrieve several API function that will need to operate on various areas of the affected systems like FindFirstFileA, FindNextFileA, CreateFileA, WriteFile etc.etc. after to have retrieved the machine role via DsRoleGetPrimaryDomainInformation.

At this point the malware starts its job by iterating through files on the system and replacing their contents with null-bytes (\x00). It’s starts by looking for files under %SystemDrive%\Users and continuing to logical drives D:\ up to Z:\. Disk partitions from //./PHYSICALDRIVE9 to //./PHYSICALDRIVE0 are the last to be impacted.


In this analysis we observed an essential point of the execution chain. It allows the loader to decrypt and execute the real payload of the attack. In my opinion indeed one good point to hunt for threats similar to the ArguePatch version described here is at sub_471B04. According with the logic of the executable this function is needed to recover the malicious payload and ensure that the targeted systems are impacted.

Creating a rule on this code fragment (reported following) is then useful for the hunting of similar payloads:

rule Sandworm_ArguePatch_76444_00001 : RUSSIAN THREAT ACTOR {
author = “Emanuele De Lucia”
description = “YARA hunting rule for ArguePatch variants”
tlp = “white”
hash1 = “cda9310715b7a12f47b7c134260d5ff9200c147fc1d05f030e507e57e3582327”
0x4719c6L 8A01 mov al, byte ptr [ecx]
0x4719c8L 33D2 xor edx, edx
0x4719caL 8B7DF8 mov edi, dword ptr [ebp – 8]
0x4719cdL 320457 xor al, byte ptr [edi + edx*2]
0x4719d0L 42 inc edx
0x4719d1L 8801 mov byte ptr [ecx], al
0x4719d3L 83FA10 cmp edx, 0x10
0x4719d6L 72F2 jb 0x4719ca
0x4719d8L FF4DFC dec dword ptr [ebp – 4]
0x4719dbL 41 inc ecx
0x4719dcL 395DFC cmp dword ptr [ebp – 4], ebx
0x4719dfL 75E5 jne 0x4719c6
$hex = { 8A 01 33 D2 8B 7D ?? 32 04 57 42 88 01 83 FA ?? 72 ?? FF 4D ?? 41 39 5D ?? 75 ?? }
condition: (uint16(0) == 0x5a4d and $hex)

Industroyer2: The ICS-capable malware re-emerges in order to cause critical services disruption

A few days ago a new variant of an ICS-capable malware known as Industroyer has been employed during a cyber-attack conducted against industrial control systems (ICS) responsible for the management and control of power plants subsystems in Ukraine.

This new version has been named Industroyer2 and represents the evolution of a malware family already observed in December 2016 working against similar targets. This type of attack was reported after a long series of other attacks targeting Ukrainian organizations and entities which generally involved the use of wipers, backdoors and DDoS attacks.

Its peculiarity is that it is in fact the first to have been clearly targeted ICS infrastructures and to employ ICS-capable malware.


I had a look at the file identified with the following characteristics:


This is a 37.00 Kb in size 32-bit x86 Portable Executable (PE) compiled on Wednesday 23 March 2022 10:07:29 as evidence reported following

Basically speaking, the malware is designed to read some embedded configuration entries in order to craft IEC-104 Application Service Data Unit (ASDU) messages that allow it to interact with the remote targeted units (reachable as internal IP addresses) over TCP protocol.

Taking a look at the execution flow, we can see that this piece of malware handles two optional parameters from the command line which are -t and -o as evidence from the code extraction below

-o allows to write a debug file on the filesystem (by default it’s printed on the console) while -t allows to delay execution by referencing the current SystemTime.

After parsing the parameters provided via the CLI, the malware starts to retrieve the information from the embedded configuration entries

These entries appear as the image following

Each configuration entry starts with an internal IP address (in the image above obscured in the last two octets) and a port, followed by four numbers (may be some sort of operating flags) a process name and a path (in this case D:\OIK\DevCounter).

The last chunck consists of information used to construct the message intended to be send to the ASDUs. For each of the entries found the malware goes to terminate the process PServiceControl.exe.

The process name is hardcoded within the executable.

At this point it goes to enumerate processes again in order to find the process name corresponding to the one specified in the configuration entry (PService_PPD.exe).

After recovering the path D:\OIK\DevCounter and the file name PService_PPD.exe it’s going to rename the file present under this path by adding the .MZ extension to it.

Most likely this is done to prevent any task designed for the process’s ‘always-on‘ from re-launching it. For each embedded configuration a thread is then created in order to implement IEC-104 communication protocol.

The IEC-104 extends the IEC-101 in a way that it can be transmitted over a TCP/IP network. So in each such thread the malware will attempt to communicate with the specified IP address using the protocol described in the IEC-104 standard after to have iterated through the ASDU entries in the configuration block.

In IEC-104 each object in the ASDU has an Information Object Address. Basically, the primary purpose of this action is to connect to the specified IP address and send crafted ASDU messages resulting in Information Object Address state being set to either ON or OFF.


By doing a comparative analysis of INDUSTROYER (its IEC-104 module) and INDUSTROYER2 it’s possibile to note a lot similarities above all in the operating logic despite the fact that the latest samples certainly show substantial differences if compared with 2016 ones.

Among the technical similarities at the code level it’s possibile to observe overlaps in the functions dedicated to the management, composition and control of ASDU messages.

The new executable in some cases joins together some strings in respect to previous sample optimizing in some cases the global execution process but in general the strings that refer to the debug messages are the same allowing old YARA rules to match the new sample as well.

According to the first first attribution of the family shared by ESET researchers and in the light of the further technical evidence extracted in this article, the threat in question is to be linked with the threat actor known as Sandworm (aka BlackEnergy).


I can definitely say that the Industroyer malware family is a sophisticated piece of malware used against industrial control systems (ICS). The findings reported here are in line with previous operations already attributed by the security community to Russian APT groups and to the best of my current knowledge this is the first ICS-capable malware used since the beginning of the conflict between Russia and Ukraine after a long series of attacks that have seen the use of wipers, backdoors, different early and middle-stage implants and (D)DoS attacks.

The use of this type of malware should alert about the potential of Russia-State linked APT groups to focus their efforts against industrial control systems (ICS) and their willingness to use this kind of “digital weapons” to cause disruption of critical services.

It’s important to consider the attackers could adapt this malware to other similar targets and that any intrusion against targets of this type should be considered extremely dangerous and complex to mitigate in relation to the presence of protocols born decades ago without taking the security factor into consideration.


rule Sandworm_Industroyer2_76222_00001 : RUSSIAN THREAT GROUP {
author = “Emanuele De Lucia”
description = “Strings-based threat detection rule for INDUSTROYER2”
tlp = “white”
date = “2022-04-15”
hash1 = “d69665f56ddef7ad4e71971f06432e59f1510a7194386e5f0e8926aea7b88e00”
$ = “PServiceControl.exe”
$ = “Sent=x%X | Received=x%X”
$ = “Cause: %s (x%X) | Telegram type: %s (x%X)”
$ = “Length:%u bytes | “
$ = “Unknown APDU format !!!”
$ = “%02hu:%02hu:%02hu:%04hu”
condition: (uint16(0) == 0x5a4d and all of them)

The BigBoss Rules: Something about one of the Uroburos’ RPC-based backdoors

BigBoss is one of the RPC-based backdoors used by Uroburos (aka Turla, Snake, Venomous Bear, Pacifier). It was first spotted out in 2018 and was observed to include new features in the last quarter of 2020. During operations usually it’s used in combination with R.A.T. (Remote Administration Tools) such as Kazuar and Carbon. Several months ago I had the opportunity to analyze some versions of these pieces of malware and have now decided to publish an excerpt based solely on some specific technical characteristics observed. The activity had as objective the production of detection and attribution rules one of which is shared in this post.


BigBoss implants exports basically (3) three functions. The Start() one is designed to retrieve basic information and to call sub_407E50 at 0040B0D3. First of all modulename kernel32.dll is dexored through the key 0x4d4e and an handle to kernel32.dll is obtained through GetModuleHandle. Malware writer chose to dynamically resolve certain API functions likely in order to hide information, from static analysis, about libraries and functions that are used by the implant and normally stored in IAT. In this case IsWow64Process is found through GetProcAddress to retrieve OS bitness.

Shortly after a call to sub_409C70 where the path of the .inf file is retrieved.

BigBoss writes a configuration file named backport.inf. The configuration file is written to %SystemRoot%\INF\backport.inf (as reported in screenshot above) and contains a [Version] section with various configuration entries. At this point instructions performed call the StartServiceCtrlDispatcher function in order to connect to the SCM (Service Control Manager) and start the control dispatcher thread. The dispatcher thread loops, waiting for incoming control requests for the services specified in the dispatch table.

Service name is SWCheckState. Further API functions is then dynamically resolved. One of them is CreateService retrieved even in this case through a GetProcAddress call after to have obtained an handle to advapi32.dll at sub_408790. After the service is created OpenService function is called in order to interact with the service just created and ChangeServiceConfig2W ChangeServiceConfigW are subsequently used to modified parameters of the same. Finally, StartService starts the service. In ServiceMain a RegisterServiceCtrlHandlerEx function is used to register a control handler with the control dispatcher. SetServiceStatus is called to set the status of the service and the CreateEvent function is then responsible to create the event object. 

SMB Server is then enabled by creating the RegKey HKEY_LOCAL_MACHINE “SYSTEM\\CurrentControlSet\\Services\\lanmanserver\\parameters on sub_40AB90.  Named pipes are used for interprocess communication (IPC) both locally and remotely. Access to the remote named pipes is done via SMB. RegKey HKLM\SYSTEM\CurrentControlSet\Control\LSA\Restrict Anonymous is then set to 0 in order to permit anonymous logon users can access all shared resources on a remote share

The RegKey HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\LanmanServer\Parameters\NullSessionPipes is also written in order to add the following values







sub_40AAE0 is responsible for connections to remote devices via IPC$. via WNetAddConnection2

BigBoss supports connections through null sessions or via default credentials. A thread is then created having sub_408830 as StartAddress. This thread is mainly responsible to handle communications with CnC (Command and Control) server. CreateNamedPipeW and ConnectNamedPipe are used to test connection. If successfull it’s able to get additional payloads and write operation results into log files created and written under %temp% path.


BigBoss is an integral part of the Turla team’s attack and persistence suite. Its development and evolution have probably shared practices and logic with other implants linked to its main cluster such as the second stage backdoor called Carbon. For example, by analyzing both, it can be noted that it shares with it not only a partial overlap in some internal functions, as shown below

but in some cases whole code chunks having a full overlap

I based one of my hunting rules for this family on this piece of code. The rule is released in the “Detection” section




rule Turla_Code_00325_00291 {
author = “Emanuele De Lucia”
description = “Yara hunting rule for Turla shared code chunk”
hash1 = “3b8bd0a0c6069f2d27d759340721b78fd289f92e0a13965262fea4e8907af122”
hash2 = “a679dbde0f4411396af54ea6ac887bd0488b2339cd8a4b509a01ca5e906f70bd”
hash3 = “c819ec7743e2f5db13f277749961dffad08dba6dd21450eea33a27403386c959”
hash4 = “7bb65fe9421af04c5546b04a93aa0e517356c0a85856f1265587983ce2bf8aef”
hash5 = “94421ccb97b784c43d92c4b1438481eee9c907db6b13f6cfc4b86a6bb057ddcd”
$hex = { 8B (4C 24 ??|55 ??) (51|52) 8D (54 24 ??|45 ??) (52|50) 56 E8 ?? ?? ?? ?? 83 C4 ?? 8D (44 24 ??|4D ??) (50|51) 6A ?? 8D (4C 24 ??|55 ??) (51|52) 6A ?? 8D (54 24 ??|45 ??) (52|50) 8B (54 24 ??|45 ??) 6A ?? 8D (44 24 ?? | 4D ??) (50|51) 6A ?? 8D (4C 24 ??|55 ??) (51|52) 56 (52|50) FF 15 ?? ?? ?? ?? 85 C0 (0F 85 ?? ?? ?? ??|75 ??)}

Revil / Sodinokibi ransomware delivered through Kaseya VSA supply-chain attack

On July 2, 2021, Kaseya issued a notice stating that the company was experiencing a potential cyber attack against the VSA suite. The company itself advised that the on-prem customers servers should be shut down immediately until further notice from them.

VSA is a very common solution and usually used by Managed Service Providers especially in the United States and the United Kingdom. It allows to perform patch management and client monitoring for MSP customers.

From the first reconstructions of the incident, a threat actor caused the spread of malicious code together with alleged updates performing a s.c. supply-chain attack. The delivered malicious code is capable of copying a malware dropper (digitally signed with a valid signature from PB03 TRANSPORT LTD.) of the Revil / Sodinokibi ransomware on the affected systems.

As per evidence extracted, this dropper (sha1: 5162f14d75e96edb914d1756349d6e11583db0b0) has the purpose of creating two distinct files under the path C:\Windows\ . Although not common practice among malware writers, this path is hard-coded within the executable.

The creation of the aforementioned files has the purpose of side-loading a malicious dll (sha1: 656c4d285ea518d90c1b669b79af475db31e30b1) within a legitimate copy of the Microsoft Windows Defender executable (MsMpEng.exe). As soon as the latter is launched, the file encryption phase is therefore carried out through a legitimate process, complicating the detection operations.

Both payloads are retrieved by referencing two resources within the dropper, as shown in the following image

Side-Loaded DLL

The loaded dll into the legitimate Windows Defender executable is intended to perform the actual file encryption operations. The malicious Revil / Sodinokibi payload is originally retrieved after an useful key for this process is dexored at sub_10001110. The DLL exports several function: ServiceCrtMain, ServiceMain, SvchostPushServiceGlobals as evidences reported

ServiceCrtMain is the one of our interest as it is responsible for initiating the logic of retrieving and executing malicious instructions

The payload is then mapped as file into the created thread through CreateFileMappingW and MapViewOfFile.

File mapping is commonly used in order to load into memory a file and permits malware writers to manipulate it easily. CreateFileMapping function is useful to load a file into memory while MapViewOfFile function returns a pointer to the base address of the mapping. The payload is then executed. Following is reported the implant configuration file as it has been extracted in its original form:


Propagation and Related Risks

Supply chain attacks perpetrated with the aim of targeting new victims is something we are not used to see in a ransomware-related incident. This one appears however to have a big impact and certainly opens to considerations about the devastating new trend in cybercrime to study and focus on a single target only to hit hundreds or thousands of them. What must definitely be considered in this event is that the first targets are MSPs (Managed Service Providers) because, by hitting them, the attacker has the potential to further spread malicious payloads even towards their customers.


Managed Service Providers located at least in the following countries: US, DE, UK, IE according to the visibility I can dispose of at the time of writing. MSPs are generally to be considered a strategic target as they offer a direct channel to reach many other potential targets (the same MSP customers).

Indicators of Compromise / Linked Artifacts

updatename: Kaseya VSA Agent Hot-fix

filePath: c:\kworking\agent.exe

filePath: c:\kworking\agent.crt

Task commandline: C:\WINDOWS\system32\cmd.exe” /c ping -n 4979 > nul & C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Set-MpPreference -DisableRealtimeMonitoring $true -DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true -DisableScriptScanning $true -EnableControlledFolderAccess Disabled -EnableNetworkProtection AuditMode -Force -MAPSReporting Disabled -SubmitSamplesConsent NeverSend & copy /Y C:\Windows\System32\certutil.exe C:\Windows\cert.exe & echo %RANDOM% >> C:\Windows\cert.exe & C:\Windows\cert.exe -decode c:\kworking\agent.crt c:\kworking\agent.exe & del /q /f c:\kworking\agent.crt C:\Windows\cert.exe & c:\kworking\agent.exe

md5: 561cffbaba71a6e8cc1cdceda990ead4

sha1: 5162f14d75e96edb914d1756349d6e11583db0b0

sha256: d55f983c994caa160ec63a59f6b4250fe67fb3e8c43a388aec60a4a6978e9f1e

md5: a47cf00aedf769d60d58bfe00c0b5421

sha1: 656c4d285ea518d90c1b669b79af475db31e30b1

sha256: 8dd620d9aeb35960bb766458c8890ede987c33d239cf730f93fe49d90ae759dd



The following rule can be useful to identify the Revil / Sodinokibi dropper

rule REvil_Dropper_827322_000001 {
description = “Detects REvil/Sodinokibi dropper as observed in Kaseya supply-chain attack”
author = “Emanuele De Lucia”
reference1 = “”
reference2 = “”
date = “2021-07-02”
hash1 = “d55f983c994caa160ec63a59f6b4250fe67fb3e8c43a388aec60a4a6978e9f1e”
$ = “MpSvc.dll” fullword ascii
$ = “MsMpEng.exe” fullword wide
$ = “Antimalware Service Executable” fullword wide
$ = “MsMpEng.pdb” fullword ascii
$ = “SOFTIS” fullword wide
$ = “MODLIS” fullword wide
condition: uint16(0) == 0x5a4d and all of them


A possible way to get a first degree of visibility into potential events related to such threat could be to detect how the adversary tries to disable the defenses of the victim system (T1562). In particular, this allows us to observe events in which the adversary successfully disabled Windows Defender through powershell message

Get-WinEvent -LogName Microsoft-Windows-PowerShell/Operational | where {($_.message -match “.Set-MpPreference.” -and $_.message -match “.-DisableRealtimeMonitoring $true.” -and $_.message -match “.-DisableIntrusionPreventionSystem $true.” -and $_.message -match “.-DisableIOAVProtection $true.” -and $_.message -match “.-DisableScriptScanning $true.” -and $_.message -match “.-EnableControlledFolderAccess Disabled.” -and $_.message -match “.-EnableNetworkProtection AuditMode.” -and $_.message -match “.-Force -MAPSReporting Disabled.” -and $_.message -match “.-SubmitSamplesConsent NeverSend.”) } | select TimeCreated,Id,RecordId,ProcessId,MachineName,Message