A targeted attack is defined as a security incident perpetrated by an adversary who purposefully selected his or...
This sort of incident stands in stark contrast to the majority of security incidents, which are often opportunistic events: The typical victim is exploited simply because he or she uses the sort of Internet-enabled services and devices that an intruder expects to encounter. A targeted attacker, conversely, deliberately chooses a specific victim.
In order to defend against both types of attacks properly, security professionals must assume their systems will be assaulted by both targeted and opportunistic attackers. Unfortunately, most organizations are barely postured to withstand or even detect opportunistic intruders, let alone confront those pulling off targeted intrusions. Because opportunistic attackers rely on mass-market exploitation, they often use tools and techniques familiar to defensive security tool makers. For example, antivirus developers are more likely to be prepared to detect and defeat opportunistic-minded malware (to the extent conventional antivirus works at all).
If traditional defenses can’t handle opportunistic intruders, what hope does the weary security professional have of confronting targeted attackers? The foundation for a counter-threat operation has to be knowledge of attackers and common intrusion methods. This knowledge means more than the sort of industry-wide threat information available from public (or even some private) sources. While it is important to understand the big picture, it is just as important to have an accurate, current view of the security-related activity of the enterprise to be defended.
This process of gathering enterprise-specific intelligence means collecting and analyzing information about specific devices, data and activities within the organization. There are many ways to gather information about digital enterprise activity, and it's easy to become lost in the details of any specific technology or approach. If starting from scratch, it's best to keep certain categories of information in mind. For completeness, these include:
1. Network traffic, or specifically network security monitoring data
2. Application logs
3. Host data
How to collect Windows Event logs
For the purposes of this short article, we’ll focus on collecting logs from the Windows operating system. While it is often equally important to collect logs from a number of other types of systems, Windows systems are on the front lines of the digital battle, due to the fact that users interact with websites and malicious content linked to or carried within email. The approach here can be architected to scale to the largest enterprises, but it's best to start small, such as with a test group, to validate the approach and to determine if the information collected meets the expectations of the security professionals managing the project.
Collecting Windows log data involves two main issues: log collection and transmission, and collection and storage. To address the first issue, consider using a free agent such as Snare for Windows by Intersect Alliance. I have has used Snare on a variety of Windows systems, ranging from Windows NT 4 through Windows 7. Different binaries exist depending on whether the system to be monitored is a 32-bit or 64-bit version of Windows. Most administrators configure Snare to export Windows Event logs in Syslog format.
When installing Snare, be sure to let the log analyzer reconfigure the Windows event log to facilitate the generation of logs that are suitable for detecting targeted intruders. Also, be sure to match the correct version of Snare to the OS in question. If the output from Snare doesn’t isn’t what you expect to see, double-check that you matched the Snare version against the host operating system.
To address the issue of log collection and storage, consider starting with the free version of Splunk. The free edition will archive up to 500 MB of logs for free, and runs on Windows, Linux and even FreeBSD. By pointing Windows logs via Snare to a Splunk server, security teams will now have easy access to the sort of data they need to discover targeted attackers.
Analysts can use Windows Event Logs in a variety of ways, but one useful way is to observe intruders running binaries on victim systems. For example, the following screen shot shows Windows event logs collected by Snare from a Windows XP victim and transmitted to a Splunk server. The oldest activity appears at the bottom of the image and the newest at the top.
(Click to enlarge)
After the back door (the unfamiliar executable bzTdpLKa.exe, shown at the bottom of the image) is executed by rundll32.exe, you see cmd.exe, netstat.exe, and tasklist.exe executed by the intruder. Process-creation logs like the one shown above are helpful because they are a neutral and rich source of activity at the process level, and analysts can easily follow the activity without knowing a variety of cryptic Windows event codes or systems.
Once you begin to collect Windows Event logs, you can expand to collecting logs from any device that is capable of exporting them, with analysis to follow. Happy hunting!
About the author:
Richard Bejtlich is director of incident response for General Electric and author of the TaoSecurity blog.