The botnet crew that served its own /root

An open directory at 66.154.127[.]156:22223 exposed something more revealing than a malware download folder: the working environment around a device recruitment pipeline.

Huntback's captured records contain 110 files, representing 70,217,188 bytes. Alongside Linux executables are successive revisions of Telnet brute-force code, an ADB loader designed to connect through residential SOCKS5 proxies, deployment supervisors, protocol test harnesses, bot upgrade documents and remote-access configuration.

Two otherwise distinct access paths converge on 23.95.228[.]20. A Telnet deployment script identifies that address as the source of a third-party loader. An ADB payload list downloads architecture-specific wife.* binaries from the same host. A bot development document separately describes existing devices connecting to that address on TCP/1337.

The exposure itself has a plausible explanation in the captured files. A PM2 process backup records an HTTP server configured on port 22223 with /root/ as its document directory. That configuration would expose the development environment around the payloads, including dotfiles, rather than just the payloads intended for distribution.

Key findings

• A documented link between two deployment paths: Telnet deployment and ADB loading both reference 23.95.228[.]20; bot documentation also identifies it as a C2 endpoint.
• Residential proxies are part of the ADB design: discovery and application-layer access are separate stages. The README describes ZMap discovery followed by proxied ADB connections, with the target device fetching its own payload.
• The workspace prioritises reliable device recruitment: fake Telnet services, an ADB mock endpoint, protocol tracers, banner collection and regression scripts address false positives and failed delivery.
• Competition for devices appears in the operator's own comments: a retargeting script explains that rival bots remove dropped files, motivating short-cycle retries against previously responsive endpoints.
• A TLS migration is specified, not established: development notes describe preserving existing TCP/1337 devices while adding TLS/443 and a remote update path. The captured previews do not prove that migration was deployed.
• Sensitive operational material was exposed: remote-proxy tokens and session records, cloud access credentials, environment files, shell history and an ADB key appear in the inventory. Secret values are omitted here.

Evidence scope: what was actually examined

This investigation uses Huntback's search_loot response for ip:66.154.127.156, retrieved on 14 October 2026. The response contains file paths, sizes, capture timestamps, hashes, labels and bounded content previews. The analysis does not involve logging into infrastructure, using recovered credentials, executing payloads or testing third-party systems.

The distinction between a preview and a complete file matters. Some small scripts are visible in their entirety; larger documents and sources are only partly visible. Hashes and file sizes are reported by Huntback and were not recalculated from downloaded originals. ELF files were not disassembled or executed. Archives were not unpacked.

Three evidence levels are used throughout:

The 110 records are a captured subset, not a recursive filesystem acquisition. Referenced files such as node.conf, proxies.txt, hits.txt, wife.zip and bot C source files are not included in this result. A missing record is not evidence that a file never existed.

1. The exposure: a root home directory used as a web document root

The most useful infrastructure artefact is .pm2/dump.pm2.bak. Its preview records a process named http-server with these arguments:

{
  "name": "http-server",
  "args": ["-m", "http.server", "22223", "--directory", "/root/"]
}

This excerpt establishes a saved configuration consistent with serving /root/ using Python's HTTP server module. It is not a live process listing, but its port and directory layout match the captured URLs.

That choice explains why distribution files coexist with .android/adbkey, .dsh/, .pm2/ and .bash_history. A convenient payload server appears to have exposed the surrounding home directory as well. The capture alone does not establish whether that broader exposure was accidental or intentional.

The root-level ssh.sh is a separate administration artefact. Its visible code changes SSH to port 22222, handles systemd socket overrides and disables ICMP echo replies. Those are script actions, not verified observations of the host's listening ports or current firewall state.

The directory includes both development and runtime material. PM2 logs and a saved process environment sit alongside source revisions, test utilities, deployment instructions and executable builds. This is consistent with a host used for several roles: development, orchestration, remote administration and file distribution.

2. ADB recruitment through residential proxies

The strongest description of the ADB component comes from adb-spread/README.md. It describes a Go spread loader receiving targets discovered by ZMap, connecting through residential SOCKS5 proxies, and issuing shell or exec commands over open ADB, usually on port 5555.

It explicitly separates payload download from C2 connectivity. The target device downloads the binary over HTTP; the bot then uses its own compiled C2 settings. That separation creates several different network identities around one attempted infection.

This diagram represents the design described in the captured workspace. It does not assert that a particular target completed every step.

