Email Incidents practice questions

Click the URL to inspect the landing page

Why it fails: Clicking the URL from the analyst's environment risks credential theft, drive-by compromise, or attacker fingerprinting, and may notify the threat actor. Direct browsing suits sanctioned sandboxed analysis. Triage first requires passive inspection, such as reputation checks or detonation in an isolated sandbox, before any interaction.

Block the sender domain immediately

Why it fails: Blocking the sender domain is a containment action taken after analysis confirms malicious intent, and premature blocking may tip off attackers or disrupt legitimate mail. Sender blocking suits confirmed campaigns. Triage first requires safely examining the URL, for example via sandbox or reputation lookup, without interacting directly.

Forward the email to the user for confirmation

Why it fails: Forwarding the email back to the user risks re-exposure and relies on a non-expert's judgement, and the user may click the link. User confirmation suits ambiguous internal mail, not clear suspicious URLs. The analyst should first analyse the URL safely using isolated tooling before any containment or notification.

Forward the email to a colleague in the security team and ask them to click the link.

Why it fails: Asking a colleague to click the link exposes another user to the same risk and is not a controlled analysis method. It also lacks documentation and could lead to multiple infections. Proper incident response requires safe, isolated analysis techniques.

Open the link in a virtual machine with a standard corporate image to see the page.

Why it fails: Using a standard corporate image in a VM risks infection if the VM is not properly isolated and may expose corporate credentials or network access. It also lacks the instrumentation of a dedicated sandbox, making it less safe and less informative for incident analysis.

Copy the link and paste it into a browser on the responder's workstation.

Why it fails: Visiting the link directly on a responder's workstation is highly unsafe; it could lead to compromise of the responder's system and the corporate network. It also may alert the attacker that the link was accessed, potentially causing them to change tactics or delete evidence.

The message fails DMARC alignment for the displayed From domain.

Why it fails: Failure of DMARC alignment indicates spoofing, which is the opposite of what the scenario states. Since the email passes SPF and DKIM, DMARC alignment would likely pass as well. BEC often uses legitimate or compromised accounts that pass authentication, so a DMARC failure would point to a different, more traditional spoofing attack.

The email includes a link to a credential-harvesting page.

Why it fails: Credential harvesting is a phishing technique aimed at stealing login credentials, not the hallmark of a wire-transfer BEC. While BEC may use phishing for initial access, the described email is asking for a direct financial action. A credential-harvesting link would indicate a phishing incident rather than the social-engineering BEC pattern shown here.

The email contains a malicious macro-enabled attachment.

Why it fails: A macro-enabled attachment indicates malware delivery, not BEC. BEC typically relies on social engineering and text-based requests without malicious payloads, because the goal is to trick a human into transferring funds or data. The presence of a macro would shift the incident classification toward a malware or phishing-with-attachment scenario.

Open the .eml in the mail client and use the Print to PDF option to capture the headers

Why it fails: Rendering the message in a mail client can execute remote content, and converting to PDF flattens and reorders the header text, making it harder to read and easy to misquote. It also risks loading tracking pixels that notify the attacker, so it is both an integrity and an operational-security problem.

Open the attachment in a sandbox and read the SMTP envelope fields from the sandbox report

Why it fails: Sandbox reports describe behavior of attachments, not the routing history of the message itself, and the SMTP envelope is not stored inside the attachment. This approach answers a different question, so it would not yield the originating IP or the hop-by-hop path needed for the investigation.

Forward the .eml to your own mailbox and read the headers in the received copy

Why it fails: Forwarding rewrites the message, adding new Received headers and often altering the body or attachments depending on the client. This destroys the original header chain and can strip or re-encode content, so the forwarded copy is no longer reliable evidence of the original message path.

The sender's IP address is on a blocklist

Why it fails: Blocklisting concerns the sending IP's reputation and is enforced at connection time, whereas DKIM verification hashes the message content and headers against the published public key. Blocklist checks belong in a reputation-filtering scenario, not in diagnosing a signature that fails to validate.

The user clicked a phishing link

