AN0723: Analytic 0723
Forged web credentials in Office Suite contexts may appear as abnormal authentication headers in Outlook or Teams traffic, or unexplained OAuth grants in M365/Azure logs. Defenders should correlate token usage events with missing authentication flows and mismatched device/user context.
Analyst context for executives and security teams
This analytic matters because forged web credentials in Office Suite environments can let activity appear inside normal Outlook or Teams traffic without a clean, expected sign-in trail. For leaders, the practical issue is whether Microsoft 365/Azure identity telemetry is sufficient to prove that token use, OAuth grants, device context, and user context line up during an incident or audit.
Executive priority
Prioritize this as an identity and cloud visibility validation item for M365-dependent organizations. The business question is not simply whether authentication logs exist, but whether security teams can correlate Office Suite traffic, OAuth grant activity, token usage, and device/user context quickly enough to support containment decisions, compliance evidence, and incident response scoping.
Technical view
For SOC, detection engineering, and IR teams, validate correlation around abnormal authentication headers in Outlook or Teams traffic and unexplained OAuth grants in M365/Azure logs. Investigations should compare token usage events against expected authentication flows and confirm whether device, user, and session context match. Because no ATT&CK detection logic or relationships were supplied, teams should treat this as a detection strategy to operationalize locally rather than a complete rule.
Likely telemetry
- Outlook and Teams traffic metadata, including authentication-related headers where available
- M365/Azure sign-in and authentication logs
- OAuth grant and consent activity logs
- Token usage or session activity events
- Device identity, user identity, and session context records
Detection direction
- Validate that token usage can be correlated to an expected authentication flow rather than reviewed as isolated events.
- Alert or hunt for unexplained OAuth grants in M365/Azure logs, with tuning for legitimate administrative and application consent activity.
- Review Outlook or Teams traffic for abnormal authentication header patterns where such telemetry is collected.
- Compare user, device, and session context for mismatches that may indicate forged or misused web credentials.
- Document blind spots where Office Suite traffic headers, OAuth events, or token/session telemetry are not retained or are not joined in the SIEM.
Mitigation priorities
- Ensure M365/Azure identity, OAuth grant, token/session, and Office Suite activity logs are enabled, retained, and accessible to SOC and IR teams.
- Review OAuth consent and grant governance so unusual or unexplained grants can be triaged quickly.
- Strengthen identity investigation playbooks around token usage, device context, and missing authentication flows.
- Use this analytic to test whether managed detection or internal SOC workflows can reconstruct Office Suite identity activity end to end.
- Preserve evidence needed for compliance and incident response, including sign-in records, grant history, and session context.
Analyst notes and limits
The supplied object is an ATT&CK detection analytic for Office Suite contexts, focused on forged web credentials that may appear through abnormal Outlook or Teams authentication headers or unexplained OAuth grants in M365/Azure logs. There are no supplied relationships, tactics, or official detection implementation details, so this take focuses on defensive validation and telemetry readiness.
No official detection logic, tactic mapping, related techniques, adversary relationships, or procedure examples were supplied. Local Microsoft 365/Azure logging configuration, retention, licensing, and SIEM correlation capabilities will determine whether this can be operationalized effectively.
Analytic 0723
Forged web credentials in Office Suite contexts may appear as abnormal authentication headers in Outlook or Teams traffic, or unexplained OAuth grants in M365/Azure logs. Defenders should correlate token usage events with missing authentication flows and mismatched device/user context.
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 | df0f3a7b4c04… |
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 AN0723Open 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.