Establish the trusted response route and affected identity
Record the account, first observed time with timezone, suspicious message or alert and the business systems involved. Contact the administrator through an existing trusted route. A potentially compromised mailbox should not be the only channel used to approve sensitive recovery actions or send new credentials. Keep the initial evidence specific without copying unnecessary private messages.
Identify whether the identity is cloud-managed, synchronized or federated and whether administrative roles are involved. The authoritative identity source affects recovery. A suspicious sign-in or message is a reason to investigate, not proof of the full incident scope. Record what is observed, what is suspected and who has authority to contain access.
Contain access using the appropriate administrator procedure
Follow the current provider process to restrict the affected account and address active sessions or access paths within the authorized scope. Consider the business effect and maintain a trusted recovery administrator, especially if a privileged identity is involved. Do not make a broad tenant change that locks out the responders while the affected route remains unexamined.
Resetting a password, revoking refresh/session access and removing an app grant are different operations. Token lifetimes, resource behavior and independently managed application sessions can affect when restrictions take effect. Verify the result in the relevant systems; do not promise that one button instantly terminates every access route.
Preserve a timeline while remediation proceeds
Retain available sign-in, audit, mail-trace and relevant configuration evidence for the authorized investigation. Record collection times and the timezone used for comparison. Feature availability, roles and retention determine what can be examined; an empty or unavailable log does not establish that no earlier access occurred.
Record the containment actions and their timestamps as well as the suspicious activity. This helps distinguish an attacker change from a legitimate responder action. Do not delay necessary containment solely to collect every possible artifact, and do not delete the account or wipe evidence as a generic first step. Agree how sensitive records will be accessed and stored.
| Area | What the authorized owner reviews | What acceptance must distinguish |
|---|---|---|
| Identity and sign-in | Source of authority, roles, recovery methods and relevant sign-ins | A changed password versus effective access restriction. |
| Sessions and applications | Sessions/tokens, grants and connected access in scope | One revoked route versus all affected services. |
| Mailbox behavior | Forwarding, inbox rules, delegates and relevant mail events | Removal of one rule versus the full observed persistence scope. |
| Files and business processes | Affected sharing or sensitive requests supported by evidence | Observed access versus assumed data extraction. |
| Recovery | Controlled sign-in, intended settings and service workflow | User access restored versus investigation complete. |
Review persistence and business impact separately from the password
Inspect relevant forwarding settings, inbox rules, delegated access, authentication methods and application permissions through the appropriate administrator tools. Compare suspicious entries with the business's known configuration before removing them. Some legitimate processes use delegation or forwarding; retain the evidence and explain the targeted correction.
Determine whether unauthorized mail, file access or a sensitive business request needs further investigation. Do not infer data extraction from a login alone or infer no exposure from a missing log. If a payment change, customer communication or personal-data issue may be involved, engage the responsible business owners and the appropriate specialist process for the situation and jurisdiction.
Restore access through explicit return-to-service checks
Use a trusted device and the provider-supported identity-recovery process. Confirm the intended authentication methods and recovery ownership, correct roles, relevant session/app restrictions and removal of unauthorized configuration within scope. Do not send new secrets back through a mailbox while its control is still uncertain.
Verify the affected business workflow, such as receiving and sending controlled mail, and confirm the monitored behavior after restoration. Re-enabling a user is not equivalent to closing the incident. Keep unresolved evidence gaps and dependencies visible, with an owner and a plan for follow-up. Escalate when privileged access, multiple accounts or broader infrastructure may be involved.
Document the conclusion and agree the next scope
Summarize the observed window, actions, confirmed findings, limits and outstanding decisions. Separate a technical account-recovery result from a complete forensic or legal conclusion. Review why the control failed where evidence supports it, then assign focused improvements rather than claiming that one configuration change makes recurrence impossible.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with business email, account-access and digital-infrastructure work. Our Israeli technical knowledge supports scoped technical review and recovery. More extensive forensic, legal or multi-system response needs its own agreed competence and scope; no round-the-clock response or universal recovery outcome is implied.
