Spotting the adversary with windows event log monitoring

Events to Monitor in a Windows Environment

O.K. you have purchased a SIEM, added your Windows servers and you’re ready to create your use-cases. You draw a blank. The amazing part about a SIEM is that you can build use-cases for literally thousands of scenarios. Unfortunately, however, the problem with a SIEM is that you have to create literally tens of thousands of alerts to monitor said use-cases. Monitoring for five failed logins followed by a successful login is great, but what good is the alert if the account locks after three failed attempts? Or if you have 10,000 users to monitor? To add to this, according to Verizon’s 2013 Data Breach Report, 76% of breaches involved stolen or weak credentials. So what to monitor for?

1. Clearing Event Logs
2. Account Usage
3. Remote Desktop Logon Detection
4. Windows Defender Activities
5. Application Crashes
6. Software and Service Installation
7. External Media Detection
8. Pass the Hash Detection
9. AppLocker
10. System or Service Failures
11. Windows Update Errors
12. Kernel Driver Signing
13. Group Policy Errors
14. Mobile Device Activities
15. Printing Services
16. Windows Firewall

Before I start I want to clarify a not-so-obvious gotcha about Windows event logs for newcomers—Windows NT to Windows 2003 event IDs are identified via three digits; however, Windows Vista/Windows 2008 and beyond event IDs are identified by a four-digit ID. Therefore, any event ID with three digits is only applicable to Windows 2003 and before (and four digits beyond 2003.) Another useful tip is Randy’s Ultimate Windows Security, which provides detailed information on nearly every Windows security event.

1. Clearing Event Logs

This is often the first alert I will install in a client’s environment. There are very few reasons to clear the audit log directly, if the audit log is too large the event log’s maximum size should be set to a smaller size. As such, outside of an improperly configured device an event log would only be cleared to hide malicious activities. As such, a simple alert looking for the following events is usually sufficient.

Table-1: Event Log Cleared

2. Account Usage

A proper set of alerts and reports for improper account activity is key to a useful SIEM. Setting an alert for X failed logins may drive your SOC crazy every Monday morning after a long weekend, but setting this threshold to alert when it occurs after-hours or on non-user systems could indicate malicious behaviour.

The size of your environment and your companies security policies will weigh heavily on the value of certain actions being an alert or a report—a team of 200 may have a weekly report on created users, whereas a team of 20,000 may have a daily report. As such I will make my recommendations based on generalizations of a business with 1,000 users:

• A weekly report for created users and users added to privileged groups;
• An alert for Security-enabled group modifications;
• An alert for service account failed logins or account lockouts, although this is prone to alert-spamming in the case of an incorrectly configured script or service continually trying to log in;
• An alert for three non-service failed logins to a non-user system after-hours;
• Interactive logins by a service account; and
• A successful user login from a non-whitelisted country

Table-2: Account Usage

Of course this is not a complete list of recommended alerts or reports, rather a couple of examples to get you started.

3. Remote Desktop Logon Detection

Remote desktop alerts and reports are tricky. Datacenter jumpboxes are the most used machines—they are the most heavily used, store endless amounts of ‘temporary’ data, and are often the most sought after machine by a hacker. Typically once a hacker gains access to a jumpbox they have access to your most valuable resources, so tracking access is very important.

But how do you identify when access is malicious? In a 24h SOC access will be made 24 hours a day, so after-hour logins are not useful. This is something that I usually need to discuss in length with a client to really understand their environment before making remote desktop alerts. Some general concepts are:

• If your jumpbox is accessed from a specific subnet, alert when the connection is made from a different subnet, such as the DMZ.
• Alert when a service account attempts to connect to a jumpbox
• Alert or report for after-hour connections during non-change-window hours

Table-3: Remote Desktop Logins

4. Windows Defender Activities

This is pretty straight forward—a windows defender event shows detected malware/failed scan/failed update, etc. Essentially all events should be an alert.

Table-4: Windows Defender

5. Application Crashes

Application crashes are difficult to judge whether they will be effective alerts or reports in a client’s environment. I tend to try to determine if the company has the resources available to perform an active investigation as towards why the application crashed. In the least a report or alert should be made for your high-value assets. That said, application crashes can be an indication of malicious code interfacing with an application to exploit it or replace it.

Table-5: Application Crashes

6. Software and Service Installation

Installed software and services should be at the least a report, and an alert for high priority assets (although change-window time frames can be excluded to avoid false-positives.)

Table-5: Software and Service Installation

7. External Media Detection

There should always be a legitimate reason for plugging an external device into a high-value asset. An alert is recommended for medium to high severity events, and it is good to monitor external devices that are plugged in a new service is run within a few minutes on the system as this often indicates that something has executed off of the external media.

Table-6: External Media Detection

8. Pass the Hash Detection

Tracking user accounts for detecting Pass the Hash (PtH) requires creating a custom view with XML to configure more advanced filtering options. The event query language is based on XPath, a query language for selecting nodes from an XML document. 

Spotting the Adversary has defined a QueryList described below that is limited in detecting PtH attacks. These queries focus on discovering lateral movement by an attacker using local accounts that are not part of the domain. The QueryList captures events that show a local account attempting to connect remotely to another machine not part of the domain. This event is a rarity so any occurrence should be treated as suspicious.


