Python: print “Hello DFIR World!”

Wednesday, April 8, 2015 Posted by Corey Harrell 5 comments
Coursera's mission is to "provide universal access to the world's best education." Judging by their extensive course listing it appears as if they are delivering on their mission since the courses are free for anyone to take. I knew about Coursera for some time but only recently did I take one of their courses (Python Programming for Everybody.) In this post I'm sharing some thoughts about my Coursera experience, the course I took, and how I immediately used what I learned.

Why Python? Why Coursera?


Python is a language used often in information security and DFIR. Its usage is varied from simple scripts to extensive programs. My interest in Python was modest; I wanted to be able to modify (if needed) Python tools I use and to write automation scripts to make my job easier. Despite the wealth of resources available to learn Python, I wanted a more structured environment to learn the basics. An environment that leverages lectures, weekly readings, and weekly assignments to explore the topic. My plan was to learn the basics then proceed exploring how Python applies to information security using the books Black Hat Python and Violent Python. Browsing through the Cousera offerings I found the course Programming for Everybody (Python). The course “aims to teach everyone to learn the basics of programming computers using Python. The course has no pre-requisites and avoids all but the simplest mathematics.” Teaches the basics in a span of 10 weeks without the traditional learning to code by mathematics; the course was exactly what I was looking for.

Programming for Everybody (Python)


I’m not providing a full fledge course review but I did want to provide some thoughts on this course. The course itself is “designed to be a first programming course using the popular Python programming language.” This is important and worth repeating. The course is designed to be someone’s first programming course. If you already know how to code in a different language then this course isn’t for you. I didn’t necessary fit the target audience since I know how to script in both batch and Perl. However, I knew this was a beginner’s course going in so I expected things would move slowly. I could easily overlook this one aspect since my interest was to build a foundation in Python. The course leveraged some pretty cool technology for an online format. The recorded lectures used a split screen between the professor, his slides, and his ability to write on the slides as he taught. The assignments had an auto grader where students complete assignments by executing their programs and the grader confirms if the program was written correctly. The text book is Python for Informatics: Exploring Information, which focuses more on trying to solve data analysis problems instead of math problems like traditional programming texts. The basics covered include: variables, conditional code, functions, loops/iteration, strings, files, lists, dictionaries, tuples, and regular expressions.

Overall, spending the past 10 weeks completing this course was time well spent. Sure, at times I wish times moved faster but I did achieve what I wanted to. Exploring the basics of the Python language so I can have a foundation prior to exploring how the language applies to security work. The last thing I wanted to mention about the course, which I highly respect. The entire course from the textbook to the lecture videos is licensed under a Creative Common Attribution making it available for pretty much anyone to use.

Applying What I Learned


The way I tend to judge courses, trainings, and books is by how much of the content can be applied to my work. If the curriculum is not relevant to one’s work than what is the point in wasting time completing it? It’s just my opinion but judging courses and trainings in this manner has proven to be effective. To illustrate this point as it applies to the Python Programming for Everybody course I’m showing how the basics I learned solved a recent issue. One issue I was facing is how to automate parsing online content and consuming it in a SIEM. This is a typical issue for those wishing to use open source threat intelligence feeds. One approach is to manually parse it in to a machine readable form that your SIEM and tools can use. Another and a better approach is to automate as much as possible through scripting. I took the later approach by creating a simple script to automate this process. For those interested in Python usage in DFIR should check out David Cowen's Automating DFIR series or Tom Yarrish's Year of Python series.

There are various open source threat intelligence feeds one can incorporate in to their enterprise detection program. Kyle Maxwell’s presentation Open Source Threat Intelligence touched on some of them. For this post, I’m only discussing one and it was something I was interested in knowing how to do it. Tor is an anonymity service that enables people to hide where they are coming from as they surf the Internet. Tor has a lot of legitimate uses and just because someone is using it does not mean they are doing something wrong. Being able to flagged users connecting to your network from Tor can add context to other activity. Is the SQL injection IDS alert a false positive? Is the SQL injection IDS alert coming from someone who is also using Tor a false positive? See what I mean by adding context. This was an issue that needed a Python solution (or at least a solution where I could apply what I learned.)

To accomplish adding Tor context to activity in my SIEM I first had to identify the IP addresses for the Tor exit nodes. Users using the service will have the IP address of the exit node they are going through. The Tor Project FAQs provides an answer to the question "I want to ban the Tor network from my service." After trying to discourage people from blocking two options are presented by using either the Tor exit relay list or a DNS-based list. The Tor exit relay list webpage has a link to the current list of exit addresses. The screenshot below shows how this information is presented:


Now we’ll explore the script I wrote to parse the Tor exit node IP addresses into a form my SIEM can consume, which is a text file with one IP address per line. The first part –as shown in the image below - imports the urllib2 module that is used to open URLs. This part wasn’t covered in the course but wasn’t too difficult to figure out by Googling. The last line in the image creates a dictionary called urls. A dictionary associates a key with a value and in this case the key is tor-exit with the value being the URL to the Tor exit relay list. Leveraging a dictionary allows the script to be extended to support other feeds without having to make significant changes to the script.


The next portion of the script as shown below is where the first for loop occurs. The for loop will process each entry (key and value pair) in the urls dictionary. The try and except is a method to account for errors such as a URL not working. Inside the try section the URL is opened in to a variable named file and then it is read in to a variable named data using the urllib2 readlines() option. Lastly, a file is created to store the output using the key value and the file handle is named output.


The next part of the script –image below - is specific to each threat feed being parsed. This accounts for the differences in the way threat feeds present data. The if statement checks to see if the key matches “tor-exit” and if it does then the second for loop executes. This for loop reads each line in the data variable (hence the data listed at the URL.) As each line is read there is additional actions performed such as skipping blank lines and any line that doesn’t start with the string “ExitAddress.” For the lines that do start with this string, the line is broken up in to a list named words. Basically, it breaks the line up into different values by using the space as a separator. The IP address is the second value so it is contained in the second index location in the words list (words[1]). The IP address is then written to the output file and after each line is processed a message is displayed saying processing completed.


The screenshot below shows the script running.


The end result is a text file containing the Tor exit IP addresses with one address per line. This text file can then be automatically consumed by my SIEM or I can use it when analyzing web logs to flag any activity involving Tor.


It’s Basic but Works


Harlan recently said in his Blogging post “it doesn't matter how new you are to the industry, or if you've been in the industry for 15 years...there's always something new that can be shared, whether it's data, or even just a perspective.” My hope with this post is it would be useful to others who are not programmers but want to learn Python. Coursera is a good option that can teach you the basics. Even just learning the basics can extend your DFIR capabilities as demonstrated by my simple script.
Labels:

Compromised Root Cause Analysis Model Revisited

Wednesday, March 11, 2015 Posted by Corey Harrell 3 comments
How? The one question that is easy to ask but can be very difficult to answer. It's the question I kept asking myself over and over. Reading article after article where publicized breaches and compromises were discussed. Each article alluded to the answer about how the breach or compromise occurred in the first place but each one left something out. Every single one left out the details that influenced their conclusions. As a result, I was left wondering how they figure out how the attack occurred in the first place. It was the question everyone alluded to and everyone said to perform root cause to determine the answer. They didn’t elaborate on how to actually do root cause analysis though. Most incident response literature echoes the same sentiment; do root cause analysis while omitting the most critical piece explaining how to do it.  I asked my question to a supposed "incident responder" and their response was along the lines "you will know it when you see it." Their answer along with every other answer on the topic was not good enough. What was needed was a repeatable methodical process one can use to perform root cause analysis. The type of methodical process found in the Compromise Root Cause Analysis Model.

