GreenBlood Ransomware Analysis

At a Glance

I was handed a suspicious Windows executable: no metadata, no digital signature, just a 64-bit PE file. Before touching a debugger, I ran the simplest tool in the book: strings{}.

What jumped out immediately was “Go build ID” embedded right in the binary. This payload was written in Go, not the usual C/C++ malware binary. Even more interesting, it leaked its own source path: /root/victims/ransom/daf/enc.go (unstripped debug symbols). That is remarkably rare. Most malware authors strip symbols prior to deployment, but this author did not.

The strings also spilled its entire playbook: AES encryption routines, a .tgbg extension, destructive commands like vssadmin delete shadows{}, a Tor onion address, and two contact email addresses: thegreenblood@proton.me and thegreenblood@onionmail.org. We were looking at a full-fledged ransomware strain — and not a subtle one.

So I fired up Ghidra, installed the GoAnalyzerExtension (essential for Go binaries, as their calling conventions and runtime string layouts differ substantially from standard PE files), and started decompiling function by function.

Execution Flow

Phase 1: Initialization

What happens

1. Mutex check — creates Global\GREENBLOOD_ENCRYPTOR_MUTEX_2A3B4C5D{} to prevent multiple instances from running concurrently.
2. Key generation — invokes crypto/rand.Read(){} to generate 32 cryptographically secure random bytes.
3. Machine fingerprint — collects system attributes: hostname, drive serial numbers, MAC address, Windows Product ID, and motherboard BIOS UUID.
4. Recovery token — derived from the machine fingerprint for victim tracking and payment attribution.
5. Worker pool — initializes 50 worker goroutines backed by a 10,000-entry buffered file queue channel.

1
// Simplified key generation
2
key := make([]byte, 32)
3
crypto/rand.Read(key)           // OS CSPRNG — unbreakable
4

5
// Simplified fingerprint
6
fingerprint := hostname + "||" +
7
               driveSerials + "||" +
8
               macAddress + "||" +
9
               windowsProductId + "||" +
10
               biosUUID
11
machineID := hex(first32Bytes(fingerprint))

Phase 2: Encryption

Drive Discovery

The malware calls GetLogicalDrives(){} to obtain a bitmask of available drive letters, followed by GetDriveTypeW(){} for each letter to filter out remote and non-local drives. Only fixed drives and removable drives are targeted — network shares are excluded entirely. On a standard workstation, this targets C:\ and any attached auxiliary drives like D:\.

Directory Walking

Each drive is walked recursively inside its own goroutine. As directories are discovered, the malware validates them against a hardcoded exclusion list containing 14 critical system paths. The motivation is purely practical: encrypting C:\Windows would crash the operating system before file encryption could complete, and the malware requires the system to stay operational to finalize its routine.

1
systemExclusions := map[string]bool{
2
    "C:\\Windows":                   true,
3
    "C:\\Program Files":             true,
4
    "C:\\Program Files (x86)":       true,
5
    "C:\\ProgramData":               true,
6
    "C:\\Boot":                      true,
7
    "C:\\Recovery":                  true,
8
    "C:\\System Volume Information":  true,
9
    // ... 14 paths total
10
}

File Targeting

The file selection logic applies a multi-tiered filtering mechanism:

1. Hard block: Ignores any file containing "read_me" in the name.
2. Hard block: Skips extensionless files entirely.
3. Blacklist check: If the file extension matches extensionsToSkip, it is skipped.
4. Whitelist check: If the file extension matches extensionsToEncrypt, it is queued for encryption.
5. Fallthrough condition: If the extension is in neither list but the file size exceeds 100 bytes, it gets encrypted anyway.
6. Catch-all: Small, unrecognized files below 100 bytes are ignored.

Encryption Algorithm

The encryption scheme uses AES-256 in CTR mode. A unique 32-byte key is generated per victim via crypto/rand.Read(){}, and every individual file receives its own 16-byte random IV from the CSPRNG.