In the QueryList below, substitute the <DOMAIN NAME> section with the desired domain name.
<QueryList>
<Query Id=»0″ Path=»ForwardedEvents»>
<Select Path=»ForwardedEvents»>
*[System[(Level=4 or Level=0) and (EventID=4624)]]
and
*[EventData[Data[@Name=’LogonType’] and (Data=’3′)]]
and
*[EventData[Data[@Name=’AuthenticationPackageName’] = ‘NTLM’]]
and
*[EventData[Data[@Name=’TargetUserName’] != ‘ANONYMOUS LOGON’]]
and
*[EventData[Data[@Name=’TargetDomainName’] != ‘<DOMAIN NAME>’]]
</Select>
</Query>

</QueryList>

These XPath queries are used for the Event Viewer’s Custom Views, and are not applicable to a SIEM itself.


The successful use of PtH for lateral movement between workstations would trigger the following:
   — Event ID 4624 
   — Event level Information 
   — LogonType of 3 
   — Logon method is NTLM authentication 
   — A not-domain logon and not ANONYMOUS account. 

Table-8: Pass the Hash Successful Logon Properties

A failed PtH logon attempt would have all of the above properties except Event ID 4625 indicating a failed logon:

Table-9: Pass the Hash Failed Logon Properties

Conclusion

The NSA’s Spotting the Adversary with Windows Event Log Monitoring provides an excellent breakdown of key Windows events when creating an initial set of alerts and reports for key windows assets. Part two will break down the second half of the event categories

The NSA released a PDF entitled “Spotting the Adversary with Windows Event Log Monitoring” earlier this year. While there’s a bit of irony in this, given the whole Snowden story that followed the release of this document, the PDF is still chock full of great information on what to watch for in an effort to “spot the adversary.”  Now, I must warn you – there’s good news and bad news that comes with this document.

The good news is it’s probably one of the most detailed documents I’ve seen in a long time.  Everything from setting up Event Subscriptions, to a hardened use of Windows Remote Management, including the use of authentication and firewalls, this document tells you how to securely setup an environment where you can natively consolidate and monitor event log based entries.

In addition, the NSA goes onto cover a number of areas that should be monitored – complete with event IDs – which I’ve broken into two sections.

Machine-specific issues – which can be indications of malicious activity

• Application Crashes
• System or Service Failures
• Kernel and Device Signing
• The Windows Firewall

Administrator Activity – specific actions performed that may be suspect

• Clearing of Event Logs
• Software and Service Installation
• Remote Desktop Logon
• Account Usage

OK – so what’s the bad news?  The bad news is you’re still left to sort out a TON of event log detail and interpret whether the entries are a problem or not.

The real value of event logs is being able to see what specifically has changed.  In some cases, like a service failure, it’s easy to see – the once working service now no longer is.  Same goes for something simple like the clearing of an event log – you’ll know Joe Smith cleared it at a specific date and time.  So what’s the big deal then?  Well, when you start looking at more advanced activity, like Account Usage, event logs will only take you so far.  Let’s take the one example the NSA document hasn’t taken into consideration – changing the audit policies themselves.  Think about it.  The entire setup spanning 67 pages only works IF auditing of each type of activity is enabled.  So what happens when the “adversary” simply turns off the auditing of, say, Account Usage, and then performs some dastardly deed?

You’ll never catch it.  The reason? Changes to Group Policy only show up in the events as a change to the policy, but lack detail on exactly what was changed within the Group Policy.

To truly have a grasp on whether you have an “adversary” within or not and, if so, what that adversary is doing, you’re going to require a solution that not only collects events, but can correlate them into something intelligent.  Your solution should:

• Consolidate events
• Focus on the events you are concerned about
• Provide comprehensive detail about the changes to your systems, security and data

The NSA doc will take you to about 2 and a quarter of the three bullets, but it’s the rest of that last bullet that is going to make the difference.  Knowing a change to a server was made last night at 11:53pm is well and fine, but knowing exactly what was changed is going to make all the difference in the world when trying to spot and address your enemies within.

In this webinar I will take you through the guidance in NSA’s Spotting the Adversary with Windows Event Log Monitoring. I’m sure you will agree that it’s an intriguing and highly targeted topic for folks like us who geek out on Windows Security Log Event IDs. This in-depth 54-page document is from the NSA’s Information Assurance Directorate. And when I say in-depth, I mean it.

• Application Whitelisting
• Application Crashes
• System or Service Failures
• Windows Update Errors
• Windows Firewall
• Clearing Event Logs
• Software and Service Installation
• Account Usage
• Kernel Driver Signing
• Group Policy Errors
• Windows Defender Activities
• Mobile Device Activities
• External Media Detection
• Printing Services
• Pass the Hash Detection
• Remote Desktop Logon Detection

It definitely has its share of recommendations that only highly classified agencies with large budgets could hope to implement but there’s plenty of useful knowledge and recommendations as well. We will focus on areas that are relevant and practical for the private and corporate sectors.

In particular I think it’s interesting that this document goes beyond just the security log and points out events in other Windows event logs that have high-security value. I’ve been thinking for a long time that I need to show the community some of these other logs and this is a great opportunity to do it.

I’ll also point out areas I think should be addressed differently or additional areas that are missing from the guidance. EventTracker is an apropos sponsor for this event because EventTracker has a purpose-built knowledge and reporting pack for this NSA guidance. And with EventTracker you can avoid the management heavy burden of implementing Windows event forwarding which figures heavily in NSA guidance.

This is will be an interesting real training for free ™ event. Please register now.

Skip to content

Skip to main content

Information Assurance Directorate: Spotting the Adversary with Windows Event Log Monitoring: National Security Agency: 9781508532323: Amazon.com: Books