The Secureworks Incident Response (IR) team responds to incidents at a wide variety of client organizations, each of which have unique threat profiles, campaigns and actors targeting them. As responders, we love the challenge of being prepared to respond to vastly different incidents; however, with unfamiliarity comes challenges. Logging practices should aim to close gaps in visibility and retention that would otherwise hinder investigation and response. Yet we often see organizations approach log retention as a regulatory check-the-box exercise, resulting in missed opportunities to capture what matters most in an investigation down the line. Perhaps the greatest example of this is the tendency to overlook “what is being logged” for the sake of “how long” it is being logged.
Windows Event Logs
Since the introduction of Windows NT in 1993, Microsoft’s Windows operating system has logged system events into the Event Log format in either the System, Security, or Application event log. With the introduction of Windows Vista in 2006 this system was overhauled, allowing additional event log files, with modern systems having over 100 individual event logs. This shift has allowed for highly granular event logs that play a key role in incident response, such as tracking lateral movement and service installs, for example.
Login Events
The Security event log contains a wealth of information key to tracking lateral movement and account login activity to include source workstation and account name used. Unfortunately, by default this log has a maximum size of 20 MB before the oldest events begin to “roll over,” or get overwritten, as new events are recorded.
Losing security event log entries, especially 4624 successful login events, can make it difficult and time consuming to identify the source of a login event, preventing the determination of root cause.
PowerShell
Support the originator by clicking the read the rest link below.
