Incident Play Book:

Phishing

Issue: 1.0
Issue Date: September 12, 2017
Copyright © 2017 Independent Electricity System Operator. Some Rights Reserved.

The following work is licensed under the Creative Commons Attribution 4.0 International
License.

Under the terms of this license, you are permitted to:

• Share — copy and redistribute the material in any medium or format
• Adapt — remix, transform, and build upon the material for any purpose, even
commercially.

The IESO as licensor cannot revoke these freedoms as long as you follow the following license
terms:

Attribution — You must give appropriate credit, provide a link to the license, and indicate if
changes were made. You may do so in any reasonable manner, but not in any way that suggests
the licensor endorses you or your use.

To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/

Table of Contents

Contents
1. Introduction ................................................................................................................................... 3
1.1 Purpose of the Phishing Playbook ................................................................................. 3
1.2 Scope................................................................................................................................... 3
1.3 Assumptions and Limitations ........................................................................................ 3
2. Phishing Playbook ....................................................................................................................... 4
2.1 Phishing Definition .......................................................................................................... 4
2.2 Process Summary ............................................................................................................. 4
2.3 Phishing Playbook Procedures ....................................................................................... 6
2.3.1 Identification Stage .................................................................................................... 6
2.3.2 Triage Stage................................................................................................................. 9
2.3.3 Investigation Stage ................................................................................................... 10
2.3.4 Remediation Stage ................................................................................................... 13
2.3.5 Post-Incident Stage .................................................................................................. 15
List of Figures

Figure 2-1: Phishing Incident Response Workflow......................................................................... 5

Figure 2-2: Identification Process ...................................................................................................... 6
Figure 2-3: Triage Process ................................................................................................................... 9
Figure 2-4: Investigation Process ..................................................................................................... 10
Figure 2-5: Remediation Process...................................................................................................... 14
Figure 2-6: Post-Incident Process ..................................................................................................... 15

List of Tables

Table 2-1: Process Stage Descriptions ............................................................................................. 4

Table 2-2: Responsibility Index ........................................................................................................ 5
Table 2-3: Identification Procedures ................................................................................................ 6
Table 2-4: Triage Procedures ............................................................................................................ 9
Table 2-5: Investigation Procedures .............................................................................................. 10
Table 2-6: Remediation Procedures ............................................................................................... 14
Table 2-7: Post-Incident Procedures .............................................................................................. 15
1. Introduction
Playbooks define the procedures for security event investigation and response. Each security
monitoring use case will generally have a corresponding playbook, which allows a responder to
follow a structured methodology for validating and responding to each unique security alert.
The playbook for a specific use case is a living document; updates are encouraged in order to
capture current procedures and unique guidance, in order to quickly respond and contain the
detected event or incident.

1.1 Purpose of the Phishing Playbook

Phishing has become a serious concern for organizations in all industries. Threat actors often
leverage phishing tactics to entice victims into providing valuable information such as
credentials in an effort to gain an initial foothold into the environment.
The procedures in this playbook will assist the Security Operations team in responding to
Phishing related alerts. The response procedures will include validating Phishing emails,
understanding the impact, and determining the best containment approach for the incumbent
threat. The remediation process ends with resolving any potential impact and implementing
preventative controls to protect systems.

1.2 Scope

The scope of this document includes any phishing related events or alerts that are either
identified during daily security operations, or is otherwise escalated to the Security Operations
team. Security Operations owns this procedure and is responsible for maintenance activities,
including reviews and revisions.

1.3 Assumptions and Limitations

This document is to be used as a reference for the following security roles:

• Level 1 (L1) Security Operations Center (SOC) – 24x7 security monitoring team that
reviews and performs initial investigation into security alerts.
• Level 2 (L2) Incident Analyst – Perform incident investigation and response for
frequently occurring or more common security events.
• Level 2 (L2) Incident Specialist – Handles confirmed major incidents, or attacks
attributed to a targeted attacker.
This document version is limited to the current environment and the currently deployed
technology in its current configuration state within. Procedures should be regularly updated to
include any new and relevant technology. Furthermore, all investigation and analysis activities
must be performed in a lab environment with limited internet connectivity or a dedicated
internet connection that is not attributable.
 – End of Section –

2. Phishing Playbook

2.1 Phishing Definition

Phishing is when an attacker attempts to collect sensitive information such as usernames,

passwords, credit card details, Social Security Numbers, Protect Health Information and other
personal or protected data, often for malicious reasons, by masquerading as a trustworthy entity
in an electronic communication. The term is sometimes confused with emails that contain
malware intended to infect the recipient’s system; however, the appropriate term for those types
of emails is “malspam” or “Malicious SPAM Emails”. Those types of events should follow the
Malicious Code Playbook.

2.2 Process Summary

