Phishing Triage for SOC Analysts

Preserve the original report and define the question

Record how the message was reported, when it arrived and what the recipient says they did. Preserve the original message through the approved process so headers and identifiers remain available. Work from a safe copy or trusted administrative tooling, not by opening the message links.

Ask a precise question: was this an unwanted message, did someone visit the destination, or is there evidence of unauthorised account activity? These are different findings. Do not click the URL, open attachments or contact the supposed sender outside the approved investigation process.

Compare sender and domain evidence

Separate the display name, visible From address, reply address and actual link destination. Compare the domain with the expected organisation using a trusted reference, not a link supplied in the message. Watch for a plausible display name attached to a different registered domain.

In a synthetic example, “Help Desk” sends a message from helpdesk.training.invalid while the organisation expects its own corporate domain. The mismatch is a reason to investigate, not proof that credentials were stolen. Reserved .invalid examples here are not live malicious destinations.

• Keep the message identifier and timestamps with your notes.
• Record the observed domain rather than a visual impression of the logo.
• Treat shortened or obscured destinations as additional uncertainty.
• Do not visit a destination to decide whether it is safe.

Read authentication results narrowly

SPF concerns an authorised sending path for an envelope domain; DKIM concerns a signature and signed content. DMARC adds alignment with the visible From domain and policy handling. Read the authentication results added by your trusted receiving system, not arbitrary header text supplied by a sender.

Passing authentication does not prove that the message is benign or the sender is authorised to make the request. An attacker-controlled domain can authenticate its own mail, and a legitimate account can be compromised. A failure can also need context, such as forwarding behaviour.

Review advanced phishing defence →

Correlate identity and application activity

If the report suggests a visit or credential submission, review the relevant sign-in window through authorised tools. Consider session outcomes, MFA events, app consent and mailbox activity. Keep the time zone consistent and do not treat one field as a complete incident conclusion.

Suppose a synthetic packet shows a reported click at 09:10, an unfamiliar sign-in at 09:12 and a denied MFA prompt at 09:13. The denial limits what that attempt establishes; it does not rule out other sessions or grants. Request the missing success and session evidence before writing that the account is safe or compromised.

Review MFA basics →

Review cloud identity foundations →

Choose containment proportional to the evidence

Follow the organisation’s authority and escalation process. Possible defensive actions may include quarantining a confirmed malicious message, revoking affected sessions or reviewing an unauthorised application grant. The correct action depends on the verified scope and operational context.

Preserve relevant evidence and record who approved and executed each change. A password reset alone may not address an active session or delegated application access. Validate the outcome rather than assuming a control worked because someone clicked its button.

Write the handoff another analyst needs

State the trigger, timeline, evidence, current scope, confidence and next owner. Include what has been contained and what remains unresolved. Do not inflate a suspected event into a confirmed account compromise to make the report sound decisive.

For practice, repeat your assessment after adding a confirmed unauthorised mailbox rule. Explain how that new evidence changes scope, severity, containment and evidence priorities. The released Pro SOC lab gives you a complete synthetic packet and worked reviews for this kind of reasoning.

Open the SOC phishing-triage lab preview →

Check the free phishing lesson →