Back to Intelligence

Shelbit Sanctions: Detecting and Blocking Exposure to Iran's $6B Fake Crypto Exchange

SA
Security Arsenal Team
August 10, 2026
11 min read

The U.S. Department of the Treasury's Office of Foreign Assets Control (OFAC) has sanctioned Shelbit, an Iranian operation that presented itself as a legitimate cryptocurrency exchange while functioning as a laundering pipeline that processed approximately $6 billion in illicit transactions. Blockchain intelligence firm TRM Labs' analysis was instrumental in unmasking the operation: Shelbit was never a real exchange. It was a front — infrastructure purpose-built to move value for sanctioned Iranian actors and associated criminal networks while wearing the costume of a legitimate trading platform.

This matters to defenders far beyond the cryptocurrency industry. If your organization accepts crypto payments, operates a fintech product, processes transactions through payment processors with crypto rails, or simply has employees moving corporate funds through digital asset platforms, you now have a sanctions exposure problem to quantify. OFAC liability is strict liability — you don't need to have known you were transacting with a sanctioned entity to be penalized. The $6 billion figure also tells us something important about scale: this wasn't a niche darknet service. It touched mainstream liquidity, which means counterparties across the legitimate financial ecosystem are now holding tainted transaction histories.

Your immediate priorities: (1) determine whether your organization or its customers have transacted with Shelbit-linked wallet addresses, (2) confirm your sanctions screening tooling ingested the updated OFAC SDN list, and (3) hunt for internal network or endpoint activity suggesting employees or systems interacted with Shelbit infrastructure.

Technical Analysis

What Shelbit Actually Was

Per TRM Labs' reporting, Shelbit presented the surface features of a legitimate exchange — order books, trading pairs, user accounts, KYC theater — but functioned operationally as a money transmission and layering service for Iranian actors cut off from the traditional financial system. Key characteristics of the operation:

  • Fake liquidity and wash activity: The exchange simulated trading volume to appear legitimate to blockchain analytics heuristics and casual due diligence.
  • Nested services: Like many illicit exchanges, Shelbit effectively operated as a nested service on top of larger compliant exchanges, meaning tainted funds flowed through major platforms' infrastructure — a direct exposure vector for any exchange or payment processor.
  • Sanctions evasion rails: Funds were moved through chains of intermediary wallets, chain-hopping and peel chains to break attribution before re-entering compliant venues.

This follows the established pattern of previously sanctioned crypto infrastructure — Garantex, Chatex, Suex, Bitzlato — but at a scale ($6B) that puts it among the largest laundering operations OFAC has ever designated in the digital asset space.

Why This Is a Defender Problem, Not Just a Compliance Problem

Three concrete risk vectors for enterprise security teams:

  1. Strict-liability sanctions exposure: Any U.S.-person transaction with a Shelbit-controlled address is a potential OFAC violation. Treasury has aggressively pursued crypto-related enforcement, and "we didn't know" is not a defense.
  2. Tainted asset flows: Funds that transited Shelbit may land in your treasury, customer accounts, or payment flows. Downstream holders of tainted assets face frozen funds, enhanced scrutiny, and potential blocking obligations.
  3. Internal misuse: Employees or contractors using illicit exchanges for personal trading — or worse, moving corporate or customer funds through them to obfuscate theft — create both legal and forensic exposure. Insider embezzlement schemes routinely route through obscure offshore exchanges precisely because compliance teams don't screen them.

Exploitation Status

This is not a software vulnerability — there is no CVE, no patch, no exploit. The "exploitation" is of the global financial system's trust assumptions, and it is confirmed active at scale: $6 billion in processed volume before designation. The SDN listing is live, meaning wallet addresses associated with Shelbit are now published screening targets. Expect follow-on designations of associated wallets and facilitators over the coming weeks as TRM, Chainalysis, and Elliptic attribution data propagates into OFAC actions.

Detection & Response

The detection strategy here is threefold: (a) hunt for network-level interaction with Shelbit infrastructure from corporate assets, (b) screen transaction and wallet data against newly designated addresses, and (c) verify your controls actually ingested the sanctions update.

SIGMA Rules

The following rules target observable behaviors associated with illicit exchange interaction and crypto-laundering tradecraft on corporate endpoints. Tune the domain set as additional Shelbit infrastructure is published by OFAC and TRM.

YAML
---
title: Network Connection to Sanctioned Crypto Exchange Infrastructure
id: 8c2f4a71-3b5d-4e6a-9f1c-7d8e2a3b4c5d
status: experimental
description: Detects DNS or web proxy requests from corporate assets to domains associated with Shelbit or previously sanctioned crypto exchanges (Garantex, Chatex, Suex, Bitzlato). Presence on corporate networks may indicate employee misuse, insider fund movement, or compromised assets interacting with laundering infrastructure.
references:
  - https://www.infosecurity-magazine.com/news/us-sanctions-iranian-6bn-crypto/
  - https://attack.mitre.org/techniques/T1071/001/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1071.001
logsource:
  category: dns
  product: windows
