Security log analysis is helpful and effective on Windows when it comes to characterizing activity involving user accounts, remote access to a network, and lateral movement amongst other behavior. Event Viewer is native to the Windows OS and allows you to view Windows logs as well as filter on specific events, users, hosts, and event severity levels. In this post we'll be taking a look specifically at the Windows Security Log and how details contained within it can be useful when trying to assess anomalous or suspicious behavior at a rudimentary level. (Details on how to access the Windows Security Log can be found here )
What does the Security Log document?
Depending on the event, the Windows Security Log can contain the following information:
Event ID
Event level (criticality)
User associated with the event
Hostname
Date logged
Keywords associated
Source IP/port
Logon type
Logon authentication method
Account domain
Logon GUID
Using all of these details can help you get a relatively strong timeline of events on a particular host.
What can we gather from the Event ID?
The Event ID alone is very informative. Microsoft uses a numerical identifier as the Event ID and a useful Event ID dictionary by Ultimate IT Security can be found here. Microsoft also offers a list of events that administrators should monitor within their environments, found here.
The Event ID correlates to a specific action or behavior carried out on the host. Some events are innately head-turning, whereas most others require context in order to properly assess the ongoing behavior. A perfect example of the latter would be a successful login. More often than not this is benign behavior; however if there's been suspicious activity occurring on or originating from a host, reviewing the 4624 Event ID within the timeframe in question can help identify the user that is logged into the host at that time. Further investigation can lead to discovering that maybe the user's credentials have been compromised or possibly that the user is an insider threat. Below is a screenshot of a 4624 event in Event Viewer:
One important piece of information that is useful specifically for 4624 events is the logon type. The screenshot below is a reference provided by Microsoft, and more details can be found here.
The logon type may raise questions if, for example, users shouldn't be logging in to the network remotely, but the logon was a type 10. It may also reveal network security and configuration holes that need to be remediated.
Timelining and Context
As I mentioned previously, most often a standalone event is not enough to determine whether activity is malicious or not. A standalone 4624 may not tell you very much if the details are within baseline expectations for a user on your network. Even a handful of 4625s (failed login attempts) followed by a 4624 may just be a user that's recently returned from a two-week vacation and had trouble remembering his or her password.
However, let's say the same user exhibits the same behavior at an off-hour when users typically are not logging into their endpoints. That would then warrant, at minimum, a check to determine what the logon type was to see if the user was locally or remotely logging on.
Additionally, looking into the events that followed the successful login. Were there permissions or privilege change events, such as a 4670 (permissions on an object were changed)? Did possible malware persistence activity take place, such as a 4698 (scheduled task creation), 4697 (attempt to install a service), or a 4657 (registry value modification)? If it was a remote logon, is the IP from another host within your network or is it an external address? If the latter, some simple OSINT may assist in identifying whether or not the IP has been associated with nefarious activity in the past.
This highlights the importance of assessing the context of the behavior and knowing the network environment. It's imperative that administrators know what is normal and expected activity across their networks; it assists in weeding out potential false positives and highlighting glaring evidence when it comes to incident investigations.
Conclusion
Log analysis is a useful method of utilizing native tools to conduct basic investigations within an environment. A plethora of information can be extracted by simply timelining the events surrounding any activity that is raising questions amongst network administrators. It offers insight to user activity and is also a no-cost tool to have in your arsenal. Paid and additional resources absolutely exist to make analysis much more efficient and robust, especially if you want proactive detection monitoring across your environment, however it does not hurt to be familiar with the basics and understand what tools are available should a limiting circumstance arise. A good analyst is one that is not dependent on but rather augmented by automation and tooling.
Additional Resources & References
There are many resources available online that identify important events to monitor or what patterns to look out for. Some are available below:
6 windows event log IDs to monitor now (InfoSec Institute)
Incident Response Event Log Analysis (SANS DFIR Webcast)
Appendix L: Events to Monitor (Microsoft)
Windows Security Logs Event Dictionary (Ultimate IT Security)
Windows Event Log Analyst Reference (Forward Defense)