Journey Into Incident Response

I find myself in more situations where I’m not completely satisfied with my DFIR tools. They either don’t parse certain information or lack capabilities I want. Batch scripting helped in some situations but the scripts are limited in what I can do. For example, it’s difficult (if not impossible) to create a script to extract information from an artifact that’s not supported by existing tools. Learning a programming language has been at the top of my to-do list for some time due to these reasons. I was browsing my local book store when I came across the book Perl Programming for the Absolute Beginner.

Why Perl Programming for the Absolute Beginner

I chose the book after I skimmed through a few other Perl programming books. Perl Programming for the Absolute Beginner is written for an audience without previous programming experience. The book goes into great detail explaining basic programming concepts such as variables, arrays, loops, and subroutines. I took a C++ course in my undergraduate about seven years ago and the only thing I remember is that I took a C++ course. Basically, I have zero programming knowledge including not knowing much about programming concepts. A lot of the books I skimmed, such as Learning Perl, don’t take the time to explain the basic concepts since they expect the reader to be already familiar with them. I wanted a book to explain the basics in addition to the language; Perl Programming for the Absolute Beginner fit the bill.

Numerous books I looked at use exercises at the end of each chapter to reinforce the material covered. The exercises are pretty simple and perform one action such as a math calculation. Perl Programming for the Absolute Beginner takes a different approach in teaching Perl. Instead of individual exercises the book has the reader write computer games which are fully functioning programs. I thought this approach does a better job showing how to use Perl since it covers the planning, organizing, coding, and testing activities involved with script development. Plus the approach was entertaining and it kept my interest. I’d rather write a “Fortune Teller Game” than a script to compute “the circumference of a circle”. ‘nuff said.

What I learned

My review is going to be a little different. I’m neither discussing the book’s contents (if you want to know then read the table of contents) nor how helpful the book could be. Instead I’m talking about what I learned from the book and how it has impacted my DFIR work so far.

Seeing Behind the Curtain

Bear with me for this analogy… When I was younger I used to love watching Kung-fu. At times I watched movies completely in another language without subtitles. I got the gist of what was going on by watching body language, facial expressions, tones of people’s voices, and the bad guys getting stomped. However, when I watched the same movie in English (subtitles or dubbed over) I realized how much I missed about the movie’s plot. Learning Perl is the equivalent of adding subtitles or dubbed English to a Kung-fu movie. Before I understood the gist of what my Perl tools were doing but it’s completely different when you can read and actually understand the code to see how it produces its output. It let me see behind the tool abstraction curtain.

Extending my Capability

I was considering between learning Perl or Python since programs in my toolbox are written in those languages. One of my goals is to learn a language that lets me customize tools to better meet my needs. I picked Perl because two tools I extensively use are written in Perl and plug-in based. Plug-ins allow the tool to be extended fairly easily and I felt knowing how to write them would have a greater impact on my DFIR work. My immediate need was for a Regripper plug-in to parse the UserInfo registry key in an NTUSER.DAT hive (I could have asked others for this but I wanted to learn how to do it). In the past I manually examined the UserInfo key in the NTUSER.DAT hive and if present the hives in system restore points or volume shadow copies. Performing the task was time consuming but I needed to know the information. Perl Programming for the Absolute Beginner taught me enough about Perl to make it pretty easy to write a plug-in once I re-read the creating plug-ins section in Windows Registry Forensics. Taking the time to put the userinfo plug-in together will make things easier and faster for me in the future since I can now extract the information from a system in seconds. Talk about improving efficiency.

Breaking my Handcuffs

I’m still wearing handcuffs since I’m still dependent on existing tools and scripts created by others. However, Perl Programming for the Absolute Beginner opened my eyes to a future where if I encounter an artifact not supported by my tools then I could just write my own. A future where I no longer have to be satisfied and accept tools’ outputs when I want to see data differently. A future where repetitive tasks can be automated enabling me to spend more time on analyzing information. The book opened my eyes to a world where I don’t have to be handcuffed to my DFIR tools and the capabilities they provide. Perl Programming for the Absolute Beginner did not make me into a tool developer but it provided me with a foundation to build upon.

Four Star Review

Not all is rosy with the book though. I normally can overlook typos but I’m not very forgiven when there are typos in the code the reader is suppose to copy. It’s bad enough that beginners are going to mess something up and spend time tracking down their own mistakes. There’s no need to add even more typos resulting in people questioning themselves wondering what else they did wrong. Chapter Four’s Star Wars Quiz declares a variable named $valid but the rest of the program uses the variable $isvalid (on page 129). That small typo makes the game not work until the variable $valid is changed to $isvalid. As a reader I shouldn’t be required to find typos in code in order to make things work. I spend enough time finding my own mistakes as it is.

Overall I give Perl Programming for the Absolute Beginner a four star review (based on Amazon’s rating scheme). I highly recommend the book for anyone looking to learn the Perl programming language in addition to basic programming concepts. The book teaches the basics in an entertaining way enabling anyone to write simple scripts to solve issues. For those with programming backgrounds then I suggest looking elsewhere for a book on Perl since this is too basic. Learning Perl is a decent candidate because the target audience is for people familiar with programming concepts (I moved on to this book after reading Perl Programming for the Absolute Beginner).