I developed the Compromise Root Cause Analysis Model three years ago to fulfill the need for a repeatable investigative process for doing root cause analysis. In this post I'm revisiting the model and demonstrating its usefulness by outlining the following:

        - Exploring Locard’s Exchange Principle
        - Exploring Temporal Context
        - Exploring Attack Vectors
        - Exploring the Compromise Root Cause Analysis Model
        - The Model is Cyclical
        - Applying the Compromise Root Cause Analysis Model
                * Webserver Compromise

Exploring Locard’s Exchange Principle


The essential principle in the Compromise Root Cause Analysis Model is Locard’s Exchange Principle. This principle states “when two objects come into contact, something is exchanged from one to the other.” Locard’s Exchange Principle is typically explained using examples from the physical world. When one object – such as someone’s hand – comes in to contact with another object – such as a glass – something is exchanged from one to the other. In this example, on the glass are traces of oils from the person’s hand, skin flakes, and even fingerprints.

The principle is not only limited to the physical world; it applies to the digital world as well. Harlan Carvey’s example demonstrated the principle in the digital world as follows: “well, in essence, whenever two computers come "into contact" and interact, they exchange something from each other.” The principle is not only limited to computers; it applies to everything such as routers, switches, firewalls, or mobile devices. The essence of this principle for the Compromise Root Cause Analysis Model is:

When an attacker goes after another system; the exchange will leave remnants of the attack on the systems involved. There is a transfer between the attacker’s system(s), the targeted system(s), and the networking devices connecting them together.

The transfer between the systems and networks involved in the attack will indicate the actual attack used. By identifying and exploring the remnants left by the transfer is what enables the question of “how did the attack occur in the first place” to be answered.

Exploring Temporal Context


The second principle and one that supports the Compromise Root Cause Analysis Model is the psychology principle of proximity. The principle of proximity is one of the Gestalt laws of grouping and states that “when we see stimuli or objects that are in close proximity to each other, we tend to perceive them as being grouped together.” As it relates to the Compromise Root Cause Analysis Model, the grouping is based on the temporal relationship between each object. Temporal proximity impacts the model in two ways.

The first way temporal proximity impacts the Compromise Root Cause Analysis Model is by enabling the grouping of remnants related to an attack. When an attacker goes after another system, remnants are left is various places within system and the network the system is a part of. Networking devices logs showing the network activity, application logs showing what the intruder was doing, and remnants on the system showing what the intruder accomplished are only a few of the places where these artifacts could be located. The attacker’s actions are not the only remnants left within the network and system. The organization and its employees are creating remnants every day from their activity as well as remnants left by the normal operation of the information technology devices themselves. Temporal proximity enables the grouping of the remnants left by an attacker throughout a network and system by their temporal relationship to each other. Remnants that occur within a short timeframe of each other can be grouped together while remnants outside of this timeframe are excluded. Other factors are involved to identify the attacker’s remnants amongst normal activity but temporal proximity is one of the most significant factors.

The second way temporal proximity impacts the Compromise Root Cause Analysis Model is the time that lapses between when an attacker attacks the system and an investigation is conducted affects the ability to identify and group the remnants left by the attacker. The reason for this impact is that “time is what permits other forces to have an effect on the persistence of data.” The remnants left by the attacker is in the form of data on information technology devices. The more time that goes by after these remnants are left the more opportunity there is for them to be changed and/or removed. Logs can be overwritten, files modified, or files deleted through activities of the organization and its employees along with the normal operation of the information technology devices. The more time that lapses between when the attack occurred and when the investigation begins the greater the opportunity for remnants to disappear and the inability to group the remaining remnants together. The Compromise Root Cause Analysis Model can still be used to identify these remnants and group them but it is much more difficult as more time lapses between the initial attack and investigation.

Exploring Attack Vectors


Root cause analysis is trying to determine how an attacker went after another system or network by identifying and understanding the remnants they left on the systems involved during the attack. In essence, the analysis is identifying the attack vector used to compromise the system. It is crucial to explore what an attack vector is to see how it applies to the Compromise Root Cause Analysis Model.

SearchSecurity defines an attack vector as "a path or means by which a hacker (or cracker) can gain access to a computer or network server in order to deliver a payload or malicious outcome." Based on this definition, the attack vector can be broken down into three separate components. The path or means is the exploit used, the payload is the outcome of the exploit, and the delivery mechanism is what delivers the exploit and/or the payload to the target. The definition combines the delivery mechanism and exploit together but in reality these are separated. The exploit, payload, and delivery mechanism can all leave remnants (or artifacts) on the compromised system and network and these artifacts are used to identify the attack vector used.

Exploit


An exploit is defined as "a piece of software, a chunk of data, or a sequence of commands that takes advantage of a bug, glitch or vulnerability in order to cause unintended or unanticipated behavior to occur on computer software, hardware, or something electronic (usually computerized).." An exploit takes advantage of a weakness in a system to cause a desirable activity on that system for the attacker. Exploits can target vulnerabilities in either operating systems, applications, or the people using the system. In accordance with Locard’s Exchange Principle, when the exploit comes in contact with the system containing the weakness remnants are left by the attacker. Identifying these exploit artifacts left on a system are one piece of the puzzle for identifying the attack vector.

Payload


A payload is defined (in security) as “the cargo of a data transmission.” A payload is the desirable activity on a system for the attacker that was caused by an exploit taking advantage of a weakness. In accordance with Locard’s Exchange Principle, when the payload comes in contact with the system remnants are left by the attacker. Identifying these payload artifacts left on a system are another piece of the puzzle for identifying the attack vector.

Delivery Mechanism


A delivery mechanism is defined as “a method by which malicious software places a payload into a target computer or computer network.” The delivery mechanism is what delivers the exploit and/or payload to the system to enable the desirable activity to occur on the system for the attacker. Similar to the exploit and payload, when the delivery mechanisms come in contact with the system remnants are left by the attacker. Identifying these delivery mechanisms artifacts left on a system are the last piece of the puzzle for identifying the attack vector.

Exploring the Compromise Root Cause Analysis Model


When an attacker goes after another system; the exchange leaves artifacts of the attack on the systems involved. These artifacts are identified during an investigation and grouped together based on their temporal proximity to one another. Root cause analysis identifies the attack vector used by determining what of the identified artifacts are related to the exploit, payload, and delivery mechanism(s). The Compromise Root Cause Analysis Model is a methodical process for organizing information and identified artifacts during an investigation to make it easier to answer the question of how did a compromise occur. The model is a not a replacement for any existing models; rather it’s a complimentary model to help discover information related to a system compromise. The Compromise Root Cause Analysis Model organizes the artifacts left on a network and/or system after being attacked into the following categories: source, delivery mechanism, exploit, payload, and indicators. The relationship between the categories are shown below.



Source


