Logo

Overview

In this post, I’m going over my analysis of a recent Global ransomware sample, a group that I only discovered when someone shared a promotional video they created with me. The video is oddly polished and visually almost resembles an advertisement Apple would release during a new product launch. They also boast about having support for ESXi systems and networked storage devices. There are some other bold claims, such as, one-click propagation across networks, “mount mode” (encrypting remote disks locally), “new attacks every single day”, 85% revenue share, AI-powered negotiation support, and access to their platform on mobile devices. Affiliate groups are supposedly allowed to post on their leak site without intervention. The video alone made me curious about the capabilities of their “product” so that is how we arrived here.

Post Analysis Note: The Global ransomware group operates utilizing the leaked Mamona ransomware builder (can be confirmed by the created mutex), which has ties to the Blacklock ransomware group also referred to “El Dorado” (before they were shut down by the DragonForce group). The DragonForce group utilizes the leaked Lockbit3.0 and ContiV3 variants (very original).

IOCs

The sample analyzed in this post is a 32-bit Windows executable.

Group Site: hxxp://vg6xwkmfyirv3l6qtqus7jykcuvgx6imegb73hqny2avxccnmqt5m2id[.]onion

MD5: c5a8d4c07e1dca5e9cfbbaadfc402063  

SHA-1: c95056c8682373d0512aea2ed72c18f79c854308  

SHA-256: 13b82f4ac62faf87a105be355c82bacfcbdd383050860dfa93dfbb7bb2e6c9ba

Initial Inspection

Before opening the sample in IDA, I dropped it into DIE (Detect It Easy) to get an idea if I was going to be spending most of my time unpacking or deobfuscating the sample. This was NOT the case at all, as the affiliates behind this sample shipped a clean release build out the door.

DIE
Figure 1: Detect It Easy  

There was no obvious obfuscation, and it was unpacked. Loading the file in IDA and heading straight to the entry point, we see all the usual C runtime setup. We can skip past all of these to the actual main function.

EntryPoint
Figure 2: Entry Point  

Here is where the actual important execution starts.

MainFunction
Figure 3: Main Function  

There are a handful of interesting flags that can be set on execution, -log can be passed to view the verbose event logging, -detached will forcibly detach the console window if the encryptor is run interactively, -force will bypass the mutex check which prevents multiple instances of the encryptor from running simultaneously to prevent double encryption of files.

Interestingly enough, if -detached is not passed as an argument, the encryptor will attempt to relaunch and set the flag.

DetachConsole
Figure 4: Detach Console and Relaunch  

After executing in detached mode, the handles for standard in, out, and error are set to NUL.

SetStdHandles
Figure 5: Set STDIN/STDOUT/STDERR to NUL  

API Resolution

The encryptor then will continue setup by dynamically resolving APIs with a custom hashing algorithm.

ResolveAPIs_1
Figure 6: Resolve APIs  

The ResolveModule function calculates module hashes by first walking the PEB module list (InLoadOrderModuleList), lowercasing the module name, stripping the path off the file name, hashing the module name, and comparing it to the target hash.

If kernel32.dll, advapi32.dll, and shell32.dll successfully resolve, APIs will be resolved next.

The ResolveAPI function calculates API hashes by walking exported functions for the target module, calculating the hash for each entry, comparing it to the target hash, and returning the function address when a match is found.

This python snippet is a recreation of how the hash is generated from the API name.

#thanks hashdb
def hash(data): 
    hash_value = 0x42
    for b in data:
        hash_value = ((hash_value * 33) + b) & 0xFFFFFFFF
    return hash_value

print("CreateMutexW = " + str(hash(b'CreateMutexW')))

Mutex Creation

Once APIs have been resolved, the encryptor creates a mutex using the resolved CreateMutexW function.

CreateMutex
Figure 7: Create Mutex  

Emptying Recycle Bin

Next, the recycle bin is cleared. This is the first of several steps to prevent recovery of encrypted files.

ClearTrash
Figure 8: Clear Recycle Bin  