detection:
  selection:
    query|contains:
      - 'shelbit'
      - 'garantex'
      - 'chatex'
      - 'suex.io'
      - 'bitzlato'
falsepositives:
  - Security researchers and compliance teams performing due diligence
level: high
---
title: Cryptocurrency Wallet Address Copied to Clipboard
id: 2e7b9c14-6a3f-4d8e-b5c2-9f1a3d4e5b6c
status: experimental
description: Detects clipboard content matching Bitcoin, Ethereum, or Tron address formats on endpoints where PowerShell clipboard access is observed. Combined with network context, this can identify manual movement of wallet addresses during unauthorized crypto transfers — a common artifact in insider embezzlement and sanctions-evasion activity.
references:
  - https://attack.mitre.org/techniques/T1115/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.collection
  - attack.t1115
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains:
      - 'Get-Clipboard'
falsepositives:
  - Developers and administrators using clipboard inspection legitimately
  - Password manager diagnostics
level: low
---
title: Execution of Crypto Wallet or Trading Tooling on Corporate Endpoint
id: 4f1a8d62-7c3b-4e5f-a9d1-2b6c8e3f5a7d
status: experimental
description: Detects execution of standalone cryptocurrency wallet or exchange arbitrage/trading software on corporate workstations. In the context of the Shelbit designation, unauthorized wallet software on managed assets is a policy violation and a potential indicator of employees moving funds through non-compliant venues.
references:
  - https://attack.mitre.org/techniques/T1204/002/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1204.002
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith:
      - '\electrum.exe'
      - '\exodus.exe'
      - '\atomicwallet.exe'
      - '\wasabiwallet.exe'
      - '\tornado.exe'
falsepositives:
  - Fintech development teams with authorized tooling (whitelist by host OU)
level: medium

KQL — Microsoft Sentinel / Defender

This hunt query looks for network and DNS activity toward sanctioned exchange infrastructure across both Defender endpoint telemetry and ingested firewall/proxy logs. Run it over a 90-day lookback — you want historical exposure, not just current connections.

KQL — Microsoft Sentinel / Defender
// Hunt: Corporate asset interaction with sanctioned crypto exchange infrastructure
// Covers Shelbit designation and prior sanctioned venues for exposure baseline
let SanctionedDomains = dynamic([
    "shelbit.com", "shelbit.io", "shelbit.net",
    "garantex.io", "garantex.org",
    "chatex.com", "suex.io", "bitzlato.com"
]);
let DNSHits = (
    DeviceNetworkEvents
    | where TimeGenerated > ago(90d)
    | where RemoteUrl has_any (SanctionedDomains)
    | project TimeGenerated, DeviceName, InitiatingProcessName, RemoteUrl, RemoteIP, InitiatingProcessAccountName
);
let ProxyHits = (
    CommonSecurityLog
    | where TimeGenerated > ago(90d)
    | where RequestURL has_any (SanctionedDomains) or DestinationHostName has_any (SanctionedDomains)
    | project TimeGenerated, SourceIP, RequestURL, DestinationHostName, DeviceAction
);
union DNSHits, ProxyHits
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Hits=count()
    by DeviceName, RemoteUrl, InitiatingProcessAccountName
| order by LastSeen desc

For transaction screening exposure, query your payment/treasury logs (if ingested into Sentinel) for counterparty wallet addresses published in the OFAC SDN notice — pull the designated address list from the Treasury press release and load it as a watchlist, then join it against transaction records:

KQL — Microsoft Sentinel / Defender
// Requires: OFAC SDN crypto addresses loaded as watchlist 'OFAC_SDN_Crypto_Addresses'
let SDNWallets = _GetWatchlist('OFAC_SDN_Crypto_Addresses') | project WalletAddress;
CryptoTransactions_CL
| where TimeGenerated > ago(180d)
| where counterparty_address_s in (SDNWallets) or destination_address_s in (SDNWallets)
| summarize ExposureTotal=sum(amount_usd_d), TxCount=count(),
    FirstTx=min(TimeGenerated), LastTx=max(TimeGenerated)
    by counterparty_address_s, direction_s, customer_id_s
| order by ExposureTotal desc

Velociraptor VQL

Deploy this hunt across your fleet to identify endpoints with browser history artifacts referencing sanctioned exchange domains — useful for scoping insider exposure after the designation:

VQL — Velociraptor
-- Hunt: Browser history artifacts referencing sanctioned crypto exchanges
-- Scopes employee/insider interaction with Shelbit and prior designated venues
LET domains = '(shelbit|garantex|chatex|suex\.io|bitzlato)'

SELECT FullPath, Key.LastWriteTime AS LastVisit, Url, Title
FROM foreach(
    row={
        SELECT FullPath FROM glob(globs='C:/Users/*/AppData/Local/*/User Data/*/History')
    },
    query={
        SELECT FullPath, Url, Title,
               timestamp(epoch=last_visit_time/1000000 - 11644473600) AS LastVisit
        FROM sqlite(file=FullPath, query='SELECT url AS Url, title AS Title, last_visit_time FROM urls')
        WHERE Url =~ domains
    })
