Watch for successful device-code sign-ins followed quickly by Graph reads of inbox and sent items, especially when the session is unfamiliar or originates from a developer or build host. That sequence suggests the token is being used to map correspondents and prepare impersonation, not just to authenticate normally.
Mailbox activity that looks like pre-phishing reconnaissance
The strongest sign is not a single login event, but a short sequence: successful device-code sign-in, then immediate mailbox reads, then selective attention to inbox and sent items. That pattern usually means the actor is mapping people, language, and reply threads so they can impersonate the account later. Suspicious sessions often come from unfamiliar endpoints, developer hosts, or cloud build infrastructure.
Mailbox preparation also tends to show low-volume, high-value access. Instead of bulk download or obvious disruption, the session reads enough messages to learn who approves requests, who handles finance, which vendors are active, and how the user writes. When that access occurs through a token or delegated session, it can look “normal” unless you correlate authentication, mailbox access, and origin.
A final clue is follow-on behaviour that does not fit ordinary user intent. If the same actor touches Graph endpoints for mail, contacts, calendar, or sent items, and does so before any visible phishing email is sent, the access is probably being used to stage impersonation rather than complete a legitimate workflow.
What the attacker is trying to learn from the mailbox
Mailbox access is valuable because it exposes social context. Attackers can identify recurring correspondents, active projects, approval chains, invoice language, travel patterns, and internal terminology. That material helps them craft believable lure messages, time them around real conversations, and reply inside existing threads instead of opening a new one.
This is why mailbox reconnaissance often precedes business email compromise, consent phishing, or credential harvesting. The attacker is not just stealing data, they are building a behavioral model of the victim and their network. If the mailbox also contains password resets, MFA prompts, or token exchange messages, the session can become a stepping stone to deeper account takeover.
For defenders, the key distinction is intent. Reading a mailbox for a few messages is not automatically malicious, but reading with a clear focus on sender history, sent-mail style, and relationship mapping is a strong indicator that the session is being used as a preparation stage for phishing or impersonation.
How to distinguish preparation from ordinary access
Normal use usually shows a coherent work pattern, such as reading recent mail, sending replies, and following a predictable device and network profile. Preparation activity more often combines a new sign-in context with selective reads, short dwell time, and no matching user workflow. The session may also arrive through a path that authenticates the token but bypasses the usual interactive login experience.
MITRE ATT&CK Enterprise Matrix is useful here because it helps you map the activity to credential access and follow-on abuse rather than treating every mailbox read as isolated noise. If the behavior fits a reconnaissance-to-impersonation path, investigate it as an attack chain, not just an access anomaly.
The practical test is whether the access changed the attacker’s understanding of the victim’s relationships or messaging style. If yes, the mailbox has likely been used for preparation. If no, and the activity instead matches routine user behavior, the signal is weaker and should be judged with the broader authentication and endpoint context.
Risk and Threat Considerations
Mailbox reconnaissance is dangerous because it turns a single token or session into a phishing laboratory. Once an attacker can read messages, they can imitate tone, harvest names and suppliers, and reply in real threads, which is far more convincing than a cold email.
Failure mechanism: A valid session or token is reused to read mailbox content, then the attacker extracts correspondent lists, thread context, and wording cues to build a believable lure or impersonation path.
Impact: The next message can bypass user suspicion, trigger credential capture, and expand compromise into business email compromise, fraud, or broader account takeover.
RFC 6749: The OAuth 2.0 Authorization Framework and RFC 8693: OAuth 2.0 Token Exchange matter because token-based delegation and exchange can make this abuse look like ordinary authorization unless the resulting resource use is monitored closely.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1114 — Email Collection | Mailbox reading for impersonation is email collection and preparation for follow-on abuse. |
| T1078 — Valid Accounts | A successful token or session used normally by the attacker is valid-account abuse. | |
| Recommendation — Map mailbox reconnaissance to T1114 and hunt for credential abuse plus follow-on phishing preparation. Treat suspicious mailbox access through a real session as valid-account abuse and review authentication trails. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Detection depends on correlating sign-in and mailbox-access telemetry into actionable alerts. |
| IA-5 — Authenticator Management | Device-code tokens and session material must be managed and revoked when abused. | |
| AC-2 — Account Management | Mailbox compromise response depends on account containment and session control. | |
| Recommendation — Correlate mailbox API activity with authentication logs and alert on suspicious read patterns. Rotate or revoke compromised tokens promptly and tighten authenticator lifecycle controls. Suspend risky access paths and review mailbox-related accounts when reconnaissance is detected. | ||
Practitioner Guidance
What to verify: Correlate the sign-in origin, token type, and mailbox API calls. A successful device-code login followed by immediate reads of inbox, sent items, contacts, or calendar from an unfamiliar host is a stronger signal than mailbox access alone.
Decision rule: If the session has no normal user workflow and the access pattern is read-heavy, relationship-focused, and followed by no legitimate sending activity, treat it as phishing preparation and escalate for containment, token revocation, and mailbox review.
What good looks like: Security teams can reconstruct who accessed the mailbox, from where, what was read, and whether the same token was later used for follow-on abuse. Without that correlation, preparation stages are easy to miss.
NIST AI Risk Management Framework is not the core answer here, but the same disciplined approach to observable behavior, traceability, and misuse detection is what makes mailbox-abuse hunting effective in practice.
Practitioner takeaway: The most useful signal is not “mailbox access happened”, it is whether the access meaningfully changed the attacker’s ability to impersonate the user. If it did, assume the account has moved from compromise to preparation.
Related resources from NHI Mgmt Group
- What are the signs that phishing-enabled credential theft is being used to access cloud services?
- Why do secrets stay dangerous even when they are no longer actively used?
- What should teams do when a mailbox is used for lateral phishing?
- How should security teams govern legitimate remote access tools used in phishing campaigns?