Respond to a compromised mailbox with session revocation, rule review and evidence

A mailbox compromise can expose more than messages. An attacker may create forwarding rules, authorize an application, alter recovery details or impersonate a supplier during an active payment conversation. Changing the password is an important step, but recovery must also address persistent access and the business actions taken while the attacker had control.

Start from a trusted device and a known support route

Use a device believed to be clean and reach the real provider through a bookmark or known address. If the current device may be compromised, entering a replacement password there can immediately expose it again. Notify the authorized incident owner and determine whether the account should be suspended while evidence and access are reviewed.

Record when the issue was detected, the observed symptoms and the systems the mailbox can reset. Prioritize the registrar, hosting portal, finance tools and other high-impact accounts that use this mailbox for recovery. Do not use the compromised mailbox as the only coordination channel.

umask 077
CASE_DIR="$HOME/private-incidents/mail-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$CASE_DIR"
date -u '+%Y-%m-%dT%H:%M:%SZ' > "$CASE_DIR/started-utc.txt"
stat -c '%a %U %n' "$CASE_DIR"

Keep the directory outside any public website tree and follow your evidence-retention policy. These permissions do not encrypt the material or protect it from a compromised local account. Use the approved secure evidence store when available.

Preserve useful evidence before it disappears

Capture relevant sign-in events, rule changes, authorized applications and provider audit references where accessible. Preserve suspicious messages in their original format, including headers. Avoid broad deletion of messages or logs that could establish the scope of the incident.

from email import policy
from email.parser import BytesParser
from pathlib import Path

message = BytesParser(policy=policy.default).parsebytes(
    Path("suspicious-message.eml").read_bytes()
)
for field in ("Message-ID", "Date", "From", "To", "Reply-To", "Received"):
    for value in message.get_all(field, []):
        print(f"{field}: {value!r}")

Store the output privately and remember that sender-supplied dates and headers are not independently authoritative. Correlate them with trusted provider logs and timestamps. A visible sent-mail folder can be incomplete if an attacker deleted items or used another submission route.

Revoke credentials and sessions through all supported paths

• Change the mailbox password and any reused credentials from the trusted device.
• Revoke active sessions, application passwords, OAuth grants and API tokens as the provider supports.
• Review registered MFA factors, recovery addresses, phone numbers and delegated users.
• Check the hosting-panel identity as well as the mailbox identity if either could control the other.

The effect of a password reset on existing sessions and tokens is provider-specific. Verify revocation rather than assuming the reset covered every path. Reconfigure legitimate clients with new credentials only after the access policy is understood.

Enable the strongest supported MFA and protect enrollment and recovery. Hosting-panel MFA is not proof that IMAP, SMTP or Webmail access has the same second-factor policy. Ask the administrator to identify any remaining legacy or unattended access paths.

Remove persistence in rules, forwarding and domain configuration

Inspect mailbox filters, automatic forwarding, delegates, signatures, reply settings and deleted-message rules. Check domain-level forwarders, catch-all behavior and server-side filters if you have the required access. An attacker can hide incoming replies or forward a copy without keeping an interactive session.

Review DNS and mail routing if the compromised identity had permission to change them. Also inspect application integrations that send mail as the business. Record the suspicious configuration before removing it, then verify that the legitimate delivery path still works.

If malware or a stolen browser session may have caused the compromise, coordinate device investigation and remediation. Closing the mailbox session alone does not resolve a compromised endpoint or another stolen identity.

Investigate financial and customer impact

Review recent payment conversations, changed bank details, password-reset messages and unusual outbound activity. Verify questionable instructions with established contacts using a separate known channel. If funds were sent fraudulently, involve the payment provider and appropriate incident contacts promptly.

Assess the data accessed and the obligations that apply with your organization's responsible advisers. Do not promise that a password reset proves no messages were read. Provider log availability, retention and account capabilities determine what can be established.

Verify recovery and watch for recurrence

Send and receive controlled external tests, confirm expected folders and forwarding behavior, and test legitimate applications after their credentials are replaced. Monitor new sign-ins, rule changes, bounces and support reports for renewed activity.

Document the incident timeline, confirmed access paths, revoked credentials, removed persistence and unresolved evidence gaps. Improve recovery ownership, phishing-resistant authentication and payment verification based on the findings. Recovery is complete when authorized access and business workflows are verified and the known persistence paths have been addressed.

Primary documentation

• cPanel two-factor authentication
• cPanel Email Accounts
• Python email parser documentation
• CISA phishing-resistant multifactor authentication