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


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.


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.


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.


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.


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 {
      author = "Emanuele De Lucia"
      description = "Detects an executable signed with a leaked certificate"
      hash1 = "84c9cbc01241d4b52453c467a28ab9190c1b87f0b7ac31ceb21e079fa919288b"
       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


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.


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


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 {
author = "Emanuele De Lucia"
hash1 = "250e81eeb4df4649ccb13e271ae3f80d44995b2f8ffca7a2c5e1c738546c2ab1"
hash2 = "a864282fea5a536510ae86c77ce46f7827687783628e4f2ceb5bf2c41b8cd3c6"
hash3 = "d5c2f87033a5baeeb1b5b681f2c4a156ff1c05ccd1bfdaf6eae019fc4d5320ee"
tlp = "white"
score = 80
$ = { 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 ?? ?? ?? ?? }
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).


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



Understanding the magnitude of the 3CXDesktopApp phenomenon


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


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.


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.



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)