Blog categories
Weekly newsletter
No spam. Just the latest releases and tips, interesting articles, and exclusive interviews in your inbox every week.
Latest from the blog
Emerging Ransomware Threat: Reverse Engineering the Green Blood Group Golang Payload
Posted on: 30 Jan 2026 | Author: Foresiet
Introduction
During routine Dark Web Monitoring activities, Our Threat Intelligence Team identified a newly active ransomware operation calling itself The Green Blood Group. The group operates a dedicated Tor-based leak site and follows a double-extortion model, threatening public disclosure of victim data when negotiations fail.
The screenshot shown above captures the group’s Tor portal in its current state. At the time of observation, the site displayed a holding message indicating that victim names and stolen data were temporarily withheld. According to the message, the operators deliberately delay public disclosure for a fixed period, allowing victims time to negotiate before their identities are exposed. This tactic aligns with modern ransomware pressure strategies, where timing and staged disclosure are used to increase leverage during negotiations.
Initial analysis of the ransomware payload associated with this group reveals a professionally engineered, Golang-based encryption framework. The malware employs concurrent file processing, modern cryptographic primitives, and structured key management to rapidly encrypt victim environments while maintaining operational stability. The following technical analysis documents how the ransomware operates internally, from filesystem traversal and encryption logic to ransom note deployment and victim identification mechanisms.
Threat Actor Profile: The Green Blood Group
Based on infrastructure observations and malware analysis, The Green Blood Group appears to be an emerging ransomware operation rather than a rebrand of a known legacy group. The group maintains a standalone Tor leak site and uses encrypted communication channels to interact with victims.
Observed Target Countries
- Senegal
- India
- Colombia
The targeting pattern suggests a focus on regions where incident response maturity and ransomware disclosure requirements vary, potentially increasing the likelihood of successful extortion.
Observed Victim Communication Channels
- TOX Secure Messaging ID
F97A512AA18917444315510B107AB8B46166CAC4E79DB76B849FFE48A67A4B621AB7CC9A1EFB - Encrypted Email (Tor-based)
thegreenblood@onionmail.org
These communication methods are consistent with ransomware groups attempting to avoid attribution and takedown while maintaining direct negotiation channels with victims.
Leak Site Behavior and Extortion Model
The screenshot of the Tor site shows a deliberate delay mechanism implemented by the operators. Instead of immediately listing victims, the site displays a countdown-style message stating that victim names and data will only be published after a defined waiting period if negotiations do not progress.
This behavior serves multiple purposes:
- It signals credibility without immediately burning leverage.
- It pressures victims by creating a visible deadline.
- It avoids premature exposure that could disrupt negotiations.
This staged disclosure model has become increasingly common among ransomware groups seeking to balance operational security with maximum extortion impact.
Figure 1 – Go build metadata and runtime version
the .data section containing go_buildinfo_ref, go_buildinfo, and runtime_buildVersion_str. The visible string go1.24.2 confirms the binary was compiled using a recent Go toolchain. This is not incidental metadata; Go embeds build information directly into the binary at compile time, which allows the runtime to identify ABI compatibility and module layout. The presence of go_buildinfo_ref being referenced from other runtime structures confirms this is a fully statically linked Go executable rather than a wrapper or loader. This aligns with later observations where Go runtime symbols (runtime_morestack, sync.WaitGroup, channels) are heavily used throughout the binary.
At this stage of analysis, this screenshot establishes two important facts without ambiguity: the malware is written in Golang, and it is not obfuscated at the compiler level. This means the developer relied on Go’s runtime complexity and static linking for opacity rather than traditional packers.
Figure 2 – Strings view highlighting walk And Queue
the Strings subview with walkAndQueue, main.(*EncryptionEngine).walkAndQueue, and main.(*EncryptionEngine).EncryptPath.func1.(EncryptionEngine).walkAndQueue highlighted. These are not runtime-generated names; they are preserved Go symbol names. This immediately reveals a developer-defined abstraction called EncryptionEngine and a method responsible for walking filesystem paths and queuing them.
The naming is explicit and semantically meaningful. “walkAndQueue” strongly suggests a two-phase operation: directory traversal followed by queuing of targets. This is consistent with modern ransomware that separates enumeration from encryption to enable concurrency. The presence of EncryptPath.func1 indicates that encryption is executed inside an anonymous function, almost certainly launched as a goroutine, which further supports a concurrent design.
At this point, there is already enough evidence to say the malware is designed to systematically traverse the filesystem rather than opportunistically encrypt a few files.
Figure 3 – Hex view showing Go symbol references
Where multiple Go symbols are visible inline, including repeated references to EncryptionEngine, EncryptPath, walkAndQueue, and shouldEncryptFile. Go binaries store symbol names and metadata in plaintext within the binary, which is why these strings appear directly in the hex view.
This screenshot reinforces that the logic observed in the Strings view is not an artifact of IDA reconstruction but originates from the compiled binary itself. The repetition of these names across different offsets indicates multiple references, consistent with these functions being core parts of the execution flow rather than dead code.
This view also confirms the absence of string obfuscation for control logic. The developer did not attempt to hide function names, which is typical for Go ransomware where the threat model assumes static analysis resistance comes from complexity rather than concealment.
Figure 4 – Hex view showing Go build ID
Deep inside the unpacked ransomware sample lies a quiet but telling artifact: a build fingerprint cleverly embedded in the binary’s read-only data.
It starts innocently with .Pm-build-ID: — almost like a debug or logging tag left by the developer — then spills a long, unique identifier chain:
GhmT…LuE1jb xteP/Qy_EeJTt YIfFG2C2sxar/M ZnCmJC2Sxar
These are most likely campaign IDs, compilation timestamps disguised as gibberish, or per-victim-group salts used to derive encryption keys or watermark samples.
The string abruptly ends in repeating CC bytes — classic alignment/padding behavior in Go binaries.
It confirms that the binary is not packed, not manually stripped, and not post-processed with a custom linker. This has implications for trust in the symbol names seen elsewhere: they are original and not reconstructed guesses.
Figure 5 – Disassembly of EncryptPath.func1 trampoline
At address 0x4DB579 the ransomware prepares to call its recursive directory walker.
It carefully moves four string slice components (ptr, len, cap, another ptr/len pair) from stack args into registers:
- rax ← string pointer
- rbx ← string length
- rcx/rdi/rsi ← more slice fields + context
Then it calls runtime.morestack_noctxt (Go stack growth helper — typical in deep recursion like filepath.Walk).
Right after, registers are restored and it jumps straight into the real walker function: main.(*EncryptionEngine).EncryptPath.func1 → walkAndQueue
In plain words: this tiny stub is the gateway that lets the ransomware safely traverse “C:\Users\…” or any mounted drive, queuing every file it finds for ChaCha8 encryption — the exact spot where mass file discovery begins. Classic ransomware filesystem crawl entry point.
Figure 6 – Decompiled logic of should Encrypt File
Buried in the ransomware’s core, this decompiled Go snippet reveals the “should I encrypt?” gatekeeper: a signed file check via DMORD (likely a custom hash or magic bytes) that scans for 32+ offsets across the file header.
If unsigned and non-skippable (no matches in the exclusion list like .exe or critical paths), it queues the victim for ChaCha20; else, it logs the skip in a WaitGroup tally.
Pure malice math: weigh file traits against a blacklist, then greenlight destruction — the quiet algorithm deciding which docs die first in the attack.
The malware does not blindly encrypt everything; it evaluates files against criteria before queueing them, which is consistent with avoiding system instability and maximizing successful extortion.
Figure 7 – ChaCha cryptographic primitives in Strings view
Deep in the ransomware’s read-only data section sits clear proof of its encryption engine: a full internal implementation of ChaCha8 (a faster, 8-round variant of the ChaCha20 stream cipher).
Strings reveal method names straight from Go’s crypto library internals — .State.Init, .Refill64, .Reseed, .Next, .block — plus source paths (/usr/local/go/src/internal/chacha8amd64.s) showing it was compiled with AMD64-specific assembly optimizations.
This isn’t borrowed crypto code. It’s a deliberate, tuned ChaCha8 chosen for speed on modern CPUs — exactly what you see in 2025–2026 ransomware families that encrypt hundreds of GB/hour.
This suggests the developer is using standard, vetted cryptographic primitives instead of custom or weak algorithms. Combined with the previously observed encryption workflow, this confirms that encrypted files are not trivially recoverable without the correct key material.
Figure 8 – Golang-Based Encryption Engine and Key Manager Design
Spanning 120 bytes, it holds everything needed to orchestrate destruction — a pointer to the KeyManager (where the ChaCha8 key and recovery token live), a pool of worker channels for parallel encryption, two sync.WaitGroups to track file processing and overall progress, a mutex-protected stats block, and the all-important fileQueue channel that feeds victim paths to the encryption workers.
Right beside it sits the KeyManager a lean 56-byte container carrying the 32-byte encryption key as a byte slice, the recovery token string victims will never see unless they pay, and a machineID to uniquely tag each infected host.
This clean, Go-idiomatic design shows deliberate craftsmanship: concurrent workers racing through directories, keys generated once and reused, progress silently tallied — the quiet machinery of a modern file-locker, built to scale across dozens or hundreds of cores while keeping decryption firmly out of reach.
Figure 9 – Hardcoded Ransom Message Strings Identified in Static Analysis
During execution, the ransomware operates in a clearly structured and automated manner, initializing its encryption engine before identifying the infected system and generating victim-specific identifiers that are later used for recovery negotiations. Once launched, it scans available local drives and user directories, prioritizing accessible data locations, and begins encrypting files in place while providing minimal console feedback to indicate progress. Encrypted files are appended with a custom extension, rendering them inaccessible without the corresponding decryption key.
After the encryption phase completes, the malware leaves behind a ransom note that informs the victim their data has been locked using strong cryptography, emphasizes that recovery is impossible without the attackers’ cooperation, and instructs the victim to make contact using the provided identifiers to obtain payment instructions and a decryption tool. This end-to-end flow highlights a mature ransomware design that combines automated system discovery, fast encryption, and a direct extortion mechanism intended to pressure victims into timely payment.
The presence of a dedicated function for ransom note placement, rather than inline code, shows that the developer intentionally separated encryption from extortion messaging.
This is the final stage of the ransomware lifecycle. Once encryption is complete or sufficiently progressed, the ransom note is dropped to inform the victim and provide recovery instructions.
Mitigation and Defensive Guidance
Organizations should treat activity associated with The Green Blood Group as high risk due to the ransomware’s speed, encryption strength, and structured extortion workflow.
Recommended defensive actions include:
- Monitor for execution of unknown Go-based binaries in user and server environments.
- Alert on the creation of files named READ_ME_TO_RECOVER_FILES.txt.
- Restrict outbound access to Tor and OnionMail services where possible.
- Implement behavior-based detection for rapid, concurrent file modification.
- Ensure offline and immutable backups are maintained and regularly tested.
Early detection during the filesystem traversal or queueing phase is critical, as the ransomware is designed to encrypt large numbers of files in parallel once execution begins.
Conclusion
The Green Blood Group represents a new but technically competent ransomware threat operating with a modern double-extortion model. The group combines a professionally engineered Golang ransomware payload with structured victim communication and staged data-leak tactics. While the operation is still emerging, its tooling and infrastructure indicate deliberate design choices rather than experimental development.
The technical analysis presented in this blog demonstrates how the ransomware achieves speed, reliability, and encryption strength through concurrency and modern cryptography. Continued monitoring of the group’s leak site, infrastructure, and malware variants will be essential to track its evolution and assess its long-term impact across targeted regions.
About us!
Foresiet is the pioneering force in digital security solutions, offering the first integrated Digital Risk Protection SaaS platform. With 24x7x365 dark web monitoring and proactive threat intelligence, Foresiet safeguards against data breaches and intellectual property theft. Our robust suite includes brand protection, takedown services, and supply chain assessment, enhancing your organization’s defense mechanisms. Attack surface management is a key component of our approach, ensuring comprehensive protection across all vulnerable points. Compliance is assured through adherence to ISO27001, NIST, GDPR, PCI, SOX, HIPAA, SAMA, CITC, and Third Party regulations. Additionally, our advanced antiphishing shield provides unparalleled protection against malicious emails. Trust Foresiet to empower your organization to navigate the digital landscape securely and confidently.
Latest
From the blog
The latest industry news, interviews, technologies, and resources.