Discovery source, access source and payload host are different evidence

The scanner may discover a device from one address, while the ADB session arrives from a residential proxy exit. The subsequent HTTP download originates from the device itself. A C2 connection, if established, is another event.

For defenders, this means a source IP associated with the ADB command channel may not be the host conducting broad discovery or hosting the executable. Treating any one IP as the whole operation risks missing those relationships. The recovered material supports correlation across stages; it does not support labelling every residential proxy customer or exit address as malicious.

The payload list shows architecture selection and execution intent

adb-spread/payloads.txt contains a shell command that chooses among Android-accessible directories, derives a filename with a .k prefix, queries the device ABI and selects a wife.* payload from 23.95.228[.]20.

The visible branches cover ARM64, ARMv7, x86-64, x86 and MIPS variants, with an ARMv7 fallback. Several download utilities are tried. A byte-count threshold is checked before permissions are changed and the file is launched with setsid in the background.

These details establish intended download-and-execute behaviour. They do not establish successful execution on any device. The filename-to-architecture mapping also remains an operator choice: the script's selection of a name such as wife.x86 does not independently prove the corresponding binary's architecture.

One executable, adb-spread/wife.arm7, is present in the captured inventory at 72,224 bytes. Its name matches the payload family referenced by the scripts, but a filename match alone does not establish byte identity with every remotely served payload.

Keeping discovery and delivery coupled

spread.sh describes a FIFO coupling between ZMap and the loader. The loader starts as the consumer, and the supervisor kills the scanner if the loader dies. This prevents continued discovery when there is no process available to consume the results.

start.sh exposes per-node configuration for interfaces, gateway MAC addresses, rate, sharding flags and worker concurrency. Its visible defaults include a ZMap rate of 5,000 and 200 ADB threads. The standalone supervisor has a different fallback of 500 threads. These are configuration defaults, not a measurement of sustained operational throughput.

The ZMap log preview does provide execution evidence for the discovery component: it records approximately 5,000 packets per second during the opening seconds of a run and a small number of replies. A reply to discovery is not an authenticated session, shell execution or infection.

Repeat access is explicitly designed into the pipeline

retarget.sh is particularly revealing. Its comments state that a full sweep revisits an address only after several days, while competing botnets can delete a dropped file within minutes. The script therefore selects previously observed CNXN endpoints for a separate retry loop.

The visible defaults specify a 900-second interval and a maximum of 300 selected endpoints. The comments exclude authentication-required endpoints because the operator lacks the necessary RSA key, and exclude entries classified as traps or farms.

The evidence supports an intended maintenance loop around previously responsive devices. It does not validate the operator's explanation about competitors on particular devices. Also, an endpoint that emits CNXN is not necessarily one on which the payload ran successfully.

watchdog.sh supervises both the primary scanning session and the retarget session. It restarts missing components and rotates growing logs. This is persistence of the scanner-side operation. It should not be confused with proof of persistence on recruited devices.

3. Protocol fidelity, false positives and suspected sensor avoidance

Several files show work on distinguishing real access from convincing responses.

main.go advertises a feature-rich ADB host banner, with comments explaining that a bare banner can be treated as malformed by some daemons and honeypots. It contains counters and state for authentication requirements, cloud filtering, suspected traps and repeated banner farms.

banner_grab.py collects full connection banners from endpoints already recorded as speaking ADB. adb_trace.py traces raw protocol frames and describes using a harmless first-stage command to diagnose differences from the stock client. adb_exec.py implements direct protocol interaction to avoid quoting and pipeline problems attributed to the standard client.

awsfilter.go embeds an AWS IPv4 prefix list and implements a radix-tree lookup. This supports the existence of a cloud-address exclusion mechanism, but the referenced prefix file is not in the captured result. Its contents and freshness cannot be verified here.

These artefacts support a design that filters endpoints and debugs protocol failures. They do not prove every filtered cloud address is a honeypot or that every banner-based classification is correct. Filtering can also reduce wasted connections to systems outside the operator's intended device population.

A regression gate that may not actually gate

deploy-restart.sh claims to rebuild the loader, test it against mock_adbd.py, then restart the production pipeline. The visible test checks whether a hit file is non-empty.

However, the failure branch shown in the preview prints diagnostics and then proceeds beyond the conditional. No terminating exit is visible in that branch, and the script begins with set -u, not an automatic exit-on-error setting. The visible section therefore does not establish a fail-closed regression gate, despite its comment.

