BSides Augusta Slides

Posted on

Had a great time at Bsides Augusta 2016. Heres my slide deck ir-awakens.


Keeping IR Focused

Posted on

I’m handler of the day at the ISC. I’ve got a write-up on how to keep your  IR team focused on what matters by having a chart to map where to get the best data for what they are looking for.

522 Error Code for the Win

Posted on Updated on

I’m ISC Handler for the day stop by the site and see my latest post about using HTTP error code 522 to detect infected machines.

EMET and IE 0 day ie_execcommand_uaf

Posted on Updated on

Update: Microsoft has issued a “Fix it” for this issue. A offical patch should be in place tomorrow 21-Sept-2012.

A new IE zero-day is out and is available from Metasploit.  I needed to find out if EMET would protect against this. My two platforms I tested on were Windows 7 (Full patched) and Windows XP SP3 (fresh install) with IE 7.  I tested EMET 3.0 and EMET 2.1 to make sure that both versions prevented the exploit.

The Metasploit exploit worked flawlessly on Windows 7. I then enabled EMET and added the IE executable to the protected programs.  With both versions of EMET  prevented the exploit. The odd thing is that EMET 3.0 is suppose to generate a pop-up and create an event log when it catches an exploit. It did not notify me during any of my tests. On Windows XP SP3 with IE 7, as expected, the exploit worked when EMET was not configured. Once setup to protect IE, the exploit failed to run.

While having individual users at home switch to another browser (e.g. Chrome) make sense, for large cooperate environments deploying EMET will give you a stop gap for many of the exploits that we see.

Flashback Mac Malware Analysis and Removal

Posted on Updated on

Flashback is Mac malware that has recently been showing up with a vengeance. The latest version .K is exploiting a newly patched java vulnerability on OS X.  F-secure recently posted about detecting and removing it from a system. In this post, I’ll cover some addition artifacts found on an infected machine and include a script to remove it.


When responding to an infected system, I noticed that in the /var/log/secure.log it included a couple of indicators of infection. The indicators below may help you detect infected users if you are using syslog for your OS X devices. Seeing a “/bin/sh” followed by the “suppressing keychain prompt” within a couple of minutes of each other that has been a solid indicator in the log. When looking through the systems, the suppressing keychain prompt did not show up in a years worth of logs until after it was infected.

Mar 31 14:17:32 K-MacBook-Pro[24]: UID 501 authenticated as user k (UID 501) for right ‘system.privilege.admin’ Mar 31 14:17:32 K-MacBook-Pro[24]: Succeeded authorizing right ‘system.privilege.admin’ by client ‘/private/tmp/Software Update’ for authorization created by ‘/private/tmp/Software Update’
Mar 31 14:17:32 K-MacBook-Pro[24]: Succeeded authorizing right ‘system.privilege.admin’ by client ‘/usr/libexec/security_authtrampoline’ for authorization created by ‘/private/tmp/Software Update’
Mar 31 14:17:32 K-MacBook-Pro authexec[318]: executing /bin/sh
Mar 31 14:19:55 K-MacBook[25]: suppressing keychain prompt for invalidly signed client /Applications/

Mac Times

I also collected file system MAC times on the infected machine.  You can see the malware being created .QUICKHEALXGEN.png and .QUICKHEALXGEN.xsl. Additionally you see chmod and mv accessed. This matches up with F-secure analysis.

2012 Mar 31 Sat 14:17:32
102 m.c. drwxr-xr-x 0  0  0  /Applications/
374 m.c. drwxr-xr-x 0  0 0  /Applications/
4643 m.c. -rw-rw-rw- 501 20  0 /Applications/
20400 m.c. drwxr-xr-x 0 0   0  /Applications/
403744 m… -rwxrwxrwx 501 0 0 /Applications/ .QUICKHEALXGEN.png
26168 m… -rwxrwxrwx 501 0 0 /Applications/
62656 .a.. -r-xr-xr-x 0 0 0 /bin/chmod
44848 .a.. -r-xr-xr-x 0 0   0  /bin/mv

Virus Total

Submitting the malware to virus total had poor results with only 8 out of 42 detecting it as of April 4th.

Cleaning Script

