A password reset is not the whole session-response question
When Microsoft 365 session theft is suspected after phishing, responders need to establish which identities and applications were accessed, contain the relevant access paths and verify the effect of each containment action. Changing a password may be necessary, but it is not a substitute for understanding tokens, application sessions, persistence and the endpoint from which the user authenticated.
This guide focuses on evidence and verification after suspected session compromise. It is for authorised administrators and incident coordinators, not a universal command sequence to run without context. Product behaviour, permissions and available logs vary. Use your incident process and current Microsoft guidance, with a responsible owner approving changes and their operational consequences.
An attacker may use AI to improve a phishing message, translate a lure or automate parts of an operation. That does not mean the victim must operate an AI application. Our AI incident response service includes ordinary Microsoft 365 and business infrastructure incidents where AI assistance is suspected or where the team needs expert help. Do not delay containment while trying to prove the attacker used AI.
Separate observed facts from the session-theft hypothesis
Start with the observation that triggered concern: a user reported a phishing page, an alert identified unusual access, or a mailbox performed an unexpected action. Record the time, source and affected identity. Session theft is one possible explanation, but credential theft, malicious consent, a compromised endpoint or legitimate unusual activity can produce overlapping symptoms.
Create a short hypothesis register. For each explanation, state what evidence would support or weaken it and who will collect that evidence. This prevents the investigation from treating the first plausible story as a conclusion. A successful MFA event does not by itself prove that all subsequent activity was performed by the legitimate user, and an unfamiliar IP address does not by itself prove compromise.
Ask the user for a factual account through a trusted channel: what they clicked, what they entered, whether they approved a prompt and which device was used. Preserve the original message or relevant records using the organisation’s process. Do not ask the user to revisit a suspicious site or reproduce the incident on their normal workstation merely to help the investigation.
| Observation | Useful next question | Avoid concluding |
|---|---|---|
| User entered credentials | Which page, time and device? | Every later event is malicious |
| MFA prompt approved | Was this expected and what followed? | MFA proves the session remained safe |
| Unusual sign-in | What application and subsequent activity? | Geography alone proves attribution |
| Unexpected mailbox action | Which identity, rule or application performed it? | Password compromise is the only path |
Preserve the evidence that may disappear first
Prioritise available identity, mailbox, application and endpoint records according to the suspected path. Record the available retention period, collection time and any gaps. Do not assume every tenant has the same licensing, logging configuration or history. An unavailable record should be documented as unavailable, not interpreted as proof that the activity did not occur.
Preserve relevant configuration before changing it when this can be done without delaying necessary containment. Examples include authentication methods, application consents, mailbox rules and forwarding settings. If urgent action must come first, record the action and what evidence could not be captured. The incident owner should balance ongoing harm and preservation rather than following a rigid rule that always prioritises one over the other.
Keep raw exports restricted and work from reviewed copies. They may contain personal information, IP addresses, message subjects and operational details. Use evidence identifiers in the timeline so analysts can trace a conclusion to its source without circulating full datasets. Preserve time zones and original timestamps; normalise them only in a separate analysis view.
Distinguish token and application-session boundaries
Microsoft’s access-revocation guidance distinguishes access tokens, refresh tokens and application-issued sessions. It explains that revocation effects depend on the access mechanism and that an application can control its own session. This is why responders should verify important application paths instead of assuming one identity action instantly ends every possible session.
For the incident, create a map of the applications the identity could reach and those actually implicated by evidence. Identify whether each relies directly on Microsoft 365 session behaviour, maintains an independent local session or uses another credential. The map does not need to be perfect before containment begins, but it should guide follow-up verification and identify owners who must act.
Do not copy generic token-lifetime numbers into an incident conclusion as though they describe the tenant’s actual behaviour. Policies, clients and application capabilities matter. Record the action taken and the observed outcome for the relevant service. Where you cannot verify an effect directly, state the assumption and obtain the application owner’s confirmation or further evidence.
Contain the affected identity through the approved process
The responsible administrator should follow current Microsoft guidance and the organisation’s incident procedures for restricting the affected account and revoking access. The exact sequence depends on the environment and ongoing impact. Record the intended effect of each action, including whether it prevents new authentication, invalidates relevant sessions or changes credentials. Those effects are related but not identical.
Coordinate containment with the business owner when the account supports critical operations, while avoiding unnecessary delay during active harm. Identify safe continuity arrangements such as a controlled alternative account or delegated process. Do not simply transfer the same privileges to an unreviewed identity and assume the problem is solved. The replacement arrangement should have a named owner and limited duration.
Verify that the administrative action succeeded and monitor the relevant records afterwards. A portal confirmation may show that a request was accepted, but the incident team still needs evidence about subsequent access. Record failed attempts, continued activity and application-specific exceptions. Use those observations to refine the containment map rather than declaring success after a single click.
Review ways the attacker could retain access
Account compromise can involve changes beyond the original session. Review relevant authentication methods, devices, application consents and permissions according to the evidence and current platform guidance. An unfamiliar object is not automatically malicious, but an unexplained change during the incident window deserves investigation. Preserve identifying details and ownership context before removal where practical.
For mailbox-related incidents, inspect forwarding, inbox rules and delegated permissions through authorised collection. These mechanisms can affect information flow or future access independently of the original browser session. Ask the owner whether each arrangement is legitimate and compare creation or modification evidence where available. Avoid deleting every unusual rule without understanding its purpose and preserving the relevant record.
If an application or service principal is implicated, identify its permissions, credentials and affected resources. A user password reset may not address an independent application credential. Involve the application owner and treat changes as a separate containment workstream. The objective is to remove the demonstrated or plausible persistence path while maintaining a traceable record of the decision.
| Potential persistence | Evidence question | Owner to involve |
|---|---|---|
| Authentication method | Was it expected and when was it registered? | Identity administration |
| Application consent | What access was granted and to which application? | Identity and application owner |
| Mailbox forwarding or rule | What data flow does it create? | Messaging owner |
| Delegated access | Who can act independently of the user session? | Messaging or application owner |
| Endpoint compromise | Could new credentials be captured again? | Endpoint response team |
Investigate the device that could re-expose access
A session incident may begin at a phishing page, but the endpoint still matters. Determine which device and browser were involved and whether endpoint evidence suggests malware, a malicious extension or another continuing compromise. Coordinate with the endpoint response team rather than assuming a cloud-only action closes the entire path.
Preserve and inspect evidence through the organisation’s approved tooling and authority. If isolation or rebuilding is required, record the decision and its effect on evidence and business continuity. Avoid asking the user to clean up the device ad hoc or install unapproved tools. Uncoordinated changes can remove evidence and create additional uncertainty.
Before restoring normal access, decide what constitutes an acceptable user environment. That may involve a known-clean managed device, reviewed browser state and verified authentication setup. The conclusion should identify what was checked and what remains unknown. “The user changed their password” is not an endpoint recovery criterion.
Build a timeline that can answer causal questions
Use a table with original time, normalised time, source, identity, application, action, evidence reference and confidence. Include both suspicious events and responder actions. The timeline should help answer whether an event preceded containment, whether it relates to the affected session and whether it created a separate persistence path.
Correlate using stable identifiers where available, not only similar timestamps or display names. Shared network addresses, proxies and legitimate travel can make location-based interpretation unreliable. A suspicious sequence becomes more convincing when identity, application and action records align, but the report should still distinguish observation from inference.
Mark gaps explicitly. If mailbox activity is available for a shorter period than sign-in data, the absence of an older mailbox event has limited meaning. If an application keeps no suitable session log, record that constraint. These gaps inform both the confidence of the incident conclusion and the improvements needed for future response.
Assess actions and information exposure separately
Determine what the affected identity could access and what the available evidence shows it actually accessed or changed. These are different questions. Broad permissions can create a large potential exposure, while the observed activity may be narrower. Conversely, limited logs may prevent a confident bound on actual exposure. Report both the permission boundary and the evidential limit.
For Microsoft 365, relevant workstreams may include email, files, sharing and administrative changes, depending on the account and records. Assign owners to collect and interpret each area. Avoid treating a mailbox review as a complete investigation of every service the identity could reach. The scope should follow evidence and credible dependencies rather than an arbitrary product boundary.
Coordinate privacy, legal, insurance and communications decisions with the responsible specialists. Technical responders should supply facts, uncertainty and timelines. They should not invent notification deadlines or declare that no reporting obligation exists merely because one log source shows no activity. The applicable decision depends on the organisation and incident facts.
Create a containment verification matrix
For each affected path, list the containment action, expected effect, verification method, owner and status. The matrix might include new sign-in, active application access, mailbox forwarding, application permissions and endpoint readiness. Keep the verification method safe: use authorised administrative evidence and controlled tests, not reuse of a suspected attacker session or interaction with malicious infrastructure.
Separate action completion from effect verification. An administrator can complete a revocation operation while a third-party application owner still needs to address a local session. The matrix should show that dependency as open. This prevents a single completed task from being interpreted as total containment.
Define the observation period and escalation criteria with the incident owner. No universal quiet interval proves an attacker is gone. Instead, explain which records were monitored, which events would reopen the investigation and what uncertainty remains. A bounded, evidence-based statement is more useful than an absolute claim that every attacker has been removed.
| Path | Expected effect | Verification record |
|---|---|---|
| Affected identity | New unauthorised access prevented | Administrative result and subsequent identity evidence |
| Relevant application | Impacted session no longer grants access | Application-owner confirmation or controlled check |
| Mailbox persistence | Unapproved route removed or contained | Before/after configuration and activity review |
| Application permission | Unapproved independent access addressed | Permission and credential change record |
| User endpoint | Recovery environment acceptable | Endpoint-team decision and evidence |
Use AI for organisation, not unsupported conclusions
AI assistance can help organise a large event set, suggest questions or draft a timeline summary, but the incident team must validate the underlying records. A model can misunderstand time zones, merge unrelated identities or invent a causal connection. Require evidence references for important statements and have a responder review the source before those statements enter the incident report.
Do not send raw sensitive logs or message content to an unapproved AI service. Use the organisation’s approved processing boundary, minimise information and record material use where required. Treat message content and log text as untrusted data rather than instructions to the analysis tool. The investigation should not create a new disclosure path while examining the old one.
Keep attacker AI attribution separate from response effectiveness. The team can contain a compromised session without proving how the lure was written. If evidence supports AI involvement, describe it with appropriate confidence. If not, say the method is unknown. A useful response is measured by restored control and defensible evidence, not by attaching an AI label to every event.
Worked example: a suspicious session after a phishing report
In a fictional incident, an employee reports entering credentials and approving a prompt after following an invoice message. The team records the report time and identifies unusual application activity shortly afterwards. It treats session compromise as a working hypothesis, establishes a trusted response channel and authorises identity containment while preserving available records.
The messaging review finds an unexplained forwarding arrangement created during the relevant window. The team preserves its configuration, validates that the owner did not request it and removes it through the approved process. An application owner separately confirms that a connected service maintains its own session and performs the required local containment. The endpoint team reviews the user’s device before normal access resumes.
The final account distinguishes confirmed events, inferred relationships and gaps. It does not claim that AI created the phishing message without evidence, or that every file was exfiltrated because the account could access them. The report includes a containment matrix, the restoration decision and follow-up work to improve logging and access controls.
Restore access deliberately and document the residual uncertainty
Restoration should have acceptance criteria agreed by the incident owner. These may include reviewed authentication methods, addressed persistence, an acceptable endpoint and confirmation from important application owners. The exact criteria depend on the incident. Avoid restoring access solely because the user needs to work without documenting the remaining risks and temporary controls.
Monitor the relevant paths after restoration and give the user a clear reporting channel for unexpected prompts or activity. Explain what changed without overwhelming them with speculative details. The user should know how to recognise a legitimate recovery interaction and avoid sharing credentials or codes with anyone claiming to help.
Record unresolved questions with owners and review dates. Some evidence may be unavailable, and not every uncertainty can be eliminated. The goal is a reasoned recovery decision supported by the available facts, not an impossible guarantee. Improvements to retention, device controls or application session management can become separate remediation workstreams.
Record collection scope before interpreting a quiet log
For each export, record the query period, filters, account or object identifiers and the collection tool. A result set can be empty because the wrong identity was selected, the event falls outside retention, the workload uses another log source or the query omitted a relevant activity type. Have a second responder review important negative conclusions against the collection settings. This small check can prevent an apparently reassuring absence from becoming an unsupported statement that no access occurred.
Keep the original export and a reproducible description of the collection. If the service paginates or limits results, verify that the collection completed and record any truncation. If a later export differs, identify whether new events arrived, filters changed or the platform presents delayed records. The timeline should not silently replace one dataset with another without preserving the reason.
Use calibrated wording in the incident report. “No matching event was found in the collected source for this interval” is different from “the account did not access the application.” The narrower statement may feel less decisive, but it accurately communicates the evidence. Where the distinction matters to recovery or reporting decisions, assign further collection or an explicit risk decision to the responsible owner.
Make the user recovery handoff verifiable
Give the returning user a specific recovery appointment and a trusted contact route. Explain which device and account they should use, how legitimate enrolment prompts will be presented and what unexpected activity they should report. Do not send recovery instructions only to the mailbox whose integrity is still being investigated. The response team should verify the person through the organisation’s approved process before issuing new access or approving authentication changes.
Record who confirmed the recovery steps and when. The record should identify the approved device, the reviewed authentication setup and any temporary restrictions, without storing passwords or recovery codes. If the user cannot complete a step, leave it as an open dependency rather than treating the whole recovery as successful because one login worked. A successful login demonstrates availability; it does not independently establish that every persistence path has been addressed.
Finally, provide a short escalation instruction for renewed prompts, unexpected forwarding or unusual application behaviour. The user should not have to reconstruct the incident history when reporting a new symptom. Link the report to the incident reference and make sure the response owner knows which observations would trigger immediate review.
Prepare an evidence-led handover for response support
A useful initial brief includes the affected services, approximate incident window, observed symptoms, actions already taken and available log sources. Include the business impact and the person authorised to approve changes. Do not send passwords, active tokens, raw mailbox archives or sensitive documents through a public enquiry form. Arrange a secure evidence channel with the response team.
Microsoft’s compromised-account guidance provides current platform-specific response steps. NIST SP 800-61 Revision 3 provides broader incident-response and risk-management context. Use those references alongside the actual tenant and application behaviour, not as a substitute for verification.
Explore our Microsoft 365 incident response service or contact Atlant Security with a non-sensitive summary. The next useful outcome is an agreed response boundary, collection plan and containment-verification process, with clear ownership for the systems that need attention.
