AN0216: Analytic 0216
Detection of anomalous RDP or remote service session activity where a logon session is hijacked rather than newly created. Indicators include mismatched user credentials vs. active session tokens, service session takeovers without corresponding successful logon events, or RDP shadowing activity without user consent.
Analyst context for executives and security teams
AN0216 is a Windows-focused detection analytic for suspicious RDP or remote service activity where an existing logon session appears to be taken over instead of a new logon being created. For leaders, the practical issue is accountability and incident confidence: if an attacker can operate inside an already-active session, normal “successful logon” reporting may not tell the full story.
Executive priority
Prioritize this where Windows remote administration, RDP, or remote services are important to operations. The business question is whether the organization can prove who controlled a privileged or sensitive session at the time of an incident. This analytic supports SOC and incident response readiness by highlighting gaps between session activity, user identity, and logon evidence—areas that often matter for audit trails, containment decisions, and executive confidence during investigations.
Technical view
Validate whether Windows telemetry can correlate active sessions, logon events, session tokens, service sessions, and RDP shadowing activity. The supplied ATT&CK description points to three detection themes: user credential context not matching active session tokens, service session takeover without a corresponding successful logon event, and RDP shadowing without user consent. Because no official detection logic is provided, teams should treat this as a detection engineering requirement rather than a ready-to-deploy rule.
Likely telemetry
- Windows logon and session events
- RDP session activity and remote service session records
- Evidence of active user/session tokens and credential context
- Events or logs indicating RDP shadowing activity
- Service control or remote administration activity related to session use
Detection direction
- Confirm that successful logon events are not the only source used to assess remote session control.
- Correlate remote service or RDP activity with session creation, active session state, and user/token context.
- Look for activity in an existing session without a matching new successful logon event, while tuning for legitimate administrative tooling and support workflows.
- Review whether RDP shadowing can be observed and whether consent-related indicators are logged in the environment.
- Document blind spots where session token context, RDP shadowing, or service session state is not collected or retained.
Mitigation priorities
- Limit and govern RDP and remote service access according to operational need.
- Require strong identity controls for remote administration, especially for privileged users.
- Harden administrative workflows so legitimate remote support and shadowing are approved, logged, and reviewable.
- Ensure endpoint and Windows logging retention supports post-incident reconstruction of session ownership.
- Use incident response playbooks that verify active session control, not only logon success history.
Analyst notes and limits
This object is a detection analytic, not a technique description. It is most useful as a prompt to test whether SOC and IR teams can distinguish new logons from hijacked or taken-over sessions on Windows systems. The absence of relationships and tactic mapping means local threat modeling is required to connect it to specific scenarios.
The official detection field is not provided, and no relationships, tactic mappings, aliases, or labels were supplied. This take does not assert active exploitation, actor use, or coverage. Implementation details depend on the organization’s Windows logging, RDP configuration, endpoint telemetry, and remote administration practices.
Analytic 0216
Detection of anomalous RDP or remote service session activity where a logon session is hijacked rather than newly created. Indicators include mismatched user credentials vs. active session tokens, service session takeovers without corresponding successful logon events, or RDP shadowing activity without user consent.
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 | 0a0680945689… |
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 AN0216Open 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.