Goldshell – Pool-Hijack Malware / Port-Forward Botware

Pull the Ethernet cable. Right now. Don't finish reading this paragraph first. Disconnect the miner from the network before you do anything else - every minute of continued exposure is more hash siphoned to the attacker. WiFi off too if you use it. The miner will stop hashing or hash to a stale connection. That's fine. We're going to wipe and rebuild from here.

Delete every router port-forward rule pointing at the miner. Log into your router admin (typically `192.168.0.1` / `192.168.1.1` / `10.0.0.1`). Find NAT / Virtual Servers / Port Forwarding. Delete every rule that maps any external port to the miner's LAN IP - especially TCP `22`, `80`, `8080`, `4028`. If you can't tell which rules are for the miner, screenshot the table and delete every rule you didn't deliberately create for a non-mining service. Save and reboot the router.

Disable UPnP on the router. UPnP allows applications on the LAN to silently open WAN ports without you knowing - and some Goldshell firmware variants ask UPnP to open `4028` for 'remote monitoring' without surfacing it to the user. Find the UPnP toggle in router settings. Turn it off. Modern routers don't need UPnP for any common home use; the trade-off in security is enormous.

Verify your WAN is closed. From your phone on cellular (not WiFi - cellular gives you a true outside-the-LAN view), use the GRC Shields Up port-probe tool against your public IP, or have a friend `nmap -p 22,80,8080,4028 <your-public-ip>` from their own network. Expected result: every port closed or filtered. Anything open means you missed a forward rule or UPnP punched a hole - go back to step 2.

Document what you found before you wipe. Take a screenshot of the compromised pool config, the router forward rules you deleted, and any unfamiliar entries you saw in step 5 of diagnostics. This is for the post-mortem - and so you can spot the same pattern faster on the next miner you check. Save these screenshots offline in a folder dated with the incident date.

Change the SSH root password before anything else. `ssh root@<lan-ip>` (password `19283746` if not previously changed). Run `passwd` and set a 20+ character random password from a password manager (1Password, Bitwarden, KeePass). Memorise nothing. Storage in a manager only. Same for the web UI: change the `admin` password from `123456789` to something equally strong via the web UI's settings page.

Reset `/root/product.json` to a known-clean state. Either via the web UI Pool tab (delete attacker entries, save your real pool config) or via SSH with a text editor: `vi /root/product.json`, find the `pools` array, replace with your legitimate config. Save. `reboot`. Watch the miner come back up - confirm via the dashboard that the pool URL matches what you set, with no `portforwarded.goldshell` prefix.

Audit cron and init scripts for persistence. `ssh root@<lan-ip>` again. Run `crontab -l` and `cat /etc/crontabs/root` - any entry you didn't add gets deleted. `ls -la /etc/init.d/` - compare against a clean reference (you can pull the contents of a stock Goldshell `burn-*.img` and `mount` it loop-style on a Linux box for comparison). Any unfamiliar init script gets removed and the service stopped: `/etc/init.d/<scriptname> stop && rm /etc/init.d/<scriptname>`.

Audit writable directories for malware drops. `find /tmp /var/tmp /usr/local/bin /root -type f -newer /etc/openwrt_release` lists files modified more recently than the firmware install - which, on a long-running miner, are typically all attacker-installed. Inspect with `file <path>` and `strings <path> | head -50`. Anything that smells like a binary you didn't install: `rm` it. Reboot. Verify it doesn't reappear (persistence usually re-creates on boot, which is your signal Tier 2 isn't enough - jump to Tier 3).

Re-verify pool integrity for 24 hours. Check the pool config every hour for the first 6 hours, then every 6 hours through the next 18 hours. If `product.json` reverts to attacker config, persistence is in firmware-image-level locations Tier 2 can't reach - SD-card reflash (Tier 3) is now mandatory. Track in a notebook the exact timestamps of each check so you have a clean evidence chain if you escalate to D-Central.

Email `hello@goldshell.com` to request the recovery image. Subject: `burn-<model>.img recovery request - SN: <serial> - suspected compromise`. Goldshell support response runs 24-72 hours typically. Use this window to prepare the SD card and clean your network. Goldshell does NOT publish `burn-*.img` files publicly - email is the documented channel. Also check James Chambers' archive for cross-reference images for common BOX models.

Before reflashing, dump the eMMC for forensics if you want to study the compromise. This is optional but useful for post-mortem and useful for the community. Pull the control board (Tier 3 procedure from our firmware-stuck guide). Dump the eMMC with `dd if=/dev/sdX of=goldshell-compromised.img bs=4M`. Mount loop-style on a Linux box, archive `/root/product.json`, `/etc/crontabs/`, `/etc/init.d/`, any unfamiliar binaries. This image is the evidence record - keep it offline.

SD-card reflash with the clean `burn-<model>.img`. Follow the same procedure as our firmware-stuck recovery guide: Etcher to a quality SD card (Samsung EVO Plus 16 GB), insert into the miner, cold-boot, wait for the eMMC reflash to complete (5-15 minutes, no interruption), pull SD, cold-boot from eMMC. The miner now runs untampered factory firmware. CRITICAL: do not plug Ethernet yet - the next step hardens before exposure.

Harden BEFORE the miner touches the network. Local console only or LAN-only with a transient IP that you'll discard. Disable WAN-facing services that don't need to be on at all: `/etc/init.d/dropbear disable` if you don't need SSH (you can re-enable LAN-only later via Wireguard). Set the strong root password (20+ chars, manager-stored). Set the strong web UI password. Apply LAN-only iptables rules if your firmware supports them: `iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j ACCEPT && iptables -A INPUT -i eth0 -j DROP` (adjust subnet to yours).

Re-deploy on LAN with NO port-forward, NO UPnP, NO public exposure. Plug Ethernet. Confirm the miner connects to your real pool. Confirm via cellular external scan that ports `22, 80, 8080, 4028` are closed/filtered on your WAN. Set up Wireguard or Tailscale on the router (or on a separate Raspberry Pi gateway) for any remote monitoring you actually need. Wireguard exposes one UDP port with cryptographic auth - safe. Tailscale exposes nothing on WAN at all - even safer.

When to escalate. Send to D-Central if: (a) Tier 3 reflash leaves the miner re-pwned within hours (suggests bootloader-level persistence requiring eMMC clean-room rewrite), (b) you cannot get a `burn-<model>.img` from Goldshell support within a reasonable timeframe and you don't have the equipment for direct eMMC programming, (c) you suspect bootloader / kernel-level rootkit beyond your forensic reach, (d) you have multiple compromised Goldshells and want a bench-validated fleet sweep.

What D-Central does at the bench. We run a clean-room reflash protocol: pull the eMMC, blank it via direct programmer, flash a vetted `burn-<model>.img` from our verified library, verify boot, harden the config (strong passwords, LAN-only services, no WAN listeners), re-test on an isolated VLAN with a sniffer to confirm zero outbound connections to non-pool hosts, then 24-hour burn-in. We are the only Canadian repair shop documenting Goldshell compromise as a repair class - this isn't a corner case, it's a shape of work.

Post-recovery network audit (we'll help on consult). If you have one compromised Goldshell, we'll sit on your network architecture with you and audit for any other exposed mining hardware - Goldshell, Antminer, Whatsminer. The pattern repeats: default credentials + port-forward = compromise. We'll help you redesign for defense in depth: Wireguard / Tailscale for remote, separate VLAN for miners, miner-pool-only egress firewall rules, monitoring alerts on unexpected outbound connections.