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.

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.

INSIGHTS

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 (pa.pay).

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.

THREAT HUNTING

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:

YARA
rule Sandworm_ArguePatch_76444_00001 : RUSSIAN THREAT ACTOR {
meta:
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
*/
strings:
$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.

INDUSTROYER2 INSIGHTS

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

TypeValue
MD57c05da2e4612fca213430b6c93e76b06
SHA1fdeb96bc3d4ab32ef826e7e53f4fe1c72e580379
SHA256d69665f56ddef7ad4e71971f06432e59f1510a7194386e5f0e8926aea7b88e00

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.

INDUSTROYER vs INDUSTROYER2

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).

CONCLUSIONS

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.

DETECTION

YARA
rule Sandworm_Industroyer2_76222_00001 : RUSSIAN THREAT GROUP {
meta:
author = “Emanuele De Lucia”
description = “Strings-based threat detection rule for INDUSTROYER2”
tlp = “white”
date = “2022-04-15”
hash1 = “d69665f56ddef7ad4e71971f06432e59f1510a7194386e5f0e8926aea7b88e00”
strings:
$ = “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.

Insights

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

COMNAP

COMNODE

SQLQUERY

SPOOLSS

LLSRPC

browser

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.

Conclusions

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

Indicators

TypeValue
SHA2563b8bd0a0c6069f2d27d759340721b78fd289f92e0a13965262fea4e8907af122
SHA256a679dbde0f4411396af54ea6ac887bd0488b2339cd8a4b509a01ca5e906f70bd

Detection

rule Turla_Code_00325_00291 {
meta:
author = “Emanuele De Lucia”
description = “Yara hunting rule for Turla shared code chunk”
hash1 = “3b8bd0a0c6069f2d27d759340721b78fd289f92e0a13965262fea4e8907af122”
hash2 = “a679dbde0f4411396af54ea6ac887bd0488b2339cd8a4b509a01ca5e906f70bd”
hash3 = “c819ec7743e2f5db13f277749961dffad08dba6dd21450eea33a27403386c959”
hash4 = “7bb65fe9421af04c5546b04a93aa0e517356c0a85856f1265587983ce2bf8aef”
hash5 = “94421ccb97b784c43d92c4b1438481eee9c907db6b13f6cfc4b86a6bb057ddcd”
strings:
$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 ??)}
condition:
$hex
}