BEC Mailbox-Rule Investigation: Build an Evidence Timeline

Build the BEC timeline around actions, not only suspicious messages

A business email compromise investigation should connect the suspicious message, account activity, mailbox changes and business decisions through traceable evidence. An unexpected inbox rule is a useful lead, but it is not the entire incident. Responders need to establish what the rule did, when it existed, who or what changed it, and whether it affected relevant correspondence.

This guide focuses on building an evidence timeline for mailbox-rule and forwarding investigations. It is intended for authorised responders, messaging administrators and finance leads coordinating an incident. The examples are fictional and contain no real customer records. They illustrate analysis methods rather than providing a universal command sequence for every tenant.

If a fraudulent payment may have occurred, contact the financial institution promptly through a trusted channel while technical investigation continues. Do not wait for a complete forensic report. The UK NCSC’s business payment fraud guidance recommends contacting the bank directly using its official website or phone number. Recovery is not guaranteed, and the appropriate reporting process depends on the organisation and jurisdiction.

Run financial containment and technical investigation in parallel

Assign separate but coordinated owners for payment decisions and technical response. The finance lead can identify affected transactions and contact the bank, while the incident team examines accounts and mail flow. A single shared timeline should connect the work, but one stream should not wait unnecessarily for the other. Record who is authorised to stop payments, change supplier details and approve account containment.

Use a trusted communication channel if the affected mailbox may be monitored. Independently verify supplier or executive instructions using contact information already known to the organisation, not details supplied in the suspicious thread. Preserve the original correspondence and the business records needed to understand the request. Avoid replying to the suspected attacker to test whether the message is genuine.

Record the initial uncertainty. A fraudulent message can involve a compromised internal account, a compromised supplier account, impersonation or another route. Do not assume your tenant was breached solely because an invoice was convincing. Equally, do not dismiss internal compromise because the visible sender appears external. The investigation should test competing explanations using the available evidence.

Capture current configuration without confusing it with history

Collect the current mailbox rules, forwarding settings and relevant delegated permissions through authorised administration. Preserve their identifiers, enabled state, conditions, actions and destinations. A screenshot of a rule name is rarely enough. The same name can describe a harmless filing rule or a harmful redirection, and the current state may differ from the state during the incident.

Label this collection as a snapshot at a specific time. It establishes what was visible when collected, not necessarily what existed days earlier. A rule may have been changed, disabled or removed. Historical audit records and other evidence are needed to reconstruct those changes. Keep snapshot evidence and event evidence separate in the working record.

If ongoing harm requires immediate removal or restriction, follow the approved containment decision and record what was changed. Preserve the minimum relevant configuration first when feasible, but do not allow a rigid preservation routine to prolong active damage. The incident owner should document the tradeoff and any resulting evidence gap.

Separate inbox rules, forwarding, delegation and application access

Several mechanisms can affect mailbox information. An inbox rule can act on matching messages; mailbox-level forwarding can route delivery; delegated permissions can allow another identity to read or send; application permissions can provide an independent access route. Organisation-level mail-flow configuration can also matter. Treat these as separate collection categories rather than searching for one suspicious setting.

For each category, record the relevant objects and the evidence source. Ask what the mechanism can do in this environment and what activity was actually observed. A configured destination establishes a potential route, while message or activity evidence may help establish use. Do not assume every message was forwarded solely because a forwarding configuration existed at collection time.

The distinction also matters for containment. Removing one inbox rule may leave an application permission or delegated account untouched. The investigation should identify the plausible access paths and assign owners to review them. Our session-response guide explains why account and application containment require separate verification.

Describe rule behaviour precisely

Inspect the complete conditions, actions, exceptions, priority and enabled state. A rule that moves invoice-related messages out of the inbox has a different effect from one that redirects all mail externally. A rule with a broad condition may still have an exception that changes its impact. The analyst should translate the configuration into a plain-language behavioural statement without losing those details.

Ask the mailbox owner whether the behaviour is expected, but do not use memory as the only evidence. Users may forget legitimate rules, and an attacker may choose a familiar-looking name. Compare the rule with change records, workflow documentation and historical events where available. The conclusion should state what is known and what remains unexplained.

Do not send sensitive messages to an unknown destination to see whether forwarding works. If a behavioural test is necessary, use an authorised controlled destination and synthetic content in a suitable environment. Record how that test differs from the original configuration. The investigation should not create additional disclosure in the process of proving a route exists.

Collect historical changes with reproducible filters

Microsoft provides audit investigation guidance covering mailbox forwarding and inbox-rule changes. Use current platform instructions and the correct administrative permissions. Record the time interval, users, activities and other filters used, because an incomplete query can produce a misleadingly quiet result.

