Category Archives: triage

The DFIR Hierarchy of Needs & Critical Security Controls

Posted on by

As you weigh how best to improve your organization’s digital forensics and incident response (DFIR) capabilities heading into 2017, consider Matt Swann‘s Incident Response Hierarchy of Needs. Likely, at some point in your career (or therapy 😉) you’ve heard reference to Maslow’s Hierarchy of Needs. In summary, Maslow’s terms,  physiological, safety, belongingness & love, esteem, self-actualization, and self-transcendence, describe a pattern that human motivations generally move through, a pattern that is well represented in the form of a pyramid.
Matt has made great use of this model to describe an Incident Response Hierarchy of Needs, through which your DFIR methods should move. I argue that his powerful description of capabilities extends to the whole of DFIR rather than response alone. From Matt’s Github, “the Incident Response Hierarchy describes the capabilities that organizations must build to defend their business assets. Bottom capabilities are prerequisites for successful execution of the capabilities above them:”

The Incident Response Hierarchy of Needs

“The capabilities may also be organized into plateaus or phases that organizations may experience as they develop these capabilities:”

Hierarchy plateaus or phases

As visualizations, these representations really do speak for themselves, and I applaud Matt’s fine work. I would like to propose that a body of references and controls may be of use to you in achieving this hierarchy to its utmost. I also welcome your feedback and contributions regarding how to achieve each of these needs and phases. Feel free to submit controls, tools, and tactics you have or would deploy to be successful in these endeavors; I’ll post your submission along with your preferred social media handle.
Aspects of the Center for Internet Security Critical Security Controls Version 6.1 (CIS CSC) can be mapped to each of Matt’s hierarchical entities and phases. Below I offer one control and one tool to support each entry. Note that there is a level of subjectivity to these mappings and tooling, but the intent is to help you adopt this thinking and achieve this agenda. Following is an example for each one, starting from the bottom of the pyramid.

 INVENTORY – Can you name the assets you are defending?  
Critical Security Control #1: Inventory of Authorized and Unauthorized Devices
Family: System
Control: 1.4     
“Maintain an asset inventory of all systems connected to the network and the network devices themselves, recording at least the network addresses, machine name(s), purpose of each system, an asset owner responsible for each device, and the department associated with each device. The inventory should include every system that has an Internet protocol (IP) address on the network, including but not limited to desktops, laptops, servers, network equipment (routers, switches, firewalls, etc.), printers, storage area networks, Voice Over-IP telephones, multi-homed addresses, virtual addresses, etc.  The asset inventory created must also include data on whether the device is a portable and/or personal device. Devices such as mobile phones, tablets, laptops, and other portable electronic devices that store or process data must be identified, regardless of whether they are attached to the organization’s network.” 
Tool option:
Spiceworks Inventory

 TELEMETRY – Do you have visibility across your assets?  
Critical Security Control #6: Maintenance, Monitoring, and Analysis of Audit Logs
Family: System
Control: 6.6      “Deploy a SIEM (Security Information and Event Management) or log analytic tools for log aggregation and consolidation from multiple machines and for log correlation and analysis.  Using the SIEM tool, system administrators and security personnel should devise profiles of common events from given systems so that they can tune detection to focus on unusual activity, avoid false positives, more rapidly identify anomalies, and prevent overwhelming analysts with insignificant alerts.”
Tool option:  
AlienVault OSSIM

 DETECTION – Can you detect unauthorized actvity? 
Critical Security Control #8: Malware Defenses
Family: System
Control: 8.1
“Employ automated tools to continuously monitor workstations, servers, and mobile devices with anti-virus, anti-spyware, personal firewalls, and host-based IPS functionality. All malware detection events should be sent to enterprise anti-malware administration tools and event log servers.”
Tool option:
OSSEC Open Source HIDS SECurity

 TRIAGE – Can you accurately classify detection results? 
Critical Security Control #4: Continuous Vulnerability Assessment and Remediation
Family: System
Control: 4.3
“Correlate event logs with information from vulnerability scans to fulfill two goals. First, personnel should verify that the activity of the regular vulnerability scanning tools is itself logged. Second, personnel should be able to correlate attack detection events with prior vulnerability scanning results to determine whether the given exploit was used against a target known to be vulnerable.”
Tool option:
OpenVAS         

 THREATS – Who are your adversaries? What are their capabilities? 
Critical Security Control #19: Incident Response and Management
Family: Application
Control: 19.7
“Conduct periodic incident scenario sessions for personnel associated with the incident handling team to ensure that they understand current threats and risks, as well as their responsibilities in supporting the incident handling team.”
Tool option:
Security Incident Response Testing To Meet Audit Requirements

 BEHAVIORS – Can you detect adversary activity within your environment? 
Critical Security Control #5: Controlled Use of Administrative Privileges
Family: System
Control: 5.1
“Minimize administrative privileges and only use administrative accounts when they are required.  Implement focused auditing on the use of administrative privileged functions and monitor for anomalous behavior.”
Tool option: 
Local Administrator Password Solution (LAPS)

 HUNT – Can you detect an adversary that is already embedded? 
Critical Security Control #6: Maintenance, Monitoring, and Analysis of Audit Logs       
Family: System
Control: 6.4
“Have security personnel and/or system administrators run biweekly reports that identify anomalies in logs. They should then actively review the anomalies, documenting their findings.”
Tool option:
GRR Rapid Response

 TRACK – During an intrusion, can you observe adversary activity in real time? 
Critical Security Control #12: Boundary Defense
Family: Network
Control: 12.10
“To help identify covert channels exfiltrating data through a firewall, configure the built-in firewall session tracking mechanisms included in many commercial firewalls to identify TCP sessions that last an unusually long time for the given organization and firewall device, alerting personnel about the source and destination addresses associated with these long sessions.”
Tool option:
Bro

 ACT – Can you deploy countermeasures to evict and recover? 
Critical Security Control #20: Penetration Tests and Red Team Exercises       
Family: Application
Control: 20.3
“Perform periodic Red Team exercises to test organizational readiness to identify and stop attacks or to respond quickly and effectively.”
Tool option:
Red vs Blue – PowerSploit vs PowerForensics

 Can you collaborate with trusted parties to disrupt adversary campaigns? 
