DEV Community

yutianle
yutianle

Posted on

A Repeatable Method for Measuring APT Infrastructure Exposure

#silentlynx #uat6275 #zoomeye #threatintelligence

A Repeatable Method for Measuring APT Infrastructure Exposure

An infrastructure query becomes useful when another analyst can reproduce it. The Cisco Talos research on UAT-6275 provides a concrete test case because it includes a narrative report, a Virus Bulletin paper, an IOC repository, and several kinds of infrastructure. A good measurement method should make each query answer a defined question without collapsing different evidence types into one number.

The method below starts with the source report, records exact controls, and adds broader context only when it supports the argument. It does not require a large query set. It requires discipline about what each result means.

Define the observation before the query

Write the claim the query is meant to support. For example: "The published IOC address is still visible in public scan data." The corresponding query is an exact IP search. If the claim is "FortiWeb has a substantial internet-facing population," the query is a product fingerprint, not an exact IOC address.

This step prevents count laundering. A broad product count cannot substitute for an exact IOC result. A domain count cannot prove that every subdomain is malicious. A CVE index count cannot measure installed desktop software.

The current run used five distinct observations. app="FortiWeb" returned 1,755 all-scope assets at 2026-11-08T14:41:21Z. The exact controls ip="104.248.17.222" and ip="154.205.145.179" returned 12 and 8 observations at 14:42:06Z and 14:42:09Z. domain="securitytactics.com" returned 56 at 14:42:12Z. vul.cve="CVE-2025-8088" returned 0 at 14:42:15Z.

Each result is a successful observation with a different scope and meaning. The FortiWeb count describes product visibility. The exact IP and domain counts describe observations connected to published infrastructure patterns. The CVE zero shows that the index did not return an internet-facing asset for a client-side flaw. None of the counts establishes a victim.

Record the minimum evidence set

Every query record should include the exact dork, scope, timestamp, status, count, source report, and the claim it supports. It should also include a note about what the result does not establish. This last field is easy to omit and difficult to reconstruct later.

Store the raw response outside the article workflow if the platform permits it. At minimum, preserve the query result ID and the returned count. If a query fails, keep the error. Do not replace a failed request with zero, and do not rerun until the result becomes more convenient.

The source report needs its own date and coverage. Talos described activity observed from June 2025 through August 2026. The scan observations were made in November 2026. The gap matters. A visible address in November may be the same system, a reassigned address, or a stale record. The report should show the gap rather than imply continuous control.

Compare like with like

Use the same scope when comparing two counts. An all-scope query can include services that a web-only query excludes. A historical result can use a different index or matching rule. If the scope changes, label the comparison as qualitative rather than presenting a percentage change.

Separate exact indicators from product populations in tables and prose. A row for FortiWeb exposure should not sit beside a row for one attacker address as though the two numbers describe the same population. Group them by question: incident infrastructure, product exposure, vulnerable desktop software, and local telemetry.

The most defensible finding often combines a public observation with an independent source. A ZoomEye result can show a FortiWeb fingerprint. The CVE record defines the affected versions. The asset owner supplies the installed version. Those three sources answer different parts of the exposure question.

Build a review checkpoint

Before publishing or briefing the result, ask four reviewers to check different properties. One checks the source facts and dates. One checks the query syntax and scope. One checks the interpretation of counts and uncertainty. One checks the writing for a claim that goes beyond the evidence.

For a small team, the same person can perform several checks, but the checks should still be explicit. Record the reviewer identity, the source links, the query evidence, and any correction. A short note about a limitation is more valuable than a polished paragraph that hides it.

The final output should let a reader answer three questions. What was measured? When was it measured? What decision can the result support? If the answer to the third question is "nothing until we check our own telemetry," say that plainly. A well-scoped negative result is still a useful result.

References

Top comments (0)