The workflow below depicts the five stages of the phishing Incident Response (IR) process.

Identification Triage Investigation Remediation Post-Incident

Table 2-1: Process Stage Descriptions

Process Description

Identification This stage includes the identification and initial scoping of

a security alert.
Triage This stage includes verifying if the security alert is an
incident, the severity of the incident, and additional
analysis.
Investigation This stage involves investigating the security incident in
detail, ensuring all information is documented.
Additionally, the investigator will have fully scoped the
incident by the end of this stage.
Remediation This stage includes containment and remediation steps for
mitigating and eradicating the threat.
Post-Incident This stage includes a final review of the investigation
record by the L2 – Incident Specialist, ensuring nothing
was overlooked. Once completed, the record is closed.
Figure 2-1 below illustrates a high-level overview of the Phishing IR workflow. This diagram
should be used as a quick reference for Phishing-related investigations. For detailed procedures
for each of the sub-processes, refer to the Phishing Playbook Procedures section.

Figure 2-1: Phishing Incident Response Workflow

Throughout the workflow, a specific level of the security organization as per the diagram above
and the table below, will handle each phase of the incident and be responsible for the actions
therein.

Table 2-2: Responsibility Index

Phase Responsibility Index
Identification (L1) SOC
Triage (L2) Incident Analyst
Investigation (L2) Incident Analyst
Remediation (L2) Incident Analyst
Post-Incident (L2) Incident Specialist
2.3 Phishing Playbook Procedures

2.3.1 Identification Stage

The Identification stage deals with the identification and initial scoping of a security alert.

Identification Triage Investigation Remediation Post-Incident

Figure 2-2: Identification Process

Table 2-3: Identification Procedures

(L1 – SOC) Identification

- IBM QRadar
- Case Management Utility (CMU)
- Symantec Endpoint Protection (SEP)
Relevant Tools
- Symantec Email Security, BrightMail
- Websense
- TippingPoint

1. Initial Alert: Phishing Attack

a) For SIEM Alerts – L1 will be alerted to potential phishing emails from
the SIEM solution.
b) For all other alerts – L1 will be alerted to a potential phishing email
from other, non-SIEM sources.
Procedures
2. Create an Investigation Record
An investigation record is opened for each discrete alert within the CMU
and all pertinent investigative data is recorded there. Duplicate events or
events that are components of the same investigation can be aggregated
in a previously opened case, provided the investigation record is still in
the opened state.
3. Validate that the original message headers are present
The L1 initially inspects the email message’s original headers. To do so,
the L1 must receive the original email sent to them as an attachment to a
secondary email. If an email is received by using the email “forward”
feature, the L1 must respond to the initial sender (i.e. internal recipient of
suspicious email) and request that they attach the original message to a
new email as an attachment and send it to the <SOC> email.

4. Message Data Gathering

During the Data Gathering process, the L1 gathers relevant data
regarding the alert based on the type of alert and the sources of
information available to them. In the case of a phishing, the following
details should be collected:
- Sender Email Address
- Recipient Email Address(es)
- Subject Line
- Sending server IP Address
- X-Originating-IP (or similar, if available)

5. Record Message Delivery Ratio and Impacted Users

Perform a query on Symantec Email Security for related messages.
Search based on unique identifiers that will identify all email messages in
the phishing campaign. Multiple searches may be necessary, as a simple
search by Subject or Sender may not identify all related messages from
the campaign. Attackers will vary fields, such as using differing subject
lines throughout the duration of a campaign in order to evade detection.
In the case of a phishing, the following details should be collected:
- Number of emails in the campaign that successfully bypassed
Symantec Email Security and/or BrightMail
- Number of emails in the campaign blocked by Symantec Email
Security and/or BrightMail
- Record User IDs of users that received the phishing email

6. Email Attachment Collection

If the original email message contains a file attachment, collect the file
safely and store it within a password protected zip-file, using the
password ‘infected’. Attach this file to the investigation record.

7. Domain & URL Profiling

Profile the domain and URL that is contained within the message (if
applicable):
 - Record the full URL to the phishing webpage.
- Record VirusTotal.com results by searching the URL.
o Do not submit the URL to VirusTotal; make sure you only
perform a URL search.
- Submit URL to URLVoid.com and record Safety Reputation score
and Report URL.
- Submit IP address to IPVoid.com and record Detection Ratio and
Report URL.
- Use http://www.toolsvoid.com/whois-lookup to search the
WHOIS registration information, save it in a .TXT file and attack it
to the investigation record.
- Search the URL on PhishTank.com to validate if it has already
been reported as a Phish.
- Additionally, search the URL or any related IP addresses using
https://otx.alienvault.com or
https://exchange.xforce.ibmcloud.com and report the URL and
findings in the investigation record.

