Tracking Down Persistence Mechanisms
Thursday, March 28, 2013
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.
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.
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.
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.
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 ***
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 ***
Posts
Nice post. I have used the include empty location option many times and blogged about this a few years back on the SANS Forensics Blog.
A new version of Autoruns was released yesterday. It now includes last modification time for the given asep.
Thanks Dave. I came across one of your posts on the SANs blog. The one where you provided the text files with all the auto-run locations. I was looking for something similiar but from a newer version of Autoruns program. That was when Troy and Adam gave me the pointer. Thanks for the tip about the new Autorun version release.
For anyone else who wants to see a cool way to use Autoruns. Check out Dave's posts; especially this one: http://trustedsignal.blogspot.com/2012/02/finding-evil-automating-autoruns.html
How did this compare with the list in the Sysinternals book (Chapter 5)?
http://technet.microsoft.com/en-us/sysinternals/hh290819
@Richard,
I don't own the Sysinternals book so I can't make any comparison. However, I did use the Autoruns utility so my guess is my locations will be reflected in that chapter. How many I couldnt guess since I reduced my list for the low hanging fruit