The Teams helpdesk campaign is a social-engineering intrusion, so no public scan can identify every affected organization. A measurement program is still useful if it answers a narrow question: what public assets match the infrastructure and tooling discussed in the event? The answer can trigger ownership review, configuration checks and monitoring, but it cannot replace tenant and endpoint evidence.
On 2026-11-13, ZoomEye returned 221 all-scope observations for domain="onmicrosoft.com", 460 for app="AnyDesk" and 12,781 for app="TeamViewer".
Onmicrosoft search: https://www.zoomeye.ai/searchResult?q=ZG9tYWluPSJvbm1pY3Jvc29mdC5jb20i
AnyDesk search: https://www.zoomeye.ai/searchResult?q=YXBwPSJBbnlEZXNrIg%3D%3D
TeamViewer search: https://www.zoomeye.ai/searchResult?q=YXBwPSJUZWFtVmlld2VyIg%3D%3D
The figures are time-bounded observations. They do not say that any asset is a malicious tenant, a campaign victim or an unauthorized RMM installation. They provide a repeatable population for a review.
Build an evidence ladder
Start with an observation: a query returned a count at a specific time and scope. Next comes inventory: an owner confirms that an asset belongs to the organization or is intentionally public. Configuration evidence follows: the tenant policy, remote-tool allowlist or endpoint record explains the state. Incident evidence is separate: audit logs, process execution or network telemetry show malicious activity. Only the last layer supports a compromise claim.
An evidence ladder prevents a common error in exposure reporting. A product fingerprint is not a vulnerability. A domain observation is not a tenant inventory. A large count is not a victim count. Each layer answers a different question and has a different owner.
Choose queries that match the argument
The onmicrosoft query is relevant because the event report names attacker-chosen fallback tenants. The AnyDesk and TeamViewer queries are relevant because remote-support tools appear in the observed chain. Neither query measures the Teams external-access setting. That configuration must be reviewed inside the tenant or endpoint management system.
Record every query, scope, timestamp, status and result ID. Keep failed probes as errors rather than zero. During this review, a probe for app="Microsoft Teams" failed with ZOOMEYE_ERROR; it was not used to support the article or the flash. A zero from an unrelated query is also not evidence that the campaign is absent.
Compare snapshots over time
Run the same query on a schedule, but do not treat a change in count as an incident by itself. Indexing coverage, asset changes and service ownership can move a number. Pair the snapshot with asset inventory and change records. Investigate a newly observed domain that resembles the reported infrastructure, a remote-support product appearing where no approved tool exists, or an unexplained jump in public assets under a sensitive namespace.
For the exact tenants named in the report, a union query returned zero during this test. That result does not clear the domains. The public index may not contain them, and malicious tenant resources may not expose a web service. The correct conclusion is that the tested public query found no observation, not that the domain never existed.
Turn observations into action
Send domain observations to the team that owns external collaboration and domain blocking. Send RMM observations to endpoint and application owners. Send tenant identity questions to the identity team. Give each team a deadline and a field for evidence, not only a count.
If an observation is unexplained, inspect it through approved systems and preserve the result. If the asset is legitimate, record the owner and expected exposure. If the asset is unrelated, close the lead with a reason. If a malicious pattern is confirmed, move to the incident-response path and stop treating the finding as a public-scan exercise.
ZoomEye is most useful here as a stable external sensor for a changing attack surface. It helps defenders ask better questions about the public footprint around onmicrosoft domains and remote-support products. It cannot verify the social-engineering decision that gave an attacker access, and it should never be presented as if it can.