Preserve the original export and note any limits, pagination or delayed availability. Different activity types and clients can produce different records. Do not assume one named event captures every possible change. If the result is empty, review the query and available retention before concluding that no change occurred. Ask a second analyst to review important negative conclusions.

Keep historical records tied to their source identifiers. The working timeline can normalise time and names for readability, but the original should remain available for verification. If later collection produces new or different results, record why the dataset changed. Silent replacement makes it difficult to review the investigation’s reasoning.

Correlate mailbox changes with identity evidence carefully

Compare rule or forwarding events with relevant sign-in and administrative activity. Use stable identifiers and application context where available. A display name or an IP address alone may be insufficient to identify the actor. Shared networks, proxies and legitimate administrative tools can complicate interpretation. The report should explain the basis for linking records.

Distinguish the account recorded as performing an action from the person believed to control it. An audit record may show a legitimate user identity used by an attacker. It may also show a service or administrator acting through an approved process. The analyst should preserve that distinction instead of writing that the employee created the malicious rule without qualification.

Review whether the activity follows a suspected phishing or credential event, but avoid assuming causation from proximity alone. A convincing sequence may combine a reported lure, unusual authentication, a rule change and subsequent message activity. Each link should have an evidence reference and a confidence statement. Where the relationship is inferred, label it as an inference.

Connect the timeline to the relevant message set

Identify the messages associated with the suspected fraud using stable message references where possible, along with sender, recipient, subject, time and conversation context. Preserve the original records through approved collection. A forwarded screenshot may omit headers or alter context, so it should not be the only evidence when original messages are available.

Define the relevant population rather than exporting an entire mailbox by default. Start with the business process, incident window and known correspondents, then expand when evidence justifies it. Record the criteria so another analyst can understand how the message set was selected. This supports both privacy and analytical clarity.

Compare the messages with the rule conditions and timing. A rule created after a suspicious message arrived cannot automatically explain that message’s earlier disappearance. A rule may also affect only a subset of a conversation. The timeline should identify which effects are observed, which are plausible and which cannot be established from the available records.

Reconstruct the business decision without blaming the recipient

Work with finance to document how the payment or account change was requested, verified, approved and executed. Identify the information available to each person at the time. The purpose is to understand the control path and preserve evidence, not to turn the technical report into a judgement about an employee’s motives or competence.

Compare the approved supplier details with the requested change and the eventual transaction record. Use trusted internal records and bank references. If a phone call or meeting formed part of the verification, record who participated and how the contact was established. An apparent verification can still rely on contact details supplied by the attacker.

Where AI-generated text, voice or imagery is suspected, preserve the relevant artifact and state the evidential limits. Fluent language or an unusual voice is not enough to prove AI involvement. The response can still address the fraudulent instruction, payment process and account compromise without waiting for definitive attribution.

Use a timeline schema that exposes uncertainty

A useful timeline row includes original timestamp, normalised timestamp, source, actor identity, action, object, evidence identifier and confidence. Add a separate column for interpretation. This prevents a hypothesis from being embedded inside an event description and later mistaken for a recorded fact. Keep responder actions in the same chronology but clearly label them.

Normalise time zones carefully and preserve the original values. Mail systems, endpoints and financial records may use different formats or clock references. If a discrepancy cannot be resolved, record it rather than forcing an exact sequence. A few minutes of uncertainty can matter when assessing whether a rule was active before a particular message arrived.

Use bounded statements. “The export contains a forwarding-change event at this time” is stronger than an unsupported claim that the attacker monitored the mailbox for weeks. If the available records begin after the suspected initial access, the timeline’s left boundary is an evidence limit, not necessarily the incident’s beginning.

Bound the exposure without making unsupported claims

Distinguish accessible information, observed access and confirmed disclosure. A mailbox may contain years of correspondence, but that does not prove every message was read or copied. Conversely, absence of detailed read evidence may prevent you from confidently limiting exposure to the messages you can see. The report should explain both the potential scope and the evidence-supported observations.

For a forwarding rule, assess its conditions, active period and relevant delivery evidence. For delegated or application access, assess permissions and observed activity. The resulting exposure statement may need several parts rather than one number. Avoid presenting a precise count when the data does not support it.

Provide the technical findings to the organisation’s privacy, legal and communications owners. They determine applicable notification and reporting obligations with the relevant context. The technical team should make uncertainty visible and answer follow-up questions, rather than substituting a generic legal conclusion for the organisation’s decision process.

Verify removal of the route and the access behind it

Containment should address both the mailbox mechanism and the identity or application that could recreate it. Removing a rule while leaving the attacker’s access intact may provide only temporary relief. Record the relevant account, session, authentication-method, delegation or application actions and assign an owner to verify each one.

