New Hanover Regional Medical Center€¦ · Web viewIncident Response Procedures Table of...

Date: Owner:

Version #: 1.0 Page #: i of 142

Confidential

Incident Response Procedures

Date: Owner:

Version #: 1.0 Page #: 1 of 142

Information Security Incident Response Procedures

Table of ContentsIRM Incident Response Playbook Notes 5

IRM Document Owner 5Playbooks Last Reviewed 5

Approved Third-Party Incident Response Firms 5Definitions 6Malware Workflows 8

Malware Basics 8Categories of Malware 8

Malware Workflow – Trojans and RATs 10Trojans and RATs – Incident Response Phases 10Trojans and RATs – Incident Response Process 11Trojans and RATs – Decision Charts 15

Malware Workflow – Droppers/Downloaders 18Droppers/Downloaders – Incident Response Phases 18Droppers/Downloaders – Incident Response Process 19Droppers/Downloaders – Decision Charts 22

Malware Workflow – Ransomware 25Ransomware – Incident Response Phases 25Ransomware – Incident Response Process 28Ransomware – Decision Charts 31

Malware Workflow – Malicious Documents 34Malicious Documents – Incident Response Phases 34Malicious Documents – Incident Response Procedures 35Malicious Documents – Decision Chart 37

Malware Workflow – Rootkits 38Rootkits – Incident Response Phases 38Rootkits – Incident Response Process 40Rootkits – Decision Charts 43

Malware Workflow – Viruses 46Virus – Incident Response Phases 46Virus – Incident Response Process 47Virus – Decision Charts 49

“Generic” Malware Incident Response 52General Malware IR – Incident Response Phases 52General Malware IR – Incident Response Process 53General Malware – Decision Charts 56

Distributed Denial-of-Service (“DDoS”) 59Detection 59Scoping 59Containment 59

1 IRM CONFIDENTIAL https://www.ITSecurityRiskManager.com/

https://www.nhrmc.org/

Date: Owner:



Eradication and Recovery 59DDoS – Incident Response Process 60DDoS – Decision Charts 62

DDoS – Attack Threatened 62DDoS – Attack Underway 63

External/Internal Hacking 64External/Internal Hacking – Summary 64

Detection 64Scoping 64Containment and Eradication 64Remediation 64

External/Internal Hacking – Incident Response Process 65Hacking Decision Chart 66

Phishing 67Phishing – Incident Response Procedures 67

Initial Triage 67Blocking Steps 67Forensic Analysis 68

Phishing Decision Charts 69Phishing – Triage 69Phishing – Blocking Procedures 70

Sensitive Data Disclosure 71Sensitive Data Disclosure – Summary 71

Detection 71Scoping 71

Sensitive Data Disclosure – Incident Response Process 72Sensitive Data Disclosure – Decision Chart 74

Third-Party Data Breach 75Third-Party Data Breach - Summary 75Third-Party Data Breach – Incident Response Process 75

Initial Notification or Identification 75Contractor / Vendor Systems 75Hosted Data or Services 76

Third-Party Data Breach – Decision Chart 78Rogue WiFi Access Point 80

Rogue AP – Summary 80Detection 80Scoping 80Eradication 80

Rogue AP – Incident Response Process 81Rogue AP – Decision Chart 82

Zero Day / Vulnerabilities 83Zero Day/Vulnerabilities – Incident Response Summary 83



Date: Owner:



Detection 83Scoping 83Remediation and Recovery 83

Zero Day/Vulnerabilities – Incident Response Process 84Initial Triage 84Extended Response 84Remediation 85

Zero Day/Vulnerabilities – Decision Charts 86Zero Day Vulnerability – Triage 86Zero Day Vulnerability – Extended Response 86Zero Day Vulnerability – Remediation 87

Hostile Employee Separation Lockout88Hostile Employee Termination – Workflow Summary 88Hostile Employee Termination – Process 88

General Hostile Termination Steps 88Privileged User - Hostile Termination 88

Hostile Employee Termination – Decision Charts 90Hostile Termination – General Workflow 90Hostile Termination – Privileged User Lockout 91

Unauthorized/Inappropriate Access 92Unauthorized/Inappropriate Access – Workflow Summary 92

Detection 92Unauthorized/Inappropriate Access – Incident Response Process 92

Unauthorized / Inappropriate Access – Decision Chart 94Appendix I – Windows Forensic Collection Details 95

Introduction 95Tools Needed 95Pre-acquisition Process: 95Forensic Storage Media 96Virtual Machine Imaging 96Physical: Volatile Memory Capture Instructions 97

Instructions97Physical: Hard Drive Image Capture 99

Hard Drive Imaging Instructions 99Appendix II – Malware Incident Response Notes 105

Common Malware Startup Entries 105Windows Startup Items 105Linux Startup Items 106MacOS Startup Items 107

Tools for Basic Malware Identification 108Windows Tools and Utilities 108Linux Malware Identification Tools and Utilities 108MacOS Tools and Utilities 109



Date: Owner:



Appendix III – IOC Scanning 110Common Filesystem Indicators 110

Yara and CrowdResponse Scans 111Common Network Indicators 111

IOC Sources 112Network IOC Examples 112

Appendix IV – Targeted Phishing 113Overview: What is Phishing? 113

Spear Phishing 113Whale Phishing 113

Combating Phishing 113Anatomy of a Phishing Attack 114Attack Prevention 114

Network Segmentation 115IPS/IDS Systems 115Egress Filtering 115Standardized Antivirus Implementations 115Binary Packet Inspection 115SSL Interception 115Two-Factor Authentication 115User Awareness 115

Visual Examples 115Example 1: Fake Google Drive 115Example 2: Fake IT Administrative Notice 118

Targeted Phishing – Additional Resources 120General 120Awareness Programs and Information 121URL Lookups 121

General122



Date: Owner:





Date: Owner:



IRM Incident Response Playbook Notes

Approved Third-Party Incident Response Firms1.



Date: Owner:





Date: Owner:



Definitions Analysis: The stage in the security incident response lifecycle during which the potential security

incident is verified and prioritized and a plan of action is drafted to resolve the incident.

Backdoor: A program that listens for commands on a network port and allows a remote intruder some degree of control over the compromised system.

Security Incident: The impermissible acquisition, access, use or disclosure that compromises the confidentiality, integrity or privacy of sensitive information, such that the use or disclosure poses a significant risk of financial, reputational or other harm to the affected party.

Chain of Custody Form: The document used in evidence handling to record the location of evidence at all times.

Command and Control (C2): A server that is used to remotely send often malicious commands to a botnet, or a compromised network of computers.

Computer Security Incident Response Team (“CSIRT”): IRM’s incident response team, which is comprised of the Security team as well as stakeholders from the Network Infrastructure, NOC, Client Services, and System Infrastructure teams as needed.

Conduct: The phase in security incident exercise procedures during which the actual scenario is carried out and participants must walk through their responsibilities for the given hypothetical security incident.

Containment: The stage in the security incident response lifecycle during which necessary actions are taken to prevent the incident from affecting additional resources.

Denial-of-service (“DoS”): An action that prevents or impairs the legitimate use of information systems by exhausting computing resources.

Detection: The stage in the security incident response lifecycle during which potential incidents are identified through the use of tools and through user reports.

Distributed Denial-of-service (“DDoS”): A denial of service that is performed by a large volume of attacking hosts, all coordinating to bring down one or more systems.

Eradication: The stage in the security incident response lifecycle during which vulnerabilities that allowed the incident to occur are eliminated and updates are made to prevent the incident from reoccurring.

Evaluate: The phase in exercising procedures during which participants debrief on ways to improve the security incident response process.

Inappropriate Use: The violation of acceptable computing use policies.

Lessons Learned: A meeting with all involved parties that is held after a major security incident to discuss the improvement of security measures and the incident handling process.

Malicious Code or Software (Malware): Software that is secretly inserted into a program with the intent to infiltrate a computer system without the owner's permission or knowledge.

Notification: The stage in the incident response lifecycle during which incidents are escalated to appropriate stakeholders and relevant entities are engaged.



Date: Owner:



Payment Card Industry Data Security Standard (“PCI DSS”): set of requirements designed to ensure that all companies that process, store or transmit credit card information maintain a secure environment.

Personally Identifiable Information (“PII”): Any information about an individual maintained by an agency that can be used to distinguish or trace an individual's identity; any information that is linked or linkable to an individual, such as medical, educational, financial, or employment data.

Phishing: A form of social engineering in which a malicious user masquerades as a trustworthy entity to attain unauthorized access and/or confidential data.

Personally Identifiable Information (“PII”): Information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context.

Plan: The phase in exercising procedures during which the table top design team determines the types of security incidents that should be evaluated.

Recovery: The stage in the security incident response lifecycle during which affected machines are returned to normal operations.

Root-Cause Analysis: An investigation done to determine how an incident occurred and how to minimize the risk of recurrence of similar incidents.

Security Event: Observable activity on a system, network, or application.

Security Incident: An adverse security event that poses a reasonable threat to computer security; typically, security incidents can be classified into one of five categories: denial of service, malicious code, unauthorized access, inappropriate use, or unauthorized disclosure or loss of data.

Security Incident Handling: The analysis and remediation of security incidents, performed in a manner that is meant to mitigate the negative effects of the incident.

Social Engineering: The act of manipulating people to divulge confidential information, which allows a malicious user to bypass security controls and gain access to private resources.

Threat: The potential exploitation of a current vulnerability.

Unauthorized Access: A user gaining access to a resource that he/she was not intended to have.

Virus: A form of malicious code that must insert itself into a host program and can only propagate when the infected program is run.

Vulnerability: A weakness in the security of a system, application, or network that can be exploited and can lead to a security incident.



Date: Owner:


Information Security Incident Response Program Runbook

Malware WorkflowsMalware is a label applied to any kind of executable code or script that is intended to be used for malicious purposes such as information and credential theft, data destruction, and unauthorized network access. The Malware label can also be applied to legitimate software that is used for illicit purposes not intended by the original author.

Malware BasicsThis section is intended to introduce a general overview of the most common types of Malware that affect organizations and the common identification properties of a Malware-borne system compromise. There are many types of programs that fall under the Malware umbrella; these programs frequently share basic commonalities that Incident Responders can use to effectively and efficiently respond to Malware events. Each type of operating system may be infected by any of the types of malware indicted in this document yet the ways to observe how a system may have been compromised are somewhat unique and may require a different response strategy.

Categories of Malware

VirusesThe term virus is often used to refer to all types of malware, but officially, viruses are malicious programs that can replicate themselves and infect other programs. Viruses often cause harm to the computer they infect. Notable viruses include CIH and Michelangelo. Traditional viruses have become less common in recent times.

Viruses are commonly associated with file infector type of functionality. File infector functionality was originally very popular for destructive viruses; however, once malware started being created to generate revenue, the number of new destructive viruses and file infectors diminished. File infecting viruses have recently made a comeback with new sophistication making them ideal for “destructive persistence” in order to stay installed on an infected machine.

Trojans/RATsTrojans and Remote Administration Toolkits are malicious programs designed to give the attacker full control over the compromised machine. The level of sophistication in Trojans and RATs varies, but they are often used in Advanced Persistent Threat (APT) attacks in order to gather information and exfiltrate data. They must be considered extremely high priority in investigations. Common Trojans include Zeus and SpyEye. Common RATs include Gh0stRAT1, Poison Ivy2 and ShadyRAT3. In the case of true APT (Advanced Persistent Threat) attacks, custom tools designed specifically to exploit a target and avoid common detection methods are frequently used.

RootkitsRootkits are a stealthy, malicious type of malware designed to hide the installation and activities of other malware from the user or incident responder in charge of an investigation. Rootkits interact at the system level, thereby rendering many analysis tools useless. Rootkits are generally sophisticated and difficult to detect and analyze, but must be considered extremely high-priority in investigations. Rootkits are one of

1 http://en.wikipedia.org/wiki/Ghost_Rat2 http://www.poisonivy-rat.com/3 http://www.mcafee.com/us/resources/white-papers/wp-operation-shady-rat.pdf



http://www.mcafee.com/us/resources/white-papers/wp-operation-shady-rat.pdf

http://www.poisonivy-rat.com/

http://en.wikipedia.org/wiki/Ghost_Rat

Date: Owner:



the exceptions to the efficacy of evaluating startup entries for signs of infection, due to their ability to run at the System level. In cases where Rootkit activity is suspected, investigators will need to employ rootkit-specific tools and tactics. Examples of popular rootkits include TDSS4 and ZeroAccess5.

Droppers/DownloadersDroppers and downloaders are a category of malware that serve only the purpose of installing additional malware. Many malware attacks will consist of a dropper or downloader as the first stage of the attack, which subsequently installs the payload, which is typically additional malware. The primary difference between droppers and downloaders is that droppers come packaged with the malware components and downloaders typically visit hardcoded URLs, download and install malicious components. Typically, downloaders can be more evasive since they are usually considerably smaller than droppers and the malicious URLs that the downloaders visit are scripted back-ends that can deliver one of thousands of random pieces of malware or targeted malware, depending on the host.

RansomwareRansomware is malware that will encrypt all (or most) data on a computer, as well as any network shares accessible by the infected user’s account. Earlier examples did not necessarily encrypt data but would simply lock a user out of their operating system. Most modern ransomware is based on the concept of encrypting a user’s documents and other potentially valuable data using strong file encrypting, and then forcing the victim to pay the authors via Bitcoin cryptocurrency in order to obtain the decryption key. The malware is particularly problematic in enterprise environments because it can also encrypt data stored on network shares, severely impairing business productivity.

Distribution of Ransomware commonly occurs via drive-by web browser exploit kits, direct malicious email attachments, or via malicious macro-enabled document files. When distributed via malicious documents or drive-by exploit kits, the first stage of the malware is commonly a Downloader Trojan that downloads the actual ransomware binaries.

Malware Workflow – Trojans and RATs

Trojans and RATs – Incident Response Phases

DetectionEndpoint technologies and appliances will most likely detect Trojans and RATs; detection via user notification is rare. This classification of malware is highly likely to be used in targeted attacks, but not all Trojan malware is targeted. In this classification, the malware being a known variant is not a good indicator that the attack is not targeted. Non-targeted Trojans are typically designed to provide attackers

4

5



Date: Owner:



with backdoor access to an infected system, or harvest data on the local machine such as credentials or banking information.

Detection with endpoint technologies or appliance alerts can give a head start to the investigation by identifying the malware family. Internet research about the malware’s family will give important information about remediation and recovery processes and may uncover tools or techniques used to determine the severity of the attack.

ScopingThe first step of the process will be to search for the malware hashes on the Internet. If the malware is a known variant, Internet research will give information about the functionality of the malware, indicators of infection and any other packaged malware. Samples being widely reported or available on publicly available scanning services can be an indicator that the attack is not targeted. However, this is not always the case. In some cases, an attack campaign may be targeted towards a number of corporations or be part of an information-gathering campaign as the first step in a larger attack with the attacker targeting the corporations they deem most valuable or interesting.

If results cannot be gathered from the Internet, AV battery tests must be run. Highly consistent detection names of popular toolkits can be an indicator that an attack is not highly targeted or that it is relatively unsophisticated. However, certain families of malware such as Gh0stRAT, Poison Ivy, ShadyRAT and more have been used in targeted attack campaigns. When RAT tools are used in an attack, they should be analyzed thoroughly. This is especially true with families such as Gh0stRAT where the source is available to the public, allowing for easy modification and addition of functionality. On the other hand, toolkits such as Zeus and SpyEye are unlikely to be used in targeted attacks and may only affect the infected user personally. In responding to Trojan and RAT incidents, strong knowledge of common malware families and their features, uses and popularity for various types of attacks is crucial.

ContainmentIn general, it is preferable to immediately disconnect the infected machine(s) from the network while remediation is planned and executed. The exception to this is in cases where the same malware is being observed on ten or more machines. In those cases, or in cases where the infected computer is used to work with sensitive data, it may be preferable to capture traffic briefly before disconnecting. Inspect any other machines the user has accessed for signs of compromise and if detected, remove from the network. Use network information to block access to IPs and URLs determined to be bad during the course of the investigation.