In this round of links I’m talking about drive-bys, malicious ads, web attack artifacts revealed with Mandiant’s Highlighter, and a justification for companies to fail security audits.

Video Showing Drive-by Download from MySQL

As most people probably heard by now MySQL.com was serving up malware to its visitors last month. SecurityMonkey put together the post [Video]: Watch Malware Drive-By Download from MySQL.com which contained various links about the incident. One link was to a video created by Armorize that captured what happened to anyone who visited the website when the issue was occurring. The video is about five minutes long and I highly recommend for people to check it out. I’ve never seen a drive-by broken down before by video. The video by itself is pretty cool but I think the true value is in what it shows about the attack vector infecting people visiting the website. Check out the sequence of events I noted from the video:

        -  (00:55) Internet Explorer starts to load the website mysql.com
        -  (01:04) Java.exe starts running on the computer
        -  (01:11) Executables are dropped onto the computer. These were the attack’s payload
        -  (03:43) It was revealed that a Jar file was downloaded to the system and this is why Java started. The Jar file download occurred before the executables appeared on the computer

The attack summary was a user visited mysql.com and eventually gets redirected to a site hosting the Black Hole exploit pack. In that instance, the exploit pack used a Java vulnerability to infect the system. Why does any of this even matter … knowing this can help determine how a system was compromised. Let’s say someone was dealing with an infected computer and were trying to figure out how the malware got installed on the computer. The video didn’t show what was on the system’s hard drive but the attack is very similar to the Java exploit artifacts I documented. To date I’ve documented three different ones which were Java Signed Applet Exploit Artifacts, CVE-2010-0840 (Trusted Methods) Exploit Artifacts, and CVE-2010-0094 (RMIConnectionImpl) Exploit Artifacts. There was a consistent pattern to the all the artifacts:

        -  Temporary file created (Jar file got dropped onto the system)
        -  Indications of a vulnerable Java executing
        -  Internet activity showed a user visited a malicious website

The key difference (besides the Java vulnerability) between the Armorize video and the method I used to document the exploit artifacts was the tool used to create and deliver the exploit. The video documented a Java exploit from the Blackhole exploit pack and according to Contagio’s August 2011 Exploit Pack Overview spreadsheet Blackhole goes for $1,500 a year. My testing leveraged the freely available Metasploit to document exploit artifacts. Taking the time to document the exploit artifacts can pay big dividends during an examination when trying to determine the “how”. How did the system get infected? Well if the activity on the system around the time malware was created shows either a Jar file appearing or Java executing then a Java vulnerability may have been the culprit. If there is Internet activity then the Internet and a web browser may have been used to deliver the exploit to the system.

Malicious Advertisement Leads to PDF Exploit

I first started looking into attack vector artifacts when one of my systems got whacked with a Fake AV virus. At the time I had the DF skills but I lacked the IR skills such as figuring out what happened to my system. I took a shot at trying to figure out how the system became infected to see if I could. It took me a little bit but I was not only able to find the malware dropped onto my system but I traced the infection back to Yahoo email. I was even able to determine the exploit used in the drive-by. It was a malicious PDF file that targeted a vulnerability in Adobe Reader. The PDF appeared on the system in the temporary Internet files folder just prior to the first malware getting dropped. The experience taught me valuable lessons. First the more obvious one; don’t quickly check your web email from a test system with vulnerable apps even if it’s only for a few seconds. The second and more important lesson was the need to understand how different attacks appear on a system after they have occurred. The examination took me some time to figure out since I didn’t really know what to expect or what artifacts to look for.

I recently came across TrendMicro’s post Malicious Ads Lead to PDF Exploits. The post is from last year but it made me reflect on the experience that motivated me to start my journey into incident response. The post mentioned how malvertisements on a popular web-based email service lead to users being directed to sites with exploits. The article isn’t written from the DFIR perspective since it was focused on the vulnerabilities targeted in the attack. There wasn’t much discussion about the artifacts left on a system either besides malicious PDFs and internet activity. The little information provided did show how the attack occurred.

        -  User visits web based email service
        -  Redirect downloads malicious PDFs targeting Adobe Reader vulnerabilities
        -  Adobe reader has to process the PDF for the exploit to be successful and install malware

The attack pattern is something I’ve seen in a few other places. My infected test system had the same sequence of events but it took me a bit to actually see it. That examination made me more aware about the artifacts associated with a PDF exploit thereby making it easier to spot it in a few other examinations I did afterwards. I also saw the same pattern on my test systems I exploited with Metasploit. I researched a PDF exploit in the post CVE-2010-2883 (PDF Cooltype) Exploit Artifacts. Do the following areas I noted in the post look familiar?

        -  PDF document created
        -  There were references about a PDF file being accessed
        -  A vulnerable Adobe Reader started on the system

Web Attack Artifacts