Sample Template
Note: Numbers below may vary as services are upgraded.
VirusTotal: <#> / 54
<VirusTotal URL>

URLVoid: <#> / 26
<URLVoid url>

IPVoid: <#> / 40
<IPVoid url>

URLQuery: <Alerts> / <IDS>

<URLQuery url>

PhishTank Result:
<PhishTank URL>

8. Escalate
The L1 escalates the investigation to the L2 – Incident Analyst.
2.3.2 Triage Stage

The Triage stage deals with verifying if the security alert is an incident, the severity of the
incident, and additional analysis.

Identification Triage Investigation Remediation Post-Incident

Figure 2-3: Triage Process

Table 2-4: Triage Procedures

(L2 – Incident Analyst) Triage

- Case Management Utility (CMU)
Relevant Tools - Symantec Email Security, BrightMail
- Dynamic malware analysis sandbox

1. Known False Positive

If this alert is a known false positive that is in progress of being tuned out,
close the investigation at this point.

2. Phishing Email vs. Malicious Email

Based on inspection of the message, does the message constitute a
phishing email, or an email containing malware or links to malicious
code? If applicable, submit the email attachment (previously attached to
the investigation record) to the dynamic malware analysis sandbox and
attach the resulting report to the investigation record. If the file
Procedures
attachment is malicious or contains malicious code, refer to the Malicious
Code Playbook.
3. Spear-Phishing Email Verification
Does the email appear to be sophisticated and highly targeted at the
organization and any specific individuals? Does the phishing campaign
follow any of these attributes (not limited to):
- Small number of users received the email
- Not a generic mass-mail type message (e.g., mentions our
organization)
- Impersonation of anyone within our organization
 - Embedded links or attachments are purporting to be documents
related to our organization
If the email is deemed to be highly targeted, refer to the Targeted Attack
Playbook.

4. Declare Incident, Determine the Incident Priority, and Open the

Incident Ticket
Use the Excel-based Incident Priority Calculator to calculate a priority
rating for this case based on the available information collected during
the first two phases of the investigation. Open an Incident Ticket in HP
Service Manager.
5. Escalate
If the Incident Priority rating is P1 or P2, escalate the incident to the L2 –
Incident Specialist for further investigation.

2.3.3 Investigation Stage

The Investigation stage deals with investigating the security incident in detail, ensuring all
information is documented. Additionally, the investigator will have fully scoped the incident by
the end of this stage.

Identification Triage Investigation Remediation Post-Incident

Figure 2-4: Investigation Process

Table 2-5: Investigation Procedures

(L2 – Incident Analyst) Investigation

- Symantec Endpoint Protection (SEP)
- CheckPoint, Cisco ASA Firewalls
- Symantec Email Security, BrightMail
Relevant Tools
- Websense
- TippingPoint
- Mandiant Redline
 - EnCase Enterprise
- Wireshark

1. Analyze Email Header

Examine the email header for the following phishing attributes:
- Return-Path field contains an email address that is not related to
the the name shown in the From field in the original email.
- The X-Authenticated-User field contains an email address which
appears suspicious (e.g., johnsmith@unknowndomain.ru).
- The Mail Server IP address in header is known to be malicious.
o Search the IP address on
http://mxtoolbox.com/blacklists.aspx
- The email domain is known to be malicious.
o Search the domain on
https://www.ultratools.com/tools/spamDBLookup

Email header details, including external tool search results, must be

recorded in the investigation record.

2. Determine Phishing Page Submission URL

Analyze the phishing page URL and determine where the page posts the
Procedures related data.
Option 1:
- Load the URL in ToolsVoid URL Content Dump:
http://www.toolsvoid.com/url-dump.
- Copy and paste the contents from the “Downloaded RAW Data”
section into http://jsbeautifer.org/ and click “Beautify JavaScript or
HTML”.
- Copy the beautified data into a text editor (e.g., Notepad++) for
analysis.
- Search for the FORM object. Typically, a search for <form will
identify this quickly. Ensure you are looking at the form that has
the method=”post” and is the main submission form, not a search
bar or some other form on the page.
- Read the action parameter and determine the URL where the form
is being posted.
- Record this URL in the investigation.

Option 2:
- Open the URL in your browser and prepend the phrase “view-
 source:” to the URL. This will retrieve the files to your browser
but it will present the source code to you, and will not execute the
code or render the page.
- Copy and paste the contents section into http://jsbeautifier.org/
and click “Beautify JavaScript or HTML”.
- Copy the “beautified data” into a text editor (e.g., Notepad++) for
analysis.
- Search for the FORM object. Typically, a search for <form will
identify this quickly. Ensure you are looking at the form that has
the method=”post” and is the main submission form, not a search
bar or some other form on the page.
- Read the action parameter and determine the URL where the form
is being posted.
- Record this URL in the investigation.

