When the Bazaar Burned From Within: The Silent Breach of Nobitex

Incident Analysis

Attribution and Statements

On June 18, 2025, the group Gonjeshke Darande (Predatory Sparrow) issued a public statement via X, claiming responsibility for the Nobitex breach. In their post, the group threatened to leak Nobitex’s source code and internal network data within 24 hours, warning that any remaining assets would be at risk.

Official statement from Nobitex

Following the initial breach and public claim of responsibility by Gonjeshke Darande on June 18, 2025, Nobitex issued a series of official updates via their X platform to communicate their response and recovery roadmap to users.

On June 29, 2025, Nobitex followed up with another update, focusing on the step-by-step restoration of wallet access. The process began with verified users and spot wallets, with balances reappearing in phases. Nobitex underscored the importance of the ongoing identity verification process as a prerequisite for access and warned customers against using old deposit addresses, as the migration to a new wallet system had rendered them invalid. Any deposits to legacy addresses risked permanent loss of funds — a clear sign of how deeply the breach had forced Nobitex to restructure its wallet infrastructure.

Leak Analysis

When the Nobitex source code surfaced, it offered a rare chance to dissect not only an exchange’s architecture, but also the mindset of its builders.

Multi-Wallet Architecture & Internal Reachability

Nobitex operated a multi-wallet infrastructure, with hot and cold wallets segregated across blockchains. The cold wallet was managed through an internal network server, which means it may have been potentially reachable by the threat actors once they gained access to Nobitex’s internal environment.

Domestic Fiat Integration as a Strategic Lever

The platform’s integration with Iran’s Shetab banking system and Toman gateways allowed frictionless conversion between fiat and crypto. This positioned Nobitex as a bridge between sanctioned domestic finance and global crypto rails—an asset that adversaries could exploit or disrupt.

Trading Engine & Third-Party Connectivity

The leaked code revealed a sophisticated trading core: configurable order logic, fraud detection, SegWit support, dynamic fees, and feature flags. Nobitex’s reach extended across dozens of blockchains (BTC, ETH, TON, SOL, XRP, DOGE, and more), with ties into BlockCypher, CovalentHQ, Moralis, and Etherscan. This interconnectedness amplified liquidity—yet also expanded the attack surface exponentially.

Snippet source code

Secrets, Encryption & Configuration Hygiene

To its credit, Nobitex encrypted many secrets with Fernet, drawing keys from runtime environments rather than hardcoding. Yet cracks emerged: Telegram bot tokens and KYC service credentials lingered in plaintext in development configs. Cold storage may have been conceptually air-gapped, but OPSEC oversights handed adversaries potential pivots they should never have had.

Privacy Engineering & Compliance Evasion

Most revealing was the presence of modules engineered for obfuscation: stealth address generation, mixers, and routing logic explicitly designed to frustrate blockchain analytics. Moreover, VIP accounts were exempted from compliance workflows, raising the possibility of sanctioned actors transacting with institutional impunity.

Scalability With Fragility

The modularity of the codebase—wallet daemons, fiat adapters, compliance gates, mixers—showed a system built for scale. But that same modularity made it highly forkable: this playbook could be replicated elsewhere, fueling the rise of shadow exchanges across the region.

Akatsuki Assessment

This incident is more than a theft; it is a demonstration of how credential compromise and stealth tooling remain the favored weapons of advanced actors. Even with cold wallets intact, a single point of OPSEC neglect can ripple outward into catastrophic financial ruin.

Behind the Breach

The Akatsuki research team uncovered critical details of the Nobitex breach, confirming that two employees with elevated server access had been compromised through separate infostealer campaigns.

Families Observed

What comes next?

Before reconstructing the infections chronologically, we establish working definitions for malware stealers and summarize the two families above. We then dissect, in order, each employee’s activity trail to show how their endpoints were infiltrated. Particular attention is given to cracked or potentially malicious software recovered from their machines — the most probable delivery mechanism — which ultimately enabled credential capture tied to Nobitex’s critical infrastructure.

Understanding Stealers: RedLine and StealC

Information stealers (commonly called infostealers) are a class of malware designed to operate covertly on a victim’s device, harvesting sensitive data without the user’s knowledge. Their primary purpose is to extract authentication material, personal information, and system details that can later be monetized or used to escalate intrusions.

RedLine

RedLine Stealer, also known as RECORDSTEALER, is an information stealer sold on underground forums — available either as a one-off purchase or via subscription.

Rather than dumping logs chaotically, RedLine categorizes stolen information, turning a single infection into a structured intelligence package — credentials, system reconnaissance, and visual proof — ready for immediate exploitation or resale.

StealC