This is an instructive discrepancy: the operator is investing in tests, but the implementation excerpt does not enforce the safety property claimed by its description. The unseen remainder could contain additional controls, so the conclusion is limited to the visible branch.

4. Telnet: credential testing followed by controlled deployment

The hack/ and telnet_audit/ directories contain successive Go revisions and compiled builds. Visible filenames include versions 14 through 19 and a separate v1.3 naming scheme. Version labels show retained iterations, not a reliable release chronology or a count of distinct deployed tools.

The Go source header describes protocol negotiation handling, preflight rejection of non-Telnet services, early abandonment of silent targets, failure-first result interpretation and a goroutine worker pool. Results are intended to be written incrementally so an interrupted run retains progress.

fake_telnetd.py supplies a local test environment with six Telnet behaviours. Its cases include incorrect credentials, misleading banners, unauthenticated shell-like responses, a genuine test shell and a fake shell that accepts arbitrary passwords. The stated goal is to prevent success reports based only on a prompt or banner.

The implication is operationally significant: the tool's authors distinguish a plausible login response from verified command execution. Defenders should preserve that same distinction when counting what their sensors observed.

From credentials to device assessment

telnet_post.py describes post-login fingerprinting: system and kernel details, architecture, privilege context, available outbound tools and restricted environments. Its comments frame this phase as read-only and describe retaining raw responses for review.

Those comments are statements of intended behaviour, not an independent guarantee about the full script. The preview does show a staged workflow: validate access, understand the device, then decide how to deliver a payload.

The deployment script links Telnet to the ADB payload backend

telnet_deploy.py hardcodes 23.95.228[.]20 and /dl.sh. Its comments explicitly describe the source as a third-party Mirai loader and refer to architecture-specific wife.* binaries.

The same comments warn that the deployed bot may close Telnet port 23 and remove competing processes, potentially destroying the operator's own access path. That claim is not independently verified by binary analysis, but it explains the orchestration around deployment.

deploy_daemon.py watches brute-force progress and avoids files still being processed. Its comments say deployment must wait because the payload can close port 23. It tracks completed batches and previously handled files to avoid repeated delivery.

The important relationship is between the files: credential testing, result validation and payload deployment are separate components, with the deployment daemon coordinating their handoff. This is stronger evidence of an integrated workflow than simply finding a brute-force executable beside a malware sample.

5. Bot development notes: preserving devices during a C2 migration

Three Markdown documents provide a view into intended bot evolution: BOT_V2_PROMPT.md, BOT_V2_DEV_DOC.md and BOT_UPGRADE_RUNBOOK.md.

The visible document structure describes C components for connection handling, protocol processing, attack methods, process cleanup, masquerading and self-supervision. It names a Go C2 server and Telegram integration. These source files are referenced in the documents but are not themselves present in the captured result.

The development document claims 19 DDoS methods and describes an existing bot connecting outbound to 23.95.228[.]20:1337. It reports process names such as init and kworker, and an executable path of /var/tmp/w shown as deleted. These are operator-reported observations, not measurements independently reproduced during this investigation.

The proposed change is about continuity as well as encryption

The documents specify retaining TCP/1337 for existing devices while adding TLS/443 for new builds. BearSSL is named for the client, and future CDN fronting is discussed as a design objective.

The runbook makes a remote update command a prerequisite for migration and rollback. Its concern is loss of existing devices if the communication protocol changes before an update path is available.

That emphasis reveals the operator's priorities: compatibility, device retention and recoverability. It does not establish that the update command or TLS service was deployed. Neither a live TLS handshake nor a complete upgraded binary was examined.

The notes use both a cleartext description and references to XOR command processing. It would therefore be imprecise to describe the legacy protocol as entirely unencoded. The supported conclusion is that the notes propose moving from a non-TLS transport to TLS while preserving compatibility.

A candidate hostname remains a document reference

The prompt document names bot.3.9.f.e.a.2.8.f.0.7.4.0.1.0.0.2.ip6.arpa in a build example. Its unusual shape makes it worth recording, but no DNS resolution or operational use was verified. It is a candidate configuration indicator, not a confirmed active C2 hostname.

6. Web reconnaissance and exploit material beside the device tooling

The workspace also contains material outside the Telnet and ADB paths. Co-location supports a broader range of interests; it does not demonstrate that every file belongs to one campaign.

