AN2020: Analytic 2020
Internet scanners may be used to look for patterns associated with malicious content designed to collect host software information from visitors.[1][2] Much of this activity may have a very high occurrence and associated false positive rate, as well as potentially taking place outside the visibility of the target organization, making detection difficult for defenders. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Initial Access.
Analyst context for executives and security teams
This analytic is about the difficulty of detecting broad Internet scanning for web content that may collect visitor host/software details, such as reconnaissance associated with watering-hole style activity. For leaders, the key point is not that every scan is a crisis; it is that much of this behavior is noisy, common, and may occur outside the organization’s direct visibility, so teams should not rely on this signal alone to prove risk or coverage.
Executive priority
Treat this as a coverage and decision-making issue rather than a standalone alerting priority. Security leaders should ask whether the organization can recognize relevant precursor activity, preserve evidence around externally facing web properties, and connect weak reconnaissance signals to later Initial Access investigations. This matters for incident readiness, threat intelligence triage, and audit evidence showing that the organization understands where detection is limited by Internet-scale noise and third-party visibility gaps.
Technical view
The supplied ATT&CK object provides no formal detection logic and lists the platform as PRE. SOC and detection teams should validate whether they collect evidence from public-facing infrastructure, web server logs, content delivery or hosting providers, DNS/domain intelligence, and threat intelligence sources that could show scanning or access patterns associated with suspicious content discovery. Because ATT&CK notes high false-positive rates and activity occurring outside target visibility, detections should be treated as enrichment or hunt context, not as high-confidence standalone findings. Relationship context is not supplied, so defenders should connect any findings to locally observed Initial Access indicators or incidents before escalating severity.
Likely telemetry
- Web server and reverse proxy access logs for public-facing sites
- CDN, WAF, or hosting-provider request logs where available
- DNS and domain intelligence related to infrastructure research
- Threat intelligence reports or scanner observations tied to suspicious web content patterns
- Incident timelines that connect reconnaissance-like activity to later Initial Access evidence
Detection direction
- Validate whether public-facing web telemetry is actually retained and searchable; the analytic may be ineffective if scanning happens outside organizational visibility.
- Tune for context rather than volume: Internet scanner traffic is common and likely to generate substantial false positives.
- Use this signal to enrich hunts around suspected watering-hole or Initial Access activity instead of treating scanner hits as proof of compromise.
- Document gaps where third-party hosting, CDN, or external infrastructure monitoring limits visibility.
- Correlate with changes to externally hosted content, suspicious visitor profiling behavior, or later access attempts when local evidence supports it.
Mitigation priorities
- Prioritize visibility for externally facing web assets, including logs from hosting, CDN, WAF, and reverse proxy layers where applicable.
- Maintain an accurate inventory of public web properties so scanning and suspicious content observations can be mapped to owned assets.
- Use threat intelligence to contextualize Internet-scale scanning, while avoiding over-response to generic scanner noise.
- Ensure incident response playbooks include evidence collection for public web infrastructure and linkage to possible Initial Access activity.
- Record known detection limitations for compliance and risk reporting, especially where activity may occur outside direct organizational telemetry.
Analyst notes and limits
The official object is a detection analytic, not a technique, and no ATT&CK relationships or detection procedure are supplied. The most defensible use is as a reminder that reconnaissance-related scanner observations can be noisy but still useful when correlated with public web exposure and later intrusion evidence.
ATT&CK provides no formal detection logic, no tactics, no relationships, and only the PRE platform. The object explicitly warns of high occurrence, high false positives, and visibility gaps. Local telemetry, asset ownership, and incident context are required before drawing conclusions.
Analytic 2020
Internet scanners may be used to look for patterns associated with malicious content designed to collect host software information from visitors.[1][2] Much of this activity may have a very high occurrence and associated false positive rate, as well as potentially taking place outside the visibility of the target organization, making detection difficult for defenders. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Initial Access.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 7b5a63c2ec1c… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
ThreatConnect Infrastructure Dec 2020
ThreatConnect. (2020, December 15). Infrastructure Research and Hunting: Boiling the Domain Ocean. Retrieved October 12, 2021.
Open source URL -
[2]
ATT ScanBox
Blasco, J. (2014, August 28). Scanbox: A Reconnaissance Framework Used with Watering Hole Attacks. Retrieved October 19, 2020.
Open source URL -
[3]
mitre-attack AN2020Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.