Methodology
How a host comes to be listed here, what the fields on a listing mean and do not mean, how a listing ages and how it is withdrawn, and where the method is known to have gone wrong. It is written for the analysts who use the feed and for anyone who finds an address they are responsible for in it.
Effective 27 September 2026 · Public Mosaic LLC
What a listing is
Every listing comes from Public Mosaic's Hollowpoint scanner, which connects to hosts on the public internet and records what they send back. A listing is one address and port: a statement that, at the times recorded on the listing, the scanner either observed characteristics there that identify known software — a command-and-control framework, a remote-access tool, a tunnelling tool or a botnet, among others — or found that address named as a command-and-control host in a configuration it recovered itself, and got an answer there.
It is an observation, not an allegation about a person. It does not say who owns the address, who rents it, or who is responsible for what runs on it — a large share of this infrastructure runs on rented or compromised machines whose owners had no part in it.
How a listing is established
Only by the scanner's own observation of the host. A listing needs a determinative match — evidence that identifies the software by value rather than by resemblance — on a publicly routable address. The kinds of evidence that can establish one:
- TLS certificates and their structure. The distinguished-name fields a framework writes into the certificates it generates, and the JA4X fingerprint of how a certificate was built — which fields and extensions it carries, and in which order — rather than what they say.
- Protocol handshakes and banners. What a service sends when spoken to in its own protocol: a greeting, a banner, or a reply that only that software gives — and, over HTTP, the default pages, headers and paths a framework serves.
- Stager fetches. For Cobalt Strike, the scanner requests the first-stage payload a listener hands to an implant and reads the configuration out of it: the watermark, the callback hosts, the request profile.
- Recovered configurations. Settings the scanner recovered from samples it captured and analysed itself — the command-and-control hosts a sample is built to call back to, its ports and keys. An address can be listed when such a configuration names it as a command-and-control host and the address answers on that port. A host page says whether a configuration names that address as its command-and-control host, or came from a sample the address served that points somewhere else.
- Served files and samples. Files a host serves are captured and identified by their SHA-256, and a file matching a signature for known malicious software counts as evidence. Some samples are run in a sandbox the scanner's operators run; others are analysed statically, without being run, and each sample page says which. A sandbox run establishes a family only when it extracts the sample's configuration; a sandbox verdict on its own does not.
What does not establish a listing:
- TLS server fingerprints (JARM, JA4S). Unrelated servers share them, so they can support an identification but never make one.
- Somebody else's report. Another publisher's indicator feed, a reputation list or a search index can prompt a scan (see where the scanner looks). It cannot establish a listing: the publication rules withhold any listing that rests on a third-party claim alone.
- A score below the floor. The scanner scores every identification; the lower-confidence candidate tier is never published, and nothing below confidence 90 is.
- An address that is not publicly routable. Private, loopback and other non-routable addresses are refused before publication.
Where the scanner looks
The scanner does not probe every address continuously, so something decides where it looks: sweeps of network ranges it chooses to watch — including ranges on public blocklists of abused hosting networks — searches it designs itself, pivots from what it has already observed, and outside sources such as internet search engines, other publishers' reports and public malware-sample repositories. Those sources only put an address in front of the scanner.
Third-party indicator feeds. On 27 September 2026 Public Mosaic decided that the scanner will no longer use third-party indicator feeds to choose which addresses to probe. Until then, an address could reach the scanner because one of those feeds named it. The change is being made in the scanner, and this page will give the time it took effect once it has. A listing first recorded before then may have reached the scanner through one of those feeds, and so may a listing first recorded shortly after, from a scan already under way when the change took effect.
The change is to which hosts are examined, not to what it takes to list one. Whatever prompted a scan, a listing needs the scanner's own observation, as set out above: a third party's report can never establish one.
What the fields mean, and what they do not
- Family. The software the evidence identifies. Not the operator, not a campaign, and not the owner of the machine.
- Confidence. The scanner's own score, 0 to 100, for how strongly the evidence supports the identification; nothing below 90 is published. It can include context about the network the host sits on — a network on a public blocklist of abused hosting, for example — but that context never establishes a listing by itself. It is not a probability, and it says nothing about who operates the host, whether it is still running, or how much harm it does.
- First seen and last seen. The first and the most recent time the scanner confirmed the listener. "Last seen" is the last confirmation, not the last time anyone looked.
- Live and archived. A listing is live while the feed carries it, which it does for up to 90 days after its last confirmation. Being in the feed means exactly that and no more: it does not mean the host answered recently, and for a large share of listings the two differ. A listing the feed no longer carries is archived.
- Liveness. On the live table only, the result of the most recent re-probe after the last confirmation: live (it answered again), silent (it was probed and nothing answered — it stays in the feed, because silence at one moment is not proof the service has gone), unchecked (not re-probed since it was last seen) or indeterminate (the re-probe could not reach a conclusion either way). It goes stale within hours, so it is shown on the live table and never stored in the archive or printed on a host page.
- Observed host. A name seen on a host, usually in its certificate, is shown as an attribute of the address, captioned and dimmed. It is often a real site the operator chose to impersonate, and it is not evidence that the host belongs to that name. A name is the subject of a listing only when it is independently corroborated.
- Payload hash. The SHA-256 of a file a host served when scanned. It is marked as a confirmed executable only when the file began with executable magic bytes; otherwise it is marked unverified, because an operator-set content type claimed a download and nothing more. No page here calls a payload hash malware.
Dual-use tools and infected devices
Some listed software is not malware. Tunnelling tools such as Chisel and Ligolo-ng are used by penetration testers and administrators as well as by intruders. Identifying one establishes which software is listening, not who runs it or why, and the Chisel and Ligolo-ng family pages frame those hosts as exposed tools rather than as controllers. Since 25 September 2026 for Chisel and 26 September 2026 for Ligolo-ng, the tool's handshake on its own no longer produces a listing; such a host is listed only where separate evidence identifies command-and-control software on it.
Many botnet hosts are infected devices. Mozi is a peer-to-peer botnet, so the scanner treats every Mozi node it lists as an infected device — a router, camera or similar device that somebody else compromised — not a machine run by an attacker, and marks it as a compromised device; host pages show that role wherever the scanner recorded it. That describes the machine, never its owner. Listings of other botnets can instead be the botnet's own control servers. A host observed serving malware samples is described as a malware distribution host, which is also a statement about the machine and not about who is responsible for it.
Lifecycle: live, archived, never purged
The live feed is a window, not a history: a listing leaves it no later than 90 days after its last confirmation, and sooner if it is withdrawn. This site keeps its own archive of the listings the feed carries, so an address keeps its page after it leaves the feed, marked archived, with the day it was last confirmed. The archive records that last confirmation and cannot say what happened after it; a host may return, and when it does the archive records it.
The archive is never purged, because it is the only record that an address was ever listed. Withdrawal is not deletion either: a withdrawn listing stays in the archive, flagged, and is no longer published on any page built from it.
How a listing is withdrawn
Three instruments, which are deliberately kept separate:
- Abuse & takedown. Anyone responsible for an address can ask, and no proof of control is needed. It withdraws what was already published about that address; a fresh detection there later is listed again. See abuse & takedown.
- Verified opt-out. A network operator who shows control of a range can have it excluded: the scanner stops probing it, and listings on it are withdrawn now and in future. See opt-out.
- Retraction by the scanner. When the scanner's operators establish that a detection's evidence does not support the listings it produced — because the detection matched software other than the one it named, or because it identified the software correctly but that identification is not evidence of malicious use — they withdraw it and the feed stops carrying what it produced. This archive then records the retraction against each listing that detection produced, under the family label withdrawn, once the scanner's operators have said which listings those were; so far that has taken from a day or two to several weeks, and until then those listings are still published here as archived. A retraction covers those listings only: a later, independent detection of the same address, or a listing of another family on it, still publishes, and if the scanner publishes a withdrawn listing again the retraction lapses. Retractions are counted, without addresses, on corrections.
Once an instrument is recorded here, the withdrawn listing disappears within minutes from every page this site builds from its archive — host pages, family pages, directories, sitemaps, detection packs and the keyed API — and the live feed drops it at its next export, if it has not already. An address with nothing left to publish answers 410 Gone, with a page that says the listing was withdrawn and does not repeat what it said. An address with other listings that still stand keeps its page, without the withdrawn one. The feed is TLP:CLEAR, so copies others took before the withdrawal cannot be recalled; we will confirm a withdrawal in writing for anyone who needs to show it to a downstream consumer.
Detections withdrawn so far
Described by class, not by address: a withdrawn listing is not republished here, even as an example. The list is not exhaustive — it covers the classes large enough or instructive enough to describe, and the scanner has found and withdrawn others. A class marked not yet recorded here was withdrawn by the scanner, but this archive has not yet received the list of listings it covered, so those listings are still published here as archived until it does. The withdrawals recorded so far are counted on corrections.
The detection matched other software.
- A probe that could not tell an echo from an answer. A NanoCore probe accepted a reply that simply repeated its own request, so tarpits and proxies — services that echo back whatever they are sent — were listed as NanoCore controllers. On 31 August 2026 the scanner withdrew every listing that probe had produced and replaced it with one that controls for echoes. An August Chisel probe had the same flaw — it accepted its own request header handed back — and was withdrawn the same day.
- An embedded tunnel server. Portainer, a container-management product, builds the open-source Chisel tunnel server into its management server as the endpoint its Edge agents connect to (port 8000), so an ordinary Portainer installation answered a Chisel probe exactly as a Chisel server would, and was listed as one between 2 and 25 September 2026. The scanner now recognises Portainer, and builds of the tool that carry no release version, and records them instead of listing them.
- A message framing shared with other software. A Quasar probe keyed on how a service frames its messages also matched other software that frames them the same way — MQTT brokers, BGP routers, Cobalt Strike team servers and other TLS services. On 25 September 2026 the scanner began requiring Quasar's own certificate before that behaviour could produce a listing, and withdrew about 370 identifications that rested on the framing alone. Not yet recorded here.
- A certificate layout shared with private certificate authorities. A structural certificate signature for Sliver — the layout of a certificate and the fact that it does not chain to a public authority, rather than any name in it — also fitted certificates issued by the private authorities that ordinary software runs: developer certificate tools, Elasticsearch deployments, and the Kubernetes distributions k3s and RKE2, all built with the same standard Go library. From late August 2026 it listed such hosts as Sliver. The signature was tightened on 27 August and again on 31 August 2026, and most of those listings left the feed. At least one Kubernetes API server whose certificate still fits the tightened signature was reported to the scanner's operators on 25 September 2026 and is under review. Not yet recorded here.
- Two smaller August classes. An Adaptix page signature that also matched the ordinary template page Adaptix's own page was built from, and a Brute Ratel signature that rested on a generic error page. Each produced two listings, and both were withdrawn on 31 August 2026. Not yet recorded here.
The software was identified, but that is not evidence of malicious use.
- A handshake that proves the tool, not the intent. Ligolo-ng, an open-source tunnelling tool widely used in penetration testing, greets a client in a way that identifies it. That establishes which software is listening and nothing about who runs it or why; listings resting on that greeting alone included a penetration-testing firm's relays and a home laboratory. The scanner withdrew them on 26 September 2026. Withdrawing them is not a finding that every such host was benign: it means the greeting alone does not show misuse.
- A banner that names the tool. Chisel's banner likewise identifies the tool and nothing more. Since 25 September 2026 it no longer produces a listing on its own, and the Chisel listings that rested on it alone were withdrawn on that basis.
What the scanner does not see
- IPv4 and TCP only. The archive holds IPv4 addresses and the feed lists TCP listeners. IPv6 hosts and UDP services are outside it.
- Addresses, not names. A listing is an address and port the scanner connected to. Infrastructure reached only by name, or hidden behind a proxy or content-delivery network the scanner cannot see past, is not listed as itself.
- Only what it looks for, where it looks. The scanner identifies the families it has signatures and probes for, in the places its discovery takes it. An address with no page here has no listing; that is not evidence that it is clean, or that the scanner has ever looked at it.
- A point in time. A listing records what a host returned when it was scanned. Hosts change hands, get cleaned up and get reused, which is why a listing carries its dates and why it expires.
Disputing a listing
If an address you are responsible for is listed and should not be, write to us — see abuse & takedown. No proof of control is needed; we re-examine the host and the evidence the listing rested on, and if we do not withdraw it we will say why in terms specific enough to argue with. If the dispute shows that a detection's evidence does not support the listings it produced, withdrawing it withdraws every listing it produced, and the withdrawal is counted on corrections. To exclude a whole range rather than contest one listing, see opt-out.
Related
The live listings are at /indicators, every archived address at /ip and every family at /c2. What this site records about you when you read it — a separate matter from the listings, and never joined to them — is set out in privacy.