Russ McRee’s October’s Toolsmith Log Analysis with Highlighter is a great read for a couple reasons. I enjoy reading his articles since he provides an overview about a tool’s functionality. In this edition he doesn’t disappoint as he covers how to perform log analysis with Mandiant’s Highlighter. Showing how to do log analysis is cool enough but he demonstrates the tool by looking for attacks in his website’s logs. He looks for specific artifacts caused by remote file include and directory traversal attacks. I haven’t found any references that document the artifacts left in logs by different attacks so I enjoyed reading about it. Eventually I’m going to start researching the artifacts left in logs but I still have a lot to do with the artifacts left on systems.

Fail a Security Audit Already Will You

When I started working full time in the information security field I was performing vulnerability assessments and security audits. Maybe I’m a little biased because of my background but I can see the value security audits provide when performed correctly. I’m not talking about audits where boxes are just checked off but risk based audits looking at the security controls protecting an organization’s critical information. Andreas M. Antonopoulos's article Fail a security audit already -- it's good for you provides an argument for why companies should fail security audits. The article makes some great points but the one thing I thought was missing is when organizations try to justify (aka make excuses) or minimize why serious weaknesses are present. Take patching as an example.

Patching isn’t done to prevent applications and systems from breaking. I was a system admin so I get it … especially since I’ve dealt with the hassle of tracking down the patches that jacked up my systems. However, using the reason as a justification to not patch without doing any due diligence by you know actually testing patches to see if anything breaks is something else. The SANs Top Cyber Security Risks report from a few years ago highlighted how third party applications on client systems are targeted. The exploits I discussed in this linkz edition targeted vulnerabilities in client applications such as Java and Adobe. How can these vulnerabilities on computers with users surfing the web be lumped into the same category as some application supporting a critical business process with neither of them getting patched? The security risk didn’t go away and the vulnerabilities don’t magically repair themselves. It’s too late to finally figure it out once the organization is staring at the artifacts from a successful exploit.

Artifact Name

Java Signed Applet Exploit Artifacts

Attack Vector Category

Exploit

Description

A signed Java applet is presented to a user and a dialog box asks the user if they trust it. If the user is socially engineered to run the applet then arbitrary code executes under the context of the currently logged on user.

Attack Description

This description was obtained using the Metasploit exploit reference. A user visits a web page hosting the signed Java applet and a Java window pops up asking the user to run the applet. Once the user runs it then a program is downloaded and executed on the system.

Exploits Tested

Metasploit v4.0 multi\browser\java_signed_applet

Target System Information

* Windows XP SP3 Virtual Machine with Java 6 update 16 using administrative user account

* Windows XP SP3 Virtual Machine with Java 6 update 16 using non-administrative user account

Different Artifacts based on Administrator Rights

No

Different Artifacts based on Software Versions

Not tested

Potential Artifacts

The potential artifacts include a Jar file and the changes the exploit causes in the operating system environment. The artifacts can be grouped under the following three areas:

        * Temporary File Creation
        * Indications of the Vulnerable Application Executing
        * Internet Activity

Note: the documenting of the potential artifacts attempted to identify the overall artifacts associated with the vulnerability being exploited as opposed to the specific artifacts unique to the Metasploit. As a result, the actual artifact storage locations and filenames are inside of brackets in order to distinguish what may be unique to the testing environment.

        * Temporary File Creation

            -JAR file created in a temporary storage location on the system within the timeframe of interest. [C:/Documents and Settings/Administrator/Local Settings/Temp/jar_cache5490377340104033776.tmp. The contents of the JAR file contained a manifest file, a class file, and an executable.


       * Indications of the Vulnerable Application Executing

           - Log files indicating Java was executed within the timeframe of interest. [C:/Documents and Settings/Administrator/Application Data/Sun/Java/Deployment/deployment.properties, C:/Documents and Settings/Administrator/Local Settings/Temp/java_install_reg.log, and C:/Documents and Settings/Administrator/Local Settings/Temp/jusched.log] The picture below shows the contents of the deployment.properties log.


            - Prefetch files of Java executing. [C:/WINDOWS/Prefetch/JAVA.EXE-0C263507.pf]

            - Registry modification involving Java executing at the same time as reflected in the jusched.log file. [HCU-Admin/Software/JavaSoft/JavaUpdate/Policy/JavaFX]

            - Folder activity involving the Java application. [C:/Program Files/Java, C:/Documents and Settings/Administrator/Application Data/Sun/Java/Deployment/, and C:/Documents and Settings/Administrator/Local Settings/Temp/hsperfdata_username]

        * Internet Activity

            - Web browser history of user accessing websites within the timeframe of interest. [Administrator user account accessed the computer -192.168.11.200- running Metasploit]

            - Files located in the Temporary Internet Files folder. [C:/Documents and Settings/Administrator/Local Settings/Temporary Internet Files/Content.IE5/]

           - Registry activity involving Internet Explorer

Timeline View of Potential Artifacts

The images below shows the above artifacts in a timeline of the file system from the Windows XP SP3 system with an administrative user account. The timeline includes the file system, registry, prefetch, event logs, and Internet Explorer history entries.






References

Exploit Information


Metasploit Exploit Information http://www.metasploit.com/modules/exploit/multi/browser/java_signed_applet