This script has several components: It checks for both types of infections discussed by F-Secure,  backups a copy of the two plist files and names them .infected, prompts user if they want to clean the infection and also prompts the user to disable java in Safari. While I have tested this script on the cleanup of the Safari Info.plist, I have not seen an infection of the environment.plist. The cleanup should work, but  please test it before you use it. I will not be held liable for any problems. 

I have built in a simple update function that will check for a new version using the -u switch at the command line. If a new outbreak happens, I’ll try and keep it updated. You can submit bug fixes to the blog or to the email address in the script.

To run the program, unzip the download below and double click on the flashback-detect.command file. It will prompt you for your password and check to see if your infected.  You can also run it from terminal using the

Get the script HERE.

When Procedures Fail

Posted on Updated on

During a recent response call, I had the perfect storm of failure. It started on Friday afternoon when we got a notice about a potential compromise on a low value system. Normally, on these systems we just hand the information off to the system admin, but we wanted to verify some information. I was armed with my trusted IR tools. Once on the system, the first thing I noticed was that the server was three major OS versions behind and running a non-X86 platform. Hmmm this is going to be interesting….

I ran my live IR script and had a massive failure on every command. I switched to my trusty version of F-response to collect MAC times on the system. F-response also failed to run on the server. Fortunately the system had GCC on it and I pulled down the source-code for mac-robber. I did not have access to another server with this OS version and architecture combination, so I had to compile the binary on server.Make failed! Thankfully, in the install.txt, it references if make does fail try make -simple.  That worked, the first good news and now I was able to collect file times on the server.

Making changes to systems you are responding to is not a deal breaker, but you need to make sure that you document everything that you do and include the reason why.The rest of the volatile information was gathered by running the built-in binaries on the server. While using this method has its issues, it’s best to collect volatile data any way you can before the system is taken offline.

Lessons Learned

  • No matter how well tested your documentation is, be ready for hiccups.
    • This procedure had been tested many times on incidents, but never had all our contingencies failed when trying to collect data.
  • It’s critical in these instances that you have experienced team members that understand the systems they are responding to.
  • Compiling source code on a server you are responding is never a great option, but you should include source-code of critical tools to your response toolkit in case you need it.

Live IR CDROM Basic Needs

Posted on Updated on

Preparation, in my opinion, is the most important phase of incident response.  When possible you should have well test procedures for all major tasks you preform, especially when it comes to how you collect your data. In many situations, you will get only one chance to gather the information and you need make it count. These procedures should be review on a quarterly bases, so setup a reoccurring calendar appointment to get that done today.

Having a IR CDROM with all your collection tools is critical to having a great start to a incident.  I’ve previously talked about a couple freely available ones, but now I’m we are going to cover what the basic requirements that need to be met when creating your own. Why create your own CDROM? The simple answer is control. Creating your own script allows you to do what you want to do, when and how you want to do it.  Additionally, you want to make sure the trusted binaries are really trusted. Installing and verifying them yourself is the best way to make sure you can trust them.

One of the hardest questions to answer when first trying to get started is, what do you need to collect from a compromised host? It depends on your policy and questions you want to answers from the investigation, but here is a list of some of the most common things to collect and analyze from a live host:

-RAM dump
-Processes lists ( process id, user running, parent process, path of executable)
-Network stats (listening process, established connections, PID)
-List of open files
-Modify,Access,Creation times (mac)
-System logs (logs for services running, authentication and authorization)
-Internet history
-Registry/system config
-Virus logs
-Schedule’s tasks and start-up items

You could run these tools manually, but this leads to inconsistent data collection. The most effective way to collect this data is using an automated script. Scripts are a great way to help reduce documentation for collecting the evidence and make data collection consistent.The data should be collected using trusted binaries, which are ran from an external source. It’s best to rename the trusted file to distinguish the difference between versions that may already be running on the system ( e.g. ls to ir_ls). The script  and tools should be ran from a write protected USB or CDROM where the result are dumped to another system (smb or cryptcat) or an external drive.

Lessons learned is generally the step most people do not to complete. Many time you may have overlapping incidents with little time to document things that went right and wrong.  This step is important to make sure that you improve on your experience, and prevent the same mistake from happening more than once.  If you do not have a formal meeting, it’s good to keep a to-do list of things that need to be added to your collection script, new tools and process adjustments. Keep it as an ongoing list and when you start your quarterly review of processes you’ll have an action list.