Eradication and RecoveryThe preferred course of action will be to reimage or reinstall infected hosts. Signature-based scans should be deployed network wide to check for additional infected hosts, especially in the case of Trojans or RATs with self-propagation functionality. Perform manual inspection of a random sampling of hosts accessible by the initial infected host to check for further infections.

Trojans and RATs – Incident Response Process

Initial Triage1. Trojan malware will be detected by McAfee, CrowdStrike, or Red Canary

2. Record any filesystem indicators from infected endpoint in incident notes. Document any other findings of interest.

a. Document suspect filenames/paths, file sizes, and timestamps identified in CrowdStrike and McAfee results.



Date: Owner:



b. Review the infected machine and identify any notable unusual files or live processes.

c. Document any observed open network connections (remote hostname, port, or IP address

i. Check Palo Alto logs for connections using unusual or high TCP ports, as well as common ports such as 22, 23, 80, and 443.

3. Perform Internet Research based on gathered data.

a. Search file hashes

i. MD5

ii. SHA1

b. Search for network contacts

i. URLs

ii. Domains

iii. IP Addresses

c. Submit sample(s) to Palo Alto WildFire sandbox.

i. Record any payload file hashes, contacted URLS/Domains/IP Addresses.

4. IF AFFECTING > 10 SYSTEMS OR SYSTEMS HOSTING SENSITIVE DATA: Capture network packet data moving to/from infected computer using Tap or Span. This data will be helpful if investigating potential data loss.

a. The duration of the capture should be based on the perceived risk to IRM.

i. The determination should be made by the incident commander.

5. If step 4 is not performed, or once the desired capture duration is met, isolate infected endpoint(s) from the network.

a. This occurs once the CSIRT has determined that disconnection is preferable to traffic capture, or once the capture has been concluded.

b. Initial isolation should be performed using CrowdStrike’s isolation functionality.

c. If the host cannot be isolated with CrowdStrike:

i. For wired network connections, ask network team to disable the computer's port until the physical cable can be disconnected.

ii. For wireless network connections, ask network team to block the computer's MAC address.

6. Review network appliances logs for suspect/malicious connections from infected computer.

a. Review Palo Alto web proxy and firewall logs for recent connections to/from the infected computer.

i. Contact Reliaquest to search for all events in the SIEM that may relate to the incident.

b. Record any suspicious IP addresses or hostnames present in logs or identified by ReliaQuest

7. Review detection appliance data.



Date: Owner:



a. Determine if the detection is a generic (Trojan.Gen) or specifically-named (Trojan.Zeus) malware.

b. If detection is generic, send file samples to Crowdstrike and/or McAfee (whichever did NOT detect the malware).

i. If sample is sent to McAfee:

1. Request custom signature DAT file and notification of when sample will be added to definitions.

2. Once new DAT files are provided, deploy the new DAT to all endpoints.

3. Scan entire network using new McAfee signatures to identify additional infected endpoints.

i. Ask the vendors for a functionality writeup. Specifically inquire if malware includes data stealing functionality.

1. If malware includes data stealing functionality, engage third party forensics IR support to validate potential loss.

2. If data loss is confirmed, initiate Sensitive Data Disclosure workflow.

a. If detection is a known family:

i. Determine if malware is one that has previously been observed at IRM.

1. If malware is a familiar variant, proceed to step 8.

i. If malware is a new family/variant:

1. Send samples to Crowdstrike and/or McAfee (whichever did NOT detect the malware).

2. If sample is sent to McAfee:

a. Request custom signature DAT file and notification of when sample will be added to definitions.

b. Once new DAT files are provided, deploy the new DAT to all endpoints.

c. Scan entire network using new McAfee signatures to identify additional infected endpoints.

8. Research functionality based on known Trojan sample characteristics.

a. Virustotal search for filename, hash, associated IPs and domains.

b. Malwr.com search for analysis

c. Google searches for hashes and filenames

d. Review any available Crowdstrike and McAfee analysis and Wildfire sandbox analysis:

i. How does it communicate? What IP addresses and hostnames were contacted?

1. Malware will often attempt to connect to a Google or Microsoft host and IP first to check for internet connectivity.

ii. What kind of data exfiltration features does it have?

iii. Does it spread (worm functionality)?

iv. Does it modify system files or information?



Date: Owner:



v. Does it gather passwords?

vi. Does it log keystrokes or take screenshots?

e. If internal research or Crowdstrike/McAfee analysis indicates that malware family is used for data theft/exfiltration, engage third party forensics IR support to validate potential loss.

f. If data suggests that the attack is targeted specifically at IRM, engage third-party incident response support.

g. If data loss is confirmed, initiate Sensitive Data Disclosure workflow.9. Activate ICC if incident reaches Medium or High severity threshold.

a. Determine if outside forensic expert or incident response aid is necessary.

0. If internal analysis indicates that the attack is highly sophisticated or is targeted specifically at IRM, engage IR support.

b. If third parties will assist with incident, defer subsequent steps if needed to aid third party investigation processes.

i. Internal incident commander should confer with third party lead investigator on steps to be taken.

10. Preserve any additional volatile data such as memory data, or as instructed by a third-party incident response team. Refer to Appendix I – Windows Forensic Collection for instructions.

11. Shut down the infected computer(s) as instructed by third-party IR team or once it is determined that no additional data of value can be preserved by keeping the computer powered on.

12. Once the computer is offline, notify the network team to re-enable the network port or un-ban the MAC address.

Infected Workstation Steps1. Remove hard drive and acquire backup image. (if 8e or 8f or 8g is true)

a. Store hard drive with security team.

i. Drive should be clearly labeled with associated workstation, type of incident, date of removal, and locked in a secured room.

13. Create ticket for Desktop support to scan with Malwarebytes.

14. Clean AD profile, if user leveraged a roaming profile or has synchronized folders.

15. Provision user with a new workstation.

16. Install new hard drive, reimage OS from latest gold image.

Infected Server Steps1. Acquire forensic image of hard drive and backup image (or backup snapshot clone for VM). Refer

to Appendix I or third-party IR team for instructions on image acquisition.

2. Fail over any necessary services to a secondary server, following emergency change control guidelines.

3. Identify infection vector and remediate any vulnerabilities extant in the server build image or template.

4. Rebuild server, test, and redeploy.



Date: Owner:



5. Continue to monitor servers for signs of attack.

Extended Response1. Obtain file and network indicators of compromise from CrowdStrike and McAfee

a. Network indicators

i. Block outbound connections to malicious hosts and IPs

ii. Watch SIEM logs for indications of other endpoints attempting to communicate with these hosts.

1. Connection attempts may indicate other infected endpoints, or a false-positive IoC detection.

2. Provide ReliaQuest with details on indicators for additional monitoring or rule creation.

a. File indicators

i. Scan environment for indicators of compromise using Yara via PowerShell (Refer to Appendix III – IOC Scanning) or CrowdStrike.

1. If additional infected hosts are discovered, refer to Triage step 5/6/7 and Infected Workstation Steps as needed.



Date: Owner:





Date: Owner:



Trojans and RATs – Decision Charts

Trojans and RATs – Triage



Date: Owner:





Date: Owner:



Trojans and RATs – Extended Response



Date: Owner:



Trojans and RATs – Workstation Cleanup

Trojans and RATs – Server Cleanup



Date: Owner:



Malware Workflow – Droppers/Downloaders

Droppers/Downloaders – Incident Response Phases

DetectionDroppers and downloaders are detected by most of the same methods used to detect other malware. A notable exception is that droppers and downloaders often do not modify registry keys or create other indicators of infection on their own, leaving this job to the dropped files. Some exceptions do exist, however most lack persistence mechanisms such as those described in Appendix II. In cases of non-targeted malware, droppers and downloaders frequently act as the first stage of a malware incident and serve as the installation vector for the main payload.

Most malicious document malware contains scripts that effectively function as the Downloader, and are designed to deliver the primary malware payload (Ransomware, for example), to the victim’s computer. Downloaders may also be malicious javascript (.js), PDF, or HTML Application (.hta) files. In other cases, these same files may be droppers, unpacking malicious scripts or other code directly onto disk without network connectivity.

Detection with endpoint technologies or appliance alerts can give a head start to the investigation by identifying the family of the dropper or downloader. These methods of detection are the most common way to detect droppers. Downloaders may sometimes be discovered through internet communications between an infected workstation and a known-malicious website that are encountered in web proxy logs.

ScopingThe first step of the process will be to search for the malware hashes on the Internet. Internet research will give concrete information on the functionality and family of the malicious sample. It should also be noted that the malware’s existence in publicly available scanning services or sandboxes is an indicator that the attack is not highly targeted.

Next, the malware should be sandboxed in WildFire to monitor for behavior, payload information, and network activity. All DNS requests should be blocked and logged for infected host identification. IPs and domains accessed must also be blocked and logged. Collect hashes and samples of any files dropped or downloaded and begin the process again with Internet research and sandbox testing for each sample collected. At this point, follow alternate workflows, depending on the malware category of each sample.

Further Internet research on each sample dropped and the domains and IPs accessed will allow the responder to determine whether the dropper is part of an “in-the-wild” campaign. Even though detail about specific samples may not be available on the Internet due to slight changes resulting in different hashes, information about the malicious sites accessed will give information about the malicious binaries downloaded. This is especially true if the C&C servers are down and the samples cannot be downloaded from within the sandboxed environment or if VM is used to monitor network traffic. Again, contacting known-malicious sites from existing malware campaigns can be an indicator that the attack is not targeted.

ContainmentImmediately disconnect the infected machine(s) from the network. Because of the varied nature of the malicious binaries installed by droppers and downloaders, it is important to keep infected machines contained until the severity of the incident can be determined. Inspect any other machines the user has accessed for signs of compromise and if detected, remove from the network.



Date: Owner:



Eradication and RecoveryEradication and recovery from a malware dropper/downloader incident rely heavily on alternate workflows depending on what categories of malware are installed. Please refer to these workflows to determine the best remediation and recovery strategies.

In the case of malware downloaders, achieve partial recovery by blocking and logging DNS requests and network traffic to C&Cs accessed by the malware. Further infected hosts can be discovered by this logging and should be isolated from the network until the severity of the incident can be determined.

Droppers/Downloaders – Incident Response Process

Detection and Triage1. Downloader/Dropper malware will likely be detected by McAfee, or CrowdStrike, Red Canary, or

user initiated ticket, or via a malicious document investigation.

a. For malicious documents, work in parallel between this workflow and the malicious document workflow. Skip step 2 pending results of malicious document workflow.

17. Isolate infected computer from the network.

a. Initial isolation should be performed using CrowdStrike’s isolation functionality.

b. If the host cannot be isolated with CrowdStrike:



18. Record any filesystem indicators from infected computer in incident notes.

a. Document suspect filenames/paths, file sizes, and timestamps.

b. Document any observed open network connections (remote hostname or IP) present in CrowdStrike.

19. Review network appliances for suspect/malicious connections from infected computer.

a. Review web proxy, Palo Alto firewall, ASA, and SIEM logs. Pay particular attention to traffic on ports 80 and 443, or unusually high 5-digit ports.

b. Record any suspicious IP addresses or hostnames.

c. If no suspect addresses are identified, this may be an indicator of a dropper rather than a downloader.

20. Perform Open-Source Intelligence searches based on indicators described in step 3 and 4 to identify classification information and identify scope of incident.




21. Send file samples to Crowdstrike and/or McAfee (whichever did NOT detect the malware).

a. If sample is sent to McAfee:



Date: Owner:



i. Request custom signature DAT file and notification of when sample will be added to definitions.

ii. Scan entire network using new McAfee signatures to identify additional infected endpoints.

b. Ask the vendors for a functionality writeup or summary. Specifically inquire if known payload malware includes data stealing functionality.

i. If payload malware includes data stealing functionality, engage third party forensics IR support to validate potential loss.

ii. If data loss is confirmed, initiate Sensitive Data Disclosure workflow.

iii. Otherwise, engage Trojan, Virus, Rootkit/Bootkit or Ransomware workflows as appropriate.

22. Activate CSIRT



23. Obtain file and network indicators of compromise from Crowdstrike and McAfee, and OSINT sources





2. Provide Reliaquest with details on indicators for additional monitoring or rule creation.

0. File indicators

iii. Indicators would likely be registry data, Vbscript or shellcode fragments, or payload file characteristics.

iv. Scan environment for indicators of compromise using Yara via Powershell (Refer to Appendix C: Threat Hunting)


25. Shut down the infected computer(s).


27. Execute additional malware workflows (Trojan/RAT, Ransomware, etc.) as needed to address payloads.

Infected Workstation Steps1. Remove hard drive and acquire backup image.




Date: Owner:




28. Clean AD profile, if user leveraged a roaming profile.



Extended Response1. If samples were sent to McAfee, scan endpoints with newest definitions.

31. Review CrowdStrike for potential indicators of how computer was infected.

32. Review McAfee and CrowdStrike Indicators of Compromise


iii. Block outbound connections to malicious hosts and IPs

iv. Watch SIEM logs for indications of other endpoints attempting to communicate with these hosts.



b. File indicators


33. Address the infection vector.

a. If infection source was from the web browser, identify likely vulnerability leveraged to infect the computer via drive-by download.

i. Remediate vulnerabilities in existing IRM infrastructure (push patches for commonly-exploited applications such as Flash or Microsoft patches for Internet Explorer).

b. If malware infection was from another source, review gaps in acceptable use policies that enabled infection.



Date: Owner:



Droppers/Downloaders – Decision Charts

Droppers/Downloaders – Incident Triage



Date: Owner:



Droppers/Downloaders – Extended Response



Date: Owner:



Droppers/Downloaders – Workstation Cleanup

Droppers/Downloaders – Server Cleanup



Date: Owner:



Malware Workflow – RansomwareLast Updated: 10/10/2016

Ransomware – Incident Response Phases

DetectionEndpoint technologies and appliances can detect ransomware infections, but they are often detected by user notification, as ransomware authors frequently update their software to evade detection by traditional endpoint protection solutions such as Anti-Virus. Modern (as of 2016) ransomware variants such as Locky have strong indicators of infection, such as containing graphical user interfaces and myriad files with names like “decrypt instructions” or “howto_recover_files”, and intrusive behaviors such as encrypting all of the user’s documents and images. If detected by user notification, immediately isolate the endpoint from the network and employ manual inspection to discover and isolate the sample.

Detection with endpoint technologies or appliance alerts give a head start to the investigation by identifying the ransomware family, however these detections often occur after the infection has already occurred, and are dependent on the security team monitoring McAfee Antivirus or on CrowdStrike’s Overwatch team.

Scoping

Internet Research

Following network isolation of an infected host, the first step of the scoping process is to search for the malware hashes (MD5 or SHA-1) on the Internet, beginning with a search on VirusTotal. VirusTotal is a publicly-available file scanning service that scans file samples with numerous Anti-virus engines. VirusTotal also allows visitors to search for file hashes, URLs, and IP addresses. Note that any binaries submitted to VirusTotal are available for download by any paying customers.

Do not submit files to VirusTotal or malwr.com (or other sites) unless you have manually ensured that the binary does not contain any embedded data such as credentials or named references to IRM. As a general guideline, do not submit binaries to public sandboxes or file scanners.

Another resource to check is CleanMX, which allows responders to query a live data feed based off multiple fields including domain, URL, virus name, hash, IP address, and more.

Hurricane Electric provides a BGP Toolkit. The BGP toolkit is a great resource for finding relationships between IPs and Domains. While not explicitly designed with security research in mind, the service has been invaluable in linking various malware-related websites and programs through this data.

Simply searching for interesting indicators such as file hashes, IP addresses, and hostnames via Google (or a similar anonymous search engine like DuckDuckGo) may also yield relevant data, such as vendor write-ups or blog posts.

Internet research gives concrete information on the functionality and family of the malicious sample as well as information about the existence of the sample “in the wild”. Samples being widely reported or available on publicly available scanning services are likely not targeted but the potential should not be ignored. The greatest advantage of public research data is that it may produce additional indicators of compromise that can be leveraged to facilitate the containment and remediation process, and to augment detection appliances with additional signatures.



Date: Owner:



Antivirus Vendor Support

If you can obtain a copy of the malicious files responsible for the infection, these files should be submitted to McAfee and/or CrowdStrike for analysis. At minimum, undetected files can be submitted to the vendor for them to research and add to their signatures if malicious. This can be accomplished after the computer has been turned off.

Network Indicators

Work with the networking team to review all DNS requests made by the infected endpoint, which must be blocked and logged for malicious host identification. IPs and domains accessed by the malware should be visible in Firewall or Proxy logs, or CrowdStrike. These must also be blocked and logged.

Filesystem Indicators

Filesystem indicators that apply to Ransomware typically include three areas:

1. The file extension for the encrypted files.

2. The naming scheme for the “decryption instructions” files.

3. Characteristics of the ransomware itself (name/size/path/MD5/etc.).

Typically when ransomware infects a computer, all files that are encrypted are appended with a file extension that is unique to that infection or that ransomware variant. This is often useful for tracking down encrypted files on network shares. There are some ransomware families that may randomize the file extension, however, which may impair encrypted data identification processes.

The decryption instruction files are another common presence when a ransomware infection has occurred. These files are frequently written to many directories on disk, and may be written to network shares as well. Some antivirus solutions may detect these files on occasion.

Other characteristics include the broader traits that all files exhibit, such as unique MD5s for the ransomware executable on disk, the file’s name, its size, and the path where the ransomware binary exists on disk (often found under the user’s Application Data directory structure or under the C:\ProgramData directory tree).

ContainmentImmediately disconnect the infected machine(s) from the network while planning and executing remediation. Inspect any other machines the user has accessed for signs of compromise and if detected, remove from the network. Use network information to block access to IPs and URLs determined to be bad during the course of the investigation.

File-encrypting ransomware is not known to spread to other machines using worm-like methods, however it can encrypt files on any shared network drives accessible and writeable by the infected workstation’s user.

Email Containment

If the ransomware came through an email attachment, the email team will need to ensure that the sender is blocked to prevent future impact from the same malware campaign. Obtain the sender’s address and server information from the SMTP headers in the email responsible for the infection (which will likely be a malicious document or a phishing email with a download link). Provide that data to the email team so that they can block the sender and the corresponding servers (if they are malicious). Some campaigns may send mail from legitimate email services, which cannot be blocked. Custom filtering rules within Office 365 may need to be developed in these cases.



Date: Owner:



If the ransomware email featured a malicious document, ensure that the document is provided to McAfee to be added to detection signatures.

Eradication and Recovery

Infected Workstation

Remove the hard drive from the infected computer and acquire a backup image. This can be useful for review at a later date if there is a need to reference something on the system, or if forensic investigation is necessary. The original hard drive should be stored with the Security team, and should be clearly labeled with the associated workstation name, type of incident, and date of removal. The IT Security team can store the drive in their office.

Clean the infected user’s Active Directory profile, if they were using a roaming profile. The intent is the ensure that no remnants of the malware are preserved in the user’s profile, which could reinfect them on their new computer.

Once the profile is cleaned, work with the desktop support team to provide a new workstation with a fresh image to that user so that they can resume their work. Install a new hard drive into the infected computer and install the latest clean OS image, so that the workstation itself can be re-provisioned to the next user who needs a computer.

Network Shares

Check all shares for evidence that they were accessed by the infected user’s computer, or reports from other users of inaccessible files on certain shares. Any shares that are found to have encrypted data should be restored from the last known good backup state. Continue monitoring shares for the next 24 hours in case the infection was not limited to a single computer or if other shares are found to have encrypted data.

Antivirus Scanning

If file samples were shared with McAfee and they have produced updated antivirus signatures using that sample, initiate a scan of the network to ensure no other hosts are infected by the same malware. Review Crowdstrike history on the infected computer and work with the Overwatch team to identify any other computers that may have been infected.



Date: Owner:



Ransomware – Incident Response Process Ransomware is a form of malware that encrypts documents and files then forcing the user to pay a ransom in order to obtain. This work

Initial Triage1. Infection will be detected either via McAfee, or CrowdStrike,, Red Canary, or it will be detected

through user reports.

c. User reports may include: user observes the decryption instructions message, cannot access local or remote files, or cannot access their shared files.






35. Validate detection or verify user report.

a. For endpoint detections via AV/CrowdStrike, assume the detection is valid.

i. Perform basic research of the detection name to identify the likely family. Based on this, determine how it usually spreads and what kinds of data may be affected.

b. For user-reported incidents, check live system for encrypted files or "HOW_TO_DECRYPT.TXT"-like files.

i. Review user's Downloads, Documents, and Desktop for evidence.

ii. Identify the file extension of encrypted files (for example .cccc, .lkasjsald, .locky, etc.)

c. Scan with MalwareBytes if no evidence of infection is found.

36. Record any filesystem indicators identified in step 3 in incident notes. Document any other findings of interest.

37. Perform Open-Source Intelligence searches to identify family/variant

a. Search known malicious (or suspect) file hashes (MD5 or SHA1) against online sources

i. DO NOT SUBMIT BINARY SAMPLES TO THESE SERVICES

ii. Search for the hash on VirusTotal, malwr, #totalhash

iii. Google searching the file hash (try both MD5 and SHA1) may yield additional results.

b. Search online sources for details regarding observed network contacts

i. URLs



Date: Owner:



ii. Domain names

iii. IP addresses

c. Check for available decryption tools, if variant can be identified.

38. Turn off the computer.

39. Submit the ransomware binaries to CrowdStrike for analysis. If McAfee did not detect the malware, send any file samples to McAfee support as well.


Network Share Response1. Identify network shares containing encrypted data.

a. Check for evidence of filesystem indicators described above.

i. Search for the encrypted file extension on shares using the ransomware VB script.

b. Identify all shares accessed by infected workstation's user account.

i. Shares will be identified in raw Isilon logs supplied by the SAN team or Varonis logs (if available).

ii. Review these shares manually for other evidence of encrypted data.

41. Restore affected shares from most recent known good backups.

42. Monitor unaffected shares for future appearance of data matching incident filesystem indicators.




43. Clean AD profile, if user leveraged a roaming profile or synchronized folders.

44. Investigate and clean personal mapped (F:) drive.




47. Review Crowdstrike for potential indicators of how computer was infected.

a. If malicious document is suspected, check recent email for possible malicious document attachments.

i. Identify source email address of sender.

ii. Identify remote email server IP address, determine if malicious.



Date: Owner:



b. If drive-by download from web browser is suspected, check web proxy history for user's IP Address (matched with Crowdstrike timestamps) to identify IP addresses or hostnames that may be suspect.

i. Identify likely vulnerability leveraged to infect the computer.

Remediate vulnerabilities in existing IRM infrastructure (push patches for commonly-exploited applications such as Flash or Microsoft patches for Internet Explorer).

48. For email-borne infections: Block email address(es) and sender's outbound server (if malicious).

a. Document subject line, mail user agent, and take a screenshot of the email for future reference.

49. Analyze suspect/unknown IP addresses or hostnames using Virustotal Search (https://www.virustotal.com/#search) and Hurricane Electric BGP Lookup (http://bgp.he.net/).

a. If results suggest the host/IP is clearly malicious, block connections to the IP address and/or hostname.



http://bgp.he.net/

https://www.virustotal.com/#search

Date: Owner:



b.

Ransomware – Decision Chart s

Ransomware – Triage



Date: Owner:



Ransomware – Extended Response



Date: Owner:



Ransomware – Network Share Cleanup

Ransomware – Workstation Cleanup



Date: Owner:



Malware Workflow – Malicious DocumentsLast Updated: 10/10/2016

Malicious Documents – Incident Response Phases

DetectionMalicious documents can be difficult to detect, as they are a less common method of infection for malware and tend to be utilized in relatively sophisticated attacks. Detection is not impossible, however, and requires a combination of technologies as well as personnel training.

Although early detection and quarantine of a malicious document is more desirable than allowing the sample to be delivered to a user, detection with endpoint technologies or appliance alerts can provide a lot of information for the investigation by identifying behavior and any dropper or other files delivered by the malicious document. These methods of detection are the most common way infection via malicious documents is detected. Even if a document is detected by manual inspection of a machine, research and analysis will provide a wealth of information.

ScopingIf a user opens a malicious document, the first step of the process is to determine the presence of any dropped files and to search for the malware payload hashes on the Internet. Internet research will give concrete information on the functionality and family of the malicious sample. It should also be noted that the malware’s existence in publicly available scanning services or sandboxes might be an indicator that the attack is not highly targeted.

Next, the malware should be sandboxed in WildFire to monitor for behavior and dropped. All DNS requests must be blocked and logged for host identification. IPs and domains accessed must also be blocked and logged. Hashes and samples of any files dropped or downloaded must be collected and the process should begin again with Internet research and AV testing for each sample collected. At this point, alternate workflows will need to be followed depending on the malware category of each sample.

ContainmentIf the malicious sample was caught and quarantined, simply purging the quarantine will contain the individual sample, but the event should be logged and the information should be used to improve defense and detection capabilities. If the sample was delivered and viewed by a user, the infected machine must be immediately disconnected from the network. Because of the varied nature of the malicious binaries dropped by malicious documents, it is important to keep infected machines contained until the severity of the incident can be determined. Inspect any other machines the user has accessed for signs of compromise and if detected, remove from the network.

Eradication and RecoveryEradication and recovery from a malware incident relies heavily on alternate workflows, depending on what categories of malware are dropped and installed. Please refer to these workflows to determine the best remediation and recovery strategies. Once the investigation is complete, and assuming the samples do not contain sensitive information, submit the document and related files to vendors for analysis and inclusion in signature and detection databases.



Date: Owner:



Malicious Documents – Incident Response Procedures 1. Malicious document reported or detected.

a. Detection will likely come from McAfee or CrowdStrike

b. The document may be noticed and reported by an end user.

1. Notify CSIRT. Treat as a Medium incident if the document was sent to executive staff.

a. Engage Messaging team to check if document was sent through email.

i. If found, request that Messaging team block and/or remove message from mailboxes.

2. Perform basic OSINT research on document sample.

a. Search for MD5 on Virustotal and other services to see if document has been analyzed by anyone.

b. Search for filename/variations online. Narrow search scope to within 1 year or less.

c. Send sample to McAfee/Crowdstrike for classification.

i. Ask the vendors for a functionality writeup. Specifically inquire if malware includes data stealing functionality.

1. If malware includes data stealing functionality, engage third party forensics IR support to validate potential loss.

2. If data loss is confirmed, initiate Sensitive Data Disclosure workflow.

a. Run document through WildFire sandbox to identify any dropped files or network connections related to the malicious code in the document.

1. Determine if the user attempted to open attachment.

a. Interview user and ask if they opened it.

b. Check recent FalconHost endpoint history for evidence of execution.

1. Review email systems for evidence of additional recipients

a. Search for emails from same sender, or recent emails from sender's domain or inbound emails from sender's email host.

b. If additional recipients are identified, refer to step 4

1. If document was NOT opened:

a. Review source email for sender info (email address, originating domain, sender server's IP address)

i. Block sender/domain as appropriate.

ii. Document subject line, mail user agent, and take a screenshot of the email for future reference.

1. If document WAS opened:

a. Refer to Trojan Downloader/Dropper workflow.



Date: Owner:









a. File indicators

i. Indicators would likely be registry data, Vbscript or shellcode fragments, or payload file characteristics.

ii. Scan environment for indicators of compromise using Yara via Powershell (Refer to Appendix C: Threat Hunting)



Date: Owner:



Malicious Documents – Decision Chart



Date: Owner:



Malware Workflow – RootkitsLast Updated: 10/10/2016

Rootkits – Incident Response Phases

DetectionRootkits will often be detected by endpoint technologies and appliances or stopped before they are installed via a dropper or downloader. User notification of rootkit infection is extremely unlikely. Once installed, rootkits are extremely difficult to detect as they often contain extensive code to hide themselves and their other components from the system. A number of rootkit detection tools exist that may help the investigator find rootkits on running systems, however these tools are not 100% reliable and are not meant to be used in a proactive manner.

Rootkits are often packaged with other malicious binaries and the two will work together to perform one goal. Frequently, additional malicious binaries such as Trojans or RATs will perform the majority of the malicious activity and the rootkit will simply act as an agent to hide their activity. Careful examination of all machines known to be infected with rootkits is necessary to uncover additional components of the infection.

Early detection with endpoint technologies or appliance alerts will give a head start to the investigation. Internet research on the family of the rootkit, if available, will often give insight into the current campaigns in the wild using the rootkit discovered, as these campaigns are widely researched.

Infection Validation

Manual inspection of drive images and memory dumps is frequently necessary to validate presence of a Rootkit. Forensic analysis of memory samples is the most effective way to identify rootkits that are active. Because the malware is designed to unlink itself from the normal process chain, the malware remains more difficult to detect than other types of software. Between the Detection and Scoping phases, memory image collection should be prioritized during the IR process if a rootkit is suspected or if a detection appliance indicates such malware is present. Secondary validation of suspected rootkit binaries can be made via offline forensic analysis of the computer’s hard drive, provided that the malware is stored on disk.

ScopingThe first step of the process will be to search for the malware hashes on the Internet. If the malware is a known variant, Internet research will give information about the functionality of the malware, indicators of infection and any other malware it may be packaged with. Campaigns from popular rootkits may be widely reported and researched, in which case the likelihood of the attack being highly targeted is small. Malware information the rootkit is packaged with may be discovered, giving valuable information about what domains/IPs the other components communicate with and ease remediation, recovery and identification of further infected hosts.

If Internet research fails, advanced binary analysis to determine functionality and severity of the attack as well as information about potential C&Cs referenced within the rootkit will be necessary, and should be performed by McAfee or CrowdStrike. Often, rootkits will not do any communication on their own and serve only to hide the activities of additional components. For example, the rootkit may hide network traffic by manipulating kernel-level structures when they correspond to communication with a particular domain, IP address or port range. Blocking these IP addresses or port ranges will be beneficial in



Date: Owner:



containing the incident. Any strings related to specific IPs, domains or filenames can also be used to identify the additional components of the attack.

If the original malware dropper or installer is located, the malware should be sandboxed using WildFire. The installer will drop the additional components and allow the incident responder to see the bigger picture and prepare for additional investigation and containment procedures.

Due to the sophistication of rootkit code and the use of rootkits in some high-profile targeted attacks, employ advanced binary analysis in all cases where Internet research does not prove useful. Full reverse engineering of rootkits where Internet research on information discovered with basic analysis delivers no results is especially important. Because of a rootkit’s ability to execute in kernel mode, they can interact with drivers and affect not only the infected machine but also any hardware attached to the machine that is targeted by the rootkit.

Because of the ability of rootkits to hide themselves so effectively, signature based scanning technologies may not discover additional infected hosts. Manual examination of a sampling of hosts, especially via forensic analysis or investigation of drive images, is necessary to discover how far reaching the attack is within the organization. Network alerts from discovered malicious hosts will also aid in host discovery.

ContainmentImmediately disconnect the infected machine(s) from the network while planning and executing remediation. Inspect any other machines the user has accessed for signs of compromise and if detected, remove from the network. Use Network information to block access to IPs and URLs determined to be bad during the course of the investigation.

Eradication and RecoveryBecause of the severity of rootkit infections and their ability to hide their activities and the activities of other malware on the system, full reimaging or reinstallation will be the necessary course of action. Bootkits in particular are extremely difficult to remove and a full, low-level format of the drive must be performed in order to ensure the kit does not stay resident after reinstallation. Full eradication and recovery may depend on the additional components installed with the rootkit. See the corresponding workflows for more information.



Date: Owner:



Rootkits – Incident Response Process

Detection and Triage1. Rootkit/Bootkit malware will be invisible to the end user and will be detected by McAfee , or

CrowdStrike, or Red Canary.






51. Manual validation via forensic analysis or rootkit detection tools will be needed to validate the detection and to acquire binary samples.

a. Acquire memory dump (Refer to Appendix I – Windows Forensic Collection) and analyze using Volatility's psscan plugin to identify unlinked rootkit processes.

b. Scan with GMER (http://www.gmer.net/) to locate rootkit-masked files and processes.

i. Attempt to copy samples of rootkit-masked files using GMER, if found.

52. Record any filesystem indicators from infected computer in incident notes.

a. Document suspect filenames/paths, file sizes, and timestamps if identified by GMER

b. Document any observed open network connections (remote hostname or IP)

53. Review network appliances for suspect/malicious connections from infected computer.

a. Review web proxy and firewall. Pay particular attention to traffic on ports 80 and 443.

b. Record any suspicious IP addresses or hostnames.

54. Perform Open-Source Intelligence searches based on indicators described in step 4 and 5 to identify classification information and identify scope of incident




55. Scan rootkit samples or other suspect binaries using WildFire.

a. Review sandbox analysis for additional indicators of compromise.

i. Dropped files (names, hashes, sizes, paths)

ii. Created directories (names, locations)

iii. Remote hosts/IPs connected to

56. Send file samples to Crowdstrike and/or McAfee (whichever did NOT detect the malware).



http://www.gmer.net/

Date: Owner:



a. If sample is sent to McAfee:

i. Request custom signature DAT file and notification of when sample will be added to definitions.

ii. Scan entire network using new McAfee signatures to identify additional infected endpoints.

b. Ask the vendors for a functionality writeup or summary. Specifically inquire if known payload malware includes data stealing functionality.

i. If payload malware includes data stealing functionality, engage third party forensics IR support to validate potential loss.

ii. If data loss is confirmed, initiate Sensitive Data Disclosure workflow.

iii. Otherwise, engage Trojan workflows as appropriate.

57. Activate CSIRT









b. File indicators

i. Indicators would likely be registry data, Vbscript or shellcode fragments, or payload file characteristics.

ii. Scan environment for indicators of compromise using Yara via Powershell (Refer to Appendix C: Threat Hunting)

59. Preserve any additional volatile data as instructed by a third-party incident response team. Refer to Appendix I – Windows Forensic Collection for instructions.

60. Shut down the infected computer(s).


Infected Workstation Steps1. Remove hard drive and acquire forensic image for archives.




Date: Owner:








2. Review Crowdstrike for potential indicators of how computer was infected.





Date: Owner:





Date: Owner:



Rootkits – Decision Charts

Rootkits – Triage



Date: Owner:





Date: Owner:



Rootkits – Extended Response



Date: Owner:



Rootkits – Workstation Cleanup

Rootkits – Server Cleanup



Date: Owner:



Malware Workflow – VirusesLast Updated: 10/10/2016

Virus – Incident Response Phases

DetectionEndpoint technologies and appliances will most likely detect viruses; detection via user notification is rare. This classification of malware is unlikely to be used in targeted attacks, but some forms of viruses have additional functionality such as combination viruses/droppers. Viruses have the capability to modify additional files so multiple detections for the same virus will likely be present on infected hosts.


ScopingThe first step of the process is to search for the malware hashes on the Internet. If the malware is a known variant, Internet research will give information about the functionality of the malware, indicators of infection and any other packaged malware. Samples being widely reported or available on publicly available scanning services can be an indicator that the attack is not targeted.

Viruses do not commonly have functionality apart from their ability to spread and infect other files. However, some viruses share functionality in common with other classifications of malware, such as droppers or downloaders. Notable examples include ‘Sality’ and ‘Virut’, which install additional malware on the infected host.

Viruses have the capability to damage files severely on the infected host, rendering the host unusable or making the cleaning of the host difficult if not impossible. With viruses, reimaging or reinstallation will be the necessary course of action. Because of their ability to spread, each system accessed by the infected user or host must be contained and thoroughly examined. Deploy McAfee Antivirus or Stinger to find any additional infected files.

ContainmentImmediately disconnect the infected machine(s) from the network while planning and executing remediation. Inspect any other machines the user has accessed for signs of compromise and if detected, remove from the network. Use Network information to block access to IPs and URLs determined to be bad during the course of the investigation.

Eradication and RecoveryBecause of the ability of viruses to modify, infect and damage additional files, the necessary course of action will be reimaging or reinstallation. Signature-based scans using antivirus must be deployed network wide to check for additional infected hosts. In the case of viruses with additional functionality, further eradication and recovery procedures will depend on the additional features of the malware as well as any additional malware installed. See the corresponding workflows for more information.



Date: Owner:



Virus – Incident Response Process

Detection and Triage1. Virus detections will likely come from McAfee antivirus; Antivirus products tend to be extremely

proficient at detecting virus-type malware.






63. Validate detection

a. Review number of files detected by AV as infected.

i. Large numbers of files are a strong indicator of a valid Virus detection.

ii. A single file detection may suggest a false-positive detection.

1. Download McAfee Stinger and re-scan.

b. Review filesystem for large numbers of recently-modified executable files. Check C:\Windows\System32 and sort by Modified timestamps.

64. If Step 3 produces no confirmation, reboot computer and monitor for 1-2 hours. If no change, assume false-positive and contact McAfee support and notify of potential FP.

65. If valid, continue with response. If not, restore workstation to normal use and monitor.

66. Turn off the computer.

67. If McAfee did not detect the malware, send any file samples to McAfee support.


Network Share Response1. Identify network shares recently accessed by infected user's PC.

a. Check for evidence of file modification or creation of additional executables on shares.

69. Restore affected shares from most recent known good backups if any evidence of malicious file infection has been discovered.

70. Monitor unaffected shares for future appearance of data matching virus characteristics.





Date: Owner:







Extended Response1. Review McAfee and CrowdStrike Indicators of Compromise


v. Block outbound connections to malicious hosts and IPs

vi. Watch SIEM logs for indications of other endpoints attempting to communicate with these hosts.



c. File indicators

ii. Scan environment for indicators of compromise using Yara via PowerShell (Refer to Appendix III – IOC Scanning) or CrowdStrike.

74. Address the infection vector.



b. If malware infection was from another source, review gaps in acceptable use policies that enabled infection.



Date: Owner:



Virus – Decision Charts

Virus – Triage



Date: Owner:



Virus – Extended Response

Virus – Network Share Cleanup



Date: Owner:



Virus – Workstation Cleanup

Virus – Server Cleanup



Date: Owner:



“Generic” Malware Incident ResponseMalware incident response efforts are best executed when they are tailored to the unique characteristics of the malware responsible for the incident. Unfortunately, there are situations where it is not known what kind of malware is being examined, and IRM may need to apply some generalized steps to approach the incident.

This “Generic” guide is meant to help IRM protect business operations, patient privacy, and manage risk. This guide is not a shortcut and should not be leveraged to save time and reduce effort. Where possible, the more specific workflows should be leveraged so that IRM can prove that all reasonable steps have been taken when responding to a malware incident.

General Malware IR – Incident Response Phases

DetectionEndpoint technologies and appliances will most likely detect most malware; detection via user notification is rare except when dealing with Ransomware. Many user reports outside of ransomware consist of complaints regarding system performance, or quirks they cannot explain, however without additional technical details to support a malware hypothesis, their root cause could be something benign.


ScopingIn a generalized scenario, scoping the incident primarily involves two practices: researching the detection name (if detected by AV or CrowdStrike), or leveraging CrowdStrike to search for other potentially-“infected” computers based on shared characteristics (suspicious filenames,URLs, etc.). Other appliances such as the web proxy may also be useful when it is known or suspected that the incident may be associated with a specific website or IP address.

ContainmentImmediately disconnect the infected machine(s) from the network while remediation is planned and executed. Inspect any other machines the user has accessed for signs of compromise and if detected, remove from the network. Use network information to block access to IPs and URLs determined to be bad during the course of the investigation.

Eradication and RecoveryThe preferred course of action will be to reimage or reinstall infected hosts, and clean the user’s Active Directory roaming profile and any mapped E: drives. Follow-up by searching the IRM environment for other potentially-infected hosts based on the network and filesystem characteristics identified during the IR process.



Date: Owner:



General Malware IR – Incident Response Process

Initial Triage1. Malware detection, either from AV/CrowdStrike/RedCanary, or from user reports.

75. Record any filesystem indicators from infected endpoint in incident notes. Document any other findings of interest.

a. Document suspect filenames/paths, file sizes, and timestamps identified in CrowdStrike and McAfee results.

b. Review the infected machine and identify any notable unusual files or live processes.

c. Document any observed open network connections (remote hostname, port, or IP address

i. Check Palo Alto logs for connections using unusual or high TCP ports, as well as common ports such as 22, 23, 80, and 443.

76. Perform Internet Research based on gathered data.

a. Search file hashes

i. MD5

ii. SHA1

b. Search for network contacts

i. URLs

ii. Domains

iii. IP Addresses

c. Submit sample(s) to Palo Alto WildFire sandbox.

i. Record any payload file hashes, contacted URLS/Domains/IP Addresses.

77. Isolate infected endpoint(s) from the network.





78. Review network appliances logs for suspect/malicious connections from infected computer.

a. Review Palo Alto web proxy and firewall logs for recent connections to/from the infected computer.

i. Contact Reliaquest to search for all events in the SIEM that may relate to the incident.

b. Record any suspicious IP addresses or hostnames present in logs or identified by ReliaQuest



Date: Owner:



79. Send malware samples to McAfee and/or CrowdStrike for analysis, as needed.

a. Review analysis reports and compare with internal findings in step 7.

80. Review detection appliance data, research functionality based on known Trojan sample characteristics.




d. Review any available Crowdstrike and McAfee analysis and Wildfire sandbox analysis:

i. How does it communicate? What IP addresses and hostnames were contacted?

1. Malware will often attempt to connect to a Google or Microsoft host and IP first to check for internet connectivity.

ii. What kind of data exfiltration features does it have?

iii. Does it spread (worm functionality)?

iv. Does it modify system files or information?

v. Does it gather passwords?

vi. Does it log keystrokes or take screenshots?

e. If internal research or Crowdstrike/McAfee analysis indicates that malware family is used for data theft/exfiltration, engage third party forensics IR support to validate potential loss.

f. If data suggests that the attack is targeted specifically at IRM, engage third-party incident response support.

g. If data loss is confirmed, initiate Sensitive Data Disclosure workflow.81. Activate ICC if incident reaches Medium or High severity threshold.


i. If internal analysis indicates that the attack is highly sophisticated or is targeted specifically at IRM, engage IR support.


i. Internal incident commander should confer with third party lead investigator on steps to be taken.


83. Shut down the infected computer(s) as instructed by third-party IR team or once it is determined that no additional data of value can be preserved by keeping the computer powered on.






Date: Owner:




85. Clean AD profile, if user leveraged a roaming profile or has synchronized folders.



Infected Server Steps1. Acquire forensic image of hard drive and backup image (or backup snapshot clone for VM). Refer

to Appendix I or third-party IR team for instructions on image acquisition.

6. Fail over any necessary services to a secondary server, following emergency change control guidelines.

7. Identify infection vector and remediate any vulnerabilities extant in the server build image or template.

8. Rebuild server, test, and redeploy.

9. Continue to monitor servers for signs of attack.

Extended Response1. Obtain file and network indicators of compromise from CrowdStrike and McAfee






b. File indicators


88. If additional infected hosts are discovered, refer to Triage step 5/6/7 and Infected Workstation Steps as needed.



Date: Owner:





Date: Owner:



General Malware – Decision Charts

General Malware – Triage



Date: Owner:





Date: Owner:



General Malware – Extended Response



Date: Owner:



General Malware – Workstation Cleanup

General Malware – Server Cleanup



Date: Owner:



Distributed Denial-of-Service (“DDoS”)Last Updated: 10/10/2016

Detection DDoS incidents are initially visible as standard “Denial of Service” incidents, where online resources become inaccessible for end users. As the attack progresses or gains intensity, the identification of the incident as a DDoS attack becomes easier. Distributed Denial of Service (DDoS) attacks are frequently visible in network traffic logs generated by critical infrastructure such as firewalls and web servers, normally apparent due to significant amounts of homogenous data from multiple sources. These attacks are also visible when failovers in infrastructure (redundant appliances and servers) occur when the equipment is attempting to compensate,

Scoping Determine the extent of the outage and if any systems required for patient care are affected. Most attacks are likely to only impact external-facing services such as the IRM website and should not impact operations significantly.

Review appliance logs and/or capture traffic to identify what kind of DDoS attack is occurring (UDB flood, SYN flood, NTP Amplification, etc.).

Containment Containment will be dependent on the extent of the attack. For attacks that can be managed via IRM’s networking team, rules should be deployed on perimeter devices to reject the DDoS traffic. For more significant DDoS attacks, third-party mitigation services may be necessary.

Eradication and Recovery DDoS attacks typically end after some period of time (minutes, hours, or days, depending on the attacker’s motivation and available resources). Once the attack has ended, IRM should review what occurred and what impacts to business functionality were encountered throughout the organization.



Date: Owner:



DDoS – Incident Response ProcessThis attack has two primary states of consideration: threatened or underway.

Threatened Attack ResponseIn the event IRM is threatened (for example, via a twitter post or email, where IRM is threatened by name), the proper response state is proactive.

1. Scan potential target systems for vulnerabilities with Nessus from outside the IRM network.

2. Remediate any identified vulnerabilities.

3. Activate the CSIRT and

a. Incident commander should engage MCNC to provide DDoS mitigation services. Networking team should work with MCNC engineers to set up configuration as needed.

DDoS Attack Underway ResponseIf the attack state is underway, the proper response state is reactive.

1. The Computer Security Incident Response Team (“CSIRT”) should be mobilized

b. Construct a response strategy based on the attack’s potential impact on business operations.

2. Identify impacted or potentially-impacted systems.

89. Does attack meet third-party mitigation threshold (100Gbps or three consecutive days)?

a. If yes, contact the POC for Prolexic/Cloudflare to begin remediation and get status updates.

90. For externally hosted systems, identify the hosting provider and contact the organization to obtain a liaison contact for the CSIRT.

a. MCNC Contact:

91. For local systems:

a. Use DNS redirection to filter traffic, allowing legitimate traffic while filtering out DDoS traffic.

b. Reduce DNS TTL times.

c. Disable administrative remote access.

d. To reduce the attack profile, disable public access to systems used for quality assurance, testing, development, or that are not business critical.

92. Verify device configurations for DDoS protection (router ACLs, firewalls) and monitor the devices for anomalous traffic.

93. Create a list of IP addresses to block and domain attack sources to share with upstream service providers for blocking/filtering traffic.

94. Monitor system and network metrics. Tune system and network configurations to respond accordingly to potential traffic bottlenecks.



Date: Owner:



95. Monitor traffic to systems that are not targets of the DDoS attack to determine if the attack is a distraction tactic for a separate attack.

96. If additional attack activity is observed, execute appropriate incident response workflows as necessary.

97. Document all steps, including collected artifacts verifying specific systems/endpoints used in conducting the attack, notable events, and findings.

98. Share lessons learned to improve systems, controls, and practices, as appropriate.

Throughout the incident, the CSIRT should be aware of, and watch for more covert attack types. Symptomatic events, such as account lockouts and password reset requests, may spike with the service desk.

At the conclusion of the incident, targeted systems should be analyzed thoroughly for malware or unauthorized changes. Conduct forensic examination on systems with unexplained or anomalous behavior.



Date: Owner:



DDoS – Decision Charts

DDoS – Attack Threatened



Date: Owner:



DDoS – Attack Underway



Date: Owner:



External/Internal HackingLast Updated: 10/10/2016

External/Internal Hacking – SummaryHacking in the “classic” sense involves attackers gaining direct access to computers, either through various tool-augmented methods, malware, or sheer brute force. Hackers frequently use automated scanning tools to probe the internet, or narrower IP ranges, of systems that may be vulnerable to compromise.

Many hacking incidents are unsophisticated, and are actually perpetrated by automated botnets that probe systems for default and weak credentials. Frequently in these cases, the primary goal of the attacker is to install malware that turns those systems into additional botnet “zombies”, however the adversary may also aggregate and later offer their access for sale on the dark web, where it may be leveraged by other hackers for more directed infiltration.

Sophisticated hackers often have a more subtle approach and will be less visible in logs and other security appliances. These individuals may time their activities to coincide with their local work hours (daytime for them), or they may time them alongside normal US working hours to fly under the radar. Network connections for these adversaries are frequently pivoted through US-based IP addresses to avoid geoblocking.

Detection Identification may come in the form of vulnerability system scan, abnormal system behavior, suspicious network traffic, third-party notification, or detection of unauthorized access on a network accessible host. Repeated failed logins, particularly at unusual overnight hours, are common telltale signs of brute-force hacking attempts.

Scoping Incident scoping is dependent on the availability of logs and forensic analysis to correlate those logs between multiple systems. Firewall and other infrastructure logs will indicate connections across network segments, or connections made by the attacker. Operating system or application server logs may also be required to identify specific internal systems accessed by the attacker, particularly if it is suspected that they have pivoted from one perimeter “beach head” system onto another computer.

Containment and Eradication If a compromised system hosts sensitive data such as PHI, connectivity should be revoked immediately if possible. At a minimum, efforts should be made to ensure that continued access from the outside is not possible.

For systems not hosting or providing the attacker access to sensitive information, it may be more valuable to initially capture network traffic while the attacker is active, in order to determine what they are attempting to do on the network. This may help with threat attribution or vulnerability identification.

Regardless, ultimately the access for the attacker must be cut off once it is determined that it is safe to do so without bringing down critical systems.



Date: Owner:



Remediation Remediation of the incident depends on forensic analysis, to determine how the attacker gained access into the environment. Once it is known how they gained access, IRM should remediate the vulnerabilities, and should engage a third-party penetration test following incident resolution, to identify any other vulnerabilities that could be leveraged by the attacker.

External/Internal Hacking – Incident Response Process1. Determine if affected systems host any regulatory-controlled data (PCI, HIPAA, etc.).

2. If Step 1 == No, capture all network traffic coming from, or going to affected system(s). Monitor the network traffic for C&C traffic, additional malicious payloads, and exfiltration of data.

a. The SAN team should be contacted to deploy Taps to facilitate traffic collection.

3. If Step 1 == Yes, or once capture is complete, isolate infected computer from the network.

b. Initial isolation should be performed using CrowdStrike’s isolation functionality.

c. If the host cannot be isolated with CrowdStrike:



99. Collect all logs – Firewall, Anti-Virus, System event logs, Intrusion Detection System (‘IDS’) logs, application logs, authentication logs, and any other logs deemed relevant.

a. Most of the relevant logs should be collected in the ReliaQuest-managed SIEM. Any logs not collected in the SIEM, including application logs and operating system logs, will need to be acquired manually.

100. Capture volatile system data. Be sure to preserve network socket and other volatile data. Refer to Appendix I – Windows Forensic Collection for instructions.

101. If the incident is isolated to remote facilities or other network segments, suspend intra-segment communications at the switch or router:

a. Block affected system(s) from accessing or being accessed by the Internet or other systems.

b. Replace the affected systems with hot standby systems, if available.

102. Engage third party incident response and forensic services to identify point of entry and remediate vulnerability.

103. Engage a third party to perform a full external penetration test to ensure other known vulnerabilities are remediated.



Date: Owner:



104.

Hacking Decision Chart



Date: Owner:



PhishingLast Updated: 10/10/2016

Phishing – Incident Response ProceduresShould a malicious email bypass the in-place messaging security measures, the message may infect the target with malware, trick users into volunteering sensitive information into clicking a malicious Internet link. The Incident Response team will need to work extensively with the Messaging team to manage phishing incidents. Efforts to identify and contain this incident include the following:

Initial Triage 1. Malicious messages should be isolated in the Office 365 spam quarantine, and local computer

cache for analysis and removal.

a. In the SMTP header of the email, identify message source domain, IP address, and return email address domain.

b. Utilize the Microsoft Exchange PowerShell capabilities to assist in identifying what users may have received the suspected email messages.

i. PowerShell access can be configured using the following guide: https://technet.microsoft.com/en-us/library/jj984289(v=exchg.160).aspx

ii. An example would be: C:\>Get-MessageTrackingLog -Sender <SENDERS EMAIL ADDRESS> -Start (Get-Date).AddHours(-1) | Export-Csv C:\Results.txt

1. The above command grabs all of the users who received an email from a specific email address within the past hour.

105. Identify impacted systems and nature (Motive) of suspect emails.

a. Is the email general spam? Phishing? Alternatively, is it targeted (Spear) phishing at a specific subset of users?

106. Identify if users clicked any links within the email or if they downloaded any attachments from the email.

a. Review web proxy logs for this evidence. If they clicked a link, determine if they entered any credentials on the malicious web page.

b. If they downloaded a malicious attachment, follow malware IR (malicious document or dropper/downloader to start) workflow.

107. Review user's email signatures and rules for evidence of malicious tampering (links, scripts, forwarding rules, etc.).

Blocking Steps 1. Research source information for known attack reputation ratings (e.g., www.phishtank.com or

www.mxtoolbox.com/blacklists.aspx).

a. Create and deploy blocking rules for confirmed, malicious sources.



http://www.mxtoolbox.com/blacklists.aspx

http://www.phishtank.com/

https://technet.microsoft.com/en-us/library/jj984289(v=exchg.160).aspx

Date: Owner:



b. If an Internet link is included in the message, identify both the domain and IP block using the geographically appropriate registry site: http://www.iana.org/numbers.

108. Check classification or domains for Spam blacklisting. If not blocked, have site re-categorized.

109. Ensure Office 365 email filtering is configured to block the malicious IP/domain sources.

a. If a malware payload is identified, ensure McAfee and/or Crowdstrike detect files. Send samples to McAfee if necessary.

110. If nature of the phishing messages is consistent with targeted phishing, ensure anti-virus is up-to-date and initiate a scan of the recipients’ computers.

111. Collect Office 365 audit logs and/or Azure AD logs.

a. Determine if user's email has been accessed by an unauthorized party,

b. If account has been accessed: determine if user regularly works with sensitive or regulatory-controlled data.

i. If employee regularly works with sensitive regulatory-controlled data: engage third-party forensics services to perform e-discovery and assess incident.

1. Activate CSIRT, engage third-party forensic services, and execute Sensitive Data Disclosure workflow per guidance of CSIRT incident commander.

ii. If user does not work with sensitive data: review any exfiltrated data for sensitivity and possible impact on regulatory compliance posture, customer confidentiality, and/or business impact.

c. Remediate data identified to have been inappropriately stored (if applicable).

Forensic Analysis 1. If deemed appropriate, the CSIRT team and third-party forensic analysts shall collect and analyze

forensic images for affected systems. Refer to Appendix I – Windows Forensic Collection for instructions.

d. Review hard disk images for affected systems to identify artifacts indicative of creation, access, or modification of system files and the exfiltration of data.

e. Perform a full search of Internet history files for references to known or suspicious files or malicious sites.

f. Perform a timeline analysis to identify events contemporaneous with the suspect emails.



http://www.iana.org/numbers

Date: Owner:



Phishing Decision Charts

Phishing – Triage



Date: Owner:



Phishing – Blocking Procedures



Date: Owner:



Sensitive Data DisclosureLast Updated: 10/10/2016

Sensitive Data Disclosure – SummaryA sensitive data disclosure incident refers to either an anomalous event that may indicate a security intrusion, or an accidental disclosure of sensitive information. Exceptions for this may exist in extraordinary situations, such as device loss or theft. However, due to encryption in use on mobile workstations, actual disclosure is unlikely.

The Sensitive Data Disclosure workflow also covers the basic processes that should be followed during potential Breach scenarios, where the CSIRT and Legal need to evaluate the incident and determine if notification/disclosure processes should be executed.

Detection Notification of sensitive data disclosure is likely to come from an external party, except in cases where Office 365 email DLP flags sensitive data. The response effort will be reactive in nature and will likely turn into either a malware or hacking incident response, leveraging the appropriate workflow.

Alternatively, detection comes in the form of incident response for another type of incident, wherein it is discovered that sensitive data may have been lost or disclosed.

Scoping Scoping for sensitive data disclosure incidents starts with evaluating the data to determine if it is in fact sensitive or regulatory-controlled in nature. This is dependent on data classification practices within the IRM ISIRP. The legal team will be extensively involved in managing the incident and ensuring that communications are properly handled.

Once scoping is complete, the incident response process will likely progress directly into another workflow for actual response efforts and a resolution.



Date: Owner:



Sensitive Data Disclosure – Incident Response Process1. Review information and available evidence.

112. Determine if protected or sensitive information is involved.

113. Data generally falls into one of three classifications:

a. Legally Protected Information: Information or data in this classification is typically regulated or would cause a significant business impact if it were disclosed. Data protected by Health Insurance Portability and Protection Act (“HIPAA”), Payment Card Industry Data Security Standard (“PCI DSS”), Electronic Personal Health Information (“ePHI”), and personally identifiable information (“PII”) are all examples of protected data.

i. Personal information : Protected under state law, applies to North Carolina residents – an individual’s first name or initial and last name in combination with any one or more of the following data elements, when either the name or the data elements are not encrypted:

a) Social Security number

b) Driver’s license or North Carolina identification card number

c) Account number, credit or debit card number in combination with any required password, security or access code that permits access to an account

d) Medical information such as medical history, mental or physical condition, or treatment/diagnosis

e) Health insurance information such as an individual’s health insurance policy number, subscriber identification number, or unique identifiers used to identify the individual by a health insurer