At the core of the model is the source of the attack. The source is where the attack originated from. Attacks can originate from outside or within an organization’s network; it all depends on who the attacker is. An external source is anything residing outside the control of an organization or person. An example is attacks against a web application coming from the Internet. Attacks can also be internal, which is within the network and under the control of an organization or person. An example is an employee who is stealing data from a company file server.

The artifacts left behind by the attacker on the system is used to determine where the attack came from. For example, if the attack originated from the Internet then the data left on the systems indicate this. Firewall logs, web application logs, proxy server logs, authentication logs, and email logs all will point to the attacker’s location outside of the organization’s network.

Delivery Mechanism


Proceeding to the next layer is the first delivery mechanism. This is the mechanism used to send the exploit to the system. The mechanism used is dependent on the attacker’s location. Attackers external to the organization may use avenues such as email, network services (i.e. HTTP, SSH, FTP, etc..), or removable media. Attackers internal to the organization may use avenues such as physical access or file sharing protocols.

The artifacts left behind by the attacker on the system is used to determine how they sent the exploit to the system. Where and what the artifacts are is solely dependent on the method used. If the method was HTTP then either web proxy, web browser histories, or web application logs will contain the remnants from the attacker. If the method was email then the email gateway logs, client email storage file, or user activity involving email will contain the remnants from the attacker.

Exploit


Continuing outward to the next layer is the exploit. The exploit is what was sent to take advantage of a vulnerability. As mentioned previously, vulnerabilities can be present in a range of items: from operating systems to applications to databases to network services to the person using the computer.
When vulnerabilities are exploited it leaves specific artifacts on the system and these artifacts can identify the weakness targeted by the attacker. Where and what the artifacts are is solely dependent on what weakness is targeted. The Applying the Model section illustrates this artifact for one vulnerability.

Delivery Mechanism


The next layer is the second delivery mechanism. A successful exploit may result in a payload being sent to the system. This is what the outer delivery mechanism is for. If the payload has to be sent to then there may be artifacts showing this activity. This is the one layer that may not always be present. There are times when the payload is bundled with the exploit or the payload just provides access to the system. Similar to the exploit, where and what the artifacts are present solely dependent on what the exploit was.

Payload


The next layer outlines the desired end result in any attack; to deliver a payload or malicious outcome to the system. The payload can include a number of actions ranging from unauthorized access to denial of service to remote code execution to escalation of privileges. The payload artifacts left behind will be dependent on what action was taken.

Indicators


The last layer in the model is the indicators layer. The layer is not only where the information and artifacts about how the attack was detected would go but it also encompasses all of the artifacts showing the post compromise activity. The reason for organizing all the other remnants left by the attacker into this layer is to make it easier to identify the attack vector artifacts (exploit, payload, and delivery mechanisms.) This results in the layer being broad since it contains all of the post compromise artifacts such as downloading files, malware executing, network traversal, or data exfiltration.

The Model is Cyclical


The Compromise Root Cause Analysis Model is a way to organize information and artifacts to make it easier to answer questions about an attack. More specifically to answer: how and when did the compromise occur? Information or artifacts about the compromise are discovered by completing examination steps against any relevant systems involved with the attack. The model is cyclical; as each new system is discovered the model is used to determine how the system was compromised. This ongoing process continues until each system involved with an attack is examined to confirm if it truly was a part of the attack.

To illustrate, take the hypothetical scenario of an IDS alert indicating an organization’s employee laptop is infected with malware. The IDS signature that flagged the network traffic is shown below (signature was obtained from the Emerging Threats emerging-botcc.rules.) As can be seen in the rule, the laptop was flagged for visiting an IP address associated with the Zeus Trojan.

 
The network packet captured in the IDS alert indicates the employee is a remote user connected through the organization’s VPN. The network diagram below shows the organization’s network layout and where this employee’s laptop is located.


The investigation into the employee’s laptop - remotely over the network – located the Zeus Trojan on the laptop. The examination continued by doing root cause analysis to determine how the laptop became infected in the first place. The employee was surfing the Internet prior to connecting to the organization’s network through the VPN. A drive-by attack successfully compromised the laptop when the employee visited the organization’s website. The IDS alerted on the infection once the laptop connected through the VPN. The investigation now uncovered another system involved with the attack (organization’s web server) and its location is shown below.


The organization’s main website is compromised and serving malware to its visitors. The investigation continues by moving to the compromised web server. The Root Cause Analysis Model is applied to the server to determine how it became compromised in the first place. The answer was an attacker found the webserver was running an outdated Joomla plug-in and exploited it. The attacker eventually leveraged the compromised web server to deliver malware to its visitors.

In this hypothetical scenario, the Compromise Root Cause Analysis Model was initially applied to a compromised laptop. The source of the attack pointed to another system under the control of the organization. The investigation continued to the newly discovered system by applying the Compromise Root Cause Analysis Model against it. The attack vector pointed to an attacker from the Internet so at this point all of the systems involved in the attack have been investigated and the root cause identified. If there were more systems involved then the cyclical process continues until all systems are investigated. The Compromise Root Cause Analysis Model enabled the attack vector for each system to be determined and the incident information discovered can then be further organized using other models. For example, the overall attack can be described using the Lockheed Martin's Cyber Kill Chain model.

Applying the Compromise Root Cause Analysis Model


The Compromise Root Cause Analysis Model is a way to organize information and artifacts to make it easier to answer questions about a compromise. The model can be applied to systems to either confirm how they were compromised or to determine if they were compromised. The article Malware Root Cause Analysis goes in to detail about how to apply the model for a malicious code incident involving a single system. However, the model is not limited to only malicious code incidents. It can be applied to any type of security incident including: unauthorized access, denial of service, malicious network traffic, phishing, and compromised user accounts. To demonstrate the model’s versatility, it will be applied to a hypothetical security incident using data from a published article. The incident is for a compromised Coldfusion webserver as described in the An Eye on Forensics's article A Cold Day in E-Commerce - Guest Post. The data referenced below either was influenced/borrowed from either the previously mentioned article, the Coldfusion for Pentesters presentation, or made up to appear realistic.

Webserver Compromise


An IDS alert flags some suspicious network traffic for an external system trying to connect to an organization’s Coldfusion web server located in their DMZ. The organization monitors for access attempts to the Coldfusion administrator web panel including access to features such as scheduling tasks. The external system triggered the IDS signature shown below because it accessed the Coldfusion’s scheduleedit located at hxxp://www.fake_site.com/CFIDE/administrator/scheduler/scheduleedit.cfm on an established session.


The reason the IDS alert is concerning is because what accessing scheduleedit means. One method an attacker can use to upload code on to a compromised Coldfusion server is by leveraging the scheduled tasks. The attacker can schedule a task, point it to their program’s location on a different server, and then have the task save it locally to the Coldfusion server for them to use (see page 85 in this presentation.) Accessing the interface to edit scheduled tasks is reflected by “scheduleedit” appearing in the URL. The IDS alert is triaged to determine if the Coldfusion server was successfully compromised and if an attacker was uploading anything to the server using the scheduled tasks feature.

The Coldfusion instance is running on a Windows 2008 server with IIS and its IP address is 192.168.0.1. The IIS log was reviewed for the time in question to see the activity around the time the IDS alert triggered.

