Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

7/19/2010
03:05 PM
John H. Sawyer
John H. Sawyer
Commentary
50%
50%

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.

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.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-12512
PUBLISHED: 2021-01-22
Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to an authenticated reflected POST Cross-Site Scripting
CVE-2020-12513
PUBLISHED: 2021-01-22
Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to an authenticated blind OS Command Injection.
CVE-2020-12514
PUBLISHED: 2021-01-22
Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to a NULL Pointer Dereference that leads to a DoS in discoveryd
CVE-2020-12525
PUBLISHED: 2021-01-22
M&M Software fdtCONTAINER Component in versions below 3.5.20304.x and between 3.6 and 3.6.20304.x is vulnerable to deserialization of untrusted data in its project storage.
CVE-2020-12511
PUBLISHED: 2021-01-22
Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to a Cross-Site Request Forgery (CSRF) in the web interface.