Stealth is adversary behaviour designed to blend into normal activity and avoid detection. In ATT&CK v19, it separates concealment from direct control degradation, giving defenders a clearer way to test whether visibility controls can still identify suspicious behaviour without assuming the attacker is trying to break tooling.
Expanded Definition
Stealth describes adversary behaviour that deliberately imitates normal traffic, user actions, or system processes so security tooling and analysts do not flag it quickly. In a threat-modeling context, it is less about a single exploit and more about the attacker’s operating style: low-noise execution, patient lateral movement, and careful blending into expected baselines. That distinction matters because stealth can accompany credential theft, phishing, command-and-control, or post-compromise reconnaissance without being the payload itself. For ATT&CK-oriented defenders, the term helps separate concealment from direct disruption, which makes it easier to evaluate whether logging, detection engineering, and response playbooks can still surface suspicious activity. See MITRE ATT&CK for the wider adversary-behaviour context and NIST Cybersecurity Framework 2.0 for governance language around detection and response.
Definitions vary across vendors when stealth is discussed alongside evasion, persistence, or living-off-the-land activity, so it is best treated as a behaviour pattern rather than a fixed technique category. The most common misapplication is equating stealth with malware only, which occurs when defenders ignore legitimate administrative tools, cloud control-plane actions, or identity abuse that can look routine in logs.
Examples and Use Cases
Implementing detection for stealthy behaviour rigorously often introduces more telemetry, tuning, and analyst review, requiring organisations to weigh earlier threat visibility against alert fatigue and operational cost.
- An attacker uses a stolen privileged account to make small, spaced-out changes that resemble normal administration, reducing the chance of threshold-based alerts.
- Malicious activity runs through approved remote-management tools or scripting interfaces, making the event appear like routine support work unless correlated with identity and endpoint context.
- A threat actor pauses between reconnaissance actions so a single session does not stand out in ATT&CK-style behavioural analytics, forcing defenders to look for patterns over time.
- Cloud control-plane abuse is performed with valid API keys and ordinary request rates, which can bypass simplistic anomaly rules if entitlement and token provenance are not checked.
- In identity-heavy environments, stealth may appear as gradual privilege escalation or unusual access from a known account, making identity and access management guidance essential for reconstruction.
Why It Matters for Security Teams
Stealth is operationally important because it targets the gap between “activity that happened” and “activity that was noticed.” If security teams define success only as blocking known malware, they can miss adversaries who rely on valid credentials, normal tooling, and timing discipline to stay inside expected behaviour. That risk is especially relevant in identity-driven environments, where stolen accounts, over-privileged service identities, and weak session visibility let attackers look legitimate while they move laterally or stage data theft. For NHI and agentic AI environments, the same problem can emerge when autonomous software entities or AI governance-adjacent workflows generate actions that resemble trusted automation unless provenance and intent are logged carefully. The practical takeaway is that stealth forces defenders to test not just prevention, but observability, correlation, and response speed across identity, endpoint, and cloud layers.
Organisations typically encounter the cost of stealth only after a quiet intrusion is uncovered during incident response, at which point detection tuning, access review, and log reconstruction become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Defines continuous monitoring needed to surface stealthy activity. |
| MITRE ATLAS | Captures adversary behaviours that hide malicious activity in AI-adjacent contexts. | |
| NIST AI RMF | Supports governance for AI systems whose actions can be obscured or misattributed. | |
| NIST SP 800-63 | AAL2 | Identity assurance matters because stealth often exploits valid credentials. |
Use adversary-behaviour mapping to test whether hidden actions still surface in detections.