ii. Personally identifiable information : Personal identifiable financial information that IRM collects about an individual in connection with providing a product or service, unless that information is otherwise publicly available.

b. Sensitive Information: Information or data that has the potential for significant negative impact if disclosed outside IRM, or whose access or distribution is restricted by policy or agreement. Performance evaluation, trade secrets, contracts, and agreements are potential examples of this form of data.

c. Public Information: Information or data not regulated and appropriately made available through public-facing interfaces such as public websites. Public event calendars, programs, and business offerings are examples.

114. If no protected or sensitive information is in question, execute any other applicable workflows, log, and close the event.

115. If protected or sensitive information is involved, notify CSIRT, Communications department, Compliance, and legal personnel.

116. Determine if data compromise is hosted or stored on a local system.

117. Hosted system data compromise:



Date: Owner:



a. Obtain liaison member and attach to CSIRT.

b. Legal/Compliance helps in determining required notifications and reporting.

118. Local system data compromise:

a. Engage third-party forensics/incident response firm for forensic analysis of compromised system(s).

b. The primary goal for the forensic investigator should be to determine the primary means of compromise or disclosure and refer to appropriate workflow.

c. Ensure that root cause is remediated once it is identified.

119. Establish remediation plan based on forensic analysis and/or hosting provider information (as appropriate).