Why it fails: A phishing click is a user action, not a mail-authentication event; DKIM verification fails on cryptographic grounds such as a modified body or an unresolvable selector key. Phishing simulation and awareness training address user susceptibility, which is a different control objective entirely.

The SPF record is missing

Why it fails: SPF authenticates the envelope sender's IP, a separate mechanism from DKIM's body-and-header cryptographic hash; a missing SPF record cannot invalidate a DKIM signature. SPF is the right control when the requirement is to authorise sending hosts by IP address, not to verify message integrity.

Conditional Access policies

Why it fails: Conditional Access governs sign-in and session access based on user, device and location signals; it cannot locate or delete messages already delivered to mailboxes. It is tempting because it controls access to Microsoft 365 resources, but message remediation requires a content-search purge instead.

Exchange Transport Rules

Why it fails: Transport rules act on mail in transit, so they cannot remove messages already sitting in user mailboxes. They are tempting because they can block or redirect future phishing deliveries. Retroactive removal of delivered mail requires a content search with a purge action.

Mail Flow Connector configuration

Why it fails: Mail flow connectors define routing between Microsoft 365 and other mail systems; they carry no capability to search mailboxes or delete delivered messages. They are tempting because they control mail transport, but remediation of existing phishing mail needs a compliance content search purge.

The file is a legitimate script file

Why it fails: Legitimate scripts use extensions such as .ps1, .sh or .bat, not a PDF suffix followed by .exe. The double extension signals a Windows PE executable disguised as a document, a common malware delivery technique. Script files are not renamed to resemble invoices.

The file is encrypted with a password

Why it fails: Password-protected archives typically carry extensions such as .zip or .7z, and encryption does not produce a double extension. The double extension indicates a Windows executable masquerading as a PDF, exploiting hidden file extensions. Encryption is unrelated to the filename structure observed here.

The file is a genuine PDF that requires an executable

Why it fails: PDFs are self-contained and never require an accompanying executable to open; viewers are separate applications. The .exe suffix means the file is a Windows executable, not a PDF, and the preceding .pdf is social-engineering camouflage. Genuine PDFs carry only a single .pdf extension.

SMTPS

Why it fails: SMTPS is SMTP wrapped in TLS, securing transport of mail between servers or clients; it carries no policy telling a receiver how to handle SPF or DKIM failures. It is tempting because it is an email protocol, but it would be correct only when the requirement is encrypting the SMTP session itself.

IMAP

Why it fails: IMAP is a mailbox access protocol for reading and synchronising messages on a server; it neither evaluates SPF or DKIM results nor conveys handling instructions to receivers. It is tempting because it is a familiar email protocol, but it would be the right answer only for client-side mailbox synchronisation.

POP3

Why it fails: POP3 is a mailbox retrieval protocol for downloading mail to a client; it plays no part in publishing sender authentication results or instructing receivers how to treat failed messages. It is tempting because it is a well-known email protocol, but it would be the right answer only for a question about retrieving messages from a mail server.

The message was spoofed and must be blocked

Why it fails: A softfail is not a hard fail.

The email has been encrypted with TLS

Why it fails: SPF has no relationship to TLS.

The email passed DKIM verification

Why it fails: SPF and DKIM are independent.

X-Originating-IP

Why it fails: X-Originating-IP is an optional, non-standard header inserted by some webmail providers and easily forged or stripped, so it cannot reliably evidence the relay path. It is tempting because it names an apparent source address, and would be useful when a webmail provider's own logs are available to corroborate it.

Return-Path

Why it fails: Return-Path is set by the sending side and rewritten by the final delivery agent, so it reflects the bounce address rather than the sequence of relays. It is tempting because it appears to trace origin, and would be the right field when investigating where a bounce or non-delivery notification should be sent.

X-Mailer

Why it fails: X-Mailer identifies the sending client software, not the relay path, so it cannot verify intermediate mail transfer agents. It is tempting because it appears in headers and can hint at the originating mail client, but Received headers record each hop's timestamp and server, which is what this scenario requires.

Accusatory, to discourage clicking

