Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1991: Analytic 1991

Once adversaries leverage compromised network devices as infrastructure (ex: for command and control), it may be possible to look for unique characteristics associated with adversary software, if known.[1] Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related stages of the adversary lifecycle.

EnterpriseAN1991AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic matters because it addresses adversary use of compromised network devices as external infrastructure, such as for command and control. For most organizations, the key issue is visibility: much of the activity can occur outside the target’s own environment, so internal logs alone may not prove whether this infrastructure is being used. Leaders should treat this as a prompt to validate threat intelligence, external infrastructure monitoring, and incident-response handoffs rather than as a simple endpoint or network alerting problem.

Executive priority

Prioritize this where resilience depends on early warning about adversary infrastructure and where incident decisions require evidence beyond internal telemetry. Executives should ask whether the organization can consume and action infrastructure intelligence, correlate it to related adversary lifecycle stages, and document decisions for response and compliance when direct visibility is limited.

Technical view

The object is a detection analytic in the PRE platform context with no ATT&CK tactic or formal detection logic supplied. SOC and threat intelligence teams should validate whether they can identify unique characteristics of adversary software on compromised network-device infrastructure when such characteristics are known, and then connect that intelligence to observable activity in related lifecycle stages. Because the official description states that much of the behavior may occur outside the target organization’s visibility, teams should avoid assuming internal telemetry alone is sufficient.

Likely telemetry

  • Threat intelligence reporting on adversary infrastructure characteristics
  • External infrastructure research or hunting outputs
  • Network security telemetry that can be correlated to known or suspected command-and-control infrastructure
  • DNS, proxy, firewall, or other egress records where available for related lifecycle activity
  • Incident response case notes linking external infrastructure findings to internal observations

Detection direction

  • Validate whether the SOC has a process to ingest, assess, and operationalize infrastructure intelligence rather than relying only on internal alerts.
  • Tune detections around related lifecycle activity that may be visible internally, since the described infrastructure behavior may occur outside organizational visibility.
  • Use known unique characteristics of adversary software only when supported by credible intelligence; avoid broad assumptions that create noisy or misleading detections.
  • Confirm analysts understand the blind spot: absence of internal evidence does not necessarily disprove adversary use of compromised external network devices.

Mitigation priorities

  • Establish ownership for external infrastructure intelligence review and escalation.
  • Ensure internal telemetry such as network egress, DNS, proxy, and firewall records can be correlated with intelligence about suspicious infrastructure when available.
  • Document incident response procedures for cases where evidence comes from external research rather than direct internal observation.
  • Use findings from related lifecycle stages to prioritize containment, monitoring, and executive reporting decisions.
Analyst notes and limits

ATT&CK provides a high-level analytic description but no official detection logic, no tactics, no relationships, and only the PRE platform context. The supplied reference points to infrastructure research and hunting, so the most defensible use is as guidance for threat intelligence-led detection and lifecycle correlation.

This take is limited to the supplied ATT&CK fields and references. It does not establish active exploitation, attribution, specific adversary tools, affected customers, or guaranteed detection coverage. Local telemetry, intelligence quality, and response processes determine practical value.

Official MITRE ATT&CK definition

Analytic 1991

Once adversaries leverage compromised network devices as infrastructure (ex: for command and control), it may be possible to look for unique characteristics associated with adversary software, if known.[1] Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related stages of the adversary lifecycle.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
fa0539cae9ee4682...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle fa0539cae9ee…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [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. [2]
    mitre-attack AN1991
    Open source URL
Source and licensing

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.