a. If leakage was result of hacking incident, engage hacking workflow as needed.

120. Coordinate with compliance, marketing, and legal counsel for any required notification process for disclosed data.



Date: Owner:





Date: Owner:



Sensitive Data Disclosure – Decision Chart



Date: Owner:



Third-Party Data BreachLast Updated: 10/10/2016

Third-Party Data Breach - SummaryA Third-Party Data Breach incident refers to either an intrusion or breach event occurring in a system external to IRM, wherein the breached party has connectivity and a trust relationship with IRM systems or networks. The most common examples for these third-party relationships are externally hosted data or services, such as cloud based payroll, benefits, or other Software as a Service (“SAAS”) systems, contractors, or vendors with access to IRM network or devices.

Because the majority of the incident response efforts are focused on the third party’s systems, the level of effort on IRM’s side will be variable, and depends on the nature of the third party’s services and how they interact with IRM. Much of the effort will center on audits, with any additional activities guided via other referenced workflows.

Third-Party Data Breach – Incident Response Process

Initial Notification or Identification 1. IRM receives notification or intelligence on a third-party breach.

121. Identify if the breach is of a contractor / vendor, or an external system that hosts IRM data or services.

Contractor / Vendor Systems 1. Determine if access by the contractor or vendor is disabled.

122. In most instances, access to IRM systems and network should be disabled.

