Phishing Report Investigation Runbook
Operational runbook for phishing report investigation procedures.
Continue your mission
Operational runbook for phishing report investigation procedures.
# Phishing Report Investigation Runbook
A phishing report investigation runbook establishes standardized procedures for security operations teams to analyze, triage, and respond to suspected phishing incidents reported by end users or automated detection systems. These runbooks serve as operational blueprints that ensure consistent handling of phishing reports across different analysts, shifts, and organizational contexts. By providing detailed step-by-step procedures, decision trees, and verification checkpoints, investigation runbooks eliminate the variability that leads to missed threats, inconsistent response times, and inadequate documentation. They transform what could be an ad-hoc reactive process into a systematic defensive capability that scales with organizational needs while maintaining quality and thoroughness.
A phishing report investigation runbook is a documented operational procedure that guides security analysts through the systematic examination of reported phishing attempts. The runbook encompasses the entire investigative lifecycle, from initial report intake through threat confirmation, impact assessment, containment actions, and final documentation. Unlike general incident response playbooks that address broad categories of security events, phishing investigation runbooks focus specifically on email-based social engineering attacks and their variants, including spear phishing, whaling, and business email compromise scenarios.
The scope extends beyond simple email analysis to include associated infrastructure investigation, payload analysis when attachments or links are present, user impact assessment, and coordination with relevant stakeholders. These runbooks differ fundamentally from automated phishing detection systems, which rely on algorithmic analysis, by incorporating human judgment and contextual analysis that machines cannot provide. They also distinguish themselves from general security awareness training materials by focusing on post-incident analysis rather than prevention education.
Phishing investigation runbooks are not vulnerability assessment procedures, network forensics playbooks, or malware analysis guides, though they may reference these related processes. They specifically address the human-reported suspicion of phishing attempts, whether confirmed or false positive, and provide structured approaches to validate, analyze, and respond to such reports. The runbook scope includes both technical analysis components and business process elements like user communication, management reporting, and regulatory compliance considerations where applicable.
The phishing report investigation process begins with standardized intake procedures that capture essential metadata about the reported incident. When a user submits a suspicious email through reporting mechanisms like dedicated mailboxes, browser plugins, or help desk tickets, the runbook guides analysts through initial triage steps that categorize the report by apparent threat level and required response urgency. This intake phase includes verification that the reporter has preserved the original email with full headers, confirmation of any user actions taken with the suspicious message, and preliminary assessment of potential impact scope.
Initial analysis follows a systematic examination methodology starting with email header analysis to identify routing anomalies, authentication failures, and source reputation issues. Analysts use the runbook's decision trees to evaluate SPF, DKIM, and DMARC authentication results while considering legitimate forwarding scenarios that might cause authentication failures. The procedure includes specific commands for header analysis tools and interpretation guidelines for common header manipulation techniques used by attackers. For example, when examining a suspected business email compromise attempt, the runbook would guide analysts through comparison of the sender's domain against known legitimate domains, analysis of display name spoofing techniques, and verification of reply-to address manipulation.
Content analysis procedures within the runbook address both textual and attachment components of reported emails. The runbook provides linguistic analysis guidelines that help identify common phishing indicators like urgency language, authority appeals, and credential harvesting requests while accounting for legitimate business communications that might exhibit similar characteristics. When emails contain attachments, the runbook specifies safe analysis procedures using isolated environments, hash-based reputation checking, and static analysis techniques before considering dynamic analysis options.
URL analysis represents a critical component where runbooks detail safe investigation procedures for suspicious links. This includes techniques for URL expansion without triggering malicious payloads, domain reputation analysis using threat intelligence sources, and identification of URL shortening services commonly abused by attackers. The runbook specifies when to use automated analysis tools versus manual investigation and provides decision criteria for escalating to specialized malware analysis teams.
A concrete scenario demonstrates these procedures in practice: An executive assistant reports receiving an urgent wire transfer request from the CEO while knowing the CEO is traveling. The runbook guides the analyst through examining the email headers to identify that while the display name matches the CEO, the actual sender domain uses a character substitution technique (homograph attack). The procedure includes verification steps to contact the legitimate CEO through alternative communication channels, documentation requirements for the spoofing attempt, and escalation procedures to both legal counsel and the executive protection team. The runbook specifies timeline requirements for each step and includes template communications for notifying relevant stakeholders.
User impact assessment procedures help analysts determine the scope of potential compromise. The runbook includes interview templates for affected users, guidance on identifying credential compromise indicators, and procedures for coordinating with IT teams to implement protective measures like password resets or account monitoring. When multiple users report similar phishing attempts, the runbook provides escalation criteria for declaring broader security incidents and invoking organizational incident response procedures.
Documentation requirements specified in the runbook ensure consistent record keeping that supports trend analysis, threat intelligence development, and regulatory compliance needs. The procedure includes required evidence preservation steps, standardized reporting templates, and integration points with security information and event management (SIEM) systems or ticketing platforms. Quality assurance checkpoints throughout the process help supervisors validate analyst work and identify training needs or procedure improvements.
Containment and mitigation procedures address both immediate protective actions and longer-term security improvements. The runbook specifies when and how to implement email filtering rules, conduct additional user awareness training, and coordinate with threat intelligence teams to share indicators of compromise. Integration with email security tools allows for rapid implementation of protective measures across the organization when new phishing campaigns are identified.
Phishing attacks remain the primary initial access vector for advanced persistent threats and cybercriminal organizations, making effective investigation capabilities essential for organizational defense. Without standardized investigation runbooks, security teams often exhibit inconsistent response quality, leading to missed threats that successfully compromise user credentials or deliver malware payloads. The business impact of ineffective phishing investigation extends beyond immediate security concerns to include regulatory compliance failures, customer trust erosion, and financial losses from successful business email compromise schemes.
The absence of structured investigation procedures frequently results in analysis paralysis where junior analysts spend excessive time on obvious false positives while rushing through complex threats that require thorough examination. Organizations without investigation runbooks typically experience significant variation in response times and quality based on individual analyst experience and availability. This inconsistency undermines the security program's effectiveness and creates gaps that sophisticated attackers can exploit through timing-based attacks or analyst fatigue scenarios.
Real-world consequences of inadequate phishing investigation procedures became evident in the 2016 Democratic National Committee breach, where initial spear-phishing emails were reported by users but not investigated with sufficient rigor to prevent credential compromise. The subsequent investigation revealed that standardized procedures for analyzing reported phishing attempts might have identified the attack's sophistication level and triggered appropriate escalation procedures. This incident demonstrates how investigation quality directly impacts an organization's ability to prevent initial compromise and limit attacker persistence within networks.
Common misconceptions among security practitioners include the belief that automated phishing detection systems eliminate the need for human investigation procedures or that phishing reports primarily represent false positives that require minimal analysis. In practice, automated systems generate numerous false positives while potentially missing sophisticated spear-phishing attempts that target specific individuals with carefully crafted social engineering approaches. Human analysis guided by standardized runbooks provides the contextual understanding necessary to identify advanced threats that evade automated detection mechanisms.
Another significant misconception involves treating phishing investigation as purely technical analysis work rather than recognizing its critical business process components. Effective investigation requires coordination with legal teams for regulatory reporting, human resources for user education needs, executive leadership for business email compromise attempts, and external partners for supply chain security concerns. Organizations that focus solely on technical analysis often fail to address the broader business risks associated with phishing attempts and miss opportunities for strategic security improvements based on attack trends and patterns.
The Cyber Defense Army approaches phishing report investigation through the Predictive Defense Intelligence (PDI) methodology within the Threat Intelligence Development (TID) domain, emphasizing proactive threat pattern recognition rather than reactive incident analysis. CDA's investigation runbooks incorporate forward-looking analysis that identifies emerging attack techniques and anticipates threat actor evolution based on observed phishing campaign characteristics. This approach differs from conventional reactive investigation by treating each phishing report as a data point in larger threat intelligence development efforts rather than an isolated incident requiring resolution.
CDA runbooks implement structured threat actor attribution procedures that connect individual phishing attempts to broader campaign patterns and known threat groups. This attribution capability enables predictive assessments of likely follow-on attacks and helps organizations prepare defenses against anticipated threat evolution. The runbooks include specific procedures for extracting threat intelligence indicators that feed into organizational threat modeling processes and strategic security planning efforts.
The PDI methodology emphasizes investigation procedures that identify weak signals indicating new attack methodologies before they become widespread threats. CDA runbooks include analysis steps designed to detect subtle changes in phishing techniques, emerging social engineering approaches, and novel technical tactics that might indicate threat actor adaptation or new group emergence. This forward-looking analysis helps organizations implement defensive measures against threats that have not yet reached widespread deployment.
CDA's approach integrates phishing investigation directly with strategic threat assessment processes, ensuring that operational incident response contributes to enterprise-level security decision making. The runbooks specify escalation procedures that connect tactical investigation findings with strategic threat assessment teams responsible for organizational risk management and security investment decisions. This integration ensures that phishing investigation efforts directly support broader security program effectiveness rather than operating as isolated tactical activities.
Operational differentiation in CDA runbooks includes emphasis on threat actor capability assessment and intent analysis that helps organizations understand not just what happened during a phishing attempt, but what the attack indicates about adversary capabilities and likely future activities. This assessment capability enables more effective resource allocation and strategic security planning based on actual threat actor behavior patterns rather than generic threat landscape assumptions.
• Implement decision trees with specific timing requirements for each investigation phase to prevent analysis paralysis and ensure consistent response quality across different analysts and organizational contexts.
• Establish direct integration between phishing investigation findings and organizational threat intelligence processes to transform reactive incident analysis into proactive threat preparation and strategic security planning.
• Create standardized evidence preservation procedures that capture email headers, user action timelines, and environmental context to support forensic analysis, legal proceedings, and threat intelligence development requirements.
• Develop escalation criteria based on threat sophistication indicators rather than simply impact scope to ensure that advanced persistent threat activities receive appropriate investigation resources and management attention.
• Build investigation procedures that incorporate business context analysis, including organizational hierarchy verification and process validation, to identify business email compromise attempts that technical analysis alone might miss.
• Email Security Architecture Design Patterns • Business Email Compromise Detection Methodologies • Threat Intelligence Development in Security Operations • User-Reported Security Incident Triage Procedures • Social Engineering Attack Pattern Analysis • Security Operations Center Workflow Optimization
• NIST Special Publication 800-61 Rev. 2: Computer Security Incident Handling Guide - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
• MITRE ATT&CK Framework: Initial Access Techniques (T1566 Phishing) - https://attack.mitre.org/techniques/T1566/
• Anti-Phishing Working Group Phishing Activity Trends Report - https://apwg.org/trendsreports/
• Center for Internet Security Controls Version 8: Email and Web Browser Protections - https://www.cisecurity.org/controls/v8
• SANS Institute: Incident Handler's Handbook - https://www.sans.org/white-papers/incident-handlers-handbook/
CDA Theater missions that address topics covered in this article.
Rogue access point detection identifies unauthorized wireless APs on the network using WIPS sensors, wired-side monitoring, and signal triangulation to prevent network bypass.
LLM security risks include data leakage, prompt injection, model supply chain attacks, and unauthorized tool execution, requiring organizations to treat AI models as high-privilege components.
How physical security failures enable cyber attacks, from tailgating and shoulder surfing to device theft and dumpster diving.
Written by CDA Editorial
Found an issue? Help improve this article.