Config Decryption

The embedded config in the .config section is now decrypted. This config data contains the ransom note, victim unique ID, leak site URL, and the random value that will be used as the extension for encrypted files. Other runtime configuration options if present would be stored in this data as well.

DecryptedConfig
Figure 9: Decrypted Config  

The following python script reimplements the decryption process, and can be used to extract the config section.

#!/usr/bin/env python3

import sys
from pathlib import Path
from array import array

import pefile

class ConfigDecryptor:
    def __init__(self, pe_path: Path) -> None:
        if not pe_path.exists():
            raise FileNotFoundError(f"File not found: {pe_path}")
        self.pe = pefile.PE(str(pe_path))

    def extract_config_section(self) -> bytes:
        for sec in self.pe.sections:
            name = sec.Name.rstrip(b"\x00").decode(errors="ignore")
            if name == ".config":
                return sec.get_data()
        raise RuntimeError(".config section not found")

    def decrypt_data(self, data: bytes) -> bytes:
        data = data[:len(data) // 4 * 4]
        words = array('I')
        words.frombytes(data)

        xor_current = xor_prev = xor_seed = 0x52D8FC7D

        for idx in range(len(words)):
            words[idx] ^= xor_current
            rot = ((xor_seed << 13) | (xor_prev >> 19)) & 0xFFFFFFFF
            new_key = ((-1702134675 & 0xFFFFFFFF) * rot) & 0xFFFFFFFF
            xor_current = xor_prev = xor_seed = new_key ^ 0x5E4F3D2C

        return words.tobytes()

    def process(self) -> None:
        raw = self.extract_config_section()
        print(f"Found .config section: {len(raw)} bytes")
        decrypted = self.decrypt_data(raw)

        output_file = Path("output.bin")
        with output_file.open('wb') as f:
            f.write(decrypted)
        print(f"Decrypted configuration saved to: {output_file}")


def main():
    if len(sys.argv) < 2:
        print(f"Usage: {sys.argv[0]} <pe_file>")
        sys.exit(1)

    pe_file = Path(sys.argv[1])
    try:
        ConfigDecryptor(pe_file).process()
    except Exception as e:
        print(f"Error: {e}")
        sys.exit(1)

if __name__ == "__main__":
    main()

Crypto Context Setup

To successfully encrypt files, cryptographic context is acquired and a handle to a cryptographic service provider is returned. The CRYPT_VERIFYCONTEXT flag is used during context setup, which is typically only used by apps that leverage ephemeral keys, including apps that handle hashing, or encryption.

CryptoSetup
Figure 10: Crypto Context Setup  

Custom File Icon Setup

The embedded icon that will be applied as the file icon for encrypted files is base64 decoded, and dropped into the temp directory for all accessible users.

FileIconSetup
Figure 11: File Icon Setup  

IconDataBase64
Figure 12: Base64 Icon Data  

FileIconFromBase64_1
Figure 13: File Icon Decode  

FileIconFromBase64_2
Figure 14: File Icon Written  

FileIconPreview
Figure 15: File Icon Preview  

Once the file icon is extracted and successfully dropped to disk, it is set as the associated file icon for encrypted files with the appended custom file extension.

SetFileIcon
Figure 16: Setting File Icon Association  

Next, the encryptor will start the process of printing the ransom note to all networked printers accessible by the host, by creating a PDF version of the ransom note, which is never utilized during the print jobs (funny).

CallPrintNote
Figure 17: Setup and Run Ransom Note Print Job  

The PDF copy of the ransom note is named PrintMe22.pdf and is dropped in the current user’s temp directory (still unused).

CreatePDFNote
Figure 18: Location of PDF Ransom Note  

WritePDFData
Figure 19: Creation of PDF Ransom Note  

Networked printers are now enumerated.

EnumPrinters
Figure 20: Networked Printer Discovery  

For each printer identified, a handle is opened, a temporary file containing the content of the ransom note is dropped in the current user temp directory, and a print job is created, sending the content of the ransom note temp file to each printer.

SendPrintJob
Figure 21: Sending Note Print Job  

Clear Windows Event Log

Immediately after sending the print jobs, the encryptor will attempt to clear the history of several Windows event log sources. These being Application, Security, System, Setup, and ForwardedEvents

ClearEventLogs
Figure 22: Clearing Event Logs  

Delete Shadow Copies

After wiping Windows event logs, vssadmin is executed by the encryptor in a crude attempt to delete all shadow copies, to hinder recovery efforts.

DeleteShadowCopy
Figure 23: Deleting Shadow Copies  

Token Elevation

The encryptor will then attempt to adjust the token privileges of its process.

AdjustTokenPrivs_1
Figure 24: Adjust Process Token  

AdjustTokenPrivs_2
Figure 25: Set Token Privileges  

Impersonate SYSTEM

With elevated token privileges set, the encryptor will attempt to elevate to NT AUTHORITY\SYSTEM permissions by impersonating the token of the winlogon.exe process or the TrustedInstaller service/process if the first attempt to impersonate winlogon fails.

ImpersonateToken
Figure 26: Token Impersonation  

ImpersonateWinlogon
Figure 27: Impersonate Winlogon  

ImpersonateTrustedInstaller
Figure 28: Impersonate TrustedInstaller  

Impair Defenses

Now running as SYSTEM, the encryptor will attempt to stop and delete services related to Microsoft Defender, event logging, network inspection, and system integrity.

StopSecurityServices
Figure 29: Impairing Security Services  

With security services stopped and deleted, any processes associated with those services or category of services are also terminated. The process token is then reverted to the original token.

StopSecurityProcesses
Figure 30: Terminating Security Processes  

Enumerate Domain Devices

If a domain username and password are provided, the encryptor will attempt to access neighboring devices using LDAP, and execute a copy of itself as a service, or using a scheduled task.

First, the list of devices in the domain is collected.

QueryDomainComputer_1
QueryDomainComputer_2
QueryDomainComputer_3
QueryDomainComputer_4
Figure 31-34: Query Domain Computers  

A DNS query is performed on each device identified, and each IP successfully resolved is sent an ICMP echo request to identify hosts that are alive.

ResolveDomainHostToIP
Figure 35: Resolve Domain Host IP  

PingHost
Figure 36: Ping Host  

Remote Execution

The encryptor binary is uploaded to the target host’s Temp folder through the admin$ share, and a service is created to execute it.

ExecuteRemoteService_1
ExecuteRemoteService_2
ExecuteRemoteService_3
ExecuteRemoteService_4
ExecuteRemoteService_5
Figure 37-41: Upload and Execute as Service  

If service creation fails, a scheduled task is created to execute the uploaded encryptor binary.

ExecuteRemoteTask
Figure 42: Execute as Scheduled Task  

Local Encryption Setup

Drives to be targeted for encryption are now identified.

IdentifyDrives
Figure 43: Identify Target Drives  

Two thread pools are created, one for local drive encryption, and one for remote drive encryption.

CreateThreadPools
Figure 44: Thread Pool Creation  

Local Encryption Start

Encryption for local drives is started.

LocalEncryptStart_1
LocalEncryptStart_2
Figure 45-46: Local Encryption Job Start

First, a list of every drive letter on the target host is collected (again), and for each drive, the type is determined to prevent targeting of CD-ROM drives. Remaining applicable drives are checked once more to determine if they are accessible based on file attributes, and drives that fail this check are skipped.

The files and folders on each valid drive are iterated through, queueing target files for encryption, while skipping critical system files and directories, and dropping the ransom note in writable directories.  

Each valid target file is renamed to include the ransomware custom extension, and based on its size it is either fully encrypted or partially encrypted using a Curve25519 derived one-time stream-cipher key; the encrypted data overwrites the original data in-place and a trailer containing the ephemeral public key and integrity metadata is appended to the end of the file.

LocalEncryptJob_1
LocalEncryptJob_2
Figure 47-48: Queue Target Files and Drop Note

LocalEncryptJob_3
Figure 49: Local Encryption Job  

Remote Encryption Start

With local drives finished, encryption for remote hosts is started. Remote encryption is done either by directly accessing the target share, or mounting the share as a local drive.

Alive neighboring devices are identified by sending ICMP echo requests to each IP on network the target device has access to. For devices that are alive, an connection attempt is made, and shares are enumerated. Accessible shares that do not match a list of exclusions are queued for encryption.

Files on shares are encrypted in batches, and once the last batch finishes, share connections are killed, and any shares mounted as local drives are unmounted.

RemoteEncryptJob_1
Figure 50: Get Device Network and Domain Info  

RemoteEncryptJob_2
Figure 51: Check if Target Alive  

RemoteEncryptJob_3
Figure 52: Add Connection  

RemoteEncryptJob_4
Figure 53: Enumerate Shares  

Set Desktop Wallpaper

The target host wallpaper is set, notifying the user of their demise, and the name of the ransom note.

ResolveAPIs_2
Figure 54: Resolve More APIs  

SetWallpaper
Figure 55: Set Wallpaper  

Self Deletion

To cleanup, the encryptor will launch command prompt, have it ping 127.0.0.7, giving the encryptor process just enough time to finish and close the handle to its mutex before the encryptor binary is deleted.

SelfDelete
Figure 56: Ping and Self Delete  

MITRE ATT&CK Mapping

  • Collection (TA0009)
    • T1005: Data from Local System
  • Defense Evasion (TA0005)
    • T1070: Indicator Removal
      • T1070.001: Clear Windows Event Logs
      • T1070.004: File Deletion
    • T1107: File Deletion
    • T1134: Access Token Manipulation
    • T1202: Indirect Command Execution
    • T1562: Impair Defenses
      • T1562.001: Disable or Modify Tools
  • Discovery (TA0007)
    • T1007: System Service Discovery
    • T1016: System Network Configuration Discovery
    • T1057: Process Discovery
    • T1063: Security Software Discovery
    • T1082: System Information Discovery
    • T1083: File and Directory Discovery
    • T1135: Network Share Discovery
    • T1518: Software Discovery
      • T1518.001: Security Software Discovery
  • Execution (TA0002)
    • T1053: Scheduled Task/Job
      • T1053.005: Scheduled Task
    • T1059: Command and Scripting Interpreter
    • T1106: Native API
    • T1129: Shared Modules
  • Impact (TA0040)
    • T1486: Data Encrypted for Impact
    • T1489: Service Stop
    • T1490: Inhibit System Recovery
  • Persistence (TA0003)
    • T1031: Modify Existing Service
    • T1053: Scheduled Task/Job
      • T1053.005: Scheduled Task
    • T1543: Create or Modify System Process
      • T1543.003: Windows Service
  • Privilege Escalation (TA0004)
    • T1053: Scheduled Task/Job
      • T1053.005: Scheduled Task
    • T1134: Access Token Manipulation
    • T1543: Create or Modify System Process
      • T1543.003: Windows Service

These are additional samples related to the Global Ransomware family:

SHA-256: 1f6640102f6472523830d69630def669dc3433bbb1c0e6183458bd792d420f8e
SHA-256: 232f86e26ced211630957baffcd36dd3bcd6a786f3d307127e1ea9a8b31c199f
SHA-256: 28f3de066878cb710fe5d44f7e11f65f25328beff953e00587ffeb5ac4b2faa8
SHA-256: a8c28bd6f0f1fe6a9b880400853fc86e46d87b69565ef15d8ab757979cd2cc73
SHA-256: c5f49c0f566a114b529138f8bd222865c9fa9fa95f96ec1ded50700764a1d4e7
SHA-256: c7b91de4b4b10c22f2e3bca1e2603160588fd8fd829fd46103cf536b6082e310

Acknowledgment

That’s all Folks!

If I made any mistakes please let me know!

Thanks to REMOVED for sharing the Global promo video with me!
Thanks to OALabs for HashDB!