AN1990: Analytic 1990
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
AN1990 is a detection analytic for PRE-platform activity where direct monitoring is expected to be difficult: the behavior may occur frequently, generate many false positives, and may happen outside the target organization’s visibility. For leaders, the decision value is recognizing that this is not a place to expect simple, high-confidence alerting; coverage should be assessed through adjacent lifecycle evidence, especially around Initial Access, rather than by assuming the activity itself is fully observable.
Executive priority
Treat this as a coverage and assurance question, not just an alerting rule. Security leaders should ask whether the organization can prove it has visibility into the stages that follow or surround this activity, particularly Initial Access, and whether SOC time is being protected from noisy detections. This matters for incident readiness, control prioritization, and audit discussions because sparse or external visibility can create false confidence if detection claims are not backed by collected telemetry and tested workflows.
Technical view
The supplied ATT&CK text does not provide a concrete detection procedure. SOC and detection engineering teams should validate whether this PRE-labeled analytic is expected to detect activity directly or only provide contextual leads. Because MITRE notes high occurrence, high false-positive potential, and possible activity outside organizational visibility, teams should tune around correlated evidence from related lifecycle stages, especially Initial Access, and document what cannot be observed from internal telemetry alone.
Likely telemetry
- Evidence from related Initial Access monitoring, where applicable
- Security alert and case-management records showing how noisy PRE-stage leads are triaged
- Threat intelligence or external visibility sources, if used and validated
- Network, identity, endpoint, email, or cloud access telemetry that supports investigation of adjacent lifecycle activity, where locally available
Detection direction
- Do not treat this analytic as a standalone high-confidence detection unless local testing proves it.
- Measure false-positive volume and analyst handling cost before promoting alerts to high severity.
- Correlate any PRE-stage signal with related Initial Access evidence rather than escalating on occurrence alone.
- Document visibility gaps where activity may occur outside the organization’s monitoring boundary.
- Use the official ATT&CK limitation as a tuning requirement: high-frequency events need context, suppression logic, or enrichment to avoid alert fatigue.
Mitigation priorities
- Prioritize visibility and response readiness for related lifecycle stages, especially Initial Access, where ATT&CK suggests detection may be more practical.
- Define what evidence the SOC must collect before declaring coverage for this analytic.
- Use risk-based triage so noisy PRE-stage indicators do not distract from stronger intrusion evidence.
- Review incident response playbooks for how externally observed or low-confidence leads are validated.
- Avoid compliance or executive reporting that implies guaranteed detection where the ATT&CK object provides no detection logic.
Analyst notes and limits
This object is a detection analytic, not a technique, and no tactics, relationships, aliases, or official detection steps were supplied. The main defensive value is the warning that the activity may be noisy, difficult to observe, and better handled through adjacent lifecycle detection.
The source fields are sparse. No relationship context, concrete data sources, detection logic, mitigations, or procedure examples were provided. Local environment telemetry, collection boundaries, and false-positive testing are required before making any coverage claim.
Analytic 1990
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 | 44bbe57091e2… |
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]
mitre-attack AN1990Open 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.