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.

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
New 'Nanodegree' Program Provides Hands-On Cybersecurity Training
Nicole Ferraro, Contributing Writer,  8/3/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15820
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, the markdown parser could disclose hidden file existence.
CVE-2020-15821
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, a user without permission is able to create an article draft.
CVE-2020-15823
PUBLISHED: 2020-08-08
JetBrains YouTrack before 2020.2.8873 is vulnerable to SSRF in the Workflow component.
CVE-2020-15824
PUBLISHED: 2020-08-08
In JetBrains Kotlin before 1.4.0, there is a script-cache privilege escalation vulnerability due to kotlin-main-kts cached scripts in the system temp directory, which is shared by all users by default.
CVE-2020-15825
PUBLISHED: 2020-08-08
In JetBrains TeamCity before 2020.1, users with the Modify Group permission can elevate other users' privileges.