Download Autoruns Portable
Narkis Eatman
Just an FYI that the How-To Geek site has a 10-part series Using Sysinternal Tools Like a Pro by Lowell Heddings that includes lots of helpful hints for using Autoruns, Process Explorer, Process Monitor, and other Sysinternal tools. Lesson # 6 in that series is Using Autoruns to Deal with Startup Processes and Malware.
And NEVER mess with anything in the Windows folder, unless you really know what you are doing, and can recover your PC. I once rendered my system un-bootable by going there. You can use the options to hide Windows and Microsoft entries from view.
Oh and ANOTHER question! I use VT all the time for URLs and files. But how do I search on a process? e.g. c\windows\syswow64\wow64cpu.dll? How do I do the search that autoruns does when it is working? This one is pink in autoruns.
For example, Nvidia used to add a ton of telemetry processes, some of which could be useful for gamers but for general use just got in the way and compromise privacy; autoruns was useful for disabling them.
Always create a fresh drive image before making system changes/Windows updates; you may need to start over!We all have our own reasons for doing the things that we do with our systems; we don't need anyone's approval, and we don't all have to do the same things. We were all once "Average Users".Computer Specs
Autoruns shows me 20-odd entries under Task Scheduler for Windows Media Center, in yellow for File Not Found. This is likely because my Win 10 PC was upgraded from Win 7, and MS dropped WMC in Win 10.
To get you started, try pressing Ctrl+Alt+Delete to bring up Task Manager. Click on the Start-up tab. AFAIK these are all non-MS start-ups so should be non-essential BUT some manufacturers may have necessary utilities. Be cautious doing the following
Autoruns is a tool that is part of the Microsoft Sysinternals suite. It comes in permutations of console/GUI and 32/64 bit versions. Its main purpose is to detect programs, scripts, and other items that run either periodically or at login. It's a fantastic tool for blue teams to find persistent execution, but it is not perfect! By default, autoruns hides entries that are considered "Windows" entries (Options menu -> Hide Windows Entries). There is a checkbox to unhide them, but it introduces a lot of noise. In my preparations to red team for the Information Security Talent Search (ISTS) at RIT and the Mid-Atlantic Collegiate Cyber Defense Comptition (MACCDC) this year I found a few ways to hide myself among the Windows entries reported in Autoruns.
This one is as easy as copying powershell or cmd to another name and using that name instead. It looks like autoruns will flag by name on powershell and cmd as shown below:
This entry in the infamous run key is running powershell to use Net.Webclient to download and execute a string (DownloadString -> IEX).
Clearly malicious! So now let's try copying powershell.exe to badstuff.exe:
Then we need to edit the registry key to use our copied executable:
Now looking at autoruns it appears clean
Showing windows entries reveals the entry, but this time it is not highlighted red. Autoruns doesn't know what it is, only that it is in system32 and signed by Microsoft.
The Image File Execution Options (IFEO) registry key located at HKLM:\SOFTWARE\Microsoft\Windows NT\CurrrentVersion\Image File Execution Options is used to set a myriad of options such as heap options and setting a program's debugger. For this bypass to work we can pick a lesser-used executable in System32 and set its Debugger in IFEO to cmd.exe or powershell.exe. I chose print.exe for this test, but there may be better options.
The technique involves creating a key under the parent IFEO and adding a REG_SZ value with the executable to execute.
Then we need to edit our run key to use print.exe instead of powershell.exe. Checking back with autoruns the entry is gone!
And again unhiding windows entries results in the entry being shown, but this time we have the added bonus of not appearing as powershell in the description!
A tool is really only as good as the algorithms it uses. Autoruns is no exception. It doesn't go deep enough to figure out what binary is actually executing or if that binary is something that it would normally flag with its original name. Always be skeptical of your tools and know they might not be perfect!
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 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.
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.
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 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 \Windows\System32 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.
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.
c80f0f1006