Why it fails: Accusatory wording blames the reporter, discouraging future reporting and losing the early warning the phishing report provides. It is tempting because analysts want clicking deterred, and a firm corrective tone is the right choice when addressing a repeat offender who ignored prior awareness training and warnings.

Technical and jargon-heavy

Why it fails: Jargon-heavy wording obscures what the recipient must do and can read as condescension, undermining the reassurance and clear reporting instructions the reply needs. Technical vocabulary is tempting because analysts live in it, and it would suit an email to fellow security staff or an incident ticket rather than a frightened end user.

Alarmist, to ensure they remain scared

Why it fails: Alarmist language amplifies fear and can push users to hide future mistakes or flood the service desk, defeating the report's purpose. It is tempting because urgency feels motivating, and stern warnings are the right approach when communicating an active, organisation-wide threat that demands immediate action from every recipient.

Nmap

Why it fails: Nmap probes hosts and ports to map network services and operating systems; it never parses VBA source inside an Office file. Nmap is the correct choice when enumerating reachable hosts and open ports during network reconnaissance.

Wireshark

Why it fails: Wireshark captures and decodes network traffic, so it cannot inspect VBA code stored within a document's macro stream. It is the correct tool when analysing packet-level communications, such as command-and-control traffic, rather than offline file contents.

Volatility

Why it fails: Volatility extracts forensic artefacts from memory images, such as running processes and network connections, and cannot read macro source code inside a saved document. It is the right tool when analysing a live system's RAM capture after suspected compromise.

System performance degradation

Why it fails: BEC exploits trust and authority to authorise payments or share credentials; it does not degrade server or application throughput. System performance degradation is tempting because compromised mail accounts can be used to send bulk messages, and capacity monitoring would be correct if the concern were resource exhaustion from such traffic.

Infrastructure downtime

Why it fails: BEC targets people and payment processes through forged executive requests, causing fraudulent transfers or data loss rather than taking services offline. Infrastructure downtime is tempting because email compromise can precede ransomware, and availability planning would be correct when the actual threat is disruption of hosted services.

Spam distribution

Why it fails: BEC succeeds by impersonating executives to trick staff into transferring funds or disclosing data; spam volume is unrelated to that deception. Spam distribution is tempting because BEC uses email as its vector, and bulk spam filtering would be the right control for a campaign flooding mailboxes with unsolicited messages.

To comply with legal regulations

Why it fails: Legal compliance governs retention and notification duties, not the operational purpose of updating a blocklist after an incident. It is tempting because incident handling carries regulatory obligations, but the blocklist is updated to prevent recurrence by blocking the sender addresses, domains or indicators tied to the resolved incident.

To improve system performance

Why it fails: Blocklist updates prevent recurrence by rejecting mail from the offending sender or domain; they do nothing to CPU, memory or throughput, so performance gains are not the purpose. Performance tuning would be the goal when mail flow itself is slow, not after an incident has been resolved.

To delete the user's account

Why it fails: Updating a blocklist filters future messages from the malicious sender; it does not remove identities, so account deletion is unrelated. Deleting a user account is the right action when an employee leaves or a mailbox is compromised beyond recovery, not for routine blocklist maintenance.

Scanning the email for attachments

Why it fails: Homograph attacks spoof domains using visually similar Unicode characters, leaving no malicious attachment to find; scanning attachments addresses malware delivery instead. Attachment scanning is the correct control when detecting weaponised files, but detection here requires inspecting the domain's character composition, not its payload.

Checking the SPF record

Why it fails: SPF records for the fake domain may look valid.

Looking for a valid TLS certificate

Why it fails: A valid TLS certificate only proves the holder controls the presented domain; homograph domains can obtain legitimate certificates for their own registered lookalike names, so the certificate validates without exposing the deception. It is tempting because certificate inspection normally reveals mismatched or self-signed names, and would be correct for detecting a certificate issued to an unrelated host.

Document the incident in the SIEM

Why it fails: Documentation is a later phase; logging the incident before containing the delivered email lets the threat persist and spread. SIEM recording is appropriate once containment and eradication are underway, or for tracking low-severity events, not as the immediate step after a confirmed bypass.

Update the firewall blocklist

