Termux Nmap Recon

Scope

My own lab subnet, 192.168.10.0/24, three Proxmox nodes (pve1, pve2, pve3) plus whatever VMs and services were up at the time. Whole point of the exercise: no laptop, no Kali box, just Termux on a Pixel 6a. If a phone is the only foothold an attacker has, this is what they’d see in the first twenty minutes.

Recon

Installed nmap in Termux and ran a service-version sweep of the whole subnet:

pkg install nmap
nmap -sV 192.168.10.0/24

Three hosts up immediately identifiable as the Proxmox nodes, plus a handful of VM guests. Trimmed the scan to the interesting host once the full sweep was in:

nmap -sV -p- 192.168.10.11

PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 8.9p1 Ubuntu
8006/tcp open  unknown  Proxmox VE web UI
3389/tcp closed ms-wbt-server

Impact

Nothing here is exploitation — this is what unauthenticated recon alone hands over. Port 8006 identifies the box as a Proxmox node without needing to touch the web UI at all; that’s enough for an attacker to go straight to known Proxmox CVEs or credential attacks instead of guessing. SSH banner gives an exact OpenSSH version, which narrows the search for anything unpatched a lot faster than blind brute-forcing.

The interesting part wasn’t the subnet, it was the platform: a phone with nothing but Termux did this in twenty-two minutes with zero setup cost. Recon doesn’t need a laptop.

Remediation

• Management interfaces like the Proxmox web UI shouldn’t be reachable from the same subnet as general lab traffic — separate VLAN, or bind to a management-only NIC.
• Version banners cost nothing to hide (ssh banner suppression, reverse-proxying the Proxmox UI without leaking the stack) and they remove free reconnaissance value.
• Rate-limit or firewall off ICMP/SYN sweeps at the router level so a full /24 sweep isn’t silent and free.