FreePBX tooling has a verifiable vulnerability reference

hack/wt.py identifies itself as a watchTowr FreePBX CVE-2025-57819 detection artefact generator. hack/52681.py also labels itself as a FreePBX exploit for that CVE. Those headers support identification of the files' claimed purpose, not authorship by the workspace operator or exact identity with the original public releases.

The vendor advisory independently confirms an authentication bypass leading to database manipulation and remote code execution in the commercial endpoint module. Its patched module versions are 15.0.66, 16.0.89 and 17.0.3. These are module versions, not a blanket FreePBX platform version test. [2]

No captured result here establishes a successful FreePBX compromise or connects a particular PBX victim to the bot pipeline.

Other CVE labels remain unverified

cve-2026-63030/exp.py contains administrator-account data structures, WordPress-oriented naming and batch-client scaffolding in its preview. That suggests a WordPress-related test or exploit workflow, but the entry point and complete chain are outside the visible excerpt.

cve-2026-29053.tar.gz is present as an archive. Without extraction, its contents are unknown. Neither filename is sufficient to validate a CVE mapping, affected product, novelty or working exploit.

A web application is a target reference, not a confirmed victim

The runs/ directory contains saved HTML, response headers, a JavaScript bundle, API paths and proxy utilities. unauth_scan.sh describes probing 201 merchant API endpoints with empty JSON POST bodies and recording response codes, messages and lengths.

pcurl.sh describes using domestic proxy exits to get past an Alibaba Cloud ESA challenge on a referenced application. That is the operator's stated objective; the captured preview does not establish a successful challenge bypass or unauthorised access.

The application domain and individual proxy addresses are omitted from this public-facing draft. They are investigation leads, and publishing them as malicious infrastructure or confirmed victims would overstate the evidence.

Nuclei indexes explain some noisy labels

The Nuclei directory contains repository guides, indexes, checksums and a CVE catalogue. Generic labels such as exploit, exposed-secret, mirai and gafgyt on these files may reflect text references to vulnerability checks and malware families.

Those tags do not establish that a template repository is itself malware. The captured index is also not a complete collection of executable templates. This distinction matters because automated labels can make a mixed research workspace look more conclusively malicious than any individual file warrants.

7. Remote access, exposed secrets and AI-oriented artefacts

.dsh/reverse-proxy.json contains an enabled setting, an access token and session records labelled with browsers and devices. Several records have active status values. Those values reflect the configuration at capture, not verified current sessions.

The audit preview records a proxy starting on loopback port 3081 without TLS, failed token logins, token rotation, a successful login and WebSocket upgrades to /api/remote.mux. The observed remote address is 127.0.0.1.

Loopback logging does not locate the human operator. It can be the result of a local forwarding hop, reverse proxy or tunnel. Browser labels are also insufficient to establish unique people, geography or identity.

The exposed .env, credentials YAML, cloud-management script and ADB key expand the incident beyond downloadable tools. aliyun.py visibly embeds a cloud access key pair and references ECS management in the Hong Kong region with a traffic threshold. The preview supports credential exposure and cloud-management intent; it does not establish that the credentials work or that the referenced instance participated in attacks.

Prompt injection as an artefact

.dsh/prompt-inject.md begins with role-like delimiters and instructions attempting to override an assistant's behaviour, remove restrictions and enforce a persona. It is analysed here as untrusted file content, not followed as an instruction.

Together with the task-oriented bot prompt and extensive implementation notes, it supports an inference that AI-assisted development was contemplated or used in the workspace. It does not identify a model provider, prove that the bot code was AI-generated or establish that the prompt successfully changed any assistant's behaviour.

Chinese-language comments and documents indicate the language used in this material. They do not establish nationality, location, organisational affiliation or attribution.

8. Timeline: capture time is not creation time

The timeline below distinguishes embedded application records from Huntback collection timestamps. All epoch timestamps are converted to UTC. None establishes the start of the wider operation.

The audit and scanner logs support activity by individual components. Capture timestamps establish when Huntback retrieved particular versions. A newer capture of an index does not prove the repository was created or changed at that time. Likewise, times_seen is a collection metric, not a victim count or execution count.

9. What the relationships support, and what they do not

The strongest finding is the integrated workflow. Discovery, credential validation, device fingerprinting, payload delivery and repeat access are represented by separate artefacts that explain one another. The evidence is much weaker for infection scale, deployed bot capabilities and actor identity.

