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

  • 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...
  • 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...
  • 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...
  • Digital Forensics Meets Forensic Auditing
    One of my employer’s responsibilities is to ensure taxpayers’ dollars are used “effectively and efficiently”. To accomplish this there are n...
  • 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 ...
  • Broken Chain
    The examination of the Infected 2 system didn't complete one of the initial examination steps which was examining the executables of in...
  • CVE 2010-1885 (Windows Help Center URL Validation Vulnerability) Exploit Artifacts
    Artifact Name CVE 2010-1885 (Windows Help Center URL Validation Vulnerability) Exploit Artifacts Attack Vector Category Exploit Description ...
  • 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...
  • Metasploit The Penetration Testers Guide Book Review
    A penetration test is a method to locate weaknesses in an organization’s network by simulating how an attacker may circumvent the security c...
  • Ripping Volume Shadow Copies Sneak Peek
    I was hesitant to do a sneak peak about a different approach to examine Volume Shadow Copies (VSCs). I personally don’t like sneak peeks and...

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