Anti Virus Scan

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Thursday, 28 March 2013

Tracking Down Persistence Mechanisms

Posted on 19:31 by Unknown
On my to-do list for quite some time has been tracking down the various locations in the registry that malware and attackers use to remain persistent on a system. Typically, one of my initial examination steps when confronted with malware is to review the various auto-run locations. The way I approached this step works but it isn’t as efficient as I want it to be. I do most of my registry analysis with RegRipper and it even extracts numerous auto-run locations. However, when I’m looking at persistence mechanisms I go with the Microsoft Autoruns utility since it is the best tool out there for extracting auto-runs from a system. This is where the inefficiently comes into play. I’m using two tools to extract registry auto-run locations. With the Autoruns utility, I’m forced to do additional work since it only works against mounted drives (or images). What I want is to solely use RegRipper to perform this task since it can extract this information in seconds. To do so, I had to track down the various persistence mechanisms to see what, if anything had to be added to RegRipper. This post shows what and how I went about this.

What Locations are Checked By Autoruns


To track down the registry persistence mechanisms I first needed an authoritative resource on the various locations. The Autoruns utility is the best tool for reviewing auto-runs locations since it is constantly updated. The locations checked by the tool would be one of the most authoritative resources on the subject. I reached out to the Win4n6 group to see if anyone knew of a site that outlines the different places the tool checks. Both Troy Larson and Adam said the tool itself can be used to determine this. I picked my platform – Windows 7 64-bit – to get the best coverage of artifacts and followed their guidance. I ran Autoruns (v11.4) against my system. After it completed I selected Options from the menu then Filter Options on the drop down. In the Autoruns Filter Options window: checked the box next to Include empty locations and deselected Hide Windows entries followed by clicking OK.


The end result is the most comprehensive listing of auto-start locations. More extensive then I have ever seen in books, presentations, trainings, and other tools. You may have read Harlan’s post Wow6432Node: Registry Redirection or my post Houston We’ve Had a Problem – Wow64 about the impact Wow64 has on where to look for persistence mechanisms. Well, there are numerous auto-run locations redirected due to Wow64 and this is a topic that is discussed very little in Digital Forensics and Incident Response. To see what I mean run Autoruns against a 64-bit system and you will see all the different Wow64 entries that are being missed by our processes, tools, and literature.

What To Do with these Autorun Locations


Obtaining a comprehensive list of the various persistence mechanisms was only the first step. My idea wasn’t to see every auto-run location added to RegRipper. This would require a lot of work; work done by myself or someone else volunteering their time. The more effective approach is to determine which persistence mechanisms are actually being used by malware. This is what Elizabeth Schweinsberg did when she scraped an antivirus website to determine the most common persistence mechanisms. Similar concept but different approach. I started with the most comprehensive listing of auto-run locations (Autoruns output from my 64-bit system). Then I researched every registry key and values to determine which ones were actually used by malware. I leveraged the Malware Analysis Search since it indexes numerous sites related to malware such as antivirus sites and online sandboxes. Basically, I went through hundreds of auto-start locations and selected the locations based on how many hits I got. Only a few hits wasn’t worth the effort to create test data and write a RegRipper plug-in. It took numerous hits (at least two pages worth) to make it worth the while; for it to be considered as Harlan says low hanging fruit.

Side note: I didn’t apply the search hit count to the Wow64 folder redirection locations. I barely got any hits for these locations. This shows how antivirus sites and online sandboxes are not accounting for all the artifacts created by malware.

Extending RegRipper


For the past few months I have been focused on RegRipper; specifically on the plug-ins. As a result, I know fairly well what every plug-in in the RegRipper archive does, what it checks, and which ones fall into the auto-runs category. I proceeded to review every RegRipper auto-run plug-in against my list of persistence mechanisms. What I found out was pretty cool? Excluding the Wow64 folder redirection keys/values, RegRipper already accounted for the majority of the persistence mechanisms I noted. However, I did identify what new plug-ins was needed and which ones needed to be updated.

My last step in journey to track down persistence mechanisms was to reach out to Harlan for a few reasons. First if I have any questions about Windows forensics especially with the registry then he is at the top of my list. The other reason is because he is the author of RegRipper and I felt letting him know what I was trying to do was the right thing to do. His reaction caught me by surprise after I sent him all my documentation and notes. He was willing to start writing the new plug-ins and updating the existing ones. Really cool and to me this showed his passion for our field. His willingness to help me out with about 20 different plug-ins. As he mentioned, RegRipper is being updated. Actually, he is doing all the updating and I’m just trying to give him any support I can.

In Closing


