Thursday, November 22, 2012

Identifying Compromise with the Windows Event Log

Windows event logs are primarily viewed a means to confirm a compromise and explore the depth and width of a compromise. Typically, only after having been alerted by IDS, HIDS, or AV will an incident responder examine host event logs. Until recent changes in Vista & Server 2K8, this information could be seen as unmanageable and unruly. Today, I'm advocating for the use of Windows Event Logs as a source for initial identification of security incidents, instead of an after thought.

Detecting Persistence
I'm part of team whose role is to perform penetration tests and design mitigative strategies based on our ability to break in, persist, and move laterally. Most of the time, when we land on a machine inside of the target network, we utilize some form of persistence mechanism:

  1. Add a registry setting to HKLM/.../Run or RunOnce
  2. Attempt to create a service which runs our trojan
  3. Add a task in TaskScheduler to execute our trojan
  4. Open the Windows Firewall, enable Remote Desktop/ Remote Assistance, and add a user
  5. Copy our trojan into the "Auto-Start" directory
Let's take a moment and analyse how each of the above actions is captured in the Windows Event Logs (thank you Randy Franklin):
  1. Event 4657: Registry Changes
  2. Event 4697: Service installed on a system
  3. Event 4698: A Scheduled Task was created
  4. Event 4964: Firewall Exception Added, Event 4720: User Created
  5. Event 4657: This action will trigger registry changes in the Run hive
Now, let's not get carried away! I mean, Windows registry changes happen A LOT on end user workstations. Looking at all of the registry changes as potential compromises would be like documenting each port scan of your external IP space - not helpful. With this in mind, we need to filter for changes to specific hives which should generally remain static. We can also watch out for changes to any of the hives examined by "AutoRuns.exe"; a tool created by Mark Russinovich to identify persistent applications in Windows. 

Getting the Logs Together
Let's talk about the bigger challenge: collecting events from EACH workstation in a domain into a central location. There are a few approaches that would work, some more scalable than others. Your organizations bottom line will dictate what type solution you can implement, but just collecting key events centrally is a step in the right direction. If your organization has hardware sitting around, you can implement the first 2 solutions for free (plus labor):

  • Powershell or WMI: pull specific events
    • Easy, quick, could provide spotty data depending on pull frequency
  • Event Log Forwarding: push events to central log management device
    • Built into Windows, manageable via GPO, almost real-time, encryptable
  • Splunk or Snare agent: push events to central log management device
    • Optimal, real-time, encryptable, relatively expensive 

Not Just for Persistence!
Other uses of event logs included, but are not limited to:
  • Suspicious Share usage (think pass-the-hash/psexec.exe)
  • Local administrative account creation
  • Local administrator brute force attempts
  • Use of "net" tools on non-network admin boxes
  • Suspicious internal RDP sessions

Log management is certainly not a catch all. Attackers can and will find ways to compromise networks that will go undetected by event log monitoring. Event log monitoring should be view as a essential compromise detection component of a defense-in-depth approach to network security. That being said, for an attacker to persist on a Windows machine, it is extremely likely that they will trigger an event listed above.

No comments:

Post a Comment