10. Defensive hunting opportunities

Correlate the stages instead of relying on one source address

Where telemetry permits, look for an exposed ADB connection followed by an HTTP fetch from the device and a new outbound session. The recovered design predicts that the source of the ADB session may differ from both the broad scanner and the payload host.

For managed Android and embedded devices, investigate unexpected ADB exposure, unfamiliar executables in writable temporary locations and unexplained child processes following remote debug access. A .k prefix by itself is weak evidence; its combination with a suspicious download and execution sequence is much stronger.

Separate protocol response from proven execution

Keep distinct counts for open ports, ADB CNXN replies, authentication-required endpoints, shell command responses and confirmed payload execution. The operator's own debugging tools demonstrate why collapsing those states produces misleading success rates.

Review Telnet events as a sequence

Repeated credential attempts followed by command probing, device fingerprinting and a payload fetch deserve higher priority than a login banner alone. A Telnet service disappearing after suspicious access can be a useful supporting event, but device maintenance and network changes are alternative explanations.

Hunt the payload and C2 references with historical context

Search historical HTTP, DNS, flow and endpoint telemetry for the indicators below. Prioritise the payload address when it appears with /dl.sh, /wife.* or a subsequent TCP/1337 session. Do not assume traffic to port 443 proves this operation's proposed TLS upgrade.

Address the exposed management surfaces

Restrict debug and administrative interfaces to authorised networks. For a matching incident, preserve evidence and rotate exposed credentials before removing the file exposure. Patch the FreePBX endpoint module according to the vendor advisory if that component is present. Credential rotation, module patching and bot removal are different remediation tasks.

11. Indicators and artefact hashes

Machine-readable: download these 10 indicators as CSV (type, value, context; values are not defanged).

Addresses are defanged for publication. The infrastructure roles reflect the captured evidence, not a claim of exclusive ownership or continuing malicious use.

Hash matches establish an artefact relationship, not automatically a malicious execution. Generic utilities and source files should be evaluated in context.

12. ATT&CK-oriented behavioural mapping

This is an analyst mapping of supported or intended behaviours. It is not a reproduction of every automated tag returned by Huntback, and it does not assert completed execution of the whole chain.

Closing assessment

The open directory exposes the engineering around device recruitment: handling ambiguous protocol responses, separating discovery from proxied access, coordinating payload deployment with credential testing, and keeping scanning and retry processes alive.

The common payload host links Telnet and ADB workflows more convincingly than generic malware tags do. The bot documents add context about device retention and a proposed C2 migration, but remain claims and plans until corroborated by binaries or network evidence.

The practical value of this exposure is that it lets defenders connect events that otherwise appear unrelated: a broad scan, a residential-source debug session, a device-originated payload download and a later outbound connection. Those relationships are the core finding. Victim counts, actor attribution and a completed TLS migration remain outside the evidence examined here.

Sources and methodology notes

1. Primary corpus: Huntback search_loot, query ip:66.154.127.156, limit 200, retrieved 14 October 2026. Returned 110 records with metadata and bounded previews. File paths in the text identify the underlying artefacts. Appendix A preserves the complete returned inventory and labels. 2. FreePBX vendor advisory: Authentication Bypass Leading to SQL Injection and RCE, GHSA-m42g-xg4c-5f3h. Used to verify the vulnerability class and patched endpoint module versions, not to infer activity by this host. 3. Editorial reference: InfraHunter research, including its JBRJ and JUCEC investigation. Consulted for an artefact-led research format only. Its findings are unrelated to this infrastructure.

No ASN, hosting location, domain registration, live service state or external victim status was independently established for the investigated infrastructure. No disclosure or notification is claimed. Active secrets, proxy credentials, session identifiers and third-party target details are omitted.

Appendix A: Complete captured file inventory

Paths are relative to the captured HTTP document root. Sizes are bytes. Tags are verbatim Huntback labels and require contextual interpretation. File types are the returned values, including extension-derived or truncated values. Percent-encoded filenames are decoded for readability.

Related research

• One server, three crypto crimes: wallet scanning, cryptojacking and pool brute-forcing 2026-10-07
• Searching for the Nuclear Control Room: an intrusion workbench built to find SCADA and PLC intel 2026-10-22

Live data

• Live finds: malware, C2 and open directories on the network now
• CVE intelligence: what is being exploited on the decoys