Out of my desire to work more effectively I set out to track down the various persistence mechanisms to see what needed to be added to RegRipper. I found out about the most comprehensive reference available for auto-run locations with the help of others. I saw firsthand the impact Wow64 has on our processes and tools as well as antivirus websites and online sandboxes since it’s not accounted for. I learned about the various persistence mechanisms, what they do, and more importantly if malware is actually using them. I created a nice reference for myself so I’m more aware about what to take into consideration on future casework. As a result of Harlan’s effort, RegRipper is getting updated and there will be a better tool available. The end result, going forward I will work faster and smarter since I took the time to track down the most common persistence mechanisms. Another item knocked off my to-do list and now my focus moves to the next issue...


*** Update ***

The locations identified in this post has been documented on the ASEPs RegRipper Wiki page. The page outlines all the auto-run plug-ins and the locations they check.

*** Update ***
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest
Posted in autorun, malware, regripper | No comments
Newer Post Older Post Home

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • Ripping VSCs – Developer Method
    For the past couple of weeks I’ve been talking about the Ripping VSCs approach to examining Volume Shadow Copies (VSCs). I started using the...
  • Linkz 4 Free Infosec and IT Training
    In this day and age budgets are shrinking, training funds are dwindling, and the threats we face continue to increase each day. It's not...
  • Dual Purpose Volatile Data Collection Script
    When responding to a potential security incident a capability is needed to quickly triage the system to see what's going on. Is a rogue ...
  • Finding the Initial Infection Vector
    There are different ways to spread malware. Email, instant messaging, removable media, or websites are just a few options leveraged to infec...
  • Man versus AntiVirus Scanner
    Knowing what programs ran on a system can answer numerous questions about what occurred. What was being used to communicate, what browsers a...
  • Re-Introducing $UsnJrnl
    The NTFS change journal ($UsnJrnl) is not a new artifact and has been discussed before by others. The file's importance may have been ov...
  • You Are Not Admin with UAC
    There is a tendency to focus on what is different when we are faced with newer operating systems. What are the security changes and how does...
  • Building Timelines – Tools Usage
    Tools are defined as anything that can be used to accomplish a task or purpose. For a tool to be effective some thought has to go into how t...
  • Houston We’ve Had a Problem – Wow64
    This is a piggyback post to an issue Harlan has been raising about the Wow64 issue. His most recent post on the subject Wow64Node: Registry ...
  • Microsoft Word Jump List Tidbit
    Performing examinations on the Windows 7 (and possibly 8) operating systems is going to become the norm. In anticipation of this occurring, ...

Categories

  • adobe
  • advice
  • antivirus
  • attack vectors
  • autoplay
  • autorun
  • book review
  • categories
  • chain of evidence
  • conferences
  • delivery artifacts
  • detection
  • digital forensics search
  • drive-by
  • education
  • EEDI
  • email
  • encase
  • examination steps
  • exploits
  • feedreader
  • fraud
  • Google
  • hcp
  • investigation process
  • java
  • jumplists
  • kinect
  • links
  • malvertizing
  • malware
  • malware analysis
  • memory analysis
  • metadata
  • microsoft office
  • NTFS
  • perl
  • pfic
  • prefetch
  • program execution
  • readiness
  • registry
  • regripper
  • scams
  • script
  • search poisoning
  • sharing
  • shortcut files
  • spam
  • testing
  • timeline
  • timestomping
  • tools
  • tr3secure
  • training
  • triage
  • uac
  • volume shadow copies
  • xbox

Blog Archive

  • ▼  2013 (20)
    • ►  November (1)
    • ►  October (2)
    • ►  September (4)
    • ►  July (2)
    • ►  May (3)
    • ►  April (2)
    • ▼  March (3)
      • Tracking Down Persistence Mechanisms
      • Houston We’ve Had a Problem – Wow64
      • UAC Impact on Malware
    • ►  February (1)
    • ►  January (2)
  • ►  2012 (38)
    • ►  December (3)
    • ►  November (3)
    • ►  October (3)
    • ►  September (1)
    • ►  August (3)
    • ►  July (3)
    • ►  June (3)
    • ►  May (3)
    • ►  April (3)
    • ►  March (5)
    • ►  February (6)
    • ►  January (2)
  • ►  2011 (41)
    • ►  December (4)
    • ►  November (3)
    • ►  October (3)
    • ►  September (4)
    • ►  August (4)
    • ►  July (3)
    • ►  June (5)
    • ►  May (3)
    • ►  April (3)
    • ►  March (3)
    • ►  February (2)
    • ►  January (4)
  • ►  2010 (17)
    • ►  December (2)
    • ►  November (3)
    • ►  October (3)
    • ►  September (3)
    • ►  August (6)
Powered by Blogger.

About Me

Unknown
View my complete profile