Latest Event Updates
Sometimes as an incident responder we get called on to analyze a system that has already been “looked at” by another admin or desktop support personnel. Most of the time, I tell them the evidence has been trampled on by different malware scanning software and just re-image the system. But, sometime you may need to do analysis on the system.
In this instance, a number of different malware products had been ran, along with clearing temp files and Internet cache, but the system was still showing signs of infection. After building a timeline , I was able to determine that the initial infection vector had been deleted and the malware hosting site had been pulled off-line. The system had a nasty rootkit that was injecting code into a couple of processes. I didn’t have time to run it through ollydbg or Ida Pro.
I needed a quick way of determine the capabilities of the malware, so I decided to boot a copy of the original dd image using vmware and then do behavioral analysis on the system. I could have used software such as Live View, but I wasn’t sure how well it worked with Linux as my host OS. Harlan Carvey did a great post in 2007 about booting a dd image using vmware, I wanted to turn that idea into a procedure.
- Make sure you are using a backup copy of the dd image, as this will make changes to the image file.
- Launch Prodiscover Basic
a. Select ->Image convert tools -> Vmware support for DD Images
- Select the dd file
- In the same folder as the dd file it will create a .vmdk file.
5.Create a new virtual machine. Use the wizard and select typical machine, install OS later and Guest OS and take default setting on all the rest.
6.Select VM Settings. Under VMware 7.0 choose the Vm Menu ->Setting
7.Remove the default hard drive
8. Select add-> hard disk then next
9.Select use existing virtual disk. Browse to the new vmdk file created.
10. Boot the VM.
11. Use the process described in a previous post to determine what the malware is doing. Make sure that you use the applications that you are worried about the malware interacting with. For example, if you are worried about a web-based credential stealing malware, try logging into site like E-bay, Citibank and maybe a custom app from your company. Make sure you are using fake credentials if you do not want to potentially leak real ones.
Dark reading just recently had a post on a Java based command line tool to for doing this. I have yet to use it, but it may be worth checking out.
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:
-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)
-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.
Lately I’ve been running into malware that doesn’t play nicely with analysis websites like CWsandbox or Norman. I needed to find indicators of infection for a mariposa variant and both sites would not analyze it. It appears that it needs the presence of both the .exe and its specially crafted desktop.ini before it will execute. Since you can only submit one file to these websites, I needed to do the analysis on my own. When doing this type of analysis, we are just looking at the changes it made to the system and not specifically determining the capabilities of the software.
The first thing you need to do is make sure you have a system that mirrors your environment, this is easier if you have a standard desktop build. When possible I try to use VMWare for my analysis machine. Depending on the malware, this may not work. I’ve had good results with uninstalling VMware tools and not having malware detect it running in a VM. One of the easier ways for malware to detect a VM environment is checking for VMware tools/ drivers. This may also help prevent a VMware exploit as many of these exploits use the Vmware tools to accomplish this.
Once you have removed VMware tools, you will want to install any tool that you will use for analysis. I’m going to cover Process monitor today as its quick and easy for what I was trying to do. Once your tools are installed, take a snapshot of the system. If you are going to let your malware actually connect to the Internet to pull down secondary tools, it’s a good idea to use TOR or better yet use a different internet pipe rather than your corporate network. You could also use a sandnet like TRUMAN, but that is out of scope for this post.
Capturing network traffic can also be useful in tracking down infections. Process Monitor also keeps track of network connections, but I like to do this on the host rather than the guest for a couple of reasons:
- Prevents malware detecting the network card in promiscuous mode.
- Smaller foot print on machine.
1. Start your network packet capture tool. I like to set the capture interface to the guest virtual NIC, but on most system the primary interface will capture all the traffic.
tcpdump -nni eth1 host 192.168.1.1 -w infection.pcap
-nn (tells tcpdump not to convert to names )
eth1 (is the interface I want to capture traffic from)
host 192.168.1.1 (capture all traffic from VM ip address)
-w switch says write to file
2. Start Process Monitor
It will automatically start collecting data.
3. Run Malware
Depending on the malware, it will have multiple stages that may take a while for the infection to be completed.
4. Stop tcpdump and Process Monitor (3rd button from Left or CTRL+E). Disable the Network Card from the VM or Pull the network cable.
We want to setup display filters to determine what files and registry keys were created.
Click on the filter button. (Or Ctrl + L)
The top row has a bunch of drop-down menus that allows you to select what you want to filter.
Select Operation from the first Column.
Select each of the keys individually below and click add. Additionally, you can export the data into csv format and do filtering using a spreadsheet.
(UPDATE) Addition filters to add based on this post.setbasicinformation setdispositioninformationfile regdeletekey regdeletevalue regcreatekey
To get a better look at what processes the malware spawned you can add these to the filter:
Partial list of files that were written during infection by this version of mariposia.
Partial list of registry keys that were written during infection by this version of mariposia.
When trying to find indicators of infection, you generally want to look for ways the malware stays persistent on the machine. This malware variant adds an executable file in the recycle bin to start-up at winlogin.
You may need to infect your VM a couple of times to get enough information about how it’s randomizing its name. Now you can take this info and add it to a HIPS like OSSEC or a script to query all your computers in a domain.
For /f %i in (filename with computer to search.txt) do Reg query “\\%i\hklm\software\microsoft\Windows NT\CurrentVersion\winlogon” /v taskman >winlogonreg.txt
Then you can search the results file (winlogon.txt) for any computer that has Recycler in it, as no valid item should start from recycler when you log into the system.
Once analysis is completed, be sure to revert your VM back to the snapshot before the infection.
With the pcap file you created, you’ll want to analyze it using wireshark or tcpdump. There are a couple of quick things you will want to look for:
- DNS lookups (This will allow you to search your DNS logs for anyone querying the same DNS records as your infected VM).
- Data exfiltration traffic (Most malware these days send information it collects back to some type of command or data collection server.).
- Track down infected hosts using flows or firewall logs based on identified traffic.
- If you are comfortable with writing IDS rules, writing rules for this traffic will also help pick-up future infections once the other server are taken offline.
This will be a multi-part post that will cover the windows live response portion of DEFT and CAIN, then move onto the boot-able Linux OS and finally how to create your own live CDROM.
DEFT V.4 (Extra)
- Easy to use and move around
- Icons are large
- Tab flows and categories are appropriate
- FTK Imager 18.104.22.168
- Ram Dumping
- Winen 6.11.2 (32 and 64-bit)
- MDD 1.3
- win32dd v1.1.20080818
- Collecting/Analyzing system information
- Password Recovery
- IE,Firefox,Crome,Mail and Wireless
- Web Browser History
- FileAlyzer (good for malware)
- File Browser
- Picture Scanner
- Notable Utilities
- PC On/off time
- Built-in file and picture browser.
Initial Memory Footprint~ 40K
- Lots of different tools that offer a lot of flexibility.
- Gui designs works well.
- The most popular memory imaging tools including Winen 64-bit.
- It has the zeroview utility, which allows responder to tell if whole disk encryption is used.
- WFT was expired and the tools directory needed did not exist on the CDROM.
- Some utilities are not in English.
- No automated collection of running information.
Overall this is a great live CDROM. The only downfall is that WFT was expired and no other automated collection was available on the CDROM.
Note: This was tested on a Vista 64-bit PC.
Make sure when you do live response, you understand what changes the utilities makes to the system. In future post, I’ll talk about strategies on how to reduce changes to the system.