Thanks to the detailed work of TRAC Labs, we can outline the key developments surrounding StealC. First observed in early 2023, StealC is a C++-based information stealer that quickly rose in popularity as a malware-as-a-service (MaaS) platform within underground communities.

Malware Infection Chain Leading To Nobitex Heist

Infected employee #1 — RedLine

On 17/09/2023 at 07:12 local time, a Nobitex employee was infected with RedLine Stealer, a common infostealer malware. The infection occurred on a Windows 10 Enterprise [x64] system with Windows Defender as the active antivirus, suggesting the malware either bypassed or evaded detection.

Installed Software & High-Risk Downloads

To determine root cause, the Akatsuki team parsed stealer artifacts: 172 installed applications were inventoried and cross-referenced with browser download history. A subset aligns with known RedLine delivery via cracked repos.

Cracked Software Sources (Observed)

Infected employee #2 — StealC

On 20/09/2024 at 08:04 local time, a Nobitex developer was infected with StealC. The infection occurred on a Windows 10 Pro [x64] workstation.

C:\Windows\BitLockerDiscoveryVolumeContents\BitLockerToGo.exe

Hidden Threats in the Blockchain Ecosystem

What is a Vanity Address?

A vanity address is a blockchain address that begins with a custom, human-readable pattern. These are generated with high compute tools (e.g., Vanitygen++, ETHVanity).

What is a Null Address?

• A fixed, hardcoded address (often zero-filled or patterned).
• Purpose: Token burns / sending assets to an unreachable sink.
• Custom strings: Not possible — cannot contain readable words.
• Private key: None — funds sent here are permanently lost.

The Threat: Vanity Exploitation Attacks (VEA)

A Vanity Exploitation Attack (VEA) is when an attacker creates a vanity address designed to manipulate, impersonate, or psychologically affect individuals or organizations.

VEA Attack Scenario

Impersonation Flow

1. 1
   Attacker creates a vanity address like 0xNOBITEX…
2. 2
   Posts it on Telegram / Reddit / Discord as “official support”.
3. 3
   Victim, seeing the familiar prefix, sends funds believing it’s safe.
4. 4
   Attacker withdraws funds using their private key.

VEA in Today’s Date

Used by hacktivist groups for digital propaganda.

High-Stakes Social

Deployed in high-value social engineering attacks.

Automation Exploits

Abuses AI/bot traders that misread vanity prefixes as legit.

Real-World Examples & Threats

Case studies

2022

Discord Phishing Campaigns

Vanity addresses mimicking NFT project wallets tricked users into sending ETH/NFTs.

2023

Telegram Trading Bots Exploit

Bots scanning vanity prefixes auto-bought honeypots; attackers drained value at scale.

IR

Predatory Sparrow

“Burn” vanity address as message and test; reuse of the private key could reclaim funds.

Why VEA Matters in the Real World

Financial & Governance

• Corporate Exploits: Vanity look-alikes for treasury/payout interception.
• Regulatory Exploits: Fake compliance wallets used for evasion/misreporting.
• Investor Fraud: “Burn” addresses secretly controlled by insiders.

Deception & Automation

• Impersonation Risks: Exchange-prefix mimics.
• Rug Pull Plans: Vanity exits masked as community events.
• Bot/AI Confusion: Human-readable patterns mislead automated flows.

The Predatory Sparrow Case: Burn or Message?

• Technically a vanity address, not a null address.
• Creation implies possession of a private key.
• Funds left untouched to send a statement—but could be reclaimed if the key leaks.

Conclusion: Not a trustless burn; it’s a psychological tactic with a future-risk tail.

Proposed Mitigation Techniques

Flag inbound/outbound vanity patterns at exchanges.

Require provable key deletion for declared burn addresses.

Train ML models to detect vanity impersonation.

Maintain a public ledger of trusted, audited burn addresses.

Adopt provable key-destruction protocols for burns.

Add AI/bot safety checks to validate vanity patterns before execution.

Conclusion

Vanity addresses add style and symbolism—but also enable social engineering, impersonation, and theft. Distinguishing vanity from null, and recognizing VEA patterns, is essential to secure decentralized systems. The community must innovate in trust frameworks, not just technology.

Threat Hunting

Threat hunting is a proactive discipline, not a log-reading ritual. It pursues the faint artifacts adversaries try to hide—odd headers, off-pattern status codes, misfit TLS banners, or those telltale ports that shouldn’t be open. Families like RedLine and StealC blend into routine user activity while siphoning credentials, wallets, and sessions. The hunter’s job is to surface what was designed to be invisible: the malformed response, the unexpected 1911/1912 HTTP service beside RDP 3389, or the cookie trail that betrays an ongoing campaign.

