Microsoft Workstation Logs - An Introduction

We’ve all heard the saying, "What you see is what you get." Life isn’t quite so simple for those focused on security, as what you don’t see is more likely to be what you get. Luckily, there are places to gain visibility in places that are often overlooked. Security policies have always included the protection of key assets such as servers, network infrastructure, and data center and perimeter devices. This approach will always be the first line of defense. And for those who are new to the security space, this is the best place to start. More recently, security policies have been extended to the user level. The number of endpoint protection solutions has grown markedly over the last few years as security administrators have understood that protection from attacks initiated from inside an organization is critical. These attacks are able to leverage users and their devices because, like it or not, people do download things they shouldn’t, they visit websites they shouldn’t, they share files, they let their kids use their company assets, and, they often fall prey to social engineering. Endpoint Protection (EPP) has existed since the 1980s in the form of virus-scanning clients. Over the years, the EPP landscape has become a battle of the Advanced Endpoint Protection (AEP) products. AEPs are next-gen technology, combining EPP functions, like anti-virus, with event detection and response (EDR) technology providing detection, blocking, and forensic analysis capabilities. In addition, operating systems like Windows provide a selection of endpoint tools that can be enabled out of the box. In the Microsoft world, implementing an endpoint protection strategy can start with an often overlooked feature; Windows Event Logging. Event logging provides visibility into the activities performed on the workstation by grouping application, security, and system events into a single view. The workstation event console may then be configured to forward a customized set of these events to a log aggregator like a domain controller allowing the administrator to have a consolidated view of the activities on the workstations in the domain. These consolidated events can then be further forwarded to a SIEM and used as an alert trigger (detection of an APT) or provide contextual value (workstation state for a specific user on a device that attempted a brute force attack on a key server). More of this in a later blog. To decide if Workstation Event Logs have a place in your overall security strategy, consider these use cases:

• Access: How secure are the local authentication policies of individual workstations? If an attempt is made to log in to a device using a local access credential rather than a domain controlled account, it will be logged in the workstation event log only.
• Persistence: Registry changes made by an attacker to provide a foothold into the system that persists over system reboots must be tracked.
• Discovery: IoCs can be recognized by anomalous actions, for example, events reporting misspelled service names, uncommon service paths or non-typical application crashes due to buffer overflows.
• Reconnaissance: Running of tools that indicate scanning, recon, and brute force attacks may have been attempted can be logged.
• Forensics:  In the case of a breach, building an event timeline from initial compromise to detection is critical to understanding how to recognize the extent of the compromise across multiple machines and how to remediate these systems.
• Behavioral Analysis: Changes in user behavior or inappropriate use of company assets can have both security and legal implications. If certain event types, like failed logins or privilege escalation attempts, begin to occur, or known exploitation tools are installed on a system, this could be a sign of a compromise or a potential issue with an employee.

As with any logging tool, the trick is to create a configuration and deployment strategy. One of the downsides to event collection is that a poorly tuned system can generate far too many events to be useful or even viable.  Admins must identify critical events to collect based on how they impact their environment and have an action plan defined for addressing issues. This ensures an understanding of the context and implications of an event; the rule of thumb is that proactive beats reactive. If this post has you thinking about workstation logging, future blogs will provide more information about defining your security policy, configuring endpoints, and forwarding events to an aggregation device and making use of logs in SIEMs. Stay tuned.