Administrators should close the suspicious IIS session immediately and, where appropriate, block further IIS access from that workstation by IP address or account rule. That gives a fast containment step while the event is investigated. In practice, the best response is to combine session logoff with a targeted access restriction so the same misuse cannot continue unchecked.
Why this response is a containment step, not a full conclusion
Suspicious mailbox access from a known workstation should be treated as an active trust-break event until proven otherwise. The workstation is not automatically “safe” just because it is familiar; session state, cached credentials, browser tokens, and delegated access can all be abused after initial compromise. The right first move is to stop the live access path before you spend time reconstructing motive or scope.
That is why immediate session termination matters. Closing the IIS session cuts off the current channel of misuse, while a targeted block by IP address or account rule reduces the chance that the same source continues to interact with the mailbox during investigation. This is a containment action, not a final remediation decision, and it should be paired with evidence preservation.
When the mailbox activity is consistent with compromised access rather than a benign admin workflow, the same logic applies to other active authentication material that could re-establish the session. If the attacker can simply reconnect, the incident remains live even after the first disruption. Ultimate Guide to NHIs — Key Challenges and Risks is useful background for understanding why stale or overbroad access paths keep incidents alive.
What containment should preserve and what it should stop
The objective is to preserve the ability to investigate while removing the ability to continue unauthorized mailbox access. That usually means terminating the current IIS session, then applying a narrow restriction that matches the observed access path, such as the specific workstation IP, the affected account, or the relevant session rule. Broad shutdowns can be appropriate in larger incidents, but they are not always the fastest way to stop one suspicious mailbox interaction.
The key operational judgement is scope. If the workstation is genuinely shared or managed by an admin team, blocking the machine alone may be too blunt; if the account shows misuse across multiple requests, the account rule may be the better containment boundary. Administrators should avoid assuming that ending the browser or IIS session is enough if the underlying account can immediately start a new authenticated session.
There is also a visibility issue. A workstation-associated event can look local even when the real problem is credential theft, token reuse, or a remote operator using a valid session. In that case, the response should be calibrated to the access path you actually observed, not just the host that appears in the log. OWASP Non-Human Identity Top 10 is relevant here because the same containment logic applies when access material, not the machine itself, is the real control point.
From a control perspective, this is consistent with a zero-trust style response: trust the observation less, constrain the session more, and require revalidation before access resumes. NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture both reinforce the idea of rapid containment, continuous verification, and controlled access paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.MI-1 — Incident Mitigation | Immediate session closure and targeted blocking are containment actions. |
| PR.AC-1 — Identity and Credential Management | Mailbox access hinges on authenticated access paths that may need revocation. | |
| DE.CM-8 — Monitoring for Anomalous Activity | Suspicious mailbox access should be detected and correlated with session evidence. | |
| Recommendation — Terminate the active access path and apply targeted containment to stop continued misuse. Revoke or restrict the compromised access path before restoring trust. Correlate mailbox activity and session logs to confirm whether the access is malicious. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Policy Enforcement Point | Blocking by IP or rule maps to enforcing access decisions at the control point. |
| Recommendation — Enforce the access restriction at the policy point so the session cannot continue. | ||
| CIS Controls v8 | 5.3 — Account Management | Account or session restriction is a direct account-management response to suspicious access. |
| 8.2 — Audit Log Management | Mailbox and IIS logs provide the evidence needed to confirm the access path. | |
| Recommendation — Restrict the affected account and session until the activity is validated. Retain and review IIS and mailbox logs to support investigation and containment decisions. | ||
| MITRE ATT&CK | T1539 — Steal Web Session Cookie | Suspicious mailbox access from a known workstation can reflect session misuse. |
| Recommendation — Hunt for session theft or reuse when mailbox access appears legitimate but behaves suspiciously. | ||
Practitioner Guidance
What to prioritise: Stop the live mailbox path first, then determine whether the source of misuse is the workstation, the account, or both. If the event is still active, containment is more important than perfect diagnosis.
What to verify: Confirm whether the session termination actually invalidated the active IIS session and whether any alternate path can re-establish access, such as another browser session, a different IP, or a separate account rule. If not, the incident is not contained.
Decision rule: If the workstation is only the observed source but the account itself is acting suspiciously, restrict both the session and the account path rather than relying on one control. If the account is the clearer abuse point, prioritize account-level restriction and session invalidation over a host-only block.
Practitioner takeaway: The best response is the one that prevents immediate re-entry while you investigate, because a suspicious mailbox session that can be re-established is not meaningfully contained.
Related resources from NHI Mgmt Group
- What happens when suspicious CRM access is not contained quickly?
- Why does identity matter more when vulnerabilities are discovered faster than they can be patched?
- Why do secrets stay dangerous even when they are no longer actively used?
- What should teams do when suspicious email activity overlaps with account or mailbox access?