The 16-byte IV is prepended directly to the output .tgbg file, followed by the plaintext streamed through crypto/cipher.NewCTR{} using a 1MB buffer. Because CTR mode is a stream cipher construct, encryption and decryption operations are symmetrical: XORing the ciphertext with the generated keystream yields the plaintext.

The file renaming sequence is designed to be crash-safe: original → original.bak → original.tmp → original.tgbg → delete original.bak.

If a sudden power loss occurs mid-encryption, the original data remains recoverable from the uncorrupted .bak file.

1
// Simplified encryption routine
2
iv := make([]byte, 16)
3
crypto/rand.Read(iv)                         // Unique 16-byte IV per file
4

5
block := aes.NewCipher(encryptionKey)        // AES-256 block cipher
6
stream := cipher.NewCTR(block, iv)           // CTR stream mode
7
writer := cipher.StreamWriter{dstFile, stream}
8

9
buffer := make([]byte, 1024 * 1024)          // 1 MB buffer chunks
10
for {
11
    n, err := sourceFile.Read(buffer)
12
    if n > 0 {
13
        writer.Write(buffer[:n])
14
    }
15
    if err != nil {
16
        break
17
    }
18
}
19

20
// Atomic rename chain: original -> .bak -> .tgbg -> delete .bak
21
os.Rename(originalPath, originalPath + ".bak")
22
os.Rename(tempPath, originalPath + ".tgbg")
23
os.Remove(originalPath + ".bak")

The malware also imposes an upper file size limit, skipping files that exceed 0xC80000000 bytes (53,687,091,200 bytes ≈ 50 GB):

Concurrency Model

The encryption engine leverages Go’s native channel architecture as a producer-consumer pipeline:

• File Queue Channel (capacity 10,000): Decouples directory traversal goroutines from encryption workers. Walkers push discovered file paths into the queue, and workers consume them.
• Worker Pool Semaphore (capacity 50): A buffered channel token pool limiting active concurrent encryptions to 50 threads.
• Stop Channel: Broadcasts a termination signal to gracefully shut down worker goroutines upon task completion.

1
workerPool := make(chan struct{}, 50) // 50 concurrent encryptors
2
fileQueue := make(chan string, 10000) // 10,000 queued file paths
3
stopChan := make(chan struct{})       // shutdown broadcast

Each file encryption operation is granted up to 4 retry attempts with exponential backoff (100ms × attempt number) in case of transient file-lock contention.

Phase 3: System Sabotage

Phase 3 executes conditionally if the malware detects administrative elevation. The privilege check builds a well-known SID structure (S-1-5-32-544, representing the BUILTIN\Administrators group) with a TokenIsElevated API fallback for UAC split tokens.

Decompiled command execution block:

Phase 4: Finalization

Ransom Note

A ransom note is dropped onto the victim’s desktop as !!!READ_ME_TO_RECOVER_FILES!!!.txt and duplicated across every traversed directory as READ_ME_TO_RECOVER_FILES.txt.

The ransom note embeds the victim’s unique recovery token, machine identifier, attacker contact emails, and extortion terms: payment within 7 days, with key destruction threatened after 21 days. It systematically lists third-party decryption utilities and recovery approaches, warning that each attempt will permanently corrupt the files — a psychological tactic to force ransom compliance.

Self-Deletion Routine

Because Windows locks executing binaries from deletion, the malware writes a temporary batch script (cleanup_greenblood.bat{}) to %TEMP%.

Following a 10-second countdown to allow file descriptors and socket buffers to flush, the process spawns the batch script with a hidden console window. The batch script pauses for 5 seconds and enters a loop attempting to delete the main executable. Once the PE file is deleted, the script deletes itself, leaving minimal forensic traces on disk.

Machine Fingerprint Construction

The machine fingerprint uniquely identifies the compromised endpoint without transmitting plain identifiers. It aggregates five distinct host parameters:

• Hostname: The workstation’s NetBIOS / DNS name.
• Drive Serial Numbers: 32-bit volume serial numbers for all connected local partitions.
• MAC Address: Physical address of the primary active network adapter.
• Windows Product ID: Extracted from the Windows registry hive.
• BIOS UUID: Extracted via wmic csproduct get uuid{}, hardcoded in motherboard firmware.

