Phase 6: Determine Verdict

This phase focuses on evaluating all the evidence and deciding on the phishing case's final disposition (and suggested action). The goal is to issue a clear, documented verdict that informs appropriate incident response actions.

The output of this phase is essential in:

• Preventing overreaction to false positives (e.g., legitimate marketing emails)

• Avoiding under-response to genuine threats (e.g., credential harvesting, malware)

• Enabling efficient communication between SOC teams, IT, IR, and affected users

• Feeding threat intel back into detection systems for future prevention

Step 1: Revisit and Correlate All Analysis Phases

Use the case notes or incident record to summarize findings from:

• Phase 1: Delivery method (email, SMS, etc.)

• Phase 2: Collected artifacts

• Phase 3: Content red flags (social engineering, link behavior)

• Phase 4: Sender authenticity and authentication check results

• Phase 5: Threat intel and IOC enrichment results

TIP: Create a summary sheet or bullet points to visualize the IOCs evidence, timeline stack, and associated IOC enrichment details.

Step 2: Classify the Verdict

Terminology will vary from organization to organization and system to system, but the classification logic will apply. Reported phishing attacks will take on one of the following classifications:

Benign (Legitimate)

• The message is non-malicious and from a legitimate source.

• Action: No response needed. Optionally, whitelist the sender or educate users on why the email is safe.

• For reference, collected IOCs/artifacts will return the following results:

  • All SPF/DKIM/DMARC checks pass

  • The domain is verified and established

  • No phishing lures or suspicious content (URLs are safe)

  • IOCs clean across multiple platforms

Suspicious (Gray Area)

• The message has unusual characteristics but lacks definitive indicators of malicious intent.

• Action: Monitor, report internally, and potentially notify the recipient. Escalate for further sandbox or threat hunting review. Add to the watchlist or SIEM correlation rules.

• It is difficult to provide a definitive assessment as some IOCs will generate no alerts on Threat Intelligence platforms or point to poorly configured systems/services. For example:

  • SPF pass, DKIM fail, or vice versa - Poorly configured legitimate domains?

  • Link leads to login page but not yet flagged - New phishing domains?

  • Language is off-tone or odd - Non-malicious sender using generative AI

  • One or two threat tools show warnings, rest are clean - Weak evidence of malicious behavior

Malicious (Confirmed Phishing)

• The message is malicious with clear indicators of phishing or compromise.

• Action: Trigger incident response steps — containment, user notification, IOC blocking, threat hunting.

• All indicators/IOCs will return true positive for a confirmed threat. For example:

  • Failed authentication (SPF/DKIM/DMARC) and spoofed domain

  • URL leads to a phishing kit or a credential harvesting site

  • Attachments drop malware or request enabling macros

  • Multiple IOCs flagged by VirusTotal, OTX, AbuseIPDB

  • Social engineering elements present

Alternatively, some organizations or SIEM/SOAR systems will use a risk score or confidence level for classification to improve triage and support automation.

Step 3: Document the Verdict

In the respective case management system (TheHive, RTIR, Jira, Splunk), record the following for each phishing incident:

• Final verdict - 

• Evidence Summary - 

• Reasoning - 

• Action Plan - 

• Verdict/Report Timestamp 

This documentation is essential for audit trails, post-incident reviews, and knowledge sharing.

Common Mistakes to Avoid

• Assuming anything internal is safe (accounts can be compromised)

• Ignoring suspicious behavior if the domain looks legitimate

• Relying on a single source (e.g., only VirusTotal) for intel

• Skipping documentation because “it's obvious”

Examples of Verdicts

Example 1: 

• SPF & DKIM fail

• URL points to secure-paypa1[.]com

• VirusTotal flags the domain as a phishing domain

• Risk Score: 100 

• Action: Quarantine email, alert user, block domain

Example 2:

• Email from marketing@stripe.com

• SPF, DKIM, DMARC pass

• Link resolves to legitimate stripe.com URL

• Verdict: Benign

• Action: None required

Example 3:

• Unknown sender with a Dropbox link

• No SPF or DKIM record

• URL not flagged, but newly registered domain

• Verdict: Suspicious

• Action: Escalate for deeper analysis and temporary user watch