Critical Security Control #19: Incident Response and Management       
Family: Application
Control: 19.5
“Assemble and maintain information on third-party contact information to be used to report a security incident (e.g., maintain an e-mail address of security@organization.com or have a web page http://organization.com/security).”
Tool option:
MISP

I’ve also started to map the hierarchy to the controls in CIS CSC 6.1 spreadsheet, again based on my experience and perspective, your may differ, but consider similar activity.

I’ll make my first pass at the spreadsheet mapping effort available here shortly.

I truly hope you familiarize yourself with Matt‘s Incident Response Hierarchy of Needs and find ways to implement, validate, and improve your capabilities accordingly. Consider that the controls and tools mentioned here are but a starting point and that you have many other options available to you. I look forward to hearing from you regarding your preferred tactics and tools as well. Kudos to Matt for framing this essential discussion so distinctly.

Continue reading The DFIR Hierarchy of Needs & Critical Security Controls→

The DFIR Hierarchy of Needs & Critical Security Controls

Posted on by

As you weigh how best to improve your organization’s digital forensics and incident response (DFIR) capabilities heading into 2017, consider Matt Swann‘s Incident Response Hierarchy of Needs. Likely, at some point in your career (or therapy 😉) you’ve heard reference to Maslow’s Hierarchy of Needs. In summary, Maslow’s terms,  physiological, safety, belongingness & love, esteem, self-actualization, and self-transcendence, describe a pattern that human motivations generally move through, a pattern that is well represented in the form of a pyramid.
Matt has made great use of this model to describe an Incident Response Hierarchy of Needs, through which your DFIR methods should move. I argue that his powerful description of capabilities extends to the whole of DFIR rather than response alone. From Matt’s Github, “the Incident Response Hierarchy describes the capabilities that organizations must build to defend their business assets. Bottom capabilities are prerequisites for successful execution of the capabilities above them:”

The Incident Response Hierarchy of Needs

“The capabilities may also be organized into plateaus or phases that organizations may experience as they develop these capabilities:”

Hierarchy plateaus or phases

As visualizations, these representations really do speak for themselves, and I applaud Matt’s fine work. I would like to propose that a body of references and controls may be of use to you in achieving this hierarchy to its utmost. I also welcome your feedback and contributions regarding how to achieve each of these needs and phases. Feel free to submit controls, tools, and tactics you have or would deploy to be successful in these endeavors; I’ll post your submission along with your preferred social media handle.
Aspects of the Center for Internet Security Critical Security Controls Version 6.1 (CIS CSC) can be mapped to each of Matt’s hierarchical entities and phases. Below I offer one control and one tool to support each entry. Note that there is a level of subjectivity to these mappings and tooling, but the intent is to help you adopt this thinking and achieve this agenda. Following is an example for each one, starting from the bottom of the pyramid.

 INVENTORY – Can you name the assets you are defending?  
Critical Security Control #1: Inventory of Authorized and Unauthorized Devices
Family: System
Control: 1.4     
“Maintain an asset inventory of all systems connected to the network and the network devices themselves, recording at least the network addresses, machine name(s), purpose of each system, an asset owner responsible for each device, and the department associated with each device. The inventory should include every system that has an Internet protocol (IP) address on the network, including but not limited to desktops, laptops, servers, network equipment (routers, switches, firewalls, etc.), printers, storage area networks, Voice Over-IP telephones, multi-homed addresses, virtual addresses, etc.  The asset inventory created must also include data on whether the device is a portable and/or personal device. Devices such as mobile phones, tablets, laptops, and other portable electronic devices that store or process data must be identified, regardless of whether they are attached to the organization’s network.” 
Tool option:
Spiceworks Inventory

 TELEMETRY – Do you have visibility across your assets?  
Critical Security Control #6: Maintenance, Monitoring, and Analysis of Audit Logs
Family: System
Control: 6.6      “Deploy a SIEM (Security Information and Event Management) or log analytic tools for log aggregation and consolidation from multiple machines and for log correlation and analysis.  Using the SIEM tool, system administrators and security personnel should devise profiles of common events from given systems so that they can tune detection to focus on unusual activity, avoid false positives, more rapidly identify anomalies, and prevent overwhelming analysts with insignificant alerts.”
Tool option:  
AlienVault OSSIM

 DETECTION – Can you detect unauthorized actvity? 
Critical Security Control #8: Malware Defenses
Family: System
Control: 8.1
“Employ automated tools to continuously monitor workstations, servers, and mobile devices with anti-virus, anti-spyware, personal firewalls, and host-based IPS functionality. All malware detection events should be sent to enterprise anti-malware administration tools and event log servers.”
Tool option:
OSSEC Open Source HIDS SECurity

 TRIAGE – Can you accurately classify detection results? 
Critical Security Control #4: Continuous Vulnerability Assessment and Remediation
Family: System
Control: 4.3
“Correlate event logs with information from vulnerability scans to fulfill two goals. First, personnel should verify that the activity of the regular vulnerability scanning tools is itself logged. Second, personnel should be able to correlate attack detection events with prior vulnerability scanning results to determine whether the given exploit was used against a target known to be vulnerable.”
Tool option:
OpenVAS         

 THREATS – Who are your adversaries? What are their capabilities? 
Critical Security Control #19: Incident Response and Management
Family: Application
Control: 19.7
“Conduct periodic incident scenario sessions for personnel associated with the incident handling team to ensure that they understand current threats and risks, as well as their responsibilities in supporting the incident handling team.”
Tool option:
Security Incident Response Testing To Meet Audit Requirements

 BEHAVIORS – Can you detect adversary activity within your environment? 
Critical Security Control #5: Controlled Use of Administrative Privileges
Family: System
Control: 5.1
“Minimize administrative privileges and only use administrative accounts when they are required.  Implement focused auditing on the use of administrative privileged functions and monitor for anomalous behavior.”
Tool option: 
Local Administrator Password Solution (LAPS)

 HUNT – Can you detect an adversary that is already embedded? 
Critical Security Control #6: Maintenance, Monitoring, and Analysis of Audit Logs       
Family: System
Control: 6.4
“Have security personnel and/or system administrators run biweekly reports that identify anomalies in logs. They should then actively review the anomalies, documenting their findings.”
Tool option:
GRR Rapid Response

 TRACK – During an intrusion, can you observe adversary activity in real time? 
Critical Security Control #12: Boundary Defense
Family: Network
Control: 12.10
“To help identify covert channels exfiltrating data through a firewall, configure the built-in firewall session tracking mechanisms included in many commercial firewalls to identify TCP sessions that last an unusually long time for the given organization and firewall device, alerting personnel about the source and destination addresses associated with these long sessions.”
Tool option:
Bro

 ACT – Can you deploy countermeasures to evict and recover? 
Critical Security Control #20: Penetration Tests and Red Team Exercises       
Family: Application
Control: 20.3
“Perform periodic Red Team exercises to test organizational readiness to identify and stop attacks or to respond quickly and effectively.”
Tool option:
Red vs Blue – PowerSploit vs PowerForensics

 Can you collaborate with trusted parties to disrupt adversary campaigns? 
Critical Security Control #19: Incident Response and Management       
Family: Application
Control: 19.5
“Assemble and maintain information on third-party contact information to be used to report a security incident (e.g., maintain an e-mail address of security@organization.com or have a web page http://organization.com/security).”
Tool option:
MISP

I’ve mapped the hierarchy to the controls in CIS CSC 6.1 spreadsheet, again based on my experience and perspective, yours may differ, but consider similar activity.

CIS CSC with IR Hierarchy mappings

My full mapping of Matt’s Incident Response Hierarchy of Needs in the
CIS CSC 6.1 spreadsheet is available here: http://bit.ly/CSC-IRH

I truly hope you familiarize yourself with Matt‘s Incident Response Hierarchy of Needs and find ways to implement, validate, and improve your capabilities accordingly. Consider that the controls and tools mentioned here are but a starting point and that you have many other options available to you. I look forward to hearing from you regarding your preferred tactics and tools as well. Kudos to Matt for framing this essential discussion so distinctly.

Continue reading The DFIR Hierarchy of Needs & Critical Security Controls→

The DFIR Hierarchy of Needs & Critical Security Controls

Posted on by

As you weigh how best to improve your organization’s digital forensics and incident response (DFIR) capabilities heading into 2017, consider Matt Swann‘s Incident Response Hierarchy of Needs. Likely, at some point in your career (or therapy 😉) you’ve heard reference to Maslow’s Hierarchy of Needs. In summary, Maslow’s terms,  physiological, safety, belongingness & love, esteem, self-actualization, and self-transcendence, describe a pattern that human motivations generally move through, a pattern that is well represented in the form of a pyramid.
Matt has made great use of this model to describe an Incident Response Hierarchy of Needs, through which your DFIR methods should move. I argue that his powerful description of capabilities extends to the whole of DFIR rather than response alone. From Matt’s Github, “the Incident Response Hierarchy describes the capabilities that organizations must build to defend their business assets. Bottom capabilities are prerequisites for successful execution of the capabilities above them:”

The Incident Response Hierarchy of Needs

“The capabilities may also be organized into plateaus or phases that organizations may experience as they develop these capabilities:”

Hierarchy plateaus or phases

As visualizations, these representations really do speak for themselves, and I applaud Matt’s fine work. I would like to propose that a body of references and controls may be of use to you in achieving this hierarchy to its utmost. I also welcome your feedback and contributions regarding how to achieve each of these needs and phases. Feel free to submit controls, tools, and tactics you have or would deploy to be successful in these endeavors; I’ll post your submission along with your preferred social media handle.
Aspects of the Center for Internet Security Critical Security Controls Version 6.1 (CIS CSC) can be mapped to each of Matt’s hierarchical entities and phases. Below I offer one control and one tool to support each entry. Note that there is a level of subjectivity to these mappings and tooling, but the intent is to help you adopt this thinking and achieve this agenda. Following is an example for each one, starting from the bottom of the pyramid.

 INVENTORY – Can you name the assets you are defending?  
Critical Security Control #1: Inventory of Authorized and Unauthorized Devices
Family: System
Control: 1.4     
“Maintain an asset inventory of all systems connected to the network and the network devices themselves, recording at least the network addresses, machine name(s), purpose of each system, an asset owner responsible for each device, and the department associated with each device. The inventory should include every system that has an Internet protocol (IP) address on the network, including but not limited to desktops, laptops, servers, network equipment (routers, switches, firewalls, etc.), printers, storage area networks, Voice Over-IP telephones, multi-homed addresses, virtual addresses, etc.  The asset inventory created must also include data on whether the device is a portable and/or personal device. Devices such as mobile phones, tablets, laptops, and other portable electronic devices that store or process data must be identified, regardless of whether they are attached to the organization’s network.” 
Tool option:
Spiceworks Inventory

 TELEMETRY – Do you have visibility across your assets?  
Critical Security Control #6: Maintenance, Monitoring, and Analysis of Audit Logs
Family: System
Control: 6.6      “Deploy a SIEM (Security Information and Event Management) or log analytic tools for log aggregation and consolidation from multiple machines and for log correlation and analysis.  Using the SIEM tool, system administrators and security personnel should devise profiles of common events from given systems so that they can tune detection to focus on unusual activity, avoid false positives, more rapidly identify anomalies, and prevent overwhelming analysts with insignificant alerts.”
Tool option:  
AlienVault OSSIM

 DETECTION – Can you detect unauthorized actvity? 
Critical Security Control #8: Malware Defenses
Family: System
Control: 8.1
“Employ automated tools to continuously monitor workstations, servers, and mobile devices with anti-virus, anti-spyware, personal firewalls, and host-based IPS functionality. All malware detection events should be sent to enterprise anti-malware administration tools and event log servers.”
Tool option:
OSSEC Open Source HIDS SECurity

 TRIAGE – Can you accurately classify detection results? 
Critical Security Control #4: Continuous Vulnerability Assessment and Remediation
Family: System
Control: 4.3
“Correlate event logs with information from vulnerability scans to fulfill two goals. First, personnel should verify that the activity of the regular vulnerability scanning tools is itself logged. Second, personnel should be able to correlate attack detection events with prior vulnerability scanning results to determine whether the given exploit was used against a target known to be vulnerable.”
Tool option:
OpenVAS         

 THREATS – Who are your adversaries? What are their capabilities? 
Critical Security Control #19: Incident Response and Management
Family: Application
Control: 19.7
“Conduct periodic incident scenario sessions for personnel associated with the incident handling team to ensure that they understand current threats and risks, as well as their responsibilities in supporting the incident handling team.”
Tool option:
Security Incident Response Testing To Meet Audit Requirements

 BEHAVIORS – Can you detect adversary activity within your environment? 
Critical Security Control #5: Controlled Use of Administrative Privileges
Family: System
Control: 5.1
“Minimize administrative privileges and only use administrative accounts when they are required.  Implement focused auditing on the use of administrative privileged functions and monitor for anomalous behavior.”
Tool option: 
Local Administrator Password Solution (LAPS)

 HUNT – Can you detect an adversary that is already embedded? 
Critical Security Control #6: Maintenance, Monitoring, and Analysis of Audit Logs       
Family: System
Control: 6.4
“Have security personnel and/or system administrators run biweekly reports that identify anomalies in logs. They should then actively review the anomalies, documenting their findings.”
Tool option:
GRR Rapid Response

 TRACK – During an intrusion, can you observe adversary activity in real time? 
Critical Security Control #12: Boundary Defense
Family: Network
Control: 12.10
“To help identify covert channels exfiltrating data through a firewall, configure the built-in firewall session tracking mechanisms included in many commercial firewalls to identify TCP sessions that last an unusually long time for the given organization and firewall device, alerting personnel about the source and destination addresses associated with these long sessions.”
Tool option:
Bro

 ACT – Can you deploy countermeasures to evict and recover? 
Critical Security Control #20: Penetration Tests and Red Team Exercises       
Family: Application
Control: 20.3
“Perform periodic Red Team exercises to test organizational readiness to identify and stop attacks or to respond quickly and effectively.”
Tool option:
Red vs Blue – PowerSploit vs PowerForensics

 Can you collaborate with trusted parties to disrupt adversary campaigns? 
Critical Security Control #19: Incident Response and Management       
Family: Application
Control: 19.5
“Assemble and maintain information on third-party contact information to be used to report a security incident (e.g., maintain an e-mail address of security@organization.com or have a web page http://organization.com/security).”
Tool option:
MISP

I’ve mapped the hierarchy to the controls in CIS CSC 6.1 spreadsheet, again based on my experience and perspective, yours may differ, but consider similar activity.

CIS CSC with IR Hierarchy mappings

My full mapping of Matt’s Incident Response Hierarchy of Needs in the
CIS CSC 6.1 spreadsheet is available here: http://bit.ly/CSC-IRH

I truly hope you familiarize yourself with Matt‘s Incident Response Hierarchy of Needs and find ways to implement, validate, and improve your capabilities accordingly. Consider that the controls and tools mentioned here are but a starting point and that you have many other options available to you. I look forward to hearing from you regarding your preferred tactics and tools as well. Kudos to Matt for framing this essential discussion so distinctly.

Continue reading The DFIR Hierarchy of Needs & Critical Security Controls→

Triage Practical Solution – Malware Event – Proxy Logs Prefetch $MFT IDS

Posted on by

Staring at your Mountain Dew you think to yourself how well your malware triage process worked on triaging the IDS alert. It’s not perfect and needs improvement to make it faster but overall the process worked. In minutes you went from IDS alerts to malware on the system. That’s a lot better than what it used to be; where IDS alerts went into the black hole of logs never to be looked at again. Taking a sip of your Mountain Dew you are ready to provide your ISO with an update.

Triage Scenario


To fill in those readers who may not know what is going on the following is the abbreviated practical  scenario (for the full scenario refer to the post Triage Practical – Malware Event – Proxy Logs Prefetch $MFT IDS):

The junior security guy noticed another malware infection showing up in the IDS alerts. They grabbed a screenshot of the alerts and sent it to you by email. As soon as you received the email containing the screenshot shown below you started putting your malware triage process to the test.



Below are some of the initial questions you had to answer and report back to the ISO.

        * Is this a confirmed malware security event or was the junior analyst mistaken?
        * What do you think occurred on the system to cause the malware event in the first place?
        * What type of malware is involved and what capabilities does it have?
        * What potential risk does the malware pose to your organization?
        * What recommendation(s) do you make to the security team to strengthen its security program to reduce similar incidents occurring in the future?

Information Available


Despite the wealth of information available to you within an enterprise, only a subset of data was provided for you to use while triaging this malware event. The following artifacts were made available:

        * IDS alerts for the timeframe in question (you need to replay the provide pcap to generate the IDS alerts. pcap is not provided for you to use during triage and was only made available to enable you to generate the IDS alerts in question)

        * Parsed index.dat files to simulate proxy web logs (the parsed index.dat information was modified to remove items not typically found in a web server’s proxy logs)

        * Prefetch files from the system in question (inside the Prefetch.ad1 file)

        * Filesystem metadata from the system in question (the Master File Table is provided for this practical)

Information Storage Location within an Enterprise


Each enterprise’s network is different and each one offers different information for triaging. As such, it is not possible to outline all the possible locations where this information could be located in enterprises. However, it is possible to highlight common areas where this information can be found. To those reading this post whose environments do not reflect the locations I mention then you can evaluate your network environment for a similar system containing similar information or better prepare your network environment by making sure this information starts being collected in systems.

        * Proxy web logs within an enterprise can be stored on the proxy server itself and/or in a central logging system. In addition to proxy web logs, the potentially infected system will have web usage history for each web browser on the system

        * IDS alerts within an enterprise can be stored on the IDS/IPS sensors themselves or centrally located through a management console and/or central logging system (i.e. SIEM)

        * Prefetch files within an enterprise can be located on the potentially infected system

        * File system metadata within an enterprise can be located on the potentially infected system

Collecting the Information from the Storage Locations


Knowing where information is available within an enterprise is only part of the equation. It is necessary to collect the information so it can be used for triaging. Similar to all the differences between enterprises’ networks, how information is collected varies from one organization to the next. Below are a few suggestions for how the information outlined above can be collected.

        * Proxy web logs will either be located on the proxy server itself or a centralized logging solution. The collection of the logs can be as simple as running a filter in a web graphical user interface to export the logs, copying an entire text file containing log data from the server, or viewing the logs using the interface to the central logging system.

        * IDS alerts don’t have to be collected. They only need to be made available so they can be reviewed. Typically this is accomplished through a management console, security monitoring dashboard, or a centralized logging solution.

        * Prefetch files are stored on the potentially infected system. The collection of this artifact can be done by either pulling the files off remotely or locally. Remote options include an enterprise forensic tools such as F-Response, Encase Enterprise, or GRR Rapid Response, triage scripts such as Tr3Secure collection script, or by using the admin share since Prefetch files are not locked files. Local options can use the same options.

        * File system metadata is very similar to Prefetch files because the same collection methods work for collecting it. The one exception is the file can’t be pulled off by using the admin share.

Potential DFIR Tools to Use


The last part of the equation is what tools one should use to examine the information that is collected. The tools I’m outlining below are the ones I used to complete the practical.

        * Excel to view the text based proxy logs
        * Winprefetchview to parse and examine the prefetch files
        * MFT2CSV to parse and examine the $MFT file

Others’ Approaches to Triaging the Malware Event


Placeholder since none were known at the time of this post

Partial Malware Event Triage Workflow


The diagram below outlines the jIIr workflow for confirming malicious code events. The workflow is a modified version of the Securosis Malware Analysis Quant. I modified Securosis process to make it easier to use for security event analysis


Detection: the malicious code event is detected. Detection can be a result of technologies or a person reporting it. The workflow starts in response to a potential event being detected and reported.

Triage: the detected malicious code event is triaged to determine if it is a false positive or a real security event.

Compromised: after the event is triaged the first decision point is to decide if the machine could potentially be compromised. If the event is a false positive or one showing the machine couldn’t be infected then the workflow is exited and returns back to monitoring the network. If the event is confirmed or there is a strong indication it is real then the workflow continues to identifying the malware.

Malware Identified: the malware is identified two ways. The first way is identifying what the malware is including its purpose and characteristics. The second way is identifying and obtaining the malware from the actual system.

Root Cause Analysis: a quick root cause analysis is performed to determine how the machine was compromised and to identify indicators to use for scoping the incident. This root cause analysis does not call for a deep dive analysis taking hours and/or days but one only taking minutes.

Quarantine: the machine is finally quarantined from the network it is connected to. This workflow takes into account performing analysis remotely so disconnecting the machine from the network is done at a later point in the workflow. If the machine is initially disconnected after detection then analysis cannot be performed until someone either physically visits the machine or ships the machine to you. If an organization’s security monitoring and incident response capability is not mature enough to perform root cause analysis in minutes and analysis live over the wire then the Quarantine activity should occur once the decision is made about the machine being compromised.  

Triage Analysis Solution


I opted to triage this practical similar to a real security event. As a result, the post doesn’t use all of the supplied information and the approach is more focused on speed. The triage process started with the IDS alert screenshot the junior security analyst saw then proceeded to the proxy logs before zeroing in on the system in question.

IDS alerts


The screenshot below is the one supplied by the junior security analyst. In this practical it was not necessary to replay the packet capture to generate these IDS alerts since the screenshot supplied enough information.


Typically you can gain a lot of context about a security event by first exploring the IDS signatures themselves. Gaining context around a security event solely using the IDS signature names becomes second nature by doing event triage analysis on a daily basis. Analysts tend to see similar attacks triggering similar IDS alerts over time; making it easier to remember what attacks are and the traces they leave in networks. For other analysts this is where Google becomes their best friend. The screenshot shows three distinct events related to the malware in this security incident.

1.  ET CURRENT_EVENTS Possible Dyre SSL Cert: these signatures indicate a possible SSL certificate for the Dyre malware. Dyre is a banking Trojan and it uses SSL to encrypt its communication. The practical did not include this but another way to detect this activity is by consuming the SSL Blacklist and comparing it against an organization’s firewall logs or netflow data to see if any internal hosts are communicating with known IP addresses associated with Dyre

2. ET POLICY Internal Host Retrieving External IP via icanhazip[.]com: this signature flags an internal host that contacts a known website associated with identifying the public IP address. Depending on the organization this may or may not be normal behavior for web browsing and/or end users. However, some malware tries to identify the public facing IP address, which will trigger this IDS signature

3. ET TROJAN Common Upatre Header Structure: this signature flags traffic associated with the Upatre Trojan. Upatre is a downloader that installs other programs.

One of the IDS alerts could had been a false positive but it is unlikely for this sequence of alerts all to be false positives. This confirms what the junior analyst believed about the machine being compromised. Specifically, the machine was infected with the Upatre downloader, which then proceeded to install the Dyre banking Trojan.

Web Proxy Logs


IDS alerts provide additional information that can be used in other data sources. The practical doesn’t provide the date and time when the IDS signatures fired but it does provide the destination IP addresses and domain name the machine communicated with. These IP addresses were used to correlate the IDS alerts to activity recorded in the web proxy logs. The web_logs.csv file was imported into Excel and the data was sorted using the date. This puts the log entries chronological order making it easier to perform analysis.

The web logs provided with the practical were very basic. The only information recorded was the date/time, URL, and username. Unfortunately, the destination IP address was not recorded, which is typical with web proxies. As a result, the logs did not contain any entries for the IP addresses 72.175.10.116 and 104.238.141.75.

The search on the domain icanhazip[.]com also came up empty. At this point the web proxy logs provide no additional information with a date and time to go on. This analysis did reveal these web proxy logs suck and the organization needs to make it a priority to record more information to make analysis easier. The organization also needs to ensure the network routes all HTTP/HTTPs web traffic through the proxy so it gets recorded and prevents users and programs from bypassing it.

Prefetch files


At this point in the analysis the machine in question needs to be triaged. Reviewing programs executing on a system is a quick technique to identify malicious programs on a system. The high level indicators I tend to look are below:

        * Programs executing from temporary or cache folders
        * Programs executing from user profiles (AppData, Roaming, Local, etc)
        * Programs executing from C:\ProgramData or All Users profile
        * Programs executing from C:\RECYCLER
        * Programs stored as Alternate Data Streams (i.e. C:\Windows\System32:svchost.exe)
        * Programs with random and unusual file names
        * Windows programs located in wrong folders (i.e. C:\Windows\svchost.exe)
        * Other activity on the system around suspicious files

The collected prefetch files were parsed with Winprefetchview and I initially sorted by process path. I reviewed the parsed prefetch files using the general indicators I mentioned previously and I found the suspicious program highlighted in red.


The first suspicious program was SCAN_001_140815_881[1].SCR executing from the Temporary Internet Files directory. The program was suspicious because it is executing from the lab user profile and its name resembles a document name instead of a screensaver name. To gain more context around the suspicious program I then sorted by the Last Run time to see what else was executing around this time.


The SCAN_001_140815_881[1].SCR program executed at 8/15/2015 5:49:51 AM UTC. Shortly thereafter another executed named EJZZTA8.EXE executed from user’s Temp directory at 8/15/2015 5:51:03 AM UTC. Both prefetch files did not reference any other suspicious executables in their file handles. At this point not only do I have two suspicious files of interest but I also identified the exact date and time when the security event occurred.

Web Proxy Logs Redux


The date and time of the incident obtained from the Prefetch files can now be used to correlate the IDS alerts and suspicious programs to the activity in the web proxy logs. The picture below shows leading up to when the SCAN_001_140815_881[1].SCR program executed the user was accessing Yahoo email.


The rest of the web logs continued to show the user interacting with Yahoo email around the time the infection occurred. However, the web logs don’t record the entry showing where the SCAN_001_140815_881[1].SCR program came from. This occurred either because the web proxy didn’t record it or the web proxy sucks by not recording it. I’m going with latter since the web proxy logs are missing a lot of information.


File system metadata


At this point the IDS alerts revealed the system in question had network activity related to the Upatre downloader and Dyre banking Trojans. The prefetch files revealed suspicious programs named SCAN_001_140815_881[1].SCR that executed at 8/15/2015 5:49:51 AM UTC and EJZZTA8.EXE that executed at 8/15/2015 5:51:03 AM UTC. The web proxy logs showed the user was accessing Yahoo email around the time the programs executed. The next step in the triage process is to examine the file system metadata to identify any other malicious software on the system and to try to confirm the initial infection vector. I reviewed the metadata in a timeline to make it easier to see the activity for the time of interest.

For this practical I leveraged the MFT2CSV program in the configuration below to generate a timeline. However, an effective and faster technique – but not free – is using the home plate feature in Encase Enterprise against a remote system live. This enables you to triage the system live instead of trying to collect files from the system for offline analysis.


In the timeline I went to the time of interest, which was 8/15/2015 5:49:51 AM UTC. I then proceed forward in time to identify any other suspicious files. The first portion of the timeline didn’t show any new activity of interest around the SCAN_001_140815_881[1].SCR file.


Continuing going through the timeline going forward in time lead me to the next file EJZZTA8.EXE. The activity between these two files only showed files being created in the Temporary Internet Files and Cookies directories indicating the user was surfing the Internet.


At this point the timeline did not provide any new information and the last analysis step is to triage the suspicious programs found.

Researching Suspicious Files


The first program SCAN_001_140815_881[1].SCR was no longer on the system but the second program (EJZZTA8.EXE) was. The practical file file_hash_list.csv showed the EJZZTA8.EXE’s MD5 hash was f26fd37d263289cb7ad002fec50922c7. The first search was to determine if anyone uploaded the file to VirusTotal and a VirusTotal report was available. Numerous antivirus detections confirmed the program was Upatre, which matches one of the triggered IDS signatures.

A Google search of the hash located a Hybrid Analysis report and Malware report. The Hybrid Analysis report confirm the sample sends network traffic. This information could then be used to scope the incident to identify potentially other infected machines.


The resources section in the program contains an icon confirming the file tried to mimic a document. This makes me conclude it was a social engineering attack against the user.


The reports contained other information that one could use to identify other infected systems in the enterprise. However, as it relates to the practical there wasn’t much additional information I needed to complete my triage analysis. The next step would be to contact the end user to get the phishing email and then request for the email to be purged from all users’ inboxes.

Triage Analysis Wrap-up


The triage process did confirm the system was infected with malicious code. The evidence that was present on the system and the lack of other attack vector artifacts (i.e. exploits, vulnerable programs executing, etc.) leads me to believe the system was infected due to a phishing email. The email contained some mechanism to get the user to initiate the infection. The risk to the organization is twofold. One of the malicious programs downloads and installs other malware. The other malicious program tries to capture and exhilarate credentials from the system. The next step would be to escalate the malware event to the incident response process so the system can be quarantined, system can be cleaned, end user can be contacted to get the phishing email and then it can be determined why end users have access to web email instead of using the organization’s email system.  Continue reading Triage Practical Solution – Malware Event – Proxy Logs Prefetch $MFT IDS→

Triage Practical Solution – Malware Event – Proxy Logs Prefetch $MFT IDS

Posted on by

Staring at your Mountain Dew you think to yourself how well your malware triage process worked on triaging the IDS alert. It’s not perfect and needs improvement to make it faster but overall the process worked. In minutes you went from IDS alerts to malware on the system. That’s a lot better than what it used to be; where IDS alerts went into the black hole of logs never to be looked at again. Taking a sip of your Mountain Dew you are ready to provide your ISO with an update.

Triage Scenario


To fill in those readers who may not know what is going on the following is the abbreviated practical  scenario (for the full scenario refer to the post Triage Practical – Malware Event – Proxy Logs Prefetch $MFT IDS):

The junior security guy noticed another malware infection showing up in the IDS alerts. They grabbed a screenshot of the alerts and sent it to you by email. As soon as you received the email containing the screenshot shown below you started putting your malware triage process to the test.



Below are some of the initial questions you had to answer and report back to the ISO.

        * Is this a confirmed malware security event or was the junior analyst mistaken?
        * What do you think occurred on the system to cause the malware event in the first place?
        * What type of malware is involved and what capabilities does it have?
        * What potential risk does the malware pose to your organization?
        * What recommendation(s) do you make to the security team to strengthen its security program to reduce similar incidents occurring in the future?

Information Available


Despite the wealth of information available to you within an enterprise, only a subset of data was provided for you to use while triaging this malware event. The following artifacts were made available:

        * IDS alerts for the timeframe in question (you need to replay the provide pcap to generate the IDS alerts. pcap is not provided for you to use during triage and was only made available to enable you to generate the IDS alerts in question)

        * Parsed index.dat files to simulate proxy web logs (the parsed index.dat information was modified to remove items not typically found in a web server’s proxy logs)

        * Prefetch files from the system in question (inside the Prefetch.ad1 file)

        * Filesystem metadata from the system in question (the Master File Table is provided for this practical)

Information Storage Location within an Enterprise


Each enterprise’s network is different and each one offers different information for triaging. As such, it is not possible to outline all the possible locations where this information could be located in enterprises. However, it is possible to highlight common areas where this information can be found. To those reading this post whose environments do not reflect the locations I mention then you can evaluate your network environment for a similar system containing similar information or better prepare your network environment by making sure this information starts being collected in systems.

        * Proxy web logs within an enterprise can be stored on the proxy server itself and/or in a central logging system. In addition to proxy web logs, the potentially infected system will have web usage history for each web browser on the system

        * IDS alerts within an enterprise can be stored on the IDS/IPS sensors themselves or centrally located through a management console and/or central logging system (i.e. SIEM)

        * Prefetch files within an enterprise can be located on the potentially infected system

        * File system metadata within an enterprise can be located on the potentially infected system

Collecting the Information from the Storage Locations


Knowing where information is available within an enterprise is only part of the equation. It is necessary to collect the information so it can be used for triaging. Similar to all the differences between enterprises’ networks, how information is collected varies from one organization to the next. Below are a few suggestions for how the information outlined above can be collected.

        * Proxy web logs will either be located on the proxy server itself or a centralized logging solution. The collection of the logs can be as simple as running a filter in a web graphical user interface to export the logs, copying an entire text file containing log data from the server, or viewing the logs using the interface to the central logging system.

        * IDS alerts don’t have to be collected. They only need to be made available so they can be reviewed. Typically this is accomplished through a management console, security monitoring dashboard, or a centralized logging solution.

        * Prefetch files are stored on the potentially infected system. The collection of this artifact can be done by either pulling the files off remotely or locally. Remote options include an enterprise forensic tools such as F-Response, Encase Enterprise, or GRR Rapid Response, triage scripts such as Tr3Secure collection script, or by using the admin share since Prefetch files are not locked files. Local options can use the same options.

        * File system metadata is very similar to Prefetch files because the same collection methods work for collecting it. The one exception is the file can’t be pulled off by using the admin share.

Potential DFIR Tools to Use


The last part of the equation is what tools one should use to examine the information that is collected. The tools I’m outlining below are the ones I used to complete the practical.

        * Excel to view the text based proxy logs
        * Winprefetchview to parse and examine the prefetch files
        * MFT2CSV to parse and examine the $MFT file

Others’ Approaches to Triaging the Malware Event


Placeholder since none were known at the time of this post

Partial Malware Event Triage Workflow


The diagram below outlines the jIIr workflow for confirming malicious code events. The workflow is a modified version of the Securosis Malware Analysis Quant. I modified Securosis process to make it easier to use for security event analysis


Detection: the malicious code event is detected. Detection can be a result of technologies or a person reporting it. The workflow starts in response to a potential event being detected and reported.

Triage: the detected malicious code event is triaged to determine if it is a false positive or a real security event.

Compromised: after the event is triaged the first decision point is to decide if the machine could potentially be compromised. If the event is a false positive or one showing the machine couldn’t be infected then the workflow is exited and returns back to monitoring the network. If the event is confirmed or there is a strong indication it is real then the workflow continues to identifying the malware.

Malware Identified: the malware is identified two ways. The first way is identifying what the malware is including its purpose and characteristics. The second way is identifying and obtaining the malware from the actual system.

Root Cause Analysis: a quick root cause analysis is performed to determine how the machine was compromised and to identify indicators to use for scoping the incident. This root cause analysis does not call for a deep dive analysis taking hours and/or days but one only taking minutes.

Quarantine: the machine is finally quarantined from the network it is connected to. This workflow takes into account performing analysis remotely so disconnecting the machine from the network is done at a later point in the workflow. If the machine is initially disconnected after detection then analysis cannot be performed until someone either physically visits the machine or ships the machine to you. If an organization’s security monitoring and incident response capability is not mature enough to perform root cause analysis in minutes and analysis live over the wire then the Quarantine activity should occur once the decision is made about the machine being compromised.  

Triage Analysis Solution


I opted to triage this practical similar to a real security event. As a result, the post doesn’t use all of the supplied information and the approach is more focused on speed. The triage process started with the IDS alert screenshot the junior security analyst saw then proceeded to the proxy logs before zeroing in on the system in question.

IDS alerts


The screenshot below is the one supplied by the junior security analyst. In this practical it was not necessary to replay the packet capture to generate these IDS alerts since the screenshot supplied enough information.


Typically you can gain a lot of context about a security event by first exploring the IDS signatures themselves. Gaining context around a security event solely using the IDS signature names becomes second nature by doing event triage analysis on a daily basis. Analysts tend to see similar attacks triggering similar IDS alerts over time; making it easier to remember what attacks are and the traces they leave in networks. For other analysts this is where Google becomes their best friend. The screenshot shows three distinct events related to the malware in this security incident.

1.  ET CURRENT_EVENTS Possible Dyre SSL Cert: these signatures indicate a possible SSL certificate for the Dyre malware. Dyre is a banking Trojan and it uses SSL to encrypt its communication. The practical did not include this but another way to detect this activity is by consuming the SSL Blacklist and comparing it against an organization’s firewall logs or netflow data to see if any internal hosts are communicating with known IP addresses associated with Dyre

2. ET POLICY Internal Host Retrieving External IP via icanhazip[.]com: this signature flags an internal host that contacts a known website associated with identifying the public IP address. Depending on the organization this may or may not be normal behavior for web browsing and/or end users. However, some malware tries to identify the public facing IP address, which will trigger this IDS signature

3. ET TROJAN Common Upatre Header Structure: this signature flags traffic associated with the Upatre Trojan. Upatre is a downloader that installs other programs.

One of the IDS alerts could had been a false positive but it is unlikely for this sequence of alerts all to be false positives. This confirms what the junior analyst believed about the machine being compromised. Specifically, the machine was infected with the Upatre downloader, which then proceeded to install the Dyre banking Trojan.

Web Proxy Logs


IDS alerts provide additional information that can be used in other data sources. The practical doesn’t provide the date and time when the IDS signatures fired but it does provide the destination IP addresses and domain name the machine communicated with. These IP addresses were used to correlate the IDS alerts to activity recorded in the web proxy logs. The web_logs.csv file was imported into Excel and the data was sorted using the date. This puts the log entries chronological order making it easier to perform analysis.

The web logs provided with the practical were very basic. The only information recorded was the date/time, URL, and username. Unfortunately, the destination IP address was not recorded, which is typical with web proxies. As a result, the logs did not contain any entries for the IP addresses 72.175.10.116 and 104.238.141.75.

The search on the domain icanhazip[.]com also came up empty. At this point the web proxy logs provide no additional information with a date and time to go on. This analysis did reveal these web proxy logs suck and the organization needs to make it a priority to record more information to make analysis easier. The organization also needs to ensure the network routes all HTTP/HTTPs web traffic through the proxy so it gets recorded and prevents users and programs from bypassing it.

Prefetch files


At this point in the analysis the machine in question needs to be triaged. Reviewing programs executing on a system is a quick technique to identify malicious programs on a system. The high level indicators I tend to look are below:

        * Programs executing from temporary or cache folders
        * Programs executing from user profiles (AppData, Roaming, Local, etc)
        * Programs executing from C:\ProgramData or All Users profile
        * Programs executing from C:\RECYCLER
        * Programs stored as Alternate Data Streams (i.e. C:\Windows\System32:svchost.exe)
        * Programs with random and unusual file names
        * Windows programs located in wrong folders (i.e. C:\Windows\svchost.exe)
        * Other activity on the system around suspicious files

The collected prefetch files were parsed with Winprefetchview and I initially sorted by process path. I reviewed the parsed prefetch files using the general indicators I mentioned previously and I found the suspicious program highlighted in red.


The first suspicious program was SCAN_001_140815_881[1].SCR executing from the Temporary Internet Files directory. The program was suspicious because it is executing from the lab user profile and its name resembles a document name instead of a screensaver name. To gain more context around the suspicious program I then sorted by the Last Run time to see what else was executing around this time.


The SCAN_001_140815_881[1].SCR program executed at 8/15/2015 5:49:51 AM UTC. Shortly thereafter another executed named EJZZTA8.EXE executed from user’s Temp directory at 8/15/2015 5:51:03 AM UTC. Both prefetch files did not reference any other suspicious executables in their file handles. At this point not only do I have two suspicious files of interest but I also identified the exact date and time when the security event occurred.

Web Proxy Logs Redux


The date and time of the incident obtained from the Prefetch files can now be used to correlate the IDS alerts and suspicious programs to the activity in the web proxy logs. The picture below shows leading up to when the SCAN_001_140815_881[1].SCR program executed the user was accessing Yahoo email.


The rest of the web logs continued to show the user interacting with Yahoo email around the time the infection occurred. However, the web logs don’t record the entry showing where the SCAN_001_140815_881[1].SCR program came from. This occurred either because the web proxy didn’t record it or the web proxy sucks by not recording it. I’m going with latter since the web proxy logs are missing a lot of information.


File system metadata


At this point the IDS alerts revealed the system in question had network activity related to the Upatre downloader and Dyre banking Trojans. The prefetch files revealed suspicious programs named SCAN_001_140815_881[1].SCR that executed at 8/15/2015 5:49:51 AM UTC and EJZZTA8.EXE that executed at 8/15/2015 5:51:03 AM UTC. The web proxy logs showed the user was accessing Yahoo email around the time the programs executed. The next step in the triage process is to examine the file system metadata to identify any other malicious software on the system and to try to confirm the initial infection vector. I reviewed the metadata in a timeline to make it easier to see the activity for the time of interest.

For this practical I leveraged the MFT2CSV program in the configuration below to generate a timeline. However, an effective and faster technique – but not free – is using the home plate feature in Encase Enterprise against a remote system live. This enables you to triage the system live instead of trying to collect files from the system for offline analysis.


In the timeline I went to the time of interest, which was 8/15/2015 5:49:51 AM UTC. I then proceed forward in time to identify any other suspicious files. The first portion of the timeline didn’t show any new activity of interest around the SCAN_001_140815_881[1].SCR file.


Continuing going through the timeline going forward in time lead me to the next file EJZZTA8.EXE. The activity between these two files only showed files being created in the Temporary Internet Files and Cookies directories indicating the user was surfing the Internet.


At this point the timeline did not provide any new information and the last analysis step is to triage the suspicious programs found.

Researching Suspicious Files


The first program SCAN_001_140815_881[1].SCR was no longer on the system but the second program (EJZZTA8.EXE) was. The practical file file_hash_list.csv showed the EJZZTA8.EXE’s MD5 hash was f26fd37d263289cb7ad002fec50922c7. The first search was to determine if anyone uploaded the file to VirusTotal and a VirusTotal report was available. Numerous antivirus detections confirmed the program was Upatre, which matches one of the triggered IDS signatures.

A Google search of the hash located a Hybrid Analysis report and Malware report. The Hybrid Analysis report confirm the sample sends network traffic. This information could then be used to scope the incident to identify potentially other infected machines.


The resources section in the program contains an icon confirming the file tried to mimic a document. This makes me conclude it was a social engineering attack against the user.


The reports contained other information that one could use to identify other infected systems in the enterprise. However, as it relates to the practical there wasn’t much additional information I needed to complete my triage analysis. The next step would be to contact the end user to get the phishing email and then request for the email to be purged from all users’ inboxes.

Triage Analysis Wrap-up


The triage process did confirm the system was infected with malicious code. The evidence that was present on the system and the lack of other attack vector artifacts (i.e. exploits, vulnerable programs executing, etc.) leads me to believe the system was infected due to a phishing email. The email contained some mechanism to get the user to initiate the infection. The risk to the organization is twofold. One of the malicious programs downloads and installs other malware. The other malicious program tries to capture and exhilarate credentials from the system. The next step would be to escalate the malware event to the incident response process so the system can be quarantined, system can be cleaned, end user can be contacted to get the phishing email and then it can be determined why end users have access to web email instead of using the organization’s email system.  Continue reading Triage Practical Solution – Malware Event – Proxy Logs Prefetch $MFT IDS→

Triage Practical – Malware Event – Proxy Logs Prefetch $MFT IDS

Posted on by

The ISO was thrilled and excited about the possibilities after you successfully triaged the previous suspicious network activity. They got a glimpse of the visibility one attains through security monitoring and the information one can get leveraging incident response. As you sit at your desk drinking a Mountain Dew you don’t have time to reflect on the days when your security team was like an ostrich with its head buried in the sand. You are slowly working on improving and formalizing your organization’s security monitoring and detection capabilities as you detect and respond to security events. In the background you hear the junior security guy say “we got another one.” You already know he is referring to a malware infection so you say to him “Grab a screenshot of the alerts and send it to me in an email.” As you wait for the email to arrive you start to wonder is it wrong to get excited and look forward to an alert that means your organization may have a problem. You brushed the thought aside as the email arrives and you see the screenshot below (dates and times have been censored). You put down the Mountain Dew and put your hands to the keyword as you start putting your malware triage process to the test.


Triage Scenario


The above scenario outlines the activity leading up to the current malware security event. Below are some of the initial questions you need to answer and report back to the ISO.

        – Is this a confirmed malware security event or was the junior analyst mistaken?
        – What do you think occurred on the system to cause the malware event in the first place?
        – What type of malware is involved and what capabilities does it have?
        – What potential risk does the malware pose to your organization?
        – What recommendation(s) do you make to the security team to strengthen its security program to reduce similar incidents occurring in the future?

Information Available


In an organization’s network you have a wealth of information available to you for you to use while triaging a security incident. Despite this, to successfully triage an incident only a subset of the data is needed. In this instance, you are provided with the following artifacts below for you to use during your triage. Please keep in mind, you may not even need all of these.

        – IDS alerts for the timeframe in question (you need to replay the provide pcap to generate the IDS alerts. pcap is not provided for you to use during triage and was only made available to enable you to generate the IDS alerts in question)
        – Parsed index.dat files to simulate proxy web logs (the parsed index.dat information was modified to remove items not typically found in a web server’s proxy logs)
        – Prefetch files from the system in question (inside the Prefetch.ad1 file)
        – Filesystem metadata from the system in question (the Master File Table is provided for this practical)

Supporting References


The below items have also been provided to assist you working through the triage process.

        – The jIIr-Practical-Tips.pdf document shows how to: update the IDS signatures in Security Onion, replay the packet capture in Security Onion, and mount the ad1 file with FTK Imager.

        – The file hash list from the system in question. This is being provided since you do not access to the system nor a forensic image. This can help you confirm the security event and any suspicious files you may find.

        – The file hashes of the practical files for verification purposes



The 2016-01-06_Malware-Event Web Logs Prefetch MFT IDS practical files can be downloaded here

The 2016-01-06_Malware-Event Web Logs Prefetch MFT IDS triage write-up is outlined in the post Triage Practical Solution – Malware Event – Proxy Logs Prefetch $MFT IDS 


For background information about the jIIr practical’s please refer to Adding an Event Triage Drop to the Community Bucket article Continue reading Triage Practical – Malware Event – Proxy Logs Prefetch $MFT IDS→

Triage Practical – Malware Event – Proxy Logs Prefetch $MFT IDS

Posted on by

The ISO was thrilled and excited about the possibilities after you successfully triaged the previous suspicious network activity. They got a glimpse of the visibility one attains through security monitoring and the information one can get leveraging incident response. As you sit at your desk drinking a Mountain Dew you don’t have time to reflect on the days when your security team was like an ostrich with its head buried in the sand. You are slowly working on improving and formalizing your organization’s security monitoring and detection capabilities as you detect and respond to security events. In the background you hear the junior security guy say “we got another one.” You already know he is referring to a malware infection so you say to him “Grab a screenshot of the alerts and send it to me in an email.” As you wait for the email to arrive you start to wonder is it wrong to get excited and look forward to an alert that means your organization may have a problem. You brushed the thought aside as the email arrives and you see the screenshot below (dates and times have been censored). You put down the Mountain Dew and put your hands to the keyword as you start putting your malware triage process to the test.


Triage Scenario


The above scenario outlines the activity leading up to the current malware security event. Below are some of the initial questions you need to answer and report back to the ISO.

        – Is this a confirmed malware security event or was the junior analyst mistaken?
        – What do you think occurred on the system to cause the malware event in the first place?
        – What type of malware is involved and what capabilities does it have?
        – What potential risk does the malware pose to your organization?
        – What recommendation(s) do you make to the security team to strengthen its security program to reduce similar incidents occurring in the future?

Information Available


In an organization’s network you have a wealth of information available to you for you to use while triaging a security incident. Despite this, to successfully triage an incident only a subset of the data is needed. In this instance, you are provided with the following artifacts below for you to use during your triage. Please keep in mind, you may not even need all of these.

        – IDS alerts for the timeframe in question (you need to replay the provide pcap to generate the IDS alerts. pcap is not provided for you to use during triage and was only made available to enable you to generate the IDS alerts in question)
        – Parsed index.dat files to simulate proxy web logs (the parsed index.dat information was modified to remove items not typically found in a web server’s proxy logs)
        – Prefetch files from the system in question (inside the Prefetch.ad1 file)
        – Filesystem metadata from the system in question (the Master File Table is provided for this practical)

Supporting References


The below items have also been provided to assist you working through the triage process.

        – The jIIr-Practical-Tips.pdf document shows how to: update the IDS signatures in Security Onion, replay the packet capture in Security Onion, and mount the ad1 file with FTK Imager.

        – The file hash list from the system in question. This is being provided since you do not access to the system nor a forensic image. This can help you confirm the security event and any suspicious files you may find.

        – The file hashes of the practical files for verification purposes



The 2016-01-06_Malware-Event Web Logs Prefetch MFT IDS practical files can be downloaded here

The 2016-01-06_Malware-Event Web Logs Prefetch MFT IDS triage write-up is outlined in the post Triage Practical Solution – Malware Event – Proxy Logs Prefetch $MFT IDS 


For background information about the jIIr practical’s please refer to Adding an Event Triage Drop to the Community Bucket article Continue reading Triage Practical – Malware Event – Proxy Logs Prefetch $MFT IDS→

Triage Practical Solution – Malware Event – Prefetch $MFT IDS

Posted on by

You are staring at your computer screen thinking how you are going to tell your ISO what you found. Thinking about how this single IDS alert might have been overlooked; how it might have been lost among the sea of alerts from the various security products deployed in your company. Your ISO tasked with you triaging a malware event and now you are ready to report back.

Triage Scenario


To fill in those readers who may not know what is going on you started out the meeting providing background information about the event. The practical provided the following abbreviated scenario (for the full scenario refer to the post Triage Practical – Malware Event – Prefetch $MFT IDS):

The ISO continued “I directed junior security guy to look at the IDS alerts that came in over the weekend. He said something very suspicious occurred early Saturday morning on August 15, 2015.” Then the ISO looked directly at you “I need you to look into whatever this activity is and report back what you find.” “Also, make sure you document the process you use since we are going to use it as a playbook for these types of security incidents going forward.”

Below are some of the initial questions you need to answer and report back to the ISO.

        * Is this a confirmed malware security event or was the junior analyst mistaken?
        * What type of malware is involved?
        * What potential risk does the malware pose to your organization?
        * Based on the available information, what do you think occurred on the system to cause the malware event in the first place?


    Information Available


    Despite the wealth of information available to you within an enterprise, only a subset of data was provided for you to use while triaging this malware event. The following artifacts were made available:

            * IDS alerts for the time frame in question (you need to replay the provide pcap to generate the IDS alerts. pcap was not provided for you to use during triage and was only made available to enable you to generate the IDS alerts in question)


            * Prefetch files from the system in question (inside the Prefetch.ad1 file)

            * File system metadata from the system in question (the Master File Table is provided for this practical)

      Information Storage Location within an Enterprise


      Each enterprise’s network is different and each one offers different information for triaging. As such, it is not possible to outline all the possible locations where this information could be located in enterprises. However, it is possible to highlight common areas where this information can be found. To those reading this post whose environments do not reflect the locations I mention then you can evaluate your network environment for a similar system containing similar information or better prepare your network environment by making sure this information starts being collected in systems.

              * IDS alerts within an enterprise can be stored on the IDS/IPS sensors themselves or centrally located through a management console and/or logging system (i.e. SIEM)


              * Prefetch files within an enterprise can be located on the potentially infected system

              * File system metadata within an enterprise can be located on the potentially infected system

        Collecting the Information from the Storage Locations


        Knowing where information is available within an enterprise is only part of the equation. It is necessary to collect the information so it can be used for triaging. Similar to all the differences between enterprises’ networks, how information is collected varies from one organization to the next. Below are a few suggestions for how the information outlined above can be collected.

                * IDS alerts don’t have to be collected. They only need to be made available so they can be reviewed. Typically this is accomplished through a management console or security monitoring dashboard.


                * Prefetch files are stored on the potentially infected system. The collection of this artifact can be done by either pulling the files off remotely or locally. Remote options include an enterprise forensic tools such as F-Response, Encase Enterprise, or GRR Rapid Response, triage scripts such as Tr3Secure collection script, or by using the admin share since Prefetch files are not locked files. Local options can use the same options.

                * File system metadata is very similar to prefetch files because the same collection methods work for collecting it. The one exception is the NTFS Master File Table ($MFT) can’t be pulled off by using the admin share.

          Potential DFIR Tools to Use


          The last part of the equation is what tools one should use to examine the information that is collected. The tools I’m outlining below are the ones I used to complete the practical.

                * Security Onion to generate the IDS alerts
                  * Winprefetchview to parse and examine the prefetch files
                  * MFT2CSV to parse and examine the $MFT file


            Others’ Approaches to Triaging the Malware Event


            Before I dive into how I triaged the malware event I wanted to share the approaches used by others to tackle the same malware event. I find it helpful to see different perspectives and techniques tried to solve the same issue. I also wanted to thank those who took the time to do this so others could benefit from what you share.

            Matt Gregory shared his analysis on his blog My Random Thoughts on InfoSec. Matt did a great job outlining not only what he found but by explaining how he did it and what tools he used. I highly recommend taking the time to read through his analysis and the thought process he used to approach this malware event.

            An anonymous person (at least anonymous to me since I couldn’t locate their name) posted their analysis on a newly created blog called Forensic Insights. Their post goes into detail on analyzing the packet capture including what was transmitted to the remote device.

            Partial Malware Event Triage Workflow


            The diagram below outlines the jIIr workflow for confirming malicious code events. The workflow is a modified version of the Securosis Malware Analysis Quant. I modified Securosis process to make it easier to use for security event analysis.


            Detection: the malicious code event is detected. Detection can be a result of technologies alerting on it or a person reporting it. The workflow starts in response to a potential event being detected and reported.

            Triage: the detected malicious code event is triaged to determine if it is a false positive or a real security event.

            Compromised: after the event is triaged the first decision point is to decide if the machine could potentially be compromised. If the event is a false positive or one showing the machine couldn’t be infected then the workflow is exited and returns back to monitoring the network. If the event is confirmed or there is a strong indication it is real then the workflow continues to identify the malware.

            Malware Identified: the malware is identified two ways. The first way is identifying what the malware is including its purpose and characteristics using available information. The second way is identifying and obtaining the malware sample from the actual system to further identify the malware and its characteristics.

            Root Cause Analysis: a quick root cause analysis is performed to determine how the machine was compromised and to identify indicators to use for scoping the incident. This root cause analysis does not call for a deep dive analysis taking hours and/or days but one only taking minutes.

            Quarantine: the machine is finally quarantined from the network it is connected to. This workflow takes into account performing analysis remotely so disconnecting the machine from the network is done at a later point in the workflow. If the machine is initially disconnected after detection then analysis cannot be performed until someone either physically visits the machine or ships the machine to you. If an organization’s security monitoring and incident response capability is not mature enough to perform root cause analysis in minutes and analysis live over the wire then the Quarantine activity should occur once the decision is made about the machine being compromised.

            Triage Analysis Solution


            To triage the malware event outlined in the scenario does not require one to use all of the supplied information. The triage process could had started with either the IDS alert the junior security analyst saw or the prefetch files from system in question to see what program executed early Saturday morning on August 15, 2015. For completeness, my analysis touches on each data source and the information it contains. As a result, I started with the IDS signature to ensure I included it in my analysis.

            IDS alerts


            The screenshot below shows the IDS signatures that triggered by replaying the provided malware-event.pcap file in Security Onion. I highlighted the alert of interest.



            The IDS alert by itself provides a wealth of information. The Emerging Threats (ET) signature that fired was “ET TROJAN HawkEye Keylogger FTP” and this occurred when the machine in question (192.168.200.128) made a connection to the IP address 107.180.21.230 on the FTP destination port 21. To determine if the alert is a false positive it’s necessary to explore the signature (if available) and the packet responsible for triggering it. The screenshot below shows the signature in question:


            The signature is looking for a system on the $HOME_NET going to an external system on the FTP port 21 and the system has to initiate the connection (as reflected by flow:established,to_server). The packet needs to contain the string “STOR HAWKEye_”. The packet that triggered this signature meets all of these requirements. The system connected to an external IP address on port 21 and the picture below shows the data in the packet contained the string of interest.


            Based on the network traffic and the packet data the IDS alert is not a false positive. I performed Internet research to obtain more context about the malware event. A simple Google search on HawkEye Keylogger produces numerous hits. From You Tube videos showing how to use it to forums posting cracked versions to various articles discussing it. One article is TrendMicro’s paper titled Piercing the HawkEye: Nigerian Cybercriminals Use a Simple Keylogger to Prey on SMBs Worldwide and just the pictures in the paper provide additional context (remember during triage you won’t have time to read 34 page paper.) The keylogger is easily customizable since it has a builder and it can delivery logs through SMTP or FTP. Additional functionality includes: stealing clipboard data, taking screenshots, downloading and executing other files, and collecting system information.

            Research on the destination IP address shows the AS is GODADDY and numerous domain names map back to the address.

            Prefetch files


            When I review programs executing on a system I tend to keep the high level indicators below in mind. Over the years, these indicators have enabled me to quickly identify malicious programs that are or were on a system.

            • Programs executing from temporary or cache folders
            • Programs executing from user profiles (AppData, Roaming, Local, etc)
            • Programs executing from C:\ProgramData or All Users profile
            • Programs executing from C:\RECYCLER
            • Programs stored as Alternate Data Streams (i.e. C:\Windows\System32:svchost.exe)
            • Programs with random and unusual file names
            • Windows programs located in wrong folders (i.e. C:\Windows\svchost.exe)
            • Other activity on the system around suspicious files


            The collected prefetch files were parsed with Winprefetchview and I initially sorted by process path. I reviewed the parsed prefetch files using my general indicators and I found the suspicious program highlighted in red.


            The program in question is suspicious for two reasons. First, the program executed from the temporarily Internet files folder. The second reason and more important one was the name of the program, which was OVERDUE INVOICE DOCUMENTS FOR PAYMENT 082015[1].EXE (%20 is the encoding for a space). The name resembles a program trying to be disguised as a document. This is a social engineering technique used with phishing emails. To gain more context around the suspicious program I then sorted by the Last Run time to see what else was executing around this time.


            The OVERDUE INVOICE DOCUMENTS FOR PAYMENT 082015[1].EXE program executed on 8/15/15 at 5:33:55 AM UTC, which matches up to the time frame the junior security analyst mentioned. The file had a MD5 hash of ea0995d9e52a436e80b9ad341ff4ee62. This hash was used to confirm the file was malicious as reflected in an available VirusTotal report. Shortly thereafter another executable ran named VBC.exe but the process path was not reflected in the files referenced in the prefetch file itself. The other prefetch files did not show anything else I could easily tie to the malware event.

            File System Metadata


            At this point the IDS alert revealed the system in question had network activity related to the HawkEye Keylogger. The prefetch files revealed a suspicious program named OVERDUE INVOICE DOCUMENTS FOR PAYMENT 082015[1].EXE and it executed on 8/15/15 at 5:33:55 AM UTC. The next step in the triage process is to examine the file system metadata to identify any other malicious software on the system and to try to identify the initial infection vector. I reviewed the metadata in a timeline to make it easier to see the activity for the time of interest.

            For this practical I leveraged the MFT2CSV program in the configuration below to generate a timeline. However, an effective technique – but not free – is using the home plate feature in Encase Enterprise against a remote system. This enables you to see all files and folders while being able to sort different ways. The Encase Enterprise method is not as comprehensive as a $MFT timeline but works well for triaging.


            In the timeline I went to the time of interest, which was 8/15/15 at 5:33:55 AM UTC. I then proceeded forward in time to identify any other suspicious files. A few files were created within seconds of the OVERDUE INVOICE DOCUMENTS FOR PAYMENT 082015[1].EXE program executing. The files’ hashes will need to be used to determine more information about them since I am unable to view them.


            The timeline then shows the VBC.EXE program executing followed by activity associated with a user surfing the Internet.


            The timeline was reviewed for about a minute after the suspicious program executed and nothing else jumps out. The next step is go back to 8/15/15 at 5:33:55 AM UTC in the timeline to see what proceeded this event. There was more activity related to the user surfing the Internet as shown below.


            I kept working my way through the web browsing files to find something to confirm what the user was actually doing. I worked my way through Yahoo cookies and cache web pages containing the word “messages”. There was nothing definite so I continued going back in time. I worked my way back to around 5:30 AM UTC where cookies for Yahoo web mail were created. This activity was three minutes prior to the infection; three minutes is a long time. At this point additional information is needed to definitely answer how the system became infected in the first place. At least I know that it came from the Internet using a web browser. note: in the scenario the pcap file was meant for IDS alerts only so I couldn’t use it to answer the vector question.

            Researching Suspicious Files


            The analysis is not complete without researching the suspicious files discovered through triage. I performed additional research on the file OVERDUE INVOICE DOCUMENTS FOR PAYMENT 082015[1].EXE using its MD5 hash ea0995d9e52a436e80b9ad341ff4ee62. I went back to its VirusTotal report and noticed there didn’t appear to be a common name in the various security product detections. However, there were unique detection names I used to conduct additional research. Microsoft’s detection name was TrojanSpy:MSIL/Golroted.B and their report said the malware “tries to gather information stored on your PC”. A Google search of the hash also located a Malwr sandbox report for the file. The report didn’t shed any light on the other files I found in the timeline.

            The VBC.EXE file was no longer on the system preventing me from performing additional research on this file. The pid.txt and pidloc.txt files’ hashes were associated with a Hybrid Analysis report for a sample with the MD5 hash 242e9869ec694c6265afa533cfdf3e08. The report had a few interesting things. The sample also dropped the pid.txt and pidloc.txt files as well as executing the REGSVCS.EXE as a child process. This is the same behavior I saw in the file system metadata and prefetch files. The report provided a few other nuggets such as the sample tries to dump Web browser and Outlook stored passwords.

            Triage Analysis Wrap-up


            The triage process did confirm the system was infected with malicious code. The infection was a result of the user doing something on the Internet and additional information is needed to confirm what occurred on the system for it to become infected in the first place. The risk to the organization is the malicious code tries to capture and exfiltrate information from the system including passwords. The next step would be to escalate the malware event to the incident response process so a deeper analysis can be done to answer more questions. Questions such as what data was potentially exposed, what did the user do to contribute to the infection, was the attack random or targeted, and what type of response should be done.

            Continue reading Triage Practical Solution – Malware Event – Prefetch $MFT IDS→

            Triage Practical Solution – Malware Event – Prefetch $MFT IDS

            Posted on by

            You are staring at your computer screen thinking how you are going to tell your ISO what you found. Thinking about how this single IDS alert might have been overlooked; how it might have been lost among the sea of alerts from the various security products deployed in your company. Your ISO tasked with you triaging a malware event and now you are ready to report back.

            Triage Scenario


            To fill in those readers who may not know what is going on you started out the meeting providing background information about the event. The practical provided the following abbreviated scenario (for the full scenario refer to the post Triage Practical – Malware Event – Prefetch $MFT IDS):

            The ISO continued “I directed junior security guy to look at the IDS alerts that came in over the weekend. He said something very suspicious occurred early Saturday morning on August 15, 2015.” Then the ISO looked directly at you “I need you to look into whatever this activity is and report back what you find.” “Also, make sure you document the process you use since we are going to use it as a playbook for these types of security incidents going forward.”

            Below are some of the initial questions you need to answer and report back to the ISO.

                    * Is this a confirmed malware security event or was the junior analyst mistaken?
                    * What type of malware is involved?
                    * What potential risk does the malware pose to your organization?
                    * Based on the available information, what do you think occurred on the system to cause the malware event in the first place?


              Information Available


              Despite the wealth of information available to you within an enterprise, only a subset of data was provided for you to use while triaging this malware event. The following artifacts were made available:

                      * IDS alerts for the time frame in question (you need to replay the provide pcap to generate the IDS alerts. pcap was not provided for you to use during triage and was only made available to enable you to generate the IDS alerts in question)


                      * Prefetch files from the system in question (inside the Prefetch.ad1 file)

                      * File system metadata from the system in question (the Master File Table is provided for this practical)

                Information Storage Location within an Enterprise


                Each enterprise’s network is different and each one offers different information for triaging. As such, it is not possible to outline all the possible locations where this information could be located in enterprises. However, it is possible to highlight common areas where this information can be found. To those reading this post whose environments do not reflect the locations I mention then you can evaluate your network environment for a similar system containing similar information or better prepare your network environment by making sure this information starts being collected in systems.

                        * IDS alerts within an enterprise can be stored on the IDS/IPS sensors themselves or centrally located through a management console and/or logging system (i.e. SIEM)


                        * Prefetch files within an enterprise can be located on the potentially infected system

                        * File system metadata within an enterprise can be located on the potentially infected system

                  Collecting the Information from the Storage Locations


                  Knowing where information is available within an enterprise is only part of the equation. It is necessary to collect the information so it can be used for triaging. Similar to all the differences between enterprises’ networks, how information is collected varies from one organization to the next. Below are a few suggestions for how the information outlined above can be collected.

                          * IDS alerts don’t have to be collected. They only need to be made available so they can be reviewed. Typically this is accomplished through a management console or security monitoring dashboard.


                          * Prefetch files are stored on the potentially infected system. The collection of this artifact can be done by either pulling the files off remotely or locally. Remote options include an enterprise forensic tools such as F-Response, Encase Enterprise, or GRR Rapid Response, triage scripts such as Tr3Secure collection script, or by using the admin share since Prefetch files are not locked files. Local options can use the same options.

                          * File system metadata is very similar to prefetch files because the same collection methods work for collecting it. The one exception is the NTFS Master File Table ($MFT) can’t be pulled off by using the admin share.

                    Potential DFIR Tools to Use


                    The last part of the equation is what tools one should use to examine the information that is collected. The tools I’m outlining below are the ones I used to complete the practical.

                          * Security Onion to generate the IDS alerts
                            * Winprefetchview to parse and examine the prefetch files
                            * MFT2CSV to parse and examine the $MFT file


                      Others’ Approaches to Triaging the Malware Event


                      Before I dive into how I triaged the malware event I wanted to share the approaches used by others to tackle the same malware event. I find it helpful to see different perspectives and techniques tried to solve the same issue. I also wanted to thank those who took the time to do this so others could benefit from what you share.

                      Matt Gregory shared his analysis on his blog My Random Thoughts on InfoSec. Matt did a great job outlining not only what he found but by explaining how he did it and what tools he used. I highly recommend taking the time to read through his analysis and the thought process he used to approach this malware event.

                      An anonymous person (at least anonymous to me since I couldn’t locate their name) posted their analysis on a newly created blog called Forensic Insights. Their post goes into detail on analyzing the packet capture including what was transmitted to the remote device.

                      Partial Malware Event Triage Workflow


                      The diagram below outlines the jIIr workflow for confirming malicious code events. The workflow is a modified version of the Securosis Malware Analysis Quant. I modified Securosis process to make it easier to use for security event analysis.


                      Detection: the malicious code event is detected. Detection can be a result of technologies alerting on it or a person reporting it. The workflow starts in response to a potential event being detected and reported.

                      Triage: the detected malicious code event is triaged to determine if it is a false positive or a real security event.

                      Compromised: after the event is triaged the first decision point is to decide if the machine could potentially be compromised. If the event is a false positive or one showing the machine couldn’t be infected then the workflow is exited and returns back to monitoring the network. If the event is confirmed or there is a strong indication it is real then the workflow continues to identify the malware.

                      Malware Identified: the malware is identified two ways. The first way is identifying what the malware is including its purpose and characteristics using available information. The second way is identifying and obtaining the malware sample from the actual system to further identify the malware and its characteristics.

                      Root Cause Analysis: a quick root cause analysis is performed to determine how the machine was compromised and to identify indicators to use for scoping the incident. This root cause analysis does not call for a deep dive analysis taking hours and/or days but one only taking minutes.

                      Quarantine: the machine is finally quarantined from the network it is connected to. This workflow takes into account performing analysis remotely so disconnecting the machine from the network is done at a later point in the workflow. If the machine is initially disconnected after detection then analysis cannot be performed until someone either physically visits the machine or ships the machine to you. If an organization’s security monitoring and incident response capability is not mature enough to perform root cause analysis in minutes and analysis live over the wire then the Quarantine activity should occur once the decision is made about the machine being compromised.

                      Triage Analysis Solution


                      To triage the malware event outlined in the scenario does not require one to use all of the supplied information. The triage process could had started with either the IDS alert the junior security analyst saw or the prefetch files from system in question to see what program executed early Saturday morning on August 15, 2015. For completeness, my analysis touches on each data source and the information it contains. As a result, I started with the IDS signature to ensure I included it in my analysis.

                      IDS alerts


                      The screenshot below shows the IDS signatures that triggered by replaying the provided malware-event.pcap file in Security Onion. I highlighted the alert of interest.



                      The IDS alert by itself provides a wealth of information. The Emerging Threats (ET) signature that fired was “ET TROJAN HawkEye Keylogger FTP” and this occurred when the machine in question (192.168.200.128) made a connection to the IP address 107.180.21.230 on the FTP destination port 21. To determine if the alert is a false positive it’s necessary to explore the signature (if available) and the packet responsible for triggering it. The screenshot below shows the signature in question:


                      The signature is looking for a system on the $HOME_NET going to an external system on the FTP port 21 and the system has to initiate the connection (as reflected by flow:established,to_server). The packet needs to contain the string “STOR HAWKEye_”. The packet that triggered this signature meets all of these requirements. The system connected to an external IP address on port 21 and the picture below shows the data in the packet contained the string of interest.


                      Based on the network traffic and the packet data the IDS alert is not a false positive. I performed Internet research to obtain more context about the malware event. A simple Google search on HawkEye Keylogger produces numerous hits. From You Tube videos showing how to use it to forums posting cracked versions to various articles discussing it. One article is TrendMicro’s paper titled Piercing the HawkEye: Nigerian Cybercriminals Use a Simple Keylogger to Prey on SMBs Worldwide and just the pictures in the paper provide additional context (remember during triage you won’t have time to read 34 page paper.) The keylogger is easily customizable since it has a builder and it can delivery logs through SMTP or FTP. Additional functionality includes: stealing clipboard data, taking screenshots, downloading and executing other files, and collecting system information.

                      Research on the destination IP address shows the AS is GODADDY and numerous domain names map back to the address.

                      Prefetch files


                      When I review programs executing on a system I tend to keep the high level indicators below in mind. Over the years, these indicators have enabled me to quickly identify malicious programs that are or were on a system.

                      • Programs executing from temporary or cache folders
                      • Programs executing from user profiles (AppData, Roaming, Local, etc)
                      • Programs executing from C:\ProgramData or All Users profile
                      • Programs executing from C:\RECYCLER
                      • Programs stored as Alternate Data Streams (i.e. C:\Windows\System32:svchost.exe)
                      • Programs with random and unusual file names
                      • Windows programs located in wrong folders (i.e. C:\Windows\svchost.exe)
                      • Other activity on the system around suspicious files


                      The collected prefetch files were parsed with Winprefetchview and I initially sorted by process path. I reviewed the parsed prefetch files using my general indicators and I found the suspicious program highlighted in red.


                      The program in question is suspicious for two reasons. First, the program executed from the temporarily Internet files folder. The second reason and more important one was the name of the program, which was OVERDUE INVOICE DOCUMENTS FOR PAYMENT 082015[1].EXE (%20 is the encoding for a space). The name resembles a program trying to be disguised as a document. This is a social engineering technique used with phishing emails. To gain more context around the suspicious program I then sorted by the Last Run time to see what else was executing around this time.


                      The OVERDUE INVOICE DOCUMENTS FOR PAYMENT 082015[1].EXE program executed on 8/15/15 at 5:33:55 AM UTC, which matches up to the time frame the junior security analyst mentioned. The file had a MD5 hash of ea0995d9e52a436e80b9ad341ff4ee62. This hash was used to confirm the file was malicious as reflected in an available VirusTotal report. Shortly thereafter another executable ran named VBC.exe but the process path was not reflected in the files referenced in the prefetch file itself. The other prefetch files did not show anything else I could easily tie to the malware event.

                      File System Metadata


                      At this point the IDS alert revealed the system in question had network activity related to the HawkEye Keylogger. The prefetch files revealed a suspicious program named OVERDUE INVOICE DOCUMENTS FOR PAYMENT 082015[1].EXE and it executed on 8/15/15 at 5:33:55 AM UTC. The next step in the triage process is to examine the file system metadata to identify any other malicious software on the system and to try to identify the initial infection vector. I reviewed the metadata in a timeline to make it easier to see the activity for the time of interest.

                      For this practical I leveraged the MFT2CSV program in the configuration below to generate a timeline. However, an effective technique – but not free – is using the home plate feature in Encase Enterprise against a remote system. This enables you to see all files and folders while being able to sort different ways. The Encase Enterprise method is not as comprehensive as a $MFT timeline but works well for triaging.


                      In the timeline I went to the time of interest, which was 8/15/15 at 5:33:55 AM UTC. I then proceeded forward in time to identify any other suspicious files. A few files were created within seconds of the OVERDUE INVOICE DOCUMENTS FOR PAYMENT 082015[1].EXE program executing. The files’ hashes will need to be used to determine more information about them since I am unable to view them.


                      The timeline then shows the VBC.EXE program executing followed by activity associated with a user surfing the Internet.


                      The timeline was reviewed for about a minute after the suspicious program executed and nothing else jumps out. The next step is go back to 8/15/15 at 5:33:55 AM UTC in the timeline to see what proceeded this event. There was more activity related to the user surfing the Internet as shown below.


                      I kept working my way through the web browsing files to find something to confirm what the user was actually doing. I worked my way through Yahoo cookies and cache web pages containing the word “messages”. There was nothing definite so I continued going back in time. I worked my way back to around 5:30 AM UTC where cookies for Yahoo web mail were created. This activity was three minutes prior to the infection; three minutes is a long time. At this point additional information is needed to definitely answer how the system became infected in the first place. At least I know that it came from the Internet using a web browser. note: in the scenario the pcap file was meant for IDS alerts only so I couldn’t use it to answer the vector question.

                      Researching Suspicious Files


                      The analysis is not complete without researching the suspicious files discovered through triage. I performed additional research on the file OVERDUE INVOICE DOCUMENTS FOR PAYMENT 082015[1].EXE using its MD5 hash ea0995d9e52a436e80b9ad341ff4ee62. I went back to its VirusTotal report and noticed there didn’t appear to be a common name in the various security product detections. However, there were unique detection names I used to conduct additional research. Microsoft’s detection name was TrojanSpy:MSIL/Golroted.B and their report said the malware “tries to gather information stored on your PC”. A Google search of the hash also located a Malwr sandbox report for the file. The report didn’t shed any light on the other files I found in the timeline.

                      The VBC.EXE file was no longer on the system preventing me from performing additional research on this file. The pid.txt and pidloc.txt files’ hashes were associated with a Hybrid Analysis report for a sample with the MD5 hash 242e9869ec694c6265afa533cfdf3e08. The report had a few interesting things. The sample also dropped the pid.txt and pidloc.txt files as well as executing the REGSVCS.EXE as a child process. This is the same behavior I saw in the file system metadata and prefetch files. The report provided a few other nuggets such as the sample tries to dump Web browser and Outlook stored passwords.

                      Triage Analysis Wrap-up


                      The triage process did confirm the system was infected with malicious code. The infection was a result of the user doing something on the Internet and additional information is needed to confirm what occurred on the system for it to become infected in the first place. The risk to the organization is the malicious code tries to capture and exfiltrate information from the system including passwords. The next step would be to escalate the malware event to the incident response process so a deeper analysis can be done to answer more questions. Questions such as what data was potentially exposed, what did the user do to contribute to the infection, was the attack random or targeted, and what type of response should be done.

                      Continue reading Triage Practical Solution – Malware Event – Prefetch $MFT IDS→

                      Triage Practical – Malware Event – Prefetch $MFT IDS

                      Posted on by

                      Another Monday morning as you stroll into work. Every Monday morning you have a set routine and this morning was no different. You were hoping to sit down into your chair, drink some coffee, and work your way through the emails that came in over the weekend. This morning things were different. As soon as you entered the office, your ISO had a mandatory meeting going on and they were waiting for you to arrive. As you entered the meeting the ISO announces “each week it seems like another company is breached. The latest headline about Company XYZ should be our wake up call. The breach could had been prevented but it wasn’t since their security people were not monitoring their security products and they never saw the alerts telling them they had a problem.” At this point you started to see where this was going; no one at your company pays any attention to all those alerts from the various security products deployed in your environment. Right on cue the ISO continued “what happened at Company XYZ can easily happen here. We don’t have people looking at the alerts being generated by our security products and even if we had the bodies to do this we have no processes in place outlining how this can be accomplished.” As you sipped your coffee you came close to spitting it out after you heard what came next. The ISO continued “I directed junior security guy to look at the IDS alerts that came in over the weekend. He said something very suspicious occurred early Saturday morning on August 15, 2015.” Then the ISO looked directly at you “I need you to look into whatever this activity is and report back what you find.” “Also, make sure you document the process you use since we are going to use it as a playbook for these types of security incidents going forward.”

                      Triage Scenario


                      The above scenario outlines the activity leading up to the current malware security event. Below are some of the initial questions you need to answer and report back to the ISO.

                              * Is this a confirmed malware security event or was the junior analyst mistaken?
                              * What type of malware is involved?
                              * What potential risk does the malware pose to your organization?
                              * Based on the available information, what do you think occurred on the system to cause the malware event in the first place?

                      Information Available


                      In an organization’s network you have a wealth of information available to you for you to use while triaging a security incident. Despite this, to successfully triage an incident only a subset of the data is needed. In this instance, you are provided with the following artifacts below for you to use during your triage. Please keep in mind, you may not even need all of these.

                              * IDS alerts for the timeframe in question (you need to replay the provide pcap to generate the IDS alerts. pcap is not provided for you to use during triage and was only made available to enable you to generate the IDS alerts in question)
                              * Prefetch files from the system in question (inside the Prefetch.ad1 file)
                              * File system metadata from the system in question (the Master File Table is provided for this practical)

                      Supporting References


                      The below items have also been provided to assist you working through the triage process.

                              * The jIIr-Practical-Tips.pdf document shows how to replay the packet capture in Security Onion and how to mount the ad1 file with FTK Imager.
                              * The file hash list from the system in question. This is being provided since you do not access to the system nor a forensic image. This can help you confirm the security event and any suspicious files you may find.


                      The 2015-11-22_Malware-Event Prefetch MFT IDS practical files can be downloaded from here

                      The 2015-11-22_Malware-Event Prefetch MFT IDS triage write-up is outlined in the post Triage Practical Solution – Malware Event – Prefetch $MFT IDS


                      For background information about the jIIr practicals please refer to the Adding an Event Triage Drop to the Community Bucket article

                      Continue reading Triage Practical – Malware Event – Prefetch $MFT IDS→