Yumingzhi Pan and colleagues (Southeast University, Shandong University) asked an odd question: why would anyone need Tor's anonymity to reach their own home NAS or DVR? The answer is that they don't. Attackers do. The team built TORCHLIGHT, a system that runs Tor exit relays, filters the external traffic for IoT protocols, and uses an LLM-based analyzer to identify devices and attacks in the flow. With three cheap exit relays (about $196 per year) they captured 26.5 TB and found 45 vulnerabilities, 29 of them zero-days, affecting roughly 12.71 million internet-exposed devices. After disclosure, many targets went offline and several bugs reached the CISA KEV catalogue.
Post 24 of my Black Hat Asia 2026 series. This is a measurement and threat-intelligence study. I cover the design, the ethics, and the findings, and I deliberately skip the exploit strings the deck shows for the vulnerabilities.
1. Cloud-centric vs cloudless IoT
| Cloud-centric IoT | Cloudless IoT | |
|---|---|---|
| Examples | Smart locks, many consumer gadgets | NAS boxes, NVRs, DVRs, IP cameras |
| Access | Through a vendor cloud; device sits behind NAT | Direct from the internet |
| Compute and data | Limited; data often in the cloud | Substantial; self-hosted data |
| Attack appeal | Lower (not directly reachable) | High: reachable, powerful, holds footage and files |
Cloudless devices are valuable targets precisely because they are directly exposed and reasonably capable. They also tend to be old, rarely updated and sometimes end-of-life.
2. Why Tor exits?
In Tor, traffic between relays is encrypted. At the exit relay, traffic leaves the network toward the destination server and is unencrypted unless the application itself uses TLS. IoT protocols such as plain HTTP, Telnet, FTP and RTSP are typically cleartext. That means an exit-relay operator can see attack traffic directed at IoT devices, without knowing who the attacker is (Tor hides the source). The researchers noticed IoT traffic on their own lab exit relays and realised it was a window onto real, ongoing attacks, including attacks using vulnerabilities nobody had reported yet.
3. TORCHLIGHT design
Fig. 1 — TORCHLIGHT end to end.
3.1 Collector on cheap servers
The traffic collector must run on small, low-cost VPS nodes. To separate Tor-internal traffic (relay to relay) from external traffic (exit to server) it checks source and destination against the list of more than 7,000 relay addresses from the Tor consensus. Doing that per packet in userspace would be slow, so it uses the kernel's ipset hash sets with packet-filter rules and a queue target, then stores the data and ships it over an encrypted channel to storage.
3.2 Filtering out noise
Offline filtering keeps only common IoT protocols (HTTP, RTSP, Telnet, FTP), and drops traffic to top-million clear-web sites and to big hosting-provider address ranges. It also discards error responses and Telnet negotiation-only flows.
3.3 A deployment planner
Tor picks exit relays with probability proportional to bandwidth. Since budget is limited (a basic VPS is about $12 a month), a planner chooses cost-effective nodes to maximise bandwidth on a fixed budget, hence more traffic per dollar.
3.4 The LLM traffic analyzer
26 TB is impossible to inspect manually, and the problem is open-world: unknown targets, unknown attacks. The analyzer runs in stages:
- Recognise device names in responses (vendor, type, model) using in-context learning.
- Self-verify: ask the LLM to re-check what it extracted, to cut hallucinations.
- Complete missing names with retrieval: search-engine snippets are fed back so the model can fill in vendor and type from a bare model number.
- Confirm the traffic is from the device rather than a web page that merely mentions it (a blog post about a camera is not a camera).
- Classify attacks (command injection, path traversal, information disclosure, FTP anomalies) using instructions plus labelled examples with explanations, giving the LLM the request, or the request and response, or the FTP session.
The value of an LLM here is reasoning about unseen attacks. For example it can spot an encoded command hidden inside a parameter and explain its intent, something signature rules written in advance would miss for a zero-day.
4. Measured results
| Question | Result |
|---|---|
| Deployment | 3 exit relays (Las Vegas, New York, Miami), about $196 per year |
| Traffic | 26.506 TB; 60.4M+ responses across HTTP, Telnet, FTP, RTSP |
| Device identification | Accuracy 0.9384, precision 0.9260, macro-F1 0.8671 on Tor traffic (on par with a prior rule-based engine's dataset) |
| Attack detection (F1) | Command injection 0.9655; info disclosure 0.8970; path traversal 0.8500; FTP anomalies 0.9460 (with a high false-positive rate, 0.419) |
| Devices seen | 50,874 unique devices in 148 countries; DVRs 54.9%, cameras 36.5%; Asia 53.5%, Europe 38.3% |
| Vulnerabilities | 45 (29 zero-day, 25 CVEs assigned): 14 critical, 8 high, 18 medium, 1 low |
| Exposure | ~12.71M vulnerable devices online; the most prevalent DVR family alone ~2.7M |
| Exploit attempts | 90,047+ attempts found using 45 custom detection rules |
Two more observations stand out. First, attackers target legacy products: one NAS carried six zero-day bugs in 2018-era firmware, and the vendor confirmed it is end-of-life. Second, failed-login traffic was not random: passwords were often device- or vendor-specific, meaning attackers research targets rather than blindly guessing. The estimated market value of the found vulnerabilities was around $312,000 on a pricing model.
5. Case studies (conceptual)
- Dependency-linked exploitation: on a NAS family, an initial request used an information-disclosure bug to learn device and firmware details, followed by probes for a hard-coded credential bug and a command-injection bug. Recon feeds exploitation, then attackers drop a backdoor or tools.
- Evasion by dropper: attackers used simple XOR-style obfuscation of their remote-command traffic to slip past signature-based IDS, and used command injection to disable the device's own integrity-check components for deeper control.
- Vulnerability groupings: the findings are the tip of the iceberg. The same device typically had multiple bugs (information disclosure plus command injection plus hard-coded credentials) that attackers chain.
6. What happened after disclosure
The researchers tracked exposed populations after reporting. By December 2025 the majority of zero-day targets had gone offline or dropped sharply (some by hundreds of thousands), some vulnerabilities were fixed, and several vendors confirmed end-of-life status. Certain n-day device populations grew, meaning old bugs remained attractive. High-risk zero-days were added to the CISA Known Exploited Vulnerabilities catalogue, and the automated attack patterns they saw were linked to new Mirai variants. Finally, the vulnerable-target fingerprints were reused as honeypots: their discoveries catalysed over a million honeypot deployments, "weaponising" vulnerability knowledge for defence.
7. Defensive guidance
Device owners
- Do not expose NAS, DVR or camera admin interfaces to the internet. Use a VPN or a vendor-neutral secure remote-access method.
- Change default and vendor-specific passwords; they are actively researched.
- Replace end-of-life products; they may never receive fixes.
Vendors
- Plan firmware maintenance and publish end-of-life dates; harden web interfaces against injection and traversal.
- Remove hard-coded credentials and unauthenticated information endpoints.
Defenders and researchers
- Use observation infrastructure (honeypots, exit-relay studies within ethical bounds) to see zero-days early.
- LLM-assisted triage helps with open-world traffic, but validate with precision and false-positive metrics, as the authors do.
Is this deanonymising Tor users?
The authors state that they analysed no personal data and no user IPs; Tor already hides sources at the exit. The study looks at attacks on devices, not at who the users are, and they consulted the Tor Research Safety Board.
Why do attackers use Tor for this?
To hide their origin while scanning and exploiting internet-exposed devices, so that their infrastructure is not easily blocked or traced.
Why an LLM instead of signatures?
The problem is open-world: unknown devices and previously unseen attacks. An LLM can reason about intent in unfamiliar requests, while signatures need an existing pattern.
How can the study cost only about $196 a year?
It used three small VPS-based exit relays chosen by a bandwidth-per-dollar planner.
Takeaways
- Tor exit traffic is a window onto real attacks against cloudless IoT (NAS, DVR, cameras).
- TORCHLIGHT collected 26.5 TB on $196 a year and found 45 vulnerabilities (29 zero-day) affecting about 12.71M devices.
- An LLM analyzer with self-verification, retrieval and attack reasoning handled the open-world classification.
- Attackers favour legacy and end-of-life products and research device-specific credentials.
- Disclosure had impact: mass offlining, CISA KEV listings, botnet linkage and over a million new honeypots.
References & further reading
- Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
- Official talk recording on YouTube — Black Hat channel.
- Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
- Tor Metrics — relay and bandwidth statistics used for deployment planning.
- CISA Known Exploited Vulnerabilities catalog — where several of the found bugs were listed.
- Tor relay operator guide — background on running exit relays.