Worked example: a genuine account used after compromise¶

title: 'Worked example: a genuine account used after compromise' subtitle: The email passes authentication and comes from the real mailbox, but the account activity shows another user or session may have controlled it. slug: worked-example-genuine-account-used-after-compromise series: email-evidence section: worked-examples card_type: worked_example pathway_order: 46 section_order: 2 status: draft public_safe: true video_ready: true word_count: 459 estimated_read_time_seconds: 190 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - worked example - account compromise - mailbox rules - session sources: - title: 'Microsoft Learn: Respond to a compromised email account' url: https://learn.microsoft.com/en-us/defender-office-365/responding-to-a-compromised-email-account - title: 'Microsoft Learn: Message trace in the Microsoft Defender portal' url: https://learn.microsoft.com/en-ca/defender-office-365/message-trace-defender-portal - title: 'Google Workspace Admin Help: Identify and secure compromised accounts' url: https://support.google.com/a/answer/2984349?hl=en-GB - title: 'Microsoft Learn: Email analysis in investigations' url: https://learn.microsoft.com/en-us/defender-office-365/email-analysis-investigations

Worked example: a genuine account used after compromise¶

The email passes authentication and comes from the real mailbox, but the account activity shows another user or session may have controlled it.

Script¶

A manager receives an unusual payment request from the genuine email address of a colleague.

The message uses the normal company domain.

The recipient’s provider records that it arrived through the organisation’s real email service.

SPF, DKIM and DMARC all pass.

The colleague says they didn’t send it.

At this point, the authentication results don’t settle the dispute.

They show that the genuine organisational system sent an authenticated message.

They don’t identify who controlled the account or session.

Preserve the original message and the claimed sender’s mailbox context.

Check Sent Items, Drafts, Deleted Items, Junk, archive folders, forwarding settings and inbox rules.

A suspicious rule is found that moves replies containing the word “payment” into a little-used folder.

Another rule forwards selected messages to an external address.

Those rules are consistent with an intruder trying to hide the conversation from the account holder.

Now examine sign-in and session records.

The provider records a successful sign-in from an unfamiliar network and application several hours before the disputed message.

A new authentication method was registered shortly afterwards.

The message trace confirms that the genuine mailbox submitted the payment request.

Mailbox audit links the sending event and rule creation to the same or related account session.

That creates a much stronger explanation.

The real account sent the email, but the account holder may not have controlled the relevant session.

Containment now matters.

The account should be secured through the organisation’s incident process.

Sessions and tokens may need revoking.

Credentials and authentication methods may need resetting.

Malicious rules and forwarding should be removed.

Other messages sent during the compromise period should be identified, and recipients may need warning.

Record each containment action because it changes the account.

Then test the account holder’s explanation.

Was the unfamiliar access actually caused by travel, a VPN, mobile routing or an approved application?

Was the device or authentication method known?

Did the account holder respond to a phishing prompt earlier?

Were there other suspicious messages, deletions or contact changes?

Could a delegate or administrator have created the rules?

A foreign or unfamiliar IP address isn’t enough by itself.

The strength comes from the sequence:

unusual access;

security changes;

malicious mailbox rules;

a sending event;

and a payment request denied by the account holder.

The conclusion should still be expressed carefully.

“The genuine mailbox sent the message during account activity that included unfamiliar access, new authentication details and concealed forwarding rules.”

That supports account compromise.

It may not yet identify the intruder.

Further provider, network, device and financial enquiries may be needed.

The key lesson is that successful authentication answers the domain and delivery question.

It doesn’t rule out account takeover.

When the real account is involved, the investigation has to move inside the mailbox and identity system.

A genuine account can send a fraudulent message. Move from the header into sign-in, session, rule and mailbox-audit evidence.

Scenario at a glance¶

• Visible address: genuine organisational mailbox.
• Authentication: SPF, DKIM and DMARC pass.
• Message trace: genuine provider and mailbox sent the message.
• Account evidence: unfamiliar access, new authentication method and suspicious rules.
• Alternative explanations to test: travel, VPN, authorised app, delegate or administrator.
• Immediate action: secure the account, revoke sessions and preserve the compromise period.
• Remaining question: who controlled the hostile session?

Related questions¶

• What if the sender’s account was compromised?
• Does successful DKIM prove the named sender wrote it?
• What account-access records may exist?
• What can login history show?

Source notes¶

• Microsoft Learn: Respond to a compromised email account
• Microsoft Learn: Message trace in the Microsoft Defender portal
• Google Workspace Admin Help: Identify and secure compromised accounts
• Microsoft Learn: Email analysis in investigations