Why it fails: Firewall blocklists filter IPs and ports, not email senders or URLs already delivered to a mailbox, so they cannot contain this threat. They are the right control for blocking malicious network traffic at the perimeter, not for responding to a message that has already passed the gateway.

Wait for the user to report it again

Why it fails: Waiting leaves the malicious email in the mailbox, allowing further clicks, credential theft and lateral movement while the attacker operates unhindered. Passive monitoring suits low-confidence alerts pending triage, not a confirmed gateway bypass requiring immediate containment actions such as quarantine and user notification.

The user's inbox is empty

Why it fails: An empty inbox can occur for many reasons and does not specifically indicate a forwarding rule; the rule copies or redirects mail while leaving the original in place. Emptiness is tempting because it suggests mail loss, and it would be correct if the question concerned mailbox deletion or archiving rather than forwarding.

The mailbox reached its size limit

Why it fails: A mailbox size limit is unrelated to forwarding rules; it results from accumulated mail, not from a hidden rule redirecting messages. Mailbox quotas are tempting because they are a common Exchange alert, and a size limit would be the symptom if the question concerned storage management rather than rule abuse.

The password was changed

Why it fails: A password change is a credential compromise indicator, not a forwarding rule symptom. Account takeover often accompanies rule creation, so password changes are tempting, but they would be the correct symptom if the question asked about credential theft or unauthorised account access rather than mail redirection.

It requires too much storage space

Why it fails: Compressed archives reduce size, so storage is irrelevant; the red flag is that password protection blocks antivirus and sandbox inspection of the encrypted contents. It tempts because large attachments do trigger mailbox quota warnings, but that is a capacity concern, not a concealment technique attackers deliberately use to smuggle malware past email filtering.

It is a sign of high security

Why it fails: Password-protected archives are not a security control; attackers use them because scanners cannot inspect encrypted contents, and the password is usually supplied in the same message body. It is tempting to read encryption as protective, but legitimate senders rarely need to bypass mail filtering this way.

It violates corporate policy

Why it fails: Policy breach is a consequence, not the detection mechanism: the red flag is that password-protected archives defeat gateway content inspection, hiding malware from antivirus scanning. It tempts because many organisations do prohibit encrypted attachments, so a policy violation genuinely occurs — but that is a governance outcome, not the technical reason security tools cannot examine the payload.

The user's computer is infected

Why it fails: An infected endpoint sending mail directly would typically fail SPF unless it relays through an authorised server, and infection does not explain an unauthorised sending IP passing the check. Endpoint compromise suits investigating malware propagation or credential theft, not SPF-passing mail from unexpected infrastructure.

The domain has no DMARC record

Why it fails: SPF only validates the envelope sender's sending IP; DMARC alignment would catch a mismatch between the From header domain and the SPF-authenticated domain, but its absence does not cause an unauthorised IP to pass SPF. DMARC records are for policy enforcement and reporting, not IP authorisation.

The mail server was misconfigured

Why it fails: A misconfigured mail server would normally fail SPF or produce a mismatch, not pass it from an unauthorised address. Misconfiguration suits diagnosing delivery failures, relay errors or authentication breakdowns; here the check succeeded, so the sending infrastructure itself is the anomaly.

To provide a backup of the email

Why it fails: Sandboxing detonates suspicious content in an isolated environment to observe malicious behaviour; it does not retain copies of email for restoration, which is a journaling or archiving function. It is tempting because sandboxing does quarantine messages, but backup would be the correct control when retention or recovery is required.

To store malicious emails for future reference

Why it fails: Sandboxing detonates attachments and URLs in an isolated environment to observe behaviour and block threats; storing malicious emails for later reference is a forensic or quarantine-repository function. It is tempting because sandboxing does isolate suspicious messages, but retention for future analysis would be the correct control when evidence preservation is the goal.

To encrypt the email body

Why it fails: Sandboxing executes suspicious attachments and links in an isolated environment to observe behaviour, not to encrypt message bodies; encryption is handled by transport or message-level encryption. It is tempting because sandboxing does protect content, but it would be the right control for confidentiality in transit, not threat detonation.