Incident Play Book: Phishing

Size: px

Start display at page:

Download "Incident Play Book: Phishing"

Amy Norris
5 years ago
Views:

1 Incident Play Book: Phishing Issue: 1.0 Issue Date: September 12, 2017

2 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

3 Table of Contents Contents 1. Introduction Purpose of the Phishing Playbook Scope Assumptions and Limitations Phishing Playbook Phishing Definition Process Summary Phishing Playbook Procedures Identification Stage Triage Stage Investigation Stage Remediation Stage Post-Incident Stage... 15

4 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 Figure 2-5: Remediation Process Figure 2-6: Post-Incident Process 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 Table 2-6: Remediation Procedures Table 2-7: Post-Incident Procedures... 15

5 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 s, 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.

6 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 s that contain malware intended to infect the recipient s system; however, the appropriate term for those types of s is malspam or Malicious SPAM s. 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 Identification Triage Investigation Remediation Post-Incident Description This stage includes the identification and initial scoping of a security alert. This stage includes verifying if the security alert is an incident, the severity of the incident, and additional analysis. 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. This stage includes containment and remediation steps for mitigating and eradicating the threat. 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.

7 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: Phase Identification Triage Investigation Remediation Post-Incident Responsibility Index Responsibility Index (L1) SOC (L2) Incident Analyst (L2) Incident Analyst (L2) Incident Analyst (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.

8 2.3 Phishing Playbook Procedures 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: Table 2-3: Identification Process Identification Procedures - IBM QRadar (L1 SOC) Identification - Case Management Utility (CMU) Relevant Tools Procedures - Symantec Endpoint Protection (SEP) - Symantec Security, BrightMail - Websense - TippingPoint 1. Initial Alert: Phishing Attack a) For SIEM Alerts L1 will be alerted to potential phishing s from the SIEM solution. b) For all other alerts L1 will be alerted to a potential phishing from other, non-siem sources. 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.

9 3. Validate that the original message headers are present The L1 initially inspects the message s original headers. To do so, the L1 must receive the original sent to them as an attachment to a secondary . If an is received by using the forward feature, the L1 must respond to the initial sender (i.e. internal recipient of suspicious ) and request that they attach the original message to a new as an attachment and send it to the <SOC> 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 Address - Recipient 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 Security for related messages. Search based on unique identifiers that will identify all 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 s in the campaign that successfully bypassed Symantec Security and/or BrightMail - Number of s in the campaign blocked by Symantec Security and/or BrightMail - Record User IDs of users that received the phishing 6. Attachment Collection If the original 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):

10 - 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 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 or 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.

11 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: Table 2-4: Triage Process Triage Procedures (L2 Incident Analyst) Triage - Case Management Utility (CMU) Relevant Tools - Symantec 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. Procedures 2. Phishing vs. Malicious Based on inspection of the message, does the message constitute a phishing , or an containing malware or links to malicious code? If applicable, submit the 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 attachment is malicious or contains malicious code, refer to the Malicious Code Playbook. 3. Spear-Phishing Verification Does the 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 - Not a generic mass-mail type message (e.g., mentions our organization) - Impersonation of anyone within our organization

12 - Embedded links or attachments are purporting to be documents related to our organization If the 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 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: Table 2-5: Investigation Process Investigation Procedures (L2 Incident Analyst) Investigation - Symantec Endpoint Protection (SEP) - CheckPoint, Cisco ASA Firewalls Relevant Tools - Symantec Security, BrightMail - Websense - TippingPoint - Mandiant Redline

13 - EnCase Enterprise - Wireshark 1. Analyze Header Examine the header for the following phishing attributes: - Return-Path field contains an address that is not related to the the name shown in the From field in the original . - The X-Authenticated-User field contains an 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 - The domain is known to be malicious. o Search the domain on header details, including external tool search results, must be recorded in the investigation record. Procedures 2. Determine Phishing Page Submission URL Analyze the phishing page URL and determine where the page posts the related data. Option 1: - Load the URL in ToolsVoid URL Content Dump: - Copy and paste the contents from the Downloaded RAW Data section into 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-

14 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 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

15 o o o Once the packets have been processed, a dialog box will appear labelled Wireshark: HTTP object list Review the list for a quick summary view of the HTTP transactions that occurred during the packet capture 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 Remediation Stage The Remediation stage deals with containment and remediating steps for mitigating and eradicating the incident. Identification Triage Investigation Remediation Post-Incident

16 Figure 2-5: Table 2-6: Remediation Process Remediation Procedures (L2 Incident Analyst) Remediation - Case Management Utility (CMU) - HP Service Manager Relevant Tools - Symantec Security, Brightmail - Websense - PhishTank 1. Implement a Symantec Security Block Provide Symantec with a copy of the for them to create a blocking rule on future messages of this type. If Symantec Security is unable to provide an explicit block on these exact messages from being received in the future, implement a custom rule within Symantec Security to prevent further messages matching the sample Update Web Proxy Submit the URL of the phishing page to Websense for categorization. Procedures 3. Submit URL to PhishTank 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.

17 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: Table 2-7: Post-Incident Process Post-Incident Procedures (L2 Incident Specialist) Post-Incident Relevant Tools - Case Management Utility (CMU) - 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. Procedures 3. Close the Investigation Record Resolve the investigation record in the CMU and any incident 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

18 technology changes, countermeasures, additional controls, or policy changes End of Document

Incident Report Issue: 1.0 Issue Date: September 12, 2017

Incident Report 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