a. In situations where connections need to be maintained, the CSIRT works with Subject Matter Experts (“SME”) for affected systems to put additional controls in place ensuring safe and secure communications.

b. If these controls cannot be accomplished, the third-party connectivity should be disabled.

123. Establish a Point of Contact (“POC”) at the third party. This POC serves as the CSIRT’s liaison for response activities at the third-party organization.

a. The POC must be consistent with providing continuity of information flow and ensure that the CSIRT receives timely and reliable answers regarding response and actions that IRM may need to take.

124. Working with the third-party POC, identify periods for the suspected breach of the third party.

125. IRM (working with Reliaquest) reviews security monitoring, and other log information for the connections and systems accessible by the third party.

a. These logs should at a minimum be reviewed of the period encompassing, one month prior to the suspected breach time reported by the third party, if available.



Date: Owner:



126. If evidence of malicious or suspicious activity is observed in the audit, then the CSIRT executes the hacking workflow on the systems in question.

127. In absence of an observed malicious or suspicious activity, the CSIRT continues to communicate with the third-party POC until the issue has been resolved by the third party.

128. Once the third-party organization reports a return to normal business operations, the CSIRT evaluates if the issue has been resolved to IRM’s satisfaction. The CSIRT also determines if access is restored, and what additional controls are put in place.

129. If and when third-party access has been restored, IRM increases monitoring of third-party connectivity for a minimum period of one month.

Hosted Data or Services 1. Determine if access by the contractor or vendor is disabled.

130. In most instances, access to IRM system and network should be disabled.

a. In situations where connections need to be maintained, the CSIRT works with Subject Matter Experts (“SMEs”) for affected systems to put additional controls in place, ensuring safe and secure communications.

b. If these controls cannot be accomplished, the third-party connectivity should be disabled.

131. If the determination is made to disable access, then the CSIRT determines if suitable backup systems exist.

a. If backup systems exist, they are brought online for utilization throughout the response period.

b. If suitable backup systems are not in place, the CSIRT works with SMEs and affected business units’ representative to establish an alternate process for use during the response period.

132. Establish a POC at the third party. This POC serves as the CSIRT’s liaison for response activities at the third-party organization.

a. The POC must be consistent with providing continuity for information flow and ensure that the CSIRT can receive timely and reliable answers regarding response and actions that IRM may need to take.

133. Review Service Level Agreements (SLAs) with Legal to ensure agreements are being met.

134. Identify what IRM data is being housed or accessed by third party.

a. The CSIRT may need to work with IRM business units, as well as the third-party POC, to ensure that potentially compromised records are adequately identified.

135. Consult with Legal to determine if IRM has any reporting requirements or if reporting exists only with the third party.

a. If Reporting requirements only exist for the third party, the CSIRT consults with IRM Legal and Executive Leadership to determine if IRM makes independent notification of potentially affected IRM customers or personnel.

b. If IRM makes independent notification, the CSIRT works with Legal and the CSIRT Communications representative to develop a communication plan.

136. If IRM is not making independent notification, it consults with Legal and the third-party POC for contact information that may be provided to affected customers and Personnel.



Date: Owner:



137. If IRM has reporting requirements, execute the Sensitive Data Disclosure workflow.

a. The CSIRT works with the third-party POC for elements of the workflow that are outside IRM’s dominion and control.

138. In absence of an observed malicious or suspicious activity, the CSIRT continues to communicate with the third-party POC until the issue has been resolved by the third party.

139. Once the third-party organization reports a return to normal business operations, the CSIRT evaluates if the issue has been resolved to IRM’s satisfaction. The CSIRT also determines if access will be restored, and what additional controls are put in place.

140. If and when third-party access has been restored, IRM increases monitoring of third-party connectivity for a minimum period of one month.



Date: Owner:



Third-Party Data Breach – Decision ChartThird-Party Breach – Contractor/Vendor



Date: Owner:





Date: Owner:



Third-Party Breach – Hosted Data or Services



Date: Owner:





Date: Owner:



Rogue WiFi Access PointLast Updated: 10/10/2016

Rogue AP – SummaryRogue WiFi access points may be an indicator of both an information security incident and a physical security incident. The primary concern is that there may be a malicious actor who is attempting to gain access to IRM network resources through the use of an unauthorized WiFi access point plugged into an accessible network port.

Detection Detection of a rogue AP varies based on the technologies available. Frequently, such detection methods involve either proactive scans of the WiFi frequencies using IRM’s existing WiFi hardware, or these devices will be revealed via the SIEM, as their presence should trigger DHCP and switch/router events and the presence of a new MAC address on the network.

Scoping Scoping a rogue AP incident involves performing research on the device and then locating said device on IRM premises. Switch logs are commonly reviewed to narrow the location of the device, and compared with network maps if needed.

Eradication Removing the AP from the network serves to eradicate the attacker’s access, provided they have not already pivoted into systems from a different means of access. Increased monitoring of unusual network activities and netflow data may help to identify a persistent compromise, which should be managed using the hacking workflow.



Date: Owner:



Rogue AP – Incident Response ProcessA rogue access point (‘AP’) is detected on the network potentially redirecting employee data. The following steps may apply:

1. Running a rogue AP scan from the main IRM WiFi network, an unknown AP is identified connected to the IRM network.

a. Or the ReliaQuest SIEM alerts on a new service in the DMZ

4. Using the MAC address, identify the vendor of the device.

b. There are multiple online tools that can help with this. http://www.macvendors.com/ is one of the tool that can identify the vendor from the devices MAC address.

5. Review the switch logs to identify what switch the rogue device is connected to.

6. If possible, immediately begin a packet capture on all of the traffic being received by the device, as well as being sent by the device.

c. Try to identify if sensitive data is being sent through the rogue AP.

7. Go to the physical location of the switch and identify the rogue Ethernet cable.

d. Try to identify the SSID of the rogue AP.

8. Use the rogue Ethernet cable as a guide to track down the rogue AP.

e. If the SSID of the AP is possessed, use software that can help to identify the AP by detecting the strength of the signal.

i. Some tools that can do this are Cain & Abel or Aircrack-ng.

9. Once the rogue AP is found, photograph the device in-place, and then disconnect it from the network.

f. Take additional photographs of the device’s ports and any external markings.

g. Store the device with a chain of custody form.

10. Review the security cameras and digital access control logs for the area the device was found to try to identify who placed the rogue AP.

h. If the individual can be identified, contact law enforcement.

141. Notify IRM physical security about the incident.

11. Document all steps, notable events, and findings.

12. Share lessons learned to improve systems, controls, and practices, as appropriate.



Date: Owner:



Rogue AP – Decision Chart



Date: Owner:



Zero Day / VulnerabilitiesLast Updated: 10/10/2016

Zero Day/Vulnerabilities – Incident Response SummaryZero-day (“0-day”) vulnerabilities are hardware or software vulnerabilities that are exploited by an adversary before that vulnerability has been disclosed to the public. These types of attacks may be associated with nation-state actors attempting to access very targeted systems, or with a new, widespread malvertising/ransomware campaign leveraging a vulnerability that affects common computer users.

While IRM is unlikely to be targeted directly by a nation-state, the possibility of IRM computers being vulnerable to a more widespread zero-day affecting a broad audience does exist. The intent of this workflow is to develop a plan for remediating the vulnerability once it has been discovered.

Detection Zero-day threats will likely be discovered through either forensic investigation associated with an existing incident at IRM, or they will be identified through information security news posts, FBI Infragard news releases, and social media (similar to the publicity surrounding Heartbleed in 2015). ReliaQuest may also notify IRM about such vulnerabilities as they become public knowledge.

Scoping Once the vulnerability has been discovered and made public, IRM should review the details regarding the vulnerability to determine if there is any risk. The National Vulnerability Database (https://web.nvd.nist.gov/view/vuln/search) can be referenced, as can other technical write-ups.

Research should focus on determining if there are any systems or appliances at IRM that are vulnerable. If so, the CSIRT should work with the stakeholders responsible for management of the systems to develop a remediation plan. If the vulnerability affects a large number of systems, it may be necessary to take a triage approach, and address critical infrastructure first.

Remediation and Recovery Remediation will be dependent on the availability of code patches for the affected systems. This may be firmware updates for hardware such as the firewalls, out-of-band operating system patches, or patches for specific applications.

If patches exist, they should be tested and deployed as soon as possible. For critical infrastructure, or vulnerabilities that facilitate remote code execution (RCE), this process should be expedited (but care should be taken to ensure that there is no risk to patient care or other operations).

If patches do not exist, the CSIRT will need to collectively determine what level of risk is acceptable. If the vulnerability does not affect critical infrastructure, it may be possible to isolate individual vulnerable systems temporarily (or revoke external access, depending on context). For vulnerabilities that would be more widespread, such as a Flash vulnerability associated with a widespread Ransomware campaign, the CSIRT can develop alternate strategies such as blocking Flash at the perimeter or centrally deactivating the plugins on workstations.



Date: Owner:



Zero Day/Vulnerabilities – Incident Response Process

Initial Triage 1. Vulnerability is reported or discovered.

2. If the suspected vulnerability is discovered in the course of normal business, or during response to an incident, search the National Vulnerability Database (“NVD”) to determine if it is a known vulnerability, or possible zero day vulnerability.

3. If the issue is a suspected zero-day vulnerability, contact the vendor or manufacturer of the product to determine if it is a known issue and if a patch or work around is available.

4. If the issue is a known vulnerability, or newly released vulnerability, determine if IRM is vulnerable to the issue.

a. This is context-dependent. If it affects a common software product, review the IRM software catalogue and determine if it’s a component of most system builds.

i. WMIC queries and other solutions can be used to identify installed components in the Windows environment.

b. For hardware such as firewalls, refer to other system inventories, SMEs and documentation.

5. If you are not certain IRM’s vulnerability status, search the NVD and other resources to determine if a plug-in or vulnerability assessment tool is available.

6. If no plug-in or tool exists, a mechanism for determining IRM’s vulnerability needs to be developed. This may be a manual audit, creation of a custom plug-in, or script to test systems for the susceptible software, hardware, or configuration.

Extended Response 1. Scan the network to determine if the vulnerable issue exists.

7. Based on the vulnerability, review to see if IRM has existing technologies that mitigate the vulnerability.

8. If IRM is found to be vulnerable to the issue, determine if there are patches or other mitigation techniques that IRM may apply. These may include:

c. IDS/IPS or Firewall rules

d. Patches

e. Host-based anti-virus or Signature updates

f. Manufacturer-suggested “Work around”

g. Configuration changes

142. If there are no tools, techniques, or technology recommendations for addressing the issue, attempt to determine if Proof of Concept Code has been released for the vulnerability.

a. The presence of proof of concept code escalates the need to address the vulnerability since it has been shown that the vulnerability can be exploited.



Date: Owner:



b. PoC code is frequently noted in news articles related to zero-day vulnerabilities.

143. If there is proof of concept code, attempt to obtain a copy of the proof of concept code.

a. The code should be reviewed to determine if defenses or mitigations of the exploit mechanism in the code can be enacted.

i. This review may also be facilitated by engaging with third-party incident responders, or with ReliaQuest/CrowdStrike.

144. The information in the NVD, and proof of concept code are utilized to develop indicators of compromise, firewall, and IDS/IPS rules to deploy for mitigation.

a. Work with ReliaQuest to employ SIEM alert rules based on the new IoCs.

b. Contact CrowdStrike Overwatch and verify that they are monitoring for endpoint indicators associated with the vulnerability.

Remediation 1. Review and test the remediation method to determine its viability and likelihood of adverse impact

on the network and systems.

145. If the mitigation plan is determined likely to fail, or create adverse impacts, a new plan is developed.

146. If the plan is approved, the mitigation efforts move forward and the plan is implemented.

147. The network and systems are monitored for indicators of compromise or adverse activity.

148. Going forward the vulnerability is researched to determine if the affected manufacturer or security vendors have released a patch, rules, or other mitigations.

149. If released, the patch, rule, or signature is placed into an evaluation cycle for potential deployment.

150. If compromise based on the vulnerability is discovered, the Hacking Workflow is executed on the affected systems.



Date: Owner:



Zero Day/Vulnerabilities – Decision Charts

Zero Day Vulnerability – Triage



Date: Owner:



Zero Day Vulnerability – Extended Response



Date: Owner:

Version #: 1.0 Page #: 100 of 142


Zero Day Vulnerability – Remediation



Date: Owner:

Version #: 1.0 Page #: 101 of 142


Hostile Employee Separation LockoutLast Updated: 10/10/2016

Hostile Employee Termination – Workflow SummaryThis workflow is intended to guide IRM in managing hostile terminations in a clear, concise manner. These are situations wherein a user has had their employment terminated by IRM in a non-amiable manner.

Hostile terminations are with-cause firings where the employee was terminated due to issues such as illegal activity, ethical breaches, or violations of IRM policy.

The manual steps involved in the account lockout process are described in the current SOW-Active-Directory-Termination document (currently v4).The employee separation process addresses both normal users, as well as those with privileged/admin access to IRM IT infrastructure.

Hostile Employee Termination – Process

General Hostile Termination Steps 1. Receipt of notification of termination or suspensions from HR

a. Physician terminations will be presented on the monthly termination list

151. Account will be disabled in Active Directory, Epic, HPF, CPSI, Groupwise, Outlook

a. IAM system should automatically terminate AD and Epic access for employees if not performed manually.

i. Contractors/Vendors must be terminated manually

b. Email to termination DL will allow owners of additional systems not centrally maintained to terminate access as needed.

152. Collect user's workstation.

a. For terminated users, retain the hard drive along with a chain of custody form, until it is determined that there is no need to retain evidence. The computer itself can be repurposed.

b. For suspended users, store the entire computer until that user is either terminated or returns to work. If terminated, refer to 3a, otherwise return workstation to the user.

153. If user had privileged accounts (domain admin, etc.), proceed to privileged user hostile termination steps below.

Privileged User - Hostile Termination 1. If terminated user has domain administrative credentials or other sensitive data credentials,

change passwords to administrative, service, and test accounts known and utilized by the user.

2. Secure user's former workstation for potential forensic analysis in future.



Date: Owner:

Version #: 1.0 Page #: 102 of 142


3. Change default password(s), if any, that may have been known by the user.

a. This includes the local administrator account passwords

154. Perform domain and local user account audit to identify and disable potential backdoor accounts.

155. Conduct firewall and VPN audit to identify potential backdoor network access by terminated user.

156. Review findings from audits in steps 4 and 5.

a. If evidence of malicious activities tied to terminated user exist, contract third-party forensic services to identify extent of incident.

i. Forensic examiner will review admin's workstation and other data for evidence of abuse.

b. If findings indicate data loss, refer to Sensitive Data Disclosure workflow.



Date: Owner:

Version #: 1.0 Page #: 103 of 142


Hostile Employee Termination – Decision Charts

Hostile Termination – General Workflow



Date: Owner:

Version #: 1.0 Page #: 104 of 142


Hostile Termination – Privileged User Lockout



Date: Owner:

Version #: 1.0 Page #: 105 of 142


Unauthorized/Inappropriate AccessLast Updated: 10/10/2016

Unauthorized/Inappropriate Access – Workflow SummaryThis workflow covers both access to IRM systems or data by unauthorized external actors, and unauthorized or inappropriate access by internal actors.

Examples of inappropriate access, or use of IRM data include, but are not limited to:

Utilization of user accessible data to identify, or contact IRM employees, or customers for personal reasons.

Access of employee compensation information.

Utilization of company resources for personal projects or gain.

Detection Identification of unauthorized or inappropriate access to data may come in the form of external notifications, SIEM alerts (reported by ReliaQuest), and detection or reporting by internal or external source of unauthorized access to a network accessible host or data resource. This access may be malicious or unintentional, and one of the goals of this process is to evaluate the evidence available to make that determination.

Unauthorized/Inappropriate Access – Incident Response ProcessExternal Actor:

1. If the access is suspected by an external actor, the Hacking workflow is initiated.

157. The CSIRT consults with Legal and IRM leadership to determine if law enforcement notification is made or is required, and if appropriate, included in the response efforts.

Internal Actor:

1. Identify systems and data accessed.

2. Identify the user account that accessed the data.

3. Determine if the data accessed is categorized as Protected or Sensitive?

4. If the accessed data falls into the Protected or Sensitive categories, is it suspected or known that the data was disclosed?

5. If it is known or suspected that Protected or Sensitive was disclosed, then the Sensitive Data Disclosure Workflow is executed.

6. If no Protected or Sensitive data was accessed or accessed but not disclosed, the CSIRT works with supervisors and business unit representatives to determine if access to the data in question is required by the suspected user.

7. If access is not required, determine if IRM can apply additional controls to isolate the suspected user from accessing to the data



Date: Owner:

Version #: 1.0 Page #: 106 of 142


a. This may require moving user into a different group, changing permissions, etc. The CSIRT has authority to determine the appropriate course of action.

8. If the suspected user’s job requires access to the data in question, review policies and procedures to determine if they address or identify the action as a violation of IRM policy.

9. If the violation is identified as a violation, or if the conduct is criminal in nature, the supporting evidence is collected and the Forensic collection workflow is completed on the user’s and suspect’s accessed systems.

b. This should be supported by engagement of a third-party forensics firm.

10. If the suspected conduct is criminal, the CSIRT consults with Legal and IRM leadership to determine if law enforcement notification is required.

11. If the conduct is not criminal or a violation of IRM rules, policy or procedures, the CSIRT should consider the need to collect forensic evidence in support of disciplinary action, and make recommendations for changes.

12. If conduct was consistent with legitimate business practices and represents a false-positive incident, review controls and remediate rules that caused the alert.



Date: Owner:

Version #: 1.0 Page #: 107 of 142


Unauthorized / Inappropriate Access – Decision Chart



Date: Owner:

Version #: 1.0 Page #: 108 of 142


Appendix I – Windows Forensic Collection DetailsLast Updated: 10/10/2016

IntroductionIn instances where it potentially assists in the identification of method, extent and origin of cyber events, or there is a high likelihood of legal action, collection of forensic information is prudent. In many instances, there may be statutes or regulations mandating the collection and analysis of digital data.

Due to the constantly evolving threat landscape, attack methodologies, the tools and techniques utilized to identify and investigate them, it is impossible to develop a formal methodology to address all potential situations an investigator may encounter during a forensics response. The investigative tools set available and utilized must represent a broad variety of abilities from collecting digital media, isolating unallocated space for deleted or historical files and creation of time lines, to name only a few.

The specific tools and techniques utilized in collection of forensic information are determined at the discretion of the examiner and may vary dependent on conditions encountered during the investigation. In instances where the examiner deviates from forensically accepted tools and techniques, they document the reasons for the deviation and any testing that was done to validate the utilized tools/techniques.

Instances where deviation may be required include, but are not limited to:

Anti-forensic tools or techniques on the part of a malicious actor

New or unique hardware/software encountered

Legacy or mission critical software that may be adversely affected by traditional tools or techniques

Tools NeededThe instructions in this appendix involve the following tools:

External USB 3.0 hard drive

o For best results, use portable 2TB drives that do not require external power sources.

Microsoft BitLocker

Mandatory if drive is being shipped to third-party investigators.

AccessData’s FTK Imager Lite

Magnet Forensics RAM Capture

Pre-acquisition Process:1. Determine if forensic collection is needed/required.

c. This is determined based on the type of incident, and if the workflow has called for this.

d. This may also be required if instructed by third-party incident responders.

2. Verify that authority exists for the collection/examination of the resource or system. Is this a IRM asset?



http://www.magnetforensics.com/downloads/MagnetRAMCapture.exe

http://accessdata.com/product-download/digital-forensics/ftk-imager-lite-version-3.1.1

https://technet.microsoft.com/en-us/library/cc732774.aspx

Date: Owner:

Version #: 1.0 Page #: 109 of 142


3. Is the target system virtual or is it a physical machine?

4. Record individuals present during collection.

e. IRM staff performing collection, any present third party assistants, etc.

158. Fill out the chain of custody form and ensure all appropriate devices are included, and that the individual providing the devices signs the document.

159. For physical systems: a. Photograph suspect devices in current location.

b. Photograph all cable connections.

c. Create case tags.

i. The tag must include at a minimum the case number and the date of acquisition.

ii. The case number can match an incident ticket number or other identifier.

d. Photograph serial numbers, service tags, unique markings, external components, etc.

i. Each photograph must include a corresponding case tag within the picture itself. This allows for correlation between the photo and the case.

ii. Ensure the camera is configured with the current date and time. If possible, configure the camera to write the date and time into the image itself.

160. For virtualized systems:

a. Take a screenshot of the target VM within the management console

161. Collect machine information:

a. Virtual Machine:

i. Record the name of the VM and the date/time.

ii. Create a clone/snapshot of the VM and record the name of the snapshot/clone for reference in notes.

iii. Size of VM

iv. VM owner

b. Physical Machine:

i. Collect target intelligence:

a) What OS is the target?

b) Number of disks, size, and files systems

c) Location of resource

d) Person(s) with control or access

e) Time of operations

Forensic Storage Media1. Obtain a brand new USB 3.0 external hard drive large enough to store the contents of the target

computer’s hard drive. Use multiple drives if necessary.



Date: Owner:

Version #: 1.0 Page #: 110 of 142


2. Record the make/model/serial number of the hard drive in your incident notes and on a chain of custody form.

Virtual Machine ImagingImaging VMs will ensure that a copy of the hard drive as well as the system’s memory will be preserved. To collect forensic images from a VM:

1. Snapshot and Clone the VM in the management console.

2. Copy the entire VM snapshot onto your forensic storage media. Be sure to note the filenames and the folder where the data will be stored.

Physical: Volatile Memory Capture InstructionsLive memory captures provide investigators with an opportunity to examine data that may be live in memory on the subject endpoint. This may be useful in identifying malware, open network connections, or other interesting data. Memory analysis can also provide examiners with deeper contextual understanding of evidence found during examination of the hard drive image.

Memory captures are much smaller than hard drive images, and if they are acquired first, these images can be provided to Optiv electronically for more immediate investigative efforts while the more time-consuming hard drive imaging is being completed.

Instructions 1. Download Magnet Forensics’ RAM Capture tool. This is a free utility that can acquire forensic

memory images from a Windows computer.a. http://www.magnetforensics.com/downloads/MagnetRAMCapture.exe

i. Note that the above will ask for an email address prior to download. You can provide a fake email address to prevent exposing your information.

2. Save the MagnetRAMCapture.exe onto the imaging hard drive where you’re storing the forensic data.

3. Run MagnetRAMCapture.exe on the target computer with the memory data you want to acquire. You will see a EULA (click OK/Agree) and then this window will appear (likely after a UAC popup):



http://www.magnetforensics.com/downloads/MagnetRAMCapture.exe

Date: Owner:

Version #: 1.0 Page #: 111 of 142


4. For Segment Size, leave this alone.5. The memory capture should be saved to your external drive. Do not save the image onto the

computer itself.



Date: Owner:

Version #: 1.0 Page #: 112 of 142


6. Progress during the capture will appear as follows:

7. Once the capture is complete, close the program. 8. The saved file can be analyzed by the security team using Volatility, or provided to third-party

incident responders upon request.



Date: Owner:

Version #: 1.0 Page #: 113 of 142


Physical: Hard Drive Image CaptureUtilizing AccessData’s FTK Imager Lite version, which can be run via a thumb drive or your external hard drive, a forensically-viable image of the can be saved onto an external hard drive.

Notes: Note that you will need local administrator rights to use FTK Imager Lite.

If your external hard drive that you’re using to store your images is already encrypted with BitLocker, you’ll need to be sure you can unlock it on the computer you are imaging. You may want to wait and encrypt the drive AFTER imaging is complete and verified.

Hard Drive Imaging Instructions To begin, extract all of the files from the FTK Imager.zip to the root of your external drive. Run the X:\FTK Imager\FTK Imager.exe program.

1. In the top left of the program, click the “Create Disk Image” icon:



http://accessdata.com/product-download/digital-forensics/ftk-imager-lite-version-3.1.1

Date: Owner:

Version #: 1.0 Page #: 114 of 142


162. Select “Physical Disk”

163. More often than not, the root drive (“C” Drive) will be labeled as \\.\PHYSICALDRIVE0. Select this option and press “Finish”



Date: Owner:

Version #: 1.0 Page #: 115 of 142


164. On the next screen, you’ll notice options to check and uncheck.

It is suggested that the “Verify images after they are created” remains checked unless time is a factor in this process. Removing this check will save a significant amount of time but it is not recommended to skip this step.

If you uncheck the verification box, you will need to verify the image later.The “Precalculate Progress Statistics” option will show a status update and attempt to determine the completion time.

Press the “ADD” button to advance to the next screen.



Date: Owner:

Version #: 1.0 Page #: 116 of 142




Date: Owner:

Version #: 1.0 Page #: 117 of 142


165. Select the E01 option.



Date: Owner:

Version #: 1.0 Page #: 118 of 142


166. Enter the following information for records:

Case Number: Can be an IR case number, ticket number, or Law Enforcement case number

Evidence Number: Can be sequential if multiple items are collected such as a system with multiple physical internal hard drives

Unique Description: A simple description of what’s being imaged (i.e. Suspected infected system with hostname THISSYSTEMNAME from somewhere, USA)

Examiner: The IRM staff member that is imaging the system

Notes: Special items of note



Date: Owner:

Version #: 1.0 Page #: 119 of 142


167. The next section details where to save the forensic image

Choose a path to the external USB drive. A folder can be created in this step (i.e. X:\evidence\)

Image filename is what the forensic image will be saved as. A common practice is using the hostname of the system being imaged. If multiple drives are in the system, use a naming convention such as HOSTNAME_Drive1 and HOSTNAME_Drive2.

Change the size of the Image Fragment Size to 1500 MB.

If space is limited on the external drive, change the Compression Ratio to 9. For larger drives, leave the setting at 5-6. Note that additional compression will increase the time it takes to create the forensic image.

168. Click “Finish” and then “Start”. Be patient, it will take some time to forensically image the hard drive!

169. Verify the image. If you left the Verification box checked, review the result and ensure that the hashes match.

170. Establish chain of custody for all items of evidence collected. Document the serial number information for the USB hard drive containing your images on the chain of custody form.

171. Create and validate working copies of forensic images. These are copies that you would ship to third-party examiners.



Date: Owner:

Version #: 1.0 Page #: 120 of 142


a. Encrypt these drives using Bitlocker. Ensure that you have documented the decryption key!

172. Place the original USB hard drive in evidence storage, with a copy of the chain of custody form.



Date: Owner:

Version #: 1.0 Page #: 121 of 142


Appendix II – Malware Incident Response NotesLast Updated: 10/10/2016

Common Malware Startup EntriesStartup entries tend to be the best indicators of a system suspected of being infected by malware. They are useful because they are easy to inspect and will normally include the names and paths of malicious files. All forms of operating systems have ways to identify startup items, such as registry entries in Windows and cron jobs in Linux. When analyzing computers for potential malware infections, these should be among the first data points investigated. The following sections will detail, by operating system, both the pre- and post-infection suggestions and initial research vectors.

Windows Startup Items Microsoft Windows is, by volume, one of the most prevalent and therefore one of the most vulnerable operating systems susceptible to compromise by malware. The key to protecting your organization is to develop methods for identifying any changes to a common baseline.

If there is any reason to suspect compromise, it is imperative to investigate all start-up items on the hosts. There are many locations on a Windows host that execute items on boot. When looking at start-up items on a computer that may be infected, make sure use Autoruns, which queries all common startup items.

The Windows Registry contains the most frequently-used startup items that will be encountered on infected machines. Table 1 details the most commonly-exploited Registry keys. Malicious Registry entries typically contain detailed references to the malware that they are meant to run. In some cases, full paths to files will be present. In cases where paths are not present these files are likely resident within any directory contained within a Windows system’s %PATH% environment variable, which is associated with a number of default directories but may contain custom entries added by users or installed software as well.

In addition to Registry entries, startup items may also be located in any of the Start menu Startup subdirectories, as Scheduled Tasks located in the Tasks directories, and within a number of legacy automatic execution items such as autoexec.bat and win.ini. Table 2 details these types of startup items.

Table 1: Common Windows Registry Autorun KeysHive Key Path ValueHKLM6 Software7\Microsoft\Windows\CurrentVersion\RunHKLM Software\Microsoft\Windows\CurrentVersion\RunOnceHKLM Software\Microsoft\Windows\CurrentVersion\RunOnceExHKLM Software\Microsoft\Windows\CurrentVersion\RunServicesHKLM Software\Microsoft\Windows\CurrentVersion\RunServicesOnceHKLM Software\Microsoft\Windows NT\CurrentVersion\WinLogon NotifyHKLM Software\Microsoft\Windows NT\CurrentVersion\WinLogon UserinitHKLM Software\Microsoft\Windows NT\CurrentVersion\WinLogon ShellHKLM Software\Microsoft\Windows NT\CurrentVersion\ImageFileExecutionOptions\

*.exe8Debugger

HKLM Software\Microsoft\Windows\CurrentVersion\Explorer\Run

6 HKLM = HKEY_LOCAL_Machine; HKCU = HKEY_CURRENT_USER

7 HKLM\Software data is stored within the %WinDir%\System32\Config\Software file. All HKCU values will be within a %UserProfile%\NTUSER.DAT file.

8 http://blogs.mcafee.com/mcafee-labs/image-file-execution-options



https://technet.microsoft.com/en-us/sysinternals/bb963902.aspx

Date: Owner:

Version #: 1.0 Page #: 122 of 142


HKLM Software\Microsoft\Windows\CurrentVersion\Explorer\SharedTaskSchedulerHKLM Software\Microsoft\Windows\CurrentVersion\ShellServiceObjectDelayLoadHKLM Software\Microsoft\Windows NT\CurrentVersion\Windows Appinit_DLLsHKCU Software\Microsoft\Windows\CurrentVersion\RunHKCU Software\Microsoft\Windows\CurrentVersion\RunServicesHKCU Software\Microsoft\Windows\CurrentVersion\RunServicesOnceHKCU Software\Microsoft\Windows NT\CurrentVersion\Windows LoadHKCU Software\Microsoft\Windows NT\CurrentVersion\WinLogon ShellHKCU Software\Microsoft\Windows\CurrentVersion\Explorer\Run

Table 2: Windows File/Directory Startup LocationsStartup File/Directory EntriesFor Windows Vista, Server 2008, and Newer:%ProgramData%9\Microsoft\Windows\Start Menu\Programs\Startup%AppData%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup%SystemRoot%\System32\Tasks10

For Windows XP and Server 2003:%UserProfile%\Start Menu\Programs\Startup%AllUsersProfile%\Start Menu\Programs\Startup%SystemRoot%\TasksAll Windows Versions:%SystemDrive%\autoexec.bat%SystemDrive%\config.sys%WinDir%\wininit.ini%WinDir%\win.ini%WinDir%\system.ini%WinDir%\dosstart.bat%WinDir%\system\autoexec.nt%WinDir%\system\config.nt

Linux Startup Items Like Windows, Linux has startup items, however, cataloguing them is substantially more challenging. Different distributions, the open-source development platform, and its modular nature, make it difficult to recommend a singular plan for enumerating the relevant startup items. Malware targeting a Linux-based system could be configured to load automatically via an incredible number of methods, limited in some cases only by the creativity of the Malware’s author.

The list of startup items to check for on Linux systems that is contained in Table 3 is not exhaustive, but touches on the areas that should be examined if a system is suspected of compromise. Entries in this section are universal to the Linux platform, however, in some cases the entries listed may not be present for all distributions.

There are also a handful of “best practices” for managing Linux installations that may help augment any efforts to document common startup entries:

Verify all packages with distribution-specific package manager.

Review process list for suspicious entries.

Review listening sockets for suspicious services.

9 For a list of Windows Environment Variables, refer to http://en.wikipedia.org/wiki/Environment_variable#Microsoft_Windows10 Only Windows 7 and newer



http://en.wikipedia.org/wiki/Environment_variable#Microsoft_Windows

Date: Owner:

Version #: 1.0 Page #: 123 of 142


Identify any directories on disk with permissions that allow any users to write and execute.

Search for SSH keys when performing audits.

Review loadable kernel modules (LKM) both manually and with a rootkit detection utility.

Table 3: Common Linux Startup AreasStartup File/Directory Entries/var/spool/cron/crontabs/etc/inittab/etc/inetd.conf/etc/profile~/.bash_profile~/.bash_login~/.profile~/.bashrc/etc/bash.bashrc/etc/init.d/etc/rc.d/proc/modules

MacOS Startup Items Similar to Linux, MacOS startup entries will be found within configuration files and directories, however the search for common startup entries is much more straightforward. While there are many items that can be investigated during a malware analysis of an MacOS system, two filetypes will be imperative in identifying startup anomalies: Property List (*.plist) files and Kernel Extension (*.kext) files.

Property List files are XML text files containing a number of instructions that are interpreted by the OS. These text files will also contain identifying data such as filenames or paths, from which you can find target executable files. Kernel Extension files are actually directories containing multiple files, including configuration-related .plist files and the executable files that would be used by the OSX Mach kernel itself.

In addition to the common startup files, MacOS also has the capacity to include shell-based startup items which should be evaluated during an examination of a potentially infected system. If there is a manual host investigation with access to the desktop, the Users & Groups component of the System Preferences.app lists Login Items. This list allows an investigator to view common applications that are loaded upon login. These items should be evaluated to ensure that they do not represent a threat to the system.

When establishing baseline images, ensure that system inventories of Mac systems catalogue all LaunchAgents, LaunchDaemons, StartupItems, and Extensions directories as well as any loginwindow.plist files. Table 4 provides a table of common MacOS startup entry areas that should be examined during incident response.

Table 4: Common MacOS Startup AreasStartup File/Directory Entries~/.bashrc~/.bash_profile~/Library/Preferences/loginwindow.plist~/Library/LaunchAgents/~/Library/LaunchDaemons//Library/LaunchAgents//Library/LaunchDaemons//Library/StartupItems//Library/Extensions//Library/Bundles/



Date: Owner:

Version #: 1.0 Page #: 124 of 142


/System/Library/LaunchAgents//System/Library/LaunchDaemons/System/Library/Extensions//System/Library/StartupItems//System/Library/LoginPlugins//private/etc/bashrc/private/etc/rc.common/private/etc/services/private/etc/shells/private/etc/mach_init.d/private/etc/mach_init_per_user.d

Tools for Basic Malware IdentificationMalware is designed to utilize various methods of camouflage to prevent detection, and in some cases it is necessary to leverage third-party utilities to identify malicious files. There have been many tools and utilities developed for Windows that help responders evaluate startup entries and expose other indicators, however for Linux and Mac environments there are only a few utilities that serve as analogues to the utilities available to Windows users.

For Linux and MacOS, it is important to become familiar with the Unix-derived command line functionalities built into the operating systems, which are incredibly powerful in the hands of a capable incident responder and should make up for the lack of standalone tools.

All utilities listed in this section are available for free unless otherwise noted.

Windows Tools and Utilities Many tools and utilities exist for use with the Windows platform. Some of the most commonly-leveraged tools for Optiv incident responders are distributed by Microsoft as part of the SysInternals suite. Please note that some of the utilities in these categories duplicate the functionality of other listings. Optiv encourages malware incident responders to try all tools and identify those that they prefer.

Startup Entries Microsoft SysInternals Autoruns

TrendMicro HijackThis

Processes and Events Microsoft SysInternals Process Explorer

Microsoft SysInternals Process Monitor

PETools

CrowdResponse

File Analysis and Information Safer-Networking Filealyzer

GMER Rootkit Detector

PEiD

PEStudio



https://www.winitor.com/tools/pestudio/current/pestudio.zip

http://www.aldeid.com/wiki/PEiD

http://www.gmer.net/

http://www.safer-networking.org/products/filealyzer/

https://s3.amazonaws.com/download.crowdstrike.com/crowdresponse/CrowdResponse.zip

http://sourceforge.net/projects/pe-tools/

http://technet.microsoft.com/en-us/sysinternals/bb896645

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

http://sourceforge.net/projects/hjt/

http://technet.microsoft.com/en-us/sysinternals/bb963902.aspx

Date: Owner:

Version #: 1.0 Page #: 125 of 142


Linux Malware Identification Tools and Utilities Linux malware analysis will frequently be based on the use of built-in tools. While some security tools exist for this platform, most malware analysts investigating Linux infections will leverage the Linux command-line for most analysis.

System Integrity Tiger

COPS

Rootkit Detection Chrootkit

Rootkit Hunter

File Integrity Analysis Tripwire

hashdeep

MacOS Tools and Utilities Similar to Linux, the majority of tools and utilities for MacOS environments are built into the operating system itself. There are some third party tools available, though the number is far less than for Windows environments.

Startup Entries Launchctl

Cronnix

Processes and Events Activity Monitor

File Analysis and Information Rootkit Hunter



http://rkhunter.sourceforge.net/

http://support.apple.com/kb/HT5890

https://code.google.com/p/cronnix/

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/launchctl.1.html

http://md5deep.sourceforge.net/

http://sourceforge.net/projects/tripwire/

http://rkhunter.sourceforge.net/

http://www.chkrootkit.org/

http://www.fish2.com/cops/overview.html

http://www.nongnu.org/tiger/