Option 3:
- Start Wireshark and commence a Packet capture (disable
Promiscuous Mode).
- Access the Phishing URL in a web browser with JavaScript
enabled.
- Fill in the Phishing page form with false data and submit the form.
- Close the page and stop the packet capture.
- Apply a filter in Wireshark for http.request.uri contains “phishing
domain”
o The quotation marks are important and the content within
them should be the actual domain from the investigation
and not the words phishing domain
o This identifies the initial request made by the user when
loading the phishing form page
- Click on the line item, note the packet number, and clear the filter.
- Review the following lines of traffic to understand where the
request was submitted.
- Apply a filter in Wireshark for http.request.method == POST
o This identifies the POST request made by the user when
submitting the form.
- Alternatively:
o Click File
o Click Export Objects (near the bottom)
o Select HTTP
 o Once the packets have been processed, a dialog box will
appear labelled “Wireshark: HTTP object list”
o Review the list for a quick summary view of the HTTP
transactions that occurred during the packet capture
o Identify the traffic that immediately follows the access to
the phishing domain

3. Review Proxy Logs for Evidence of Access to Phishing Page URL

Run a Websense report summarized by user with verdict “Allowed” on
the domain hosting the phishing page. Record the list of user IDs in the
investigation record.

4. Review Proxy Logs for Evidence of Phishing Click-Through

Submission Page
Run a Websense report summarized by user with verdict Allowed on the
domain hosting the phishing submission page. Record the list of user IDs
in the investigation record.
5. Affected User Profiling
Profile the users that have clicked through to the submission page and
record this information in the investigation record.
- Record User ID
- Look up and record user’s name, title, department, physical
location

6. Escalation Verification – Recalculate Priority Rating

Using the information that has been gathered at this point, recalculate the
incident priority rating using the Excel-based Incident Priority Calculator.
If the priority has been raised to a P1 or P2, escalate to the L2 – Incident
Specialist. Additionally, engage Security Operations Management to
initiate the Crisis Response Plan (CRP) as necessary.

2.3.4 Remediation Stage

The Remediation stage deals with containment and remediating steps for mitigating and
eradicating the incident.

Identification Triage Investigation Remediation Post-Incident

 Figure 2-5: Remediation Process

Table 2-6: Remediation Procedures

(L2 – Incident Analyst) Remediation

- Case Management Utility (CMU)
- HP Service Manager
Relevant Tools - Symantec Email Security, Brightmail
- Websense
- PhishTank

1. Implement a Symantec Email Security Block

Provide Symantec with a copy of the email for them to create a blocking
rule on future messages of this type. If Symantec Email Security is unable
to provide an explicit block on these exact messages from being received
in the future, implement a custom rule within Symantec Email Security to
prevent further messages matching the sample email.

2. Update Web Proxy

Submit the URL of the phishing page to Websense for categorization.

3. Submit URL to PhishTank

Procedures Submit the URL of the phishing page to PhishTank for categorization.

4. Change Affected User’s Credentials

Affected users should change their passwords for all systems that may
have been compromised by the information submitted to the phishing
submission page.

5. Monitor System and User Account for Possible Misuse

Monitor the system and user account of the victim of the phishing attack
for any possible misuse related to the possible harvesting of credentials
related to the phishing attack.
6. Update the Investigation Record
The investigation record will be updated with all actions performed.
2.3.5 Post-Incident Stage

The Post-Incident stage includes a final review of the investigation record by the L2 – Incident
Specialist, ensuring nothing was overlooked. Once completed, the record is closed.

Identification Triage Investigation Remediation Post-Incident

Figure 2-6: Post-Incident Process

Table 2-7: Post-Incident Procedures

(L2 – Incident Specialist) Post-Incident

- Case Management Utility (CMU)
Relevant Tools
- HP Service Manager

1. Review Investigation Record

Review the investigation record in the CMU and verify that all pertinent
information, including details about the investigation as well as steps
taken by the investigator are recorded accurately.

2. Document Failed Controls

Update the investigation record with the controls that failed to prevent or
detect this incident from occurring.

3. Close the Investigation Record

Resolve the investigation record in the CMU and any incident
Procedures remediation tickets in the HP Service Manager.

4. Create Incident Review Report

For incidents with a P1 or P2 rating, an After Action Report should be
created. Refer to the Playbooks Supporting Content document for more
details.

5. Improve/Update
Determine if there were area(s) for improvement or if updates are needed:
i. Update documentation (e.g., use cases, playbooks, SOPs)
ii. Create new SIEM Alerts/IOCs as needed
iii. Review Technical & Policy Controls - Review additional
technology changes, countermeasures, additional controls, or
policy changes

– End of Document –