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

TA0005: Stealth

The adversary is trying to hide and conceal their actions, appearing as normal behavior.

Stealth consists of techniques that reduce the likelihood of detection by blending in with legitimate activity or minimizing observable signals. These techniques are characterized by concealment behaviors, such as avoiding, obfuscating, or mimicking normal operations, without modifying security controls or compromising collection and monitoring feeds. The goal is to remain indistinguishable from benign activity while leaving defensive systems intact.

EnterpriseTA0005TacticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Stealth matters because it describes adversary behavior designed to make malicious activity look normal while leaving security tools and monitoring feeds intact. For leaders, the practical issue is not whether controls exist, but whether the organization can distinguish legitimate operations from activity that is intentionally low-noise, obfuscated, or blended into expected behavior.

Executive priority

Treat Stealth as a resilience and assurance problem: SOC performance, incident response confidence, audit evidence, and risk decisions depend on whether teams can prove they collect and review the right signals, not just deploy tools. Leaders should ask where the business relies on “normal behavior” assumptions, how exceptions are investigated, and whether detection engineering has enough baseline telemetry to identify concealment without excessive false positives.

Technical view

ATT&CK provides this as an enterprise tactic, not a specific technique, platform, or detection rule. SOC and IR teams should use it as a validation lens across relevant ATT&CK techniques in their environment: confirm that normal activity baselines exist, that low-signal behavior is retained long enough for investigation, and that detection logic does not depend only on obvious tool tampering or broken logging. Because no relationships or technique mappings were supplied here, local control mapping is required before assigning coverage.

Likely telemetry

  • Baseline activity records for users, systems, applications, and services where available
  • Authentication and access activity that can show behavior blending into normal use
  • Process, command, and administrative activity logs where collected
  • Network and service activity records that support normal-versus-unusual comparisons
  • Security alert, audit, and case-management evidence showing how low-confidence anomalies are triaged

Detection direction

  • Validate that monitoring can identify suspicious activity even when security controls and logging remain functional.
  • Tune detections around deviations from established normal behavior, while accounting for business processes that legitimately create unusual activity.
  • Review false-positive handling: stealthy behavior may resemble administrative or automated activity, so suppressions and allowlists should be justified and periodically reviewed.
  • Use this tactic to test detection assumptions across related techniques in the local ATT&CK coverage map; no relationship context was supplied in the object itself.
  • Confirm incident responders can reconstruct activity from retained telemetry when adversary behavior is designed to minimize observable signals.

Mitigation priorities

  • Prioritize telemetry completeness and retention before claiming coverage for stealth-oriented behavior.
  • Establish and maintain baselines for normal administrative, user, application, and service activity.
  • Govern exceptions, allowlists, and suppression rules so they do not become blind spots for behavior that mimics legitimate operations.
  • Exercise SOC and IR workflows against low-noise scenarios to validate escalation criteria and evidence quality.
  • Map specific controls and detections to the relevant ATT&CK techniques in the local environment, since this tactic object does not provide platform-specific mitigations.
Analyst notes and limits

This object is a tactic-level ATT&CK entry for Stealth in the enterprise domain. Its value is as a strategic organizing concept for detection and response readiness: it highlights the need to find malicious behavior that blends in, rather than relying only on obvious control failure or noisy indicators.

The supplied ATT&CK fields do not include official detection guidance, platforms, tactics relationships, procedures, mitigations, or linked techniques. This take therefore avoids platform-specific claims and requires local environment telemetry, ATT&CK technique mapping, and control evidence to determine actual coverage.

Official MITRE ATT&CK definition

Stealth

The adversary is trying to hide and conceal their actions, appearing as normal behavior.

Stealth consists of techniques that reduce the likelihood of detection by blending in with legitimate activity or minimizing observable signals. These techniques are characterized by concealment behaviors, such as avoiding, obfuscating, or mimicking normal operations, without modifying security controls or compromising collection and monitoring feeds. The goal is to remain indistinguishable from benign activity while leaving defensive systems intact.

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
a6ce544a6636054d...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle a6ce544a6636…
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]
    mitre-attack TA0005
    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.