Validin — RedLine Tracking

Live Intel

Validin actively tracks RedLine Stealer activity across the internet. The platform aggregates intelligence on RedLine infrastructure — including domains, IPv4 addresses, malware strings, and indicators of compromise — and exposes pivots that accelerate analyst workflows.

Domains IPv4 Malware Strings IOCs Banners Open Ports

Let's review one of the active query!

Common Name (CN) Reuse

Attribution Signal

This CN was reused across multiple hosts — a strong operational mistake by the adversaries, enabling direct correlation between servers. The timeline view shows activity spanning several weeks (June → August 2025), indicating an ongoing infrastructure set rather than transient hosts.

CN:"RedLine" June–Aug 2025 Multi-host reuse

Pivot: 45.137.22[.]254 → RootLayerNet

AS51447

Pivoting from 45.137.22[.]254 revealed several related servers hosted within RootLayerNet (AS51447).

Origin IP: 45.137.22[.]254 Hoster: RootLayerNet ASN: 51447

Attribution Conclusion

Coordinated Campaign

The clustering of servers with identical banners, recurring ports, and shared ASN ownership strongly indicates a coordinated RedLine campaign rather than isolated systems. Of particular importance is port 55615, independently noted by ThreatFox as an active hosting port for RedLine panels — further validating our attribution.

Signal Cluster

banner: Microsoft-HTTPAPI port: 1911 port: 1912 port: 80 port: 443 RDP: 3389

External Validation

ThreatFox

Observed panel exposure on 55615/tcp matches ThreatFox-reported hosting behavior for RedLine, strengthening infrastructure attribution.

Shared ASN Repeated banners Port 55615 (panel) Coordinated campaign

StealC C2

StealC campaigns rely on agile, low-noise command-and-control (C2) infrastructure: short-lived hosts, rotating subdomains, and minimal UI panels. Typical signals include ephemeral TLS certificates, sparse HTTP endpoints, and high-port services paired with standard 80/443.

URLScan.io Heuristic — StealC Panel Fingerprint

High Confidence

Using URLScan.io, we crafted a custom regex to detect StealC’s telltale behavior: C2 panels frequently rely on randomized 16-character .php filenames (e.g., jh3k2l9s8q1w7e4d.php). When URLScan observes traffic matching this pattern, the activity is flagged as StealC. Confidence is very high, as IOCs from URLScan are directly cross-validated with external threat intelligence.

Detection Regex

(?:^|/)[A-Za-z0-9]{16}\.php(?:$|[\?#])

Matches a path segment that is exactly 16 alphanumeric chars ending in .php (end of URL, query, or fragment).

Example Matches

• https://IP/jh3k2l9s8q1w7e4d.php
• http://DOMAIN/AbC123xYz90QweRt.php

Analyst Notes

• Use as a pivot to enumerate related hosts/subnets.
• Cross-check with CN reuse, short-lived certs, and title 403 behaviors.

randomized .php 16 chars URLScan heuristic cross-validated IOCs

Cross-Family Signals — StealC & RedLine

Hunting Parity

We applied our hunting rules across both families, noting similar hosting patterns and service exposure. StealC also defaults to ports 80/443. An interesting overlap surfaced in labeling: the name “Bulletproof” — historically seen on RedLine infra — is now present on StealC-tagged hosts.

Common Services

• StealC: 80, 443 (default exposure)
• RedLine: 80, 443 (+ panels commonly at 1911/1912)

Label Overlap

The label “Bulletproof” reappears on StealC infrastructure and was used as a RedLine label in prior campaigns — a useful pivot for cross-family correlation.

label: Bulletproof cross-tag signal

port:80 port:443 label overlap

Hunt.io — Additional StealC IOCs

IOC Expansion

Using Hunt.io, we identified additional StealC IOCs by pivoting on shared traits (service exposure, titles, and cert reuse), expanding the infrastructure graph beyond initial seeds.

StealC Hunt.io pivots New IOCs

Hunt.io — SQL Editor Pivot

cert-hash → C2

We tested Hunt.io’s SQL Editor to customize our hunting queries. Pivoting on a certificate hash revealed two unique IPs with uncommon ports — both confirmed as active StealC servers.

cert-hash pivot 2 unique IPs uncommon ports StealC C2

Conclusions

The Nobitex breach stemmed from two high-privilege employees infected by infostealers — RedLine and StealC. Stolen credentials and session artifacts enabled direct access to internal systems, leading to an impact exceeding $81M. No exotic exploits were required: the malware delivered the keys. The root cause combined risky behavior (cracked software) with weak operational security. The lesson is clear: credential protection and endpoint hardening are as critical as perimeter defenses.