ORDER BY LastVisit DESC

Verification & Hardening Script

Use this PowerShell script to (a) verify your proxy/firewall block lists cover sanctioned exchange domains, (b) confirm your screening platform has ingested the latest SDN update, and (c) sweep local DNS resolver caches for evidence of prior lookups:

PowerShell
# Shelbit / sanctioned-exchange exposure verification — run on endpoints or via your RMM
# 1. Check local DNS cache for historical lookups to sanctioned infrastructure
$sanctionedPatterns = 'shelbit|garantex|chatex|suex|bitzlato'
Write-Host "=== DNS Cache Sweep ===" -ForegroundColor Cyan
Get-DnsClientCache | Where-Object { $_.Entry -match $sanctionedPatterns } |
    Select-Object Entry, RecordType, Data, TimeToLive | Format-Table -AutoSize

# 2. Verify outbound blocking is effective (should fail/return block page)
Write-Host "=== Block Verification (all should FAIL) ===" -ForegroundColor Cyan
$testDomains = @('shelbit.com','garantex.io','chatex.com','suex.io','bitzlato.com')
foreach ($d in $testDomains) {
    try {
        $r = Invoke-WebRequest -Uri "https://$d" -TimeoutSec 5 -UseBasicParsing -ErrorAction Stop
        Write-Host "[EXPOSED] $d returned HTTP $($r.StatusCode) — add to egress block list" -ForegroundColor Red
    } catch {
        Write-Host "[OK] $d blocked or unreachable" -ForegroundColor Green
    }
}

# 3. Confirm SDN list freshness on this host (requires your screening feed's local cache path)
$sdnFeed = "$env:ProgramData\ComplianceFeeds\sdn_crypto_addresses.json"
if (Test-Path $sdnFeed) {
    $age = (Get-Date) - (Get-Item $sdnFeed).LastWriteTime
    if ($age.TotalHours -gt 24) {
        Write-Host "[WARN] SDN crypto address feed is $([math]::Round($age.TotalHours))h old — force refresh" -ForegroundColor Yellow
    } else {
        Write-Host "[OK] SDN feed updated $([math]::Round($age.TotalHours,1))h ago" -ForegroundColor Green
    }
} else {
    Write-Host "[INFO] No local SDN feed cache found — verify screening runs centrally (API/SaaS)" -ForegroundColor Yellow
}

# 4. Audit local crypto wallet artifacts (scoped, read-only)
Write-Host "=== Wallet Artifact Sweep ===" -ForegroundColor Cyan
$walletPaths = @("$env:APPDATA\Electrum","$env:APPDATA\Exodus","$env:APPDATA\atomic","$env:APPDATA\WasabiWallet")
foreach ($p in $walletPaths) { if (Test-Path $p) { Write-Host "[FOUND] $p" -ForegroundColor Red } }

Remediation

  1. Pull the designation details immediately. Retrieve the OFAC press release and SDN list update from the U.S. Treasury website (home.treasury.gov/news/press-releases and sanctionslist.ofac.treas.gov). Extract every designated wallet address and domain. Load them into your screening platform as a high-priority watchlist today — do not wait for your vendor's next scheduled feed update.

  2. Run a retroactive exposure screen. Screen 12–24 months of transaction history against the newly designated addresses. Document exposure totals, counterparties, and dates. If you find matches, engage sanctions counsel before taking action on the funds — blocking and rejecting obligations have specific procedural requirements, and self-disclosure to OFAC materially reduces penalty exposure.

  3. Update block lists at the egress layer. Add Shelbit domains (and the previously sanctioned venues — Garantex, Chatex, Suex, Bitzlato) to DNS filtering, web proxy, and firewall deny lists. This is a policy control as much as a sanctions control: corporate assets should never resolve illicit exchange infrastructure.

  4. Verify vendor screening coverage. Contact your blockchain analytics provider (TRM, Chainalysis, Elliptic, or your payment processor's embedded tooling) and confirm in writing that Shelbit attribution data is live in their product. Ask specifically whether they cover the exchange's deposit addresses, nested service relationships, and known peel-chain patterns.

  5. Review nested-exchange and third-party risk. If you rely on payment processors or exchanges with crypto rails, request attestation that they screen against the new designations. Nested illicit services are precisely how tainted funds reach compliant platforms.

  6. Brief treasury, finance, and insider-risk teams. Employees moving personal or corporate funds through obscure offshore exchanges is both a compliance violation and a classic embezzlement indicator. Add sanctioned-exchange interaction to your insider-risk program's behavioral indicators.

  7. Set a 10-business-day internal deadline for completing the retroactive screen and egress blocking, mirroring the urgency CISA and OFAC-adjacent guidance typically applies to financial-sector controls. Document completion for auditors — examiners will ask about Shelbit screening in your next BSA/AML or PCI/HIPAA-adjacent review if you touch crypto at all.

The Shelbit designation is a reminder that sanctions compliance is now a SOC function, not just a legal one. The telemetry to answer "did we touch this?" lives in your DNS logs, proxy logs, and transaction records — hunt it before Treasury's examiners ask.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.