All five values are concatenated with a double-pipe separator (||), and a 32-byte window is extracted from the start (cycling if the string is under 32 bytes), formatted as uppercase hexadecimal:

Raw String  : HOSTNAME||DRIVE_SERIALS||MAC_ADDR||PRODUCT_ID||BIOS_UUID
Slicing     : first32Bytes(RawString)
Machine ID  : UPPERCASE_HEX(32_BYTES)

Key Data Structures

The core internal architecture in Ghidra reveals clean object modeling:

1
struct EncryptionEngine {
2
    KeyManager  *keyManager;      // Holds master AES key & victim tokens
3
    chan        *workerPool;      // Semaphore channel (50 slots)
4
    WaitGroup   wg;               // Synchronizes directory walkers
5
    WaitGroup   fileWg;           // Synchronizes worker goroutines
6
    struct {
7
        int64 encryptedFiles;     // Successfully encrypted count
8
        int64 encryptedBytes;     // Total bytes encrypted
9
        int64 failedFiles;        // Failed encryption attempts
10
        int64 skippedFiles;       // Excluded / unhandled files
11
    } stats;
12
    RWMutex     statsMutex;       // Thread-safe mutex for metrics
13
    chan        *fileQueue;       // 10,000 buffered file paths
14
    chan        *stopChan;        // Shutdown broadcast channel
15
};
16

17
struct KeyManager {
18
    []byte  encryptionKey;        // 32-byte master key (AES-256)
19
    string  recoveryToken;        // Victim-facing recovery identifier
20
    string  machineID;            // Derived hardware fingerprint
21
};

How Decryption Works

The attacker exfiltrates the generated AES-256 key to the C2 server during Phase 2 (via an asynchronous goroutine at main.main.func1).

Because CTR mode acts as a symmetric stream cipher, the decryption transformation is mathematically identical to encryption:

.tgbg File Structure:  [ 16-byte IV ] [ Ciphertext Data ... ]
                               │
AES-256(Key) ──▶ CTR(IV) ──▶ XOR ──────▶ Recovered Plaintext

Indicators of Compromise (IoCs)

Filesystem Artifacts

• *.tgbg — Encrypted file extensions
• !!!READ_ME_TO_RECOVER_FILES!!!.txt — Desktop ransom note
• READ_ME_TO_RECOVER_FILES.txt — Directory ransom notes
• cleanup_greenblood.bat — Self-deletion batch script

Mutex Objects

• Global\GREENBLOOD_ENCRYPTOR_MUTEX_2A3B4C5D{}

Network Infrastructure

• scbrksw5fgjtujc2ah42roo6bij2unr2tggfcynpbql5a7yp3s22taid.onion:8000

Behavioral Signatures

• Bulk sequential file renaming to .tgbg
• vssadmin.exe delete shadows /all /quiet{}
• bcdedit.exe /set {default} recoveryenabled no{}
• netsh.exe advfirewall set allprofiles state off{}

Key Takeaways & Assessment

Strengths

• Go Implementation: Non-standard runtime and memory layout complicates naive reverse engineering without specialized tooling like GoAnalyzerExtension.
• Cryptographic Rigor: Proper AES-256-CTR implementation with fresh per-file random IVs generated via the OS CSPRNG.
• Atomic File Operations: Crash-safe .bak intermediary staging prevents corrupt half-written files if interrupted.
• Robust Concurrency: Producer-consumer architecture with buffered channels avoids resource starvation and locks.

Deficiencies

• Unstripped Symbols: Source file paths (/root/victims/ransom/daf/enc.go) and internal function signatures left completely intact.
• Defensive Ordering Flaw: Antivirus and firewall tampering occurs after encryption completes.
• No Long-term Persistence: Self-deletes immediately, giving no secondary re-entry mechanism.
• Crude Fingerprint Reduction: The fingerprint generation truncates raw bytes rather than hashing via SHA-256.
• Static Mutex Identifier: Distinctive mutex string creates a trivial indicator for EDR detection.

Key Function Addresses (Ghidra)