Date: Owner:

Version #: 1.0 Page #: 126 of 142




Date: Owner:

Version #: 1.0 Page #: 127 of 142


Appendix III – IOC Scanning

Throughout the incident response processes in this playbook, there are situations where the responder will need to search for Indicators of Compromise (IOCs) across the network. Performing these scans can be accomplished in a number of ways, depending on the endpoint and the type of indicator.

Common Filesystem IndicatorsFilesystem indicators can be identified using CrowdStrike’s management console for Falcon Host to search for specific indicators, or Carbon Black. Scans can also be performed using Yara rules and CrowdStrike’s CrowdResponse toolkit (which are free), launched via PowerShell.

Typical indicators that should be noted during the IR process and later leveraged via these tools include:

Filename

File hash (MD5, SHA-1, SHA-256)

Directory name

File size

Date/Timestamp

While hash matches are relatively exact, searches based on filename or directory path, size, or timestamp may not yield perfect results. Many types of malware or hacking tools will be deployed with random names, and may have variable sizes and variations in timestamps. When searching for files or directories based on these characteristics, you may need to look at multiple characteristics and make a judgement call.

For example, consider the following:System1 FileFilename: psexe.exePath: C:\Users\admin\appdata\local\temp\deervatMD5: 6828d4ee86ff8fa92d18a4aa36ff8e2cSize: 41553Created: 10/12/2016 15:41:21

System2 FileFilename: psecx.exePath: C:\users\marketing\appdata\local\temp\kljdffgMD5: 6828d4ee86ff8fa92d18a4aa36ff8e2cSize: 41553Created: 10/09/2016 02:43:15

System3 FileFilename: psexf.exePath: C:\programdata\lkjsdfdMD5: 97537eb42075bf1e881fde93c6fc8165Size: 41496Created: 09/15/2015



Date: Owner:

Version #: 1.0 Page #: 128 of 142


From the above, we can see that System1 and System2 have the same identical file, as shown with the matching MD5. As a result, we see a valid indicator of compromise. Hashes are one of the most reliable indicators. Unfortunately, not all hashes match, as we see when we add System3 into the mix.

We also see a similar naming pattern with the files from all three systems. The filename itself is fairly consistent with minimal variation, and the subdirectory in which it resides appears to be named with seven random letters. The exception here is that the file on System3 doesn’t exist in the same directory structure (though it is still in a location where it should not be!).

There is a very good chance based on these very basic characteristics that these files are all the same malware. Even if files 1 and 2 did not match on the MD5, they are very similar in terms of where they are located, the rough timeframe, and the directory structure. The size also matches.

The third file is an outlier however. Despite this, the size is very close. Based on this, you can search for a rough size range, and may be able to leverage regular expressions based on directory name (depending on the tool you are using).

Verifying that the files are related beyond this level requires some level of binary analysis, either simple static analysis using a tool like PEStudio, execution in the Wildfire sandbox, or full reverse engineering.

Yara and CrowdResponse Scans For situations where Carbon Black or CrowdStrike cannot be used, you will need to use Yara rules to scan for known indicators of compromise. Using Yara requires two steps: building the rules file for signatures, and then deploying the scanning engine using PowerShell.

Yara RulesYara leverages a straightforward rules syntax, and is incredibly powerful. Yara can be used by the IRM team, or by third-party incident responders, to search across the network for malicious files and processes. Many IR consulting firms will provide Yara rules during the IR process and within the postmortem writeup.

Yara can support basic characteristics such as hashes, names, and directory paths, but also supports binary strings encoded in ASCII or Unicode, hexadecimal code patterns, regular expressions, and even memory offsets for live malware.

Refer to the Yara wiki for tutorials on writing rules for detection for your specific incident.:

http://yara.readthedocs.io/en/v3.4.0/index.html

Scanning with Yara and CrowdResponseOnce the Yara rules are composed, either by IRM analysts or your third-party consultants, the next step is to deploy CrowdResponse and scan for the indicators. There are a number of references that cover how to leverage the tools, including the CrowdResponse User Guide (which is bundled with the tool).

CrowdResponse can be run locally on the endpoint, but you should also be able to execute it remotely over the wire if the host has not been isolated.

Refer to the SANS DFIR blog for a summary of signature detection with CrowdResponse:

https://digital-forensics.sans.org/blog/2014/04/09/signature-detection-with-crowdresponse

CrowdResponse itself can be downloaded from CrowdStrike’s website:

https://www.crowdstrike.com/resources/community-tools/



https://www.crowdstrike.com/resources/community-tools/

https://digital-forensics.sans.org/blog/2014/04/09/signature-detection-with-crowdresponse

http://yara.readthedocs.io/en/v3.4.0/index.html

Date: Owner:

Version #: 1.0 Page #: 129 of 142


Common Network IndicatorsIn addition to filesystem indicators of compromise that exist on individual computers, the incident response process will also uncover network-based indicators that can be reviewed against things like the firewall, DNS, and web proxy logs. Much of this will be queried against data flowing into the ReliaQuest SIEM.

Frequently the intent with these IOCs is to review logs for evidence of all computers that may have communicated with a known-bad host outside the IRM network, and the implement blocking for future prevention and attacker containment.

IOC Sources Network IOCs may be visible in CrowdStrike/Carbon Black, or discovered when analyzing samples in WildFire.The IOCs may also be included in reports from McAfee, CrowdStrike, or your third-party IR services consultant.

Network IOC Examples Examples of indicators include:

IP addresses and hostnames contacted by malware or from which an attacker is remotely accessing systems

Visible in firewall, switch, dns logs

URLs that malware is attempting to resolve, or from which malware has been previously downloaded. Alternatively, phishing websites.

Visible in web proxy logs, Office 365 audit logs, DNS logs (partial)

TCP ports consistent with the incident. May be common ports like 22 (SSH) or unusual virtual ports with higher numbers.

Visible in firewall logs

User Agent Strings. These may be unusual browser configurations, misconfigured hacking/audit tools, or other signature traits consistent with a malicious actor.

Visible in web proxy logs, Office 365 audit logs



Date: Owner:

Version #: 1.0 Page #: 130 of 142




Date: Owner:

Version #: 1.0 Page #: 131 of 142


Appendix IV – Targeted PhishingThis Targeted Phishing addendum describes phishing attacks and techniques leveraged against high profile organizations and the mitigation thereof. The addendum covers common phishing techniques and their prevention.

Overview: What is Phishing?Phishing involves an attacker sending emails or other electronic messages masquerading as a legitimate originator in order to steal and exploit personal information through direct means or third-party transactions. These attacks are often sent through email, but can also be transmitted through instant messages and SMS.

In addition to how the attack is delivered, phishing campaigns are categorized by target selection. In particular, two categories are of significantly greater importance to organizations due to the targeted nature of the threat they present:

Spear phishing

Whale phishing (“Whaling”)

Spear Phishing In essence, spear phishing is a highly-targeted phishing attack. Rather than taking a broad “shotgun” approach that harvests personal information of people from all over the world, an attacker executing a targeted phishing attack attempts to gather data about potential targets and then uses that information to deliver extremely well composed phishing messages that are very convincing to target users.

In a June 2012 survey by Proofpoint11, of 339 IT professionals interviewed (214 of whom represented companies with over 1,000 users), 51% of survey respondents reported that they believed their organization had been the target of a spear phishing attack.

Whale Phishing Whale phishing is a variant of spear phishing that explicitly targets an organization’s upper-management structure, with efforts commonly focused on C-level executive staff.

Combating PhishingPhishing attacks can be mitigated with human and technical controls. Attacks target individuals, meaning the human factor in prevention is more important than in other network attacks.

Human-centric phishing controls consist of user awareness training and a dependence on individuals to maintain a vigilant watch on their own incoming messages. Awareness training assists people in recognizing the signs of fraudulent messages, and is beneficial, but it is not necessarily an effective use of a security budget.

Typically, no matter how much time, effort, or money is invested in deploying user awareness training, this attack has a high success rate. Different studies show that phishing campaigns targeting user banking credentials have a success rate of around 0.5%12. The phishing campaigns that Optiv creates

11 http://www.proofpoint.com/downloads/Proofpoint-Spear-Phishing-and-Info-Security-Survey-Findings-July-2012.pdf

12 http://www.theregister.co.uk/2009/12/07/phishing_hit_rate/



http://www.theregister.co.uk/2009/12/07/phishing_hit_rate/

http://www.proofpoint.com/downloads/Proofpoint-Spear-Phishing-and-Info-Security-Survey-Findings-July-2012.pdf

Date: Owner:

Version #: 1.0 Page #: 132 of 142


and customizes for corporate clients typically have a success rate of between 10% and 30%. Despite the best intentions of user awareness training, a highly targeted and well-researched phishing attack finds victims in the majority of environments.

In the experience of Optiv’s penetration testing teams, the element that has prevented the success of our phishing attacks has been the use of technical controls. These controls should cover multiple attack vectors, and if correctly implemented, ensure that even if a malicious email link is clicked or a file is downloaded, technical controls prevent any harm to the integrity of the network, despite the failure on the human level.

Anatomy of a Phishing AttackA phishing attack, such as the kind used by Optiv during a penetration test, is comprised of five basic steps. These steps replicate real-world methods used by malicious actors in the creation of targeted phishing campaigns:

1. Target (people) identification

173. Delivery of “falsified” emails

174. Create and deploy a backdoor to steal information

175. Gather and encrypt the stolen data

176. Transfer the stolen data back to the attacking team

For a skilled attacker, target identification is a meticulous process. In essence, the attackers gather a list of target email addresses and then filter out anyone they suspect is likely to recognize the attack, such as members of the security team. The attackers use a variety of automated tools to obtain target email addresses, relying heavily on resources like Google search results, LinkedIn profiles, and Salesforce’s Jigsaw. Using publicly-available data, the attacking team continues to refine their list of potential targets until they feel confident in their chances of success.

Once targets are identified, the attackers craft their fake email message. This begins with an attention-grabbing subject line that is simple enough to appear authentic. The attack email appears to be completely genuine, without any of the spelling or grammatical errors that are frequently observed in bulk phishing emails routinely picked up by spam filters. The message itself is easy to read, and includes a hook that gives readers a reason to click the links in the email.

Attackers may also create a legitimate-looking website, often cloning a portal page or building a custom page based on the mimicked organization’s own CSS, images, and codebase. The fake site normally uses an SSL certificate, duplicates the favicon of the real website, and also features WHOIS info that would potentially fool more skeptical users. These sites may have additional features, such as the ability to serve custom malware that helps attackers extract credentials and establish their backdoor access.

After the attackers have successfully delivered their messages and compromised users’ data, they work to create a backdoor into the target organization’s network. Delivery vectors typically consist of malware that takes the form of an infected PDF (though this is less common as users have become more educated about the possibility of malicious PDFs over the years), visual basic macros encoded into Microsoft Word or Excel files, and Java applets. Any custom malware is developed in a manner designed to evade antivirus detection, frequently using custom packing routines, binary obfuscation, and digital signatures.

Once the backdoor is successfully deployed, attackers focus on exploring the network and identifying data they want to acquire. At this point, attackers likely gain access to additional network resources, increasing their overall access to the target organization’s data. Once data of interest has been identified, it is gathered up and encrypted so that it may be easily transferred out of the owner’s infrastructure. The method of data transfer varies depending on the nature of the backdoor that the attackers created.



Date: Owner:

Version #: 1.0 Page #: 133 of 142


Attack PreventionThere are multiple technical controls that can be deployed to ensure that a targeted phishing attack is less likely to succeed in accessing any private data:

Network Segmentation By compartmentalizing data and making sure that differing network areas have no trust of one another, an attacker who successfully compromises a user via a spear phishing attack does not necessarily have access to all of an organization’s resources. Segmentation may also benefit organizations subject to standards such as PCI-DSS via a reduced audit scope.

IPS/IDS Systems Intrusion Prevention Systems and Intrusion Detection Systems are two additional mechanisms that can be deployed to give a security team additional insight into attacks against the organization’s network. In the case of the IPS, these attempts may be automatically denied if the system is appropriately tuned.

Egress Filtering Limiting the amount and type of data allowed to be transmitted outside of the network environment may help limit data loss in some situations.

Standardized Antivirus Implementations Effective antivirus deployment is a significant component of any network’s overall security profile. By ensuring that all deployed AV solutions follow a consistent standard within the organization, it is much easier for security staff members to monitor anomalous activity.

Binary Packet Inspection At the perimeter level, this builds a data loss prevention system, inspecting packet content to look for anomalous binary data that should not leave the internal network.

SSL Interception As part of the same DLP concept mentioned with Binary Packet Inspection, SSL Interception should also be executed at the perimeter level to ensure that sensitive data is not removed from the network.

Two-Factor Authentication The addition of a second authentication layer helps deter and prevent attackers from taking advantage of any compromised user credentials.

User Awareness Despite insistence that it is not the most economically-effective method for preventing network compromise and data loss from a phishing attack, user awareness still plays a role in limiting and mitigating an attack. As more users are trained to become skeptics, they become allies to the security team in thwarting potential attacks by reporting attacks to the security team and protecting their own individual credentials.



Date: Owner:

Version #: 1.0 Page #: 134 of 142


Visual ExamplesIncluded below is a selection of screenshots taken by Optiv’s EIM team during actual investigations. These examples showcase targeted phishing attacks we have encountered.

Example 1: Fake Google Drive In this example, an organization using Google Apps for Business was targeted by a phishing attack. This attack featured URLs that directed victims to a website vaguely (arguably poorly) emulating the appearance of a legitimate Google site.

This image shows the overall appearance of the page. To the trained eye, it is evident that the page lacks credibility. While we have blacked out the malicious URL, there is no indication of site security in the URL navigation box. Note the distortion in the Google Docs text image at the top:

Figure 1: Fake Google Drive page

Additionally, the title of the page in the tab bar is “Googe Docs” – Another indicator of a generic attack, rather than a well-crafted spear or whale phishing campaign.



Date: Owner:

Version #: 1.0 Page #: 135 of 142


On the same page, after clicking the Gmail link button – A pop-up log in box is spawned for the visitor to enter their credentials:

Figure 2: Login Promot from Fake Google Drive page



Date: Owner:

Version #: 1.0 Page #: 136 of 142


Once entered, the credentials are transmitted by the site’s script after the user clicks Sign In:

Figure 3: Credentials in Transit

Example 2: Fake IT Administrative Notice In the second email example, a user receives a message indicating their mailbox is full and that they need to follow the included link to remediate the issue:

Figure 4: Fake IT Administrative Notice



Date: Owner:

Version #: 1.0 Page #: 137 of 142


The subsequent phish page features this dialogue:

Figure 5: Welcome to Admin Server Portal



Date: Owner:

Version #: 1.0 Page #: 138 of 142


The headers from this email are also quite telling (victim email address is blacked out):

Figure 6: Sample phishing email headers

In the figure above, a red box surrounds a word meant to be mistaken for “helpdesk.” Additional header data helps illustrate the fraudulent nature of this email. In this case, the attack is somewhat more amateurish, but a dedicated attacker can produce a phishing email that would be incredibly convincing.

Targeted Phishing – Additional Resources Below is a collection of URLs pertaining to phishing defense:



Date: Owner:

Version #: 1.0 Page #: 139 of 142


General The Anti-Phishing Working Group

Awareness Programs and Information SANS: Building a Phishing Assessment Program SANS Security Awareness Roadmap SANS Phishing Assessments Planning Package Microsoft (Outlook-centric)

URL Lookups OpenDNS Phishtank phishing URL repository



http://www.phishtank.com/

http://office.microsoft.com/en-us/outlook-help/identify-fraudulent-e-mail-and-phishing-schemes-HA001140002.aspx

http://www.securingthehuman.org/media/resources/presentations/PhishingAssessments.zip

http://www.securingthehuman.org/resources/security-awareness-roadmap/

http://www.youtube.com/watch?v=QcwqvOW5W5s

http://www.antiphishing.org/

Date: Owner:

Version #: 1.0 Page #: 140 of 142


GeneralVersion Control

Rev. Responsible Description of Revision Release Date

New Hanover Regional Medical Center€¦ · Web viewIncident Response Procedures Table of...

Documents

Transcript of New Hanover Regional Medical Center€¦ · Web viewIncident Response Procedures Table of...