Detection And Defense Of Windows Autorun Locations

As an incident responder and forensic investigator, there's a truth we expect malware to always follow: Persistence is a must to survive. OK, exceptions exist. But the general rule of thumb is that malware seeks to persist, and it will hook itself into common areas on a victim Windows machine to do so.One of the first places we look is the common "autorun" locations, or areas in the file system and Windows Registry that cause processes and services to run when Windows boots. If you remember the old "msconfig" utility, it's an example of one of the tools that allowed you to see what was enabled to start within the Startup folder, autorun.exe, config.sys, and other files. There was also Windows Services MMC and Regedit, which helped determine what was starting up at boot time.

Those tools were OK in a pinch, but they gave a limited view. Autoruns by Microsoft Sysinternals quickly supplanted all of them by providing much more insight into what was really starting when a Windows computer boots up. It's extremely comprehensive. Take a look at the following list, published at Immutable Security, of the different locations from which Autoruns draws its startup information.

It's an incredible list for responders -- and attackers who are trying to get their malware or backdoor installed during a penetration test. In addition, don't miss the recent blog from Nick Harbour at Mandiant about hijacking the search order of DLLs when they're loaded -- wicked research, Nick. After a quick read, it seems almost stupidly simple and makes you wonder why it hasn't been discussed at length before.

That all begs the question: What about defense and detection of things taking advantage of these common startup locations? We know there are numerous but limited numbers of places to search -- even though running Nick's free "finddllhijack.exe" tool will make you think otherwise. Autoruns definitely give a good start with the list linked above and little tricks to narrow down our search, like hiding Microsoft entries, verifying certificate signatures, and detailed metadata for each entry.

Monitoring all of these location should also be implemented and alerts sent whenever a file or Registry entry is written to or modified in any of these locations. OSSEC HIDS can serve that purpose nicely -- it's free and open source.

Determining which DLLs can be hijacked is another good place to start with detection, but doing so could prove to be as easy as finding a needle in a haystack when you can easily have 1,000-plus hijackable DLLs. DLLs loaded on a running system could be compared to the ones loaded on a "gold image" to find discrepancies that might indicate hijacking. My guess is now that this method of persistence is being talked about in the community, new tools will be popping up soon.

Defense can, and should, be approached with a few different methods. For one, detection through monitoring, as mentioned above, is very important. Preventing those areas from being written to is just as important as monitoring any attempts to modify or write to them. Windows provides its own mechanisms to prevent modifications to certain areas if you're not an administrator, but if you are an admin, it's basically "game over."

Application whitelisting is another area of defense that might help because it has the potential to prevent unknown DLLs from being loaded, but I haven't tested this to be sure...it's a good question to ask your friendly application whitelisting vendor.

I feel like a G.I. Joe public service announcement, but, truly, knowing is half the battle. My twist is, having the budget is the other half. Arm yourself with the knowledge of where these things are so you can fight them better.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.