2015-03-10 22:09:00 192.168.0.1 GET /CFIDE/Administrator/scheduler/scheduletasks.cfm - 80 – X.X.X.X fake-useragent  200 0 0 5353

2015-03-10 22:09:10 192.168.0.1 GET /CFIDE/Administrator/scheduler/scheduleedit.cfm submit=Schedule+New+Task 80 - X.X.X.X fake-useragent 200 0 0 5432

2015-03-10 22:09:15 192.168.0.1 GET /CFIDE/Administrator/scheduler/scheduletasks.cfm runtask=z&timeout=0 80 – X.X.X.X fake-useragent 200 0 0 1000

2015-03-10 22:11:15 192.168.0.1 GET /CFIDE/shell.cfm - 80 – X.X.X.X fake-useragent 200 0 0 432

The IIS logs showed the activity that tripped the IDS sensor occurred at 2015-03-10 22:09:10 when the external system with IP address X.X.X.X scheduled a new task successfully. Notice the 200 HTTP status code indicating the request completed successfully. This single entry answers one of the questions. The attacker did compromise the Coldfusion server and has administrator rights to the Coldfusion instance because they were able to access the schedule tasks area within the administrator panel. The next log entry shows the scheduled task named “z” executed at 2015-03-10 22:09:15 and shortly thereafter the attacker accessed a file named “shell.cfm”. Applying the Root Cause Analysis Model to this incident results in this activity along with the IDS alert being organized into the indicators layer. The activity is post compromise activity and the model is being used to identify the attack vector. The investigation continues to see what remnants the attacker left in the logs just prior to tripping the sensor while trying to upload their web shell.

The IIS log was reviewed to see what occurred prior to 2015-03-10 22:09:10 for the attackers IP address X.X.X.X. The few records are listed below:

2015-03-10 22:08:30 192.168.0.1 GET /CFIDE/adminapi/administrator.cfc method=login&adminpassword=&rdsPasswordAllowed=true 80 – X.X.X.X fake-useragent 200 0 0 432

2015-03-10 22:08:40 192.168.0.1 GET /CFIDE/administrator/images/icon.jpg 80 – X.X.X.X fake-useragent 200 0 0 432

The prior activity shows the attacker requesting a strange URL followed by successfully accessing the icon.jpg image file. Searching on the strange URL reveals it’s an Adobe ColdFusion Administrative Login Bypass exploit and when successful it provides access to the admin panel. This remnant is organized into the exploit layer. The payload of this exploit is direct access to the admin panel. There is no delivery mechanism for the payload. When the admin panel is accessed certain files are loaded such as images. In this scenario one of the images loaded by default is the file icon.jpg. This remnant indicates the attacker successfully accessed the admin panel so it means the exploit worked and the payload was admin access. The access to the icon.jpg file is organized into the payload layer. At this point the following layers in the Root Cause Analysis have been completed: indicators, payload, deliver mechanism, and exploit. The remaining layers are the delivery mechanism for the exploit and source. The attacker used a tool or web browser to attack the server so the delivery mechanism for the exploit is HTTP and the source of the attack is somewhere from the Internet.

The Compromise Root Cause Analysis Model was applied to the hypothetical web compromise security incident and it made it easier to review the remnants left by the attacker to identify the attack vector they used.

Root Cause Analysis Is Easier with a Methodical Process


The Compromise Root Cause Analysis Model is a cyclical methodical process one can use to perform root cause analysis. The model is way to organize information and artifacts discovered during investigations for each system involved in the attack. The model is a repeatable investigation process enabling the questions of how and when did the compromise occur to be answered.



References

Carvey, H. (2005). Locard's Exchange Principle in the Digital World. Retrieved from http://windowsir.blogspot.com/2005/01/locards-exchange-principle-in-digital.html

Harrell, C. (2010). Attack Vector Artifacts. Retrieved from http://journeyintoir.blogspot.com/2010/11/attack-vector-artifacts.html

Harrell, C. (2012). Compromise Root Cause Analysis Model. Retrieved from http://journeyintoir.blogspot.com/2012/06/compromise-root-cause-analysis-model.html

Harrell, C. (2012). Malware Root Cause Analysis. Retrieved from http://journeyintoir.blogspot.com/2012/07/malware-root-cause-analysis.html

Harrell, C. (2014). Malware Root Cause Analysis Dont Be a Bone Head Slide Deck. Retrieved from http://journeyintoir.blogspot.com/2014/06/malware-root-cause-analysis-dont-be.html

Hogfly. (2008). Footprints in the snow. Retrieved from http://forensicir.blogspot.com/2008/12/footprints-in-snow.html

The Jock Becomes the Geek

Sunday, February 22, 2015 Posted by Corey Harrell 2 comments
We interrupt the normal DFIR programming on this blog for a different kind of post. A post about a situation I found myself in. It's a story others may find amusing or cause them to have empathy for me. It's a story about how I evolved from being a jock to walking amongst the DFIR geeks.

In high school I didn't pay any mind to the so called “clicks.” If I had to be categorized then I guess it would had been a jock. I was a three sport athlete who enjoyed the social life outside of school. I wasn’t in to any of the things people tend to talk about to show their “geek credentials.” I didn’t care about technology (outside of video games), didn’t use computers, and definitely didn’t play any of the so called “geeky” games like dungeons and dragons. Heck, I didn’t even have a drive to learn since I was only going through the motions.

So at this point you may be wondering what the hell happened to me. To go from an athlete who didn't care about technology and learning. To someone who is passionate about one of the most technical areas within the information security field and spends their free time researching “geeky” things. What happened to me was a life changing experience.

After I graduated high school I was working for an organization who provided for people with disabilities. I have the upmost respect for the people whose calling is in this field. To care for one of the most vulnerable populations in our society. Without these organizations, there is a risk to returning to the institutions where this population was mistreated and abused for years. The people working in this field have been some of the most caring people I ever met. My mom was one of them and growing up she would bring me to the places where she worked. Now back to my story. I was a floater in the organization I worked for. Floaters worked in the residences where the people lived and did not have a set house they would always work in. We floated from house to house based on where coverage was needed. The houses varied in the people’s functional levels who lived there. Some had high functioning individuals who had jobs and took care of themselves; my job was more of a mentor then a direct care worker. Other houses had lower functioning individuals; my job was direct care taking care of their every need. Going in to this job I knew what I was in for and what the nature of the work could involve.

One day I was working at a low functioning house. During my shift, an individual who was confined to a wheel chair had an accident that involved a bowel movement. I wasn't sure how it played out with my coworker but it was my turn. It was the turn of an 19 year old kid to clean up an adult who had an accident. I worked in this position for some time but this was the first time I encountered having to attempt anything like this. As we entered into the bathroom I noticed the most awful smell I have ever smelled. Mind you, we just walked in to the bathroom and the bowel smell quickly overcame what little fresh air was left in the room. I started to envision what I had to do next. The images running through my mind along with the smell was making me more and more nauseous. That is when I blew chunks in the direction of the toilet as I dropped to my knees getting sicker and sicker as tears started rolling down my face. I mumbled and grunted to my coworker; something along the lines "I can't. I can't. I can’t. I can't stop getting sick." She was one of the people I worked with who had a serving heart but looking back on this almost 18 years later I think she took pity on me. An 19 year old kid who looked like a mess and was on his knees throwing up into the toilet. Each time I breathed in what smelled worse than death resulted in the toilet calling my name again. I tried to leave. Believe me, I tried to leave to get fresh air. Boy, how many times did I try to leave? The smell; that horrible, horrible smell. At one point, I stood up to leave and I saw my coworker attending to the individual. That provided visuals to go along with the smell and things became worse.