After changes, collect a new configuration snapshot and compare it with the preserved original. Review subsequent activity for reappearance or related changes within the agreed monitoring plan. A successful administrative operation is useful evidence, but the team also needs to understand whether the relevant access path remains available elsewhere.

Preserve legitimate business routing where possible. Removing every forwarding or delegation arrangement without review can disrupt operations. Where urgent containment requires broad restriction, record the temporary impact and the controlled restoration plan. The incident owner should decide which functions can resume and what evidence is required first.

Use AI-assisted analysis with evidence checks

AI can help group events or draft a timeline summary, but it should not decide which events are real or infer attribution without review. Require each significant statement to point to an evidence identifier. Check that timestamps, identities and actions match the source. Generated prose can accidentally turn a suspected relationship into a confident assertion.

Use only approved processing arrangements for sensitive messages and logs. Minimise data and avoid sending raw mailbox content to a consumer tool merely because it is convenient. Message bodies are untrusted input and may contain instruction-like text; analysis systems should treat them as evidence, not commands. The investigation must not introduce a new confidentiality problem.

Keep the final conclusion readable for finance and leadership. Explain the observed path, containment status, affected business process and unresolved questions. Technical detail belongs in supporting evidence, but uncertainty belongs in the summary as well. A concise accurate statement is more valuable than a dramatic account of an AI-powered attack that the evidence cannot substantiate.

Worked example: a rule that hid supplier replies

In a fictional incident, finance receives an altered payment instruction in an existing supplier conversation. A later supplier reply is not visible in the expected inbox. The response team preserves the messages, current mailbox rules and available historical records. It finds a rule that moves messages matching the supplier’s address to another folder, with a change event during the incident window.

The team compares the rule’s timing and conditions with the relevant messages. It confirms that the rule could affect the supplier replies and identifies the messages for which supporting evidence exists. Identity evidence links the change to the affected account, but the report carefully distinguishes that account from the legitimate employee. Finance separately contacts the bank and validates the supplier’s real details through a trusted route.

Containment addresses the rule and the compromised access path. The final timeline records the suspicious messages, configuration changes, payment actions and responder decisions. It does not claim that every mailbox item was exfiltrated or that AI wrote the fraudulent message. The conclusion remains specific enough to support recovery and improvements to payment verification.

Close the investigation with a usable evidence package

Deliver a timeline, source register, affected-system list, containment record and unresolved-question register. Include the collection boundaries and retention gaps that limit the conclusion. Keep sensitive raw evidence restricted and provide a redacted decision summary for broader distribution. The organisation should be able to trace important claims without giving every reader access to the entire mailbox.

Assign remediation actions to the control that failed or was absent. Examples may include payment-detail verification, delegated-access review, logging coverage or authentication controls. Avoid recommending every possible security product without linking it to the incident. The action plan should explain the expected improvement and how the organisation will verify it.

Plan a short follow-up exercise using synthetic correspondence. Test whether an unexpected supplier-detail change reaches the correct reviewer, whether the trusted verification channel is available and whether the security team can retrieve the relevant records. This converts the investigation into a practical improvement rather than leaving the lessons in a report.

Review the timeline for alternative explanations

Before finalising the account, ask a reviewer who did not build the first timeline to challenge its important links. Could a legitimate administrator have made the forwarding change? Does a message timestamp represent submission, receipt or a later export? Could a rule have been disabled during the period being discussed? These questions do not minimise the incident; they help ensure that the final explanation survives scrutiny and does not depend on an unnoticed assumption.

Record the alternatives considered and why the evidence supports the chosen interpretation. If two explanations remain plausible, preserve that uncertainty and identify the practical decisions that depend on resolving it. Some recovery actions may be appropriate under either explanation, while attribution or exposure statements may need further evidence. A clear review record helps leadership understand why the team can act confidently on containment while remaining cautious about the full historical narrative.

Prepare a non-sensitive brief for specialist help

For response support, provide the affected email platform, approximate window, suspicious behaviour, financial impact if known and actions already taken. Identify the authorised incident coordinator and available evidence sources. Do not place bank details, mailbox exports, passwords or live tokens in the public form. Arrange secure evidence exchange with the response team.

Our Microsoft 365 response service covers account and mailbox investigation as part of a wider incident boundary. The incident evidence checklist can help organise the first handover. Contact Atlant Security to discuss the collection plan and the decisions that need technical support.

The objective is to restore control and establish a defensible account of what happened. AI may have helped the attacker or may help organise the response, but neither possibility changes the need for validated evidence, trusted communication and clear ownership. Those are the foundations of an investigation that your finance, technical and leadership teams can use.