“Offline Autoruns Revisited – Auditing Malware Persistence”

I was digging through the archives recently and stumbled upon my old post, Autoruns and Dead Computer Forensics. Autoruns is an indispensable tool from Sysinternals that extracts data from hundreds of potential auto-start extensibility points (ASEPs), a fancy Microsoft term for locations that can grant persistence to malicious code. We leverage live Autoruns collection in the SANS FOR508 course to scale our efforts at identifying common malware persistence across the enterprise. If I have Autoruns output for a system, it is one of the first data sources I review since finding persistence leads to many quick wins. But what if a system of interest has already been taken offline? Technically the Autoruns tool has an offline capability, but in my previous testing it left a lot to be desired. I decided to revaluate this testing and bring my previous recommendations up-to-date. My testing used Autoruns version 13.94 and Arsenal Image Mounter version 2.0.010 on Windows 10.

The Good

The good news is that offline Autoruns performance has markedly improved. I attribute at least part of the improvement to better forensic image mounting tools. Offline Autoruns was designed to query a complete Windows file system attached to a running instance of Windows. The “-z” option allows an external file system root (Windows folder) and user profile to be specified. This feature was designed for analyzing systems containing a potential rootkit (where you don’t want the system to be running), or analyzing damaged file systems that cannot boot. However, it also nicely fits the digital forensics use case of needing to analyze ASEPs from a disk image.

OfflineAutorunsExample

Autoruns requires read-write access to the filesystem and registry hives. Our forensic image mounting capabilities have great improved since my last post on this topic. Arsenal Image Mounter provides a free capability to mount forensic images using a high-performance, low-level Storport driver. It also allows images to be safely mounted read/write, providing the data source that Autoruns expects. Thus, we can logically mount our forensic images to a drive letter, and use the offline feature of Autoruns to collect a vast amount of ASEP data.

ArsenalImageMounter_WriteTemporary

In my testing, using Autoruns with Arsenal Image Mounter solved previous issues with failures and partial data collection. I was also able to use autorunsc.exe, the command-line version of the tool, and the go-to version for incident response collection and analysis. I had success getting offline Autoruns data collected from a variety of different images and Windows OS versions, Windows 7 — Windows 10 (x86 and x64). I was also able to successfully retrieve ASEP data from user NTUSER.dat hives.

The Bad

A frustrating limitation I found with using Autoruns in offline mode was the need to reboot after every execution. This could be a problem introduced by my testing environment, but it remained across different test systems, mounting tools, and forensic images. Once Autoruns is executed against one system root and user profile, it will not parse a different image or even a different profile in the same image. A reboot is the only mitigation I found to get Autoruns to successfully switch context.

Offline Autoruns also only provides the capability to pull ASEP information from one user profile. This seems like a silly limitation given that we are pointing it to a complete disk image, and it contrasts with the live version of the autorunsc.exe, which collects from every user profile. This limitation is particularly painful when paired with the need to reboot after each offline use of the tool, eliminating the ability to script the tool to run against every user profile.

The Ugly

The biggest disappointment with Autoruns in offline mode is how few digital signatures it is able to verify. In my testing, only about ten percent of digitally signed files referenced from ASEP locations were identified as signed. Windows 64-bit operating systems have a high percentage of digitally signed system files including drivers and most of the contents of the System32 folder. The ability to perform data reduction via digital signatures from trusted providers (i.e. Microsoft) is arguably the most important feature of the tool. An analyst can’t feasibly review thousands of persistence entries for every system. Sadly, this issue has its roots in the fact that there are two primary ways files are signed in Windows. Authenticode signatures are part of the file itself, and these are the signatures that offline Autoruns will successfully verify. Unfortunately, a vast number of signed files in Windows use the more efficient catalog signing, and offline Autoruns will not verify these signatures. To give a measure of scale, approximately 80% of the files in the WindowsSystem32 directory are catalog signed. This topic deserves its own article, but as an example, note the use below of the Sysinternals tool Sigcheck to verify the signature of the well-known executable, rdpclip.exe.

Sigcheck_Catalog_Files

The offline version of Autoruns also only parses registry-based ASEP data. It misses important persistence mechanisms like scheduled tasks and WMI event consumers, which the live version of the tool easily handles. Of the hundreds of ASEPs handled by the tool, I rank scheduled tasks and WMI event consumers in the top ten I care about. While these sources can be collected and parsed with other tools, it is a significant data omission in the offline version of Autoruns.

A final limitation I encountered since my last testing of the tool was the expectation of Autoruns to run against a full file system (or disk image in our case). I seem to work with far more triage data these days than full disk images, and given that Autoruns only appears to be querying registry data in offline mode, the requirement seems like overkill. An ideal solution would be the ability to point Autoruns to an arbitrary folder and have it search recursively for the files it needs, including system registry hives and user hives from multiple profiles, should they exist. In my next post, I’ll propose an alternative tool that can accomplish this use case.

Conclusion

Autoruns is an incredibly useful tool and a cornerstone of a Windows incident response toolkit. Few tools bring such a diverse and useful set of information together for the analyst. However, it is best used for live system collection. In offline mode, it has significant limitations. While the data reported appeared accurate, multiple data sources were missing, including catalog signed digital signature verification, data resident in additional user profiles, and non-registry-based ASEPs.

Chad Tilbury, GCFA, has spent over twenty years conducting computer crime investigations ranging from hacking to espionage to multi-million dollar fraud cases. He is a senior instructor and co-author of FOR500 Windows Forensic Analysis and FOR508 Advanced Incident Response, Threat Hunting, and Digital Forensics at the SANS Institute. Find him on Twitter @chadtilbury.

 



*** This is a Security Bloggers Network syndicated blog from SANS Digital Forensics and Incident Response Blog authored by Chad Tilbury. Read the original post at: http://feedproxy.google.com/~r/SANSForensics/~3/tUWiz_XRlnk/offline-autoruns-revisited