I don't remember how long this went on for or what happened afterwards. All I know was this experience had a significant impact on my life. Again, I have the upmost respect for those who work in this field but the experience taught me the work was not meant for me and my weak stomach. The experience stuck with me and impacted me when I was joining the Marines a year later. I had the pick of any job I wanted in the Marines. I only wanted a job that kept me far away from going through the experience again. I picked what in my mind was the complete opposite of the field where I had this experience. I picked a technology field where I thought I would never again be responsible for caring for other people. (Please keep in mind, when I made this decision I was 19 and had a lot to learn.) This decision –based on my experience - is what made the jock become a geek. The rest of my story is history as I had a guiding hand leading me down the path where I eventually found my passion amongst the DFIR geeks. A community where if you have the technical skills and knowledge then you are accepted as one of their own even if you lack the traditional "geek credentials."
Labels:

Process Hollowing Meets Cuckoo Sandbox

Wednesday, February 4, 2015 Posted by Corey Harrell 2 comments
Growing up I loved to watch horror movies. In hindsight, they scared the crap out of me probably because I was too young to watch them. One such movie was the 1986 movie Night of the Creeps. Alien slugs enter through peoples' mouths and eventually take over their bodies. A classic body snatchers style movie that had me worried for few days when talking to close to people. Process hollowing (aka process replacement) is a technique malware uses to overwrite a running process with a malicious code. To me it's the technical equivalent of those alien body snatchers. This post explores process hollowing techniques using the Cuckoo Sandbox.

Process Hollowing (aka Process Replacement)


In my post Prefetch File Meet Process Hollowing I walked through what process hollowing was but for completeness I’ll copied what I wrote below:

Malware uses various techniques to covertly execute code on systems. One such technique is process hollowing, which is also known as process replacement.

The book Practical Malware Analysis states the following in regards to this technique:

"Process replacement is used when a malware author wants to disguise malware as a legitimate process, without the risk of crashing a process through the use of process injection.

Key to process replacement is creating a process in a suspended state. This means that the process will be loaded into memory, but the primary thread of the process is suspended. The program will not do anything until an external program resumes the primary thread, causing the program to start running"

In addition, the book The Art of Memory Forensics states the following:

"A malicious process starts a new instance of a legitimate process (such as lsass.exe) in suspended mode. Before resuming it, the executable section( s) are freed and reallocated with malicious code."

In essence, process hollowing is when a process is started in the suspended state, code is injected into the process to overwrite the original data, and when the process is resumed the injected code is executed. Everything about the process initial appears to reflect the original process. Similar to how everything about the person initially appears to be the original person. Upon closer inspection it reveals that everything is not what it seems. The process behaves differently (such as network communications) and the code inside the process is not the original code. This is very similar to the person behaving differently (such as trying to eat you) and the biological material inside the person is not the original biological material.

A Common Process Hollowing Technique


Through observation, the characters in the In the Night of the Creeps figured out how people’s bodies were snatched. Slugs went from one person’s mouth to another person’s mouth. After observing this method the characters put tape over their mouths and were able to fight the zombies without becoming one themselves. By knowing what technique was used to snatch a body enabled the characters to defend themselves. The same can be said about process hollowing and knowing how the technique looks enables you to spot the zombified processes. One of the more publicize techniques was described in the Practical Malware Analysis book (lab 12-2 solution on page 590) as well as Trustwave SpiderLabs’s article Analyzing Malware Hollow Processes. The sequence of Windows functions, their descriptions, and how they appear during dynamic analysis of the Profoma Invoice.exe sample (md5 ab30c5c81a9b3509d77d83a5d18091de) with the Cuckoo sandbox is as follows:

        - CreateProcessA: creates a new process and the process creation flag 0x00000004 is used to create the process in the suspended state
        - GetThreadContext: retrieves the context of the specified thread for the suspended process
        - ReadProcessMemory: reads the image base of the suspended process
        - GetProcAddress: according to Practical Malware Analysis this function “manually resolves the import UnMapViewofSection using GetProcAddress, the ImageBaseAddress is a parameter of UnMapViewofSection”. This removes the suspended process from memory.
        - VirtualAllocEx: allocates memory within the suspended process’s address space
        - WriteProcessMemory: writes data of the PE file into the memory just allocated within the suspended process
        - SetThreadContext: according to Practical Malware Analysis this function sets the EAX register to the entry point of the executable just written into the suspended process’s memory space. This means the thread of the suspended process is pointing to the injected code so it will execute when the process is resumed
        - ResumeThread: resumes the thread of the suspended process executing the injected code

Cuckoo Sandbox Showing the Common Process Hollowing Technique


Cuckoo Sandbox is an open source automated malware analysis system. In their own words "it simply means that you can throw any suspicious file at it and in a matter of seconds Cuckoo will provide you back some detailed results outlining what such file did when executed inside an isolated environment." Malwr is a free online malware analysis service that leverages the Cuckoo Sandbox. The Behavioral Analysis section outlines the function calls made during execution. The pictures below show the Profoma Invoice.exe sample’s (md5 ab30c5c81a9b3509d77d83a5d18091de) function calls that perform process hollowing.

The image below shows Profoma Invoice.exe creating a process in the suspended state. The suspended process’ handle is 0x00000088 and thread handle is 0x0000008c.


The next image shows Profoma Invoice.exe retrieving the context of the suspended process since it references the thread handle 0x0000008c.


The image below shows Profoma Invoice.exe reading the image base of the suspended process since it references the process handle 0x00000088.


The image below shows Profoma Invoice.exe getting the addresses of the UnMapViewofSection and VirtualAllocEx function calls.


The images below show Profoma Invoice.exe writing a PE file into the address space of the suspended process since it references the process handle 0x00000088. It takes multiple WriteProcessMemory function calls to write the entire PE file.


The image below shows Profoma Invoice.exe setting the thread context for the suspended process since it references the thread handle 0x0000008c.


The image below shows Profoma Invoice.exe resuming the suspended thread to execute the injected code.


Cuckoo Sandbox Detecting the Common Process Hollowing Technique


Cuckoo Sandbox detects malware functionality using signatures. The image below shows Malwr detecting the common process hollowing technique used by Profoma Invoice.exe (md5 ab30c5c81a9b3509d77d83a5d18091de).


The signature detecting process hollowing reports it as “executed a process and injected code into it, probably while unpacking.” The signature detecting the technique is named injection_runpe.py and is available in the Community Signatures. The signature is open allowing anyone to read it to see how it detects this behavior. However, the image below shows a portion of the signature that detects the sequence of function calls outlined earlier to perform process hollowing.


A Different Process Hollowing Technique


