161,907 Hosts on Port 102 and 173 Siemens S7 Fingerprints: Reading Two Numbers From the Same Internet
Two queries run minutes apart against the same internet-wide dataset return 161,907 and 173. Both describe Siemens S7 exposure. Neither is wrong. Understanding why they differ by three orders of magnitude is the difference between a defensible exposure assessment and a number that collapses under the first question.
The two queries
On 20 September 2026, the following queries were executed against the ZoomEye AI cyberspace search service with sub_type=all:
| Query | Role | Count |
|---|---|---|
port="102" |
Service port | 161,907 |
device="plc" |
Device class | 95,749 |
app="Siemens S7" |
Product fingerprint | 173 |
All three returned successfully. The counts are exact totals at query time.
Why the spread exists
Each query answers a different question.
port="102" asks: what answers on TCP 102? Port 102 is the ISO-TSAP transport used by S7comm, but it is not exclusive to it. Other industrial protocols use it, and port-forwarding appliances can make an unrelated service appear on that port. The count is a lower bound on reachability, not a count of PLCs.
device="plc" asks: what does the dataset classify as a programmable logic controller? This is a device-class fingerprint, broader than any single vendor. It includes controllers from multiple manufacturers and excludes devices whose classification is uncertain.
app="Siemens S7" asks: what does the dataset positively identify as a Siemens S7 product? This is the narrowest query and the most conservative. It returns only assets where the fingerprinting evidence supported that specific identification.
The mistake to avoid
The tempting move is to select the largest number and describe it as the count of vulnerable devices. That inference fails on two grounds.
First, port reachability is not product identity. A host answering on port 102 may be a gateway, a different protocol, or a device that has since been reconfigured.
Second, product identity is not vulnerability. An asset matching app="Siemens S7" is a Siemens S7 device. Whether it runs a firmware revision affected by a specific advisory is a separate question that the fingerprint does not answer.
CISA advisory AA26-231A, published 20 August 2026 by CISA with NSA, FBI, DOE and EPA, describes threat actors exploiting internet-reachable Siemens S7 PLCs in water and wastewater environments. The advisory is about a deployment condition. Neither of the counts above measures that condition directly.
What each number is good for
The port count is a scoping input. It tells you how much of the internet answers on the transport that this protocol family uses. If you are building an inventory, a port-scoped query against your own address space is the right starting filter because it will not miss a device simply because a fingerprint failed.
The device-class count is a population estimate. It describes how large the observable PLC population is without committing to a vendor. Useful for arguing that this is a systemic class of exposure rather than one vendor's problem.
The product fingerprint is a confirmation tool. When you need to state that a specific asset is a specific product, this is the query whose result supports that statement. Its small size is a feature: it reflects evidence, not inference.
Building the assessment
A defensible exposure statement names the query, the scope and the time.
- Run the port-scoped query against your own CIDRs to enumerate reachable services.
- Reconcile each result against your asset register. Unmatched results are the finding.
- Where product identity matters, run the product fingerprint query and treat a match as evidence of product, not of vulnerability.
- Re-run after remediation and compare. A change you have not measured is a change you cannot report.
Why this matters for industrial exposure work
Industrial control exposure assessments have a credibility problem, and it comes from exactly this conflation. A headline that reports port counts as vulnerable-device counts is easy to produce and easy to discredit. The discrediting then extends to the underlying finding, which is real.
The underlying finding is straightforward: a large number of hosts answer on the transport used by an industrial protocol, and a smaller number are positively identified as a specific product line. Both facts are worth acting on. Neither is a vulnerability count.
Using ZoomEye for this
ZoomEye's value in this workflow is that it separates these questions into distinct queries with distinct, reproducible answers. The product fingerprint is deliberately conservative: it reports what the fingerprinting evidence supports. For an exposure assessment that has to survive review, a conservative confirmation query is more useful than an aggressive one, because it produces a claim you can defend.
The practical pattern is to use the broad query to find candidates in your own space and the narrow query to confirm identity, then to state clearly which one produced the number you are reporting.
References
- CISA, NSA, FBI, DOE, EPA, advisory AA26-231A, "Threat Actors Exploit Siemens S7 PLCs", published 20 August 2026. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-231a
- ZoomEye AI cyberspace search, queries executed 20 September 2026,
sub_type=all:port="102"= 161,907;device="plc"= 95,749;app="Siemens S7"= 173. Counts describe internet-observable matching assets at query time and do not confirm vulnerability or exploitation. - ZoomEye search: https://www.zoomeye.ai/