The process hollowing technique outlined above is well publicized and is the technique I normally expected to see. It was as if I had tape on my mouth waiting for a zombified friend to come strolling down the street. There are more than one ways to perform an action similar to there being more than one way to snatch a body. In the 1998 movie The Faculty an unknown creature snatched bodies by entering the body through the ear. Now imagine what would had happened to the characters from the Night of the Creeps movie encountering these body snatchers. The zombified bodies are harder to spot since they don’t look like zombies. Trying to defend themselves with tape on their mouths and baseball bats in hand would be short lived. The tape offers no protection since the creatures enter through the ear. It’s a different technique with the same result. Process hollowing is similar with different techniques ending with the same result.

I was a bit surprised back in December when I saw the behavior in the image below after I ran the sample Kroger_OrderID.exe (md5 1de7834ba959e734ad701dc18ef0edfc) through a sandbox.


The behavior clearly shows that Kroger_OrderID.exe is going to perform process hollowing since it started the svchost.exe process in a suspended state (creation flag 0x00000004.) However, the function calls afterwards are not the typical well publicized ones; this was a different technique. After a bit of searching I found the Lexsi article Overview of the Kronos banking malware rootkit, which breaks down how this technique works. (the article also shows how to use Volatility to analyze this as well.) I summarized below the Windows function sequence and their descriptions as outlined in the article:

        - CreateProcessA: creates a new process and the process creation flag 0x00000004 is used to create the process in the suspended state
        - ReadProcessMemory: reads image base of the suspended process
        - NtCreateSection: creates two read/write/execute sections
        - ZwMapViewOfSection: maps the read/write/execute sections into the malware’s address space
        - ZwMapViewOfSection: maps the second section into the suspended process’s address space (this section is therefore shared between both processes).
        - ReadProcessMemory: reads image base of the suspended process’s image into section 1
        - ReadProcessMemory: reads image base of the malware’s image into section 2
        - NtMapViewOfSection: overwrites the suspended process's entry point code by mapping section 1 to the new process base address
        - ResumeThread: resumes the thread of the suspended process executing the injected code

Cuckoo Sandbox Showing the Different Process Hollowing Technique


The Behavioral Analysis section outlines the function calls made during execution. The pictures below show the sample Kroger_OrderID.exe (md5 1de7834ba959e734ad701dc18ef0edfc) function calls performing the different process hollowing technique.

The image below shows the first three function calls. The sample Kroger_OrderID.exe creates a suspended process with the thread handle 0x00000608 and process handle 0x00000604. Next the ReadProcessMemory function reads the image base of the suspended process due to the reference to process handle 0x00000604. The NtCreateSection function then creates the second read/write/execute section with the section handle 0x000005f8.


The image below shows the next three function calls. The ZwMapViewOfSection function maps the read/write/execute sections into the malware’s address space due to the section handle 0x000005f8 being referenced. The next ZwMapViewOfSection maps the second section into the suspended process’s address space due to both the section handle 0x000005f8 and process handle 0x00000604 both being referenced. Then the ReadProcessMemory function reads malware’s image into the section. Not shown in the image is the ReadProcessMemory function referencing the process handle 0x00000604.


The image below shows the remaining four functions. The NtCreateSection function then creates the first read/write/execute section with the section handle 0x000005f4. The ZwMapViewOfSection functions maps the read/write/execute sections between the malware and suspended process due to section handle 0x000005f4 and process handle 0x00000604 both being referenced. This mapping overwrites the entry point code in the suspended process. Finally, the ResumeThread function resumes the thread of the suspended process executing the injected code.


Cuckoo Sandbox Detecting the Different Process Hollowing Technique



**** Updated on 02/04/15 *****

This section of the blog has been edited since it was published earlier today. In the original blog post I highlighted how the injection_run.py signature did not detect this injection technique and I shared a signature I put together to detect it.


Brad Spengler sent me an email about what I was seeing. He mentioned that a change did not make it into the updated injection_run.py signature. Specifically, he mentioned the plugin is looking for NtMapViewOfSection which he uses in his Cuckoo Sandbox instead of looking for the older ZwMapViewOfSection. I modified the injection_run.py signature by renaming NtMapViewOfSection to ZwMapViewOfSection (on lines 45 and 51) and afterwards it did detect this technique. As a result, I updated this section of the blog to reflect this since this post’s purpose was to explore different injection techniques and how Cuckoo can help explore them.

**** Updated on 02/04/15 *****


Cuckoo Sandbox is able to detect this different process hollowing technique (see update about change made to the injection_runpe.py signature.) Executing the sample Kroger_OrderID.exe (md5 1de7834ba959e734ad701dc18ef0edfc) in Cuckoo results in the following behavior detection.

 

Wrapping Things Up


We don’t need to sit at our computers wearing headphones and tape on our mouths to hunt down zombified processes within our environments. Process hollowing is an interesting technique and it constantly reminds me about the various body snatcher horror movies I’ve seen. Leveraging the Cuckoo Sandbox makes exploring the various process hollowing techniques even more interesting since it allows for following the sequence of Windows function calls.

Happy hunting and if you come across any zombies in your travels don’t take any chances and just follow the rule from the movie Zombieland. Rule 2 Double Tap: when in doubt, don't get stingy with your bullets.

Linkz for Detection and Response

Monday, January 19, 2015 Posted by Corey Harrell 1 comments
The fastest way to reach a destination is to learn from those who have traveled parts of the journey you are on. Others may point you in a direction to avoid the obstacles they faced or show you the path through the woods towards your destination. In Information Security, we tend to gain knowledge from others by what they publish: websites, blogs, books, and even their 140 character tweets. The journey I have been on is exploring enterprise security detection and response; actually implementing enterprise detection and response. Implementing them not as standalone processes standing on their own but two complimentary processes that feed into each other. This Linkz post is sharing the works by others I came across whose focus is on detection and response.

Linkz for Incident Response and SIEM


I shared these linkz before but they point to some great resources about detection and response. For linkz related to incident response - including the thought process behind IR - refer to the post Linkz for Incident Response. For linkz related to detection with a focus on SIEM refer to Linkz for SIEM.

Network Security Operations Management Workflow


When it comes to network security there is a wealth of information. How to create a SOC, how to design and deploy IDS sensors, and how to use security monitoring tools are a few of the topics covered. Despite the wealth of information, there is very little about the management workflow for network security monitoring. Securosis released the Network Security Operations Quant Report about five years ago and it outlines one of the best management workflows I have come across. The Manage Process (on page 13) addresses policy review, update policies & rules, evaluate signatures, deploy, and audit/validate. It's a decent process since it touches on topics I haven't seen addressed elsewhere. At this point I could care less about the metrics portion of the document but the process portion is worth a look.

Network Security Monitoring Books


One thing I tend to look for in detection and response resources is do they outline a process or a thought process. Tools are great and all but it's pretty easy to learn a tool on your own compared to the process one  should use when doing detection and response. The processes are what you can learn from others to reach your destination and you can fill in the gaps by teaching yourself the tools. The next two resources are not free but are well worth the investment. Richard Bejtlich's The Practice of Network Security Monitoring: Understanding Incident Detection and Response and Chris Sanders  & Jason Smith's Applied Network Security Monitoring: Collection, Detection, and Analysis. Both books cover open source NSM tools and analyzing network data but the aspects I really enjoyed where their perspectives. Their perspectives about how to approach NSM and how to manage certain aspects of NSM including the response to security incidents along with detection security events.

Free Book with Strategies for Cybersecurity Operations Center


Carson Zimmerman of The MITRE Corporation released a free book titled Ten Strategies of a World-Class Cybersecurity Operations Center. I have been to a few different conferences where vendors give out free books. Needless to say, based on my past experiences I view free books with skepticism. However, Ten Strategies of a World-Class Cybersecurity Operations Center has restored my faith in free books. I'm surprised it was released for free; the content was great and the quality was top notch. The strategies covered topics from consolidating functions of detection and response under one organization to CSOC size to staff quality to sensor placement to responding to incidents. It's a great read for anyone who is looking to improve an organization's detection and response capability. It may even be worth the while for people who have been managing CSOCs to pick up a few different ideas.

Leveraging the Kill Chain for Detection


Sean Mason wrote the article Leveraging The Kill Chain For Awesome discussing the various ways the kill chain can be used. The section I wanted to focus on was the following: "when it comes to enterprise detection, the Kill Chain is useful for understanding what your capabilities are, as well as your gaps in coverage by tools and threat actors." This is one area where I think the kill chain excels. By organizing your detection rules beneath the kill chain it is easy to see what detection areas are strong and weak. Furthermore, it helps to see where external tools or intelligence can fill in the gaps. The one additional point I suggest is to do this organization for each use case that is implemented.

Questions to Answer During Response


A couple months ago Jack Crook put together a nice post over on his HandlerDiaries blog called Answering those needed questions. He walked through the typical questions he needs to answer when he is responding to an incident. In addition, he addressed "some of the actions needed during response activities." There were two things I really enjoyed about the post. First was how he broke down all of the possible questions one could ask into six categories; this simplifies the thought process making it easier to work through. The second point I liked was how he tied together response and detection. Throughout the post he touched on things to consider to improve detection as you respond.

Triage Questions


Continuing along with what questions should be answered when responding to security incidents is David Bianco's article Triage Any Alert With These Five Weird Questions!. David defines alert triage as "the process of going through all of your alerts, investigating them, and either closing them or escalating them to an incident." By far, this is one of the most common activities for those performing detection and response. The article walks through five questions one should ask while performing alert triage. The article is well worth the read since it highlights things to consider when performing this work.

If Antivirus Fires Triage that System


Speaking about triaging and alerts. Adam over at the Hexacorn blog put together an awesome post (The art of disrespecting AV (and other old-school controls), Part 2) highlighting a critical point. His conclusion was "when you see an AV alert you need to triage the system, because it has been compromised + there may be still some undetected malware present on it." I couldn't agree more with the items he brought to light in his post and his conclusion. Too many times you see organizations complacent in that their antivirus solutions detected and removed a malware without any additional work or trying to answer questions. Too many times I've seen where antivirus hits on one file but missed numerous others. The line of thinking things are all good "since antivirus got it" is broken and in the end risks leaving compromise systems on the network. Furthermore, triaging every single antivirus alert provides visibility into the network and the methods being used trying to compromise an organization.

Seeing the Complete Picture


Rounding out this linkz post is the article What It Looks Like: Malware Infection via a Weaponized Document by Harlan Carvey. Harlan obtained a weaponized document, executed it in a test system, and then walked through his examination to identify artifacts on the host. The document he obtained was already written about from the dynamic analysis perspective but it didn't address artifacts left on the system. The thing I really liked about Harlan's post is it addresses an area that very little is written about. There are a ton of articles about dynamic analysis and offensive techniques such as exploiting a vulnerability but there is not as much about attack vector artifacts left on the system. The attack vector artifacts showing how it looks when a hacker (or cracker) uses a path or means to gain access to a computer or network server in order to deliver a payload or malicious outcome. Over the past month there have been various articles mentioning the increase in malicious documents being used to compromise systems. The malicious documents mentioned vary as well as their payloads vary. However, the activity left on the system due to a malicious document will remain the same. This activity is what Harlan addressed in his post and the information helps to bring a more complete picture into view. Harlan also provided his thoughts on a few take-aways for detection and response.
Labels: , ,

Triaging a System Infected with Poweliks

Sunday, January 4, 2015 Posted by Corey Harrell 3 comments
Change is one of the only constants in incident response. In time most things will change; technology, tools, processes, and techniques all eventually change. The change is not only limited to the things we rely on to be the last line of defense for our organizations and/or customers. The threats we are protecting them against change too. One recent example is the Angler exploit kit incorporating fileless malware. Malware that never hits the hard drive is not new but this change is pretty significant. An exploit kit is using the technique so the impact is more far reaching than the previous instances where fileless malware has been used (to my knowledge.) In this post I'm walking through the process one can use to triage a system potentially impacted by fileless malware. The post is focused on Poweliks but the process applies to any fileless malware.

Background on Why This Matters


In my RSS feeds, I was following the various articles about how an exploit kit incorporated the use of fileless malware. The malware never gets dropped to the disk and gets loaded directly into memory. A few of the articles I'm referring to are: Poweliks: The file-less little malware that could, Angler EK : now capable of "fileless" infection (memory malware), Fileless Infections from Exploit Kit: An Overview, POWELIKS: Malware Hides In Windows Registry, and POWELIKS Levels Up With New Autostart Mechanism. Reading the articles made one thing clear: one of the most effective tools to deliver malware (exploit kits) is now using malware that stays in memory.

This change has a significant impact on multiple areas. If the malware stays in memory then the typically artifacts we see on the host will not be there. For example, when the malware is loaded into memory then it won't create program execution artifacts on the system. This means the triage and examination process needs to adjust. As I mentioned previously, this change was implemented into a widely known exploit kit (Angler exploit kit.) The systems infected with this exploit kit can be far reaching. This means we will encounter this change sooner rather than later; if you haven't faced it already. Case in point, recently the Internet Systems Consortium website was compromised and was redirecting visitors to the Angler exploit kit. The last impact is if this change provides better results for the people behind it then I can see other exploit kit authors following suit. This means fileless malware may become even more widespread and it's something that is here to stay.

I knew memory forensics is one technique we can use to find the malware in memory. (if you need a great reference on how to do this check out the book the Art of Memory Forensics.) However, the question remained what does this look like. I took the short route for a quick answer to my question by reaching out to my Twitter followers. I asked them the following: "Anyone know how Poweliks code looks from memory forensics perspective?"

The first responses I got back was from Adam over at the Hexacron blog (great blog by the way) as shown below.

 
Adam provided some great information; to narrow in on the dllhost.exe process and what strings to look for. Another response I got was from @lstaPee as shown below:


@lstaPee provided a few more tidbits. RunDll32.exe injects code into the Dllhost.exe and dllhost.exe should have network connections. The response I got back from Twitter was great but I really needed to address the bigger question. If and when I have to triage a system infected with Poweliks what is the fastest way to perform the triage to locate the malware and determine the root cause of the infection. A question I needed to dig in to in order to find out the answer.

Testing Environment


As much as I wanted to simulate this attack by finding a live link to an Angler exploit kit I knew it would be very difficult. Based on various articles I read, Angler is VMware aware and  it doesn't always deliverer the fileless malware. I opted to use a Powelik's dropper/downloader. I used the sample MD5 0181850239cd26b8fb8b72afb0e95eac I found on Malwr. The test system was a Windows 7 32bit virtual machine in VMware.

The test conditions were really basic. I executed the sample by clicking it and then waited for about a minute. The VM was suspended and I collected the memory and prefetch files. I then unsuspended the VM followed by rebooting the system. After reboot, I logged onto the VM and then suspended it to collect the memory and prefetch files.

My tests was to analyze the Poweliks infection from two angles. The initial infection prior to a system reboot and a persistent infection after the system reboots. My analysis had one exception. By clicking the Poweliks executable to infect the system this action created program execution artifacts. I ignored these artifacts since they wouldn't be present if the malware was loaded directly into memory. I followed my typical examination process on the memory images and vmdk files but this post only highlights the activity that directly points to Poweliks. There was other activity of interest but the activity by itself does not indicate anything malicious. This activity I opted to omit from the post.

Poweliks' Behavior


Before diving into the triage process and what to look for it's important I discuss one Poweliks' behavior. I won't go into any details how I first picked up on this but I will show the end result. What the behavior is and how it can help when triaging Poweliks specifically. The screenshot below shows partial of the Malwr's behavior analysis section showing the behavior I'm referring to.


Upon a system's initial infection, the malware calls rundll32.exe which then calls powershell.exe who injects code into the dllhost.exe process. In the image above the numbers are for the process IDs and this relevant as we dig deeper into the behavior.

The image below shows activity that occurs shortly after the rundll32.exe process starts. As can be seen, rundll32.exe attempts to load a module into its own address space with the LdrLoadDll function. The module being loaded is actually javascript; this behavior is well documented for Poweliks such as in the article Poweliks – Command Line Confusion. Notice the activity following the LdrLoadDll function call is trying to locate the address for the RunHTMLApplication function. Here's the keyword Adam pointed out.


The images below shows activity that occurs just prior to powershell.exe process exiting. Powershell.exe creates the dllhost.exe process in the suspended state. Code gets injected into this suspended dllhost.exe process and then it is resumed. This technique is process hollowing and when the suspended process is resumed it executes the injected code.



Triaging System Infected with Poweliks


Triage is the assessment of a security event to determine if there is a security incident, its priority, and the need for escalation. As it relates to potential malware incidents, the purpose of triaging may vary. In this instance, triage is being used to determine if an event is a security incident or false positive by identifying  malware on the system. Confirming the presence of malware allows for a deeper examination to be completed. The triage process I'm outlining is to confirm the presence of the Poweliks fileless malware.

Triaging with Host Artifacts


Normally, triaging a system using artifacts on the host is an effective technique to identify malware. This is especially true when leveraging program execution artifacts. However, loading malware directly into memory has a significant impact on the artifacts available on the host. There are very little artifacts available and if the malware doesn't remain persistent then there will be even less. Triaging a system infected with Poweliks is no different. Most of the typically artifacts are missing but it can still be identified using prefetch files and autorun locations.

Prefetch Files


Previously I outlined the Poweliks behavior where the rundll32.exe process runs, which then starts a powershell.exe process before injecting code into the dllhost.exe suspended process. This behavior is apparent in the prefetch files at the point of the initial infection. The image below shows the activity.


The prefetch files show the sequence of rundll32.exe executing followed by powershell.exe before dllhost.exe. Furthermore, the dllhost.exe prefetch file is missing the process path. The missing process path indicates process hollowing was used as I outlined in the post Prefetch File Meet Process Hollowing. The prefetch files contain references to files accessed during the first 10 seconds of application startup. The dllhost.exe prefetch file contains revealing ones. It contains a reference to wininet.dll for interacting with the network and files associated with Internet Explorer as shown below.


This specific prefetch file sequence only occurs upon the initial infection. Future system restarts where Poweliks is loaded into the dllhost.exe process only shows the dllhost.exe prefetch file. The file references in this prefetch still show references to files located in the user profile.


Autoruns


The prefetch files contain a distinctive pattern indicating a Poweliks infection. Depending on the sample, autoruns can reveal even more. I mention depending on the sample because Poweliks has changed its persistence mechanism. Initially it used the Run registry key before moving on to a CLSID registry key. I thought one article mentioned Poweliks may not try to remain persistent at all times. If Poweliks does try to remain persistent then its mechanism can be used to find it. Keep in mind, Poweliks has taken self protection measures to prevent this mechanism from being located on a live system. The easiest method to bypass these measures is to access the system remotely with a forensic tool like Encase Enterprise, mount the drive, and then run Regripper across the hives.

The image below shows the Run key from the user account on my test system. The sample I used was older since the Run key was used but it still is a tell-tale sign for a Poweliks infection.

...snip....

Memory Analysis Triage


Fileless malware may leave very little artifacts available on the host's hard drive but it still has to reside in memory. The most effective technique to identify a fileless malware infection is memory forensics. A Poweliks infection is not an exception since it stands out in memory whether if the memory is examined after the initial infection or a system reboot.

Network Connections


One area with malware indications is network activity are for unusual processes. @lstaPee alluded to this in their tweet about Poweliks. The Volatility netscan plug-in does show network activity for  the dllhost.exe process involving the IP address 178.89.159.35 on port 80 for HTTP traffic. dllhost.exe is not a process typically associated with web traffic so this makes it a good indicator pointing to Poweliks.


Process Listing


Another area with malware indications is the process listing showing unusual ones or ones with unusual commands. The Volatility pslist, psscan, and pstree -v plugins did not reveal anything that could definitely be used as an indicator but they did show the dllhost.exe process running. I checked a few clean systems to see if dllhost.exe normally runs but the process was not running by default.  This doesn't mean it can be used as an indicator because there could be other reasons for dllhost.exe running besides Poweliks. The screen below is from the pstree plug-in showing the command-line for launching dllhost.exe (notice there are no other options used in the command.)


Injected Code


Looking for processes with injected code is an effective technique to locate malware on a system. This is the one technique that absolutely reveals Poweliks on a system. The Volatility malfind plug-in showed the dllhost.exe process with injected code. This matches up to the articles about the malware and behavior analysis showing code does get injected into the dllhost.exe process. The image below shows the partial output from malfind.


Extracting the injected code and scanning it with antivirus confirms it is Poweliks. The image below shows the VirusTotal results for the injected code. Microsoft detected the code as Trojan:Win32/Powessere.A which is their classification for Poweliks.


Strings


The last area containing indicators pointing to Poweliks are the strings in the dllhost.exe process. The method to review the strings is not as straight forward as running a single Volatility plug-in. The strings command reference walks through the process and it's the one I used. The only thing I did different was to grep for my process ID to make the strings easier to review. The dllhost.exe strings revealed URLs such as one containing the IP address found with the netscan plug-in.


The most significant string found was the command used to make rundll32.exe inject code into the dllhost.exe process as shown below. The presence of this string alone in the dllhost.exe process indicates the system is infected with Poweliks.


Wrapping Things Up


The change introduce by the Angler exploit kit creator(s) is causing us to make adjustments in our processes. The effective techniques we used in the past may not be as effective against fileless malware. However, it doesn't mean nothing is effective preventing us from triaging these systems. It only means we need to use other processes, techniques, and tools we have at our disposal. We need to take what artifacts do remain and use it to our advantage. This post was specific to the Poweliks malware but the techniques discussed will apply to other fileless malware. The only difference will be what data is actually found in the artifacts.