<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=363521274148941&amp;ev=PageView&amp;noscript=1">
Blog

Cut Response Time from Days to Hours with Windows Event Log Forwarding

See how event log forwarding – a simple yet often overlooked process – can increase visibility and reduce response time.

From the cyber playbook

Contributed by Mark Hedrich, Lead Investigator

Windows event log forwarding is a simple yet sometimes overlooked process that can increase visibility and dramatically reduce response time. In this post, our Investigations team outlines how they parsed through Windows event logs to uncover a malware source and how the process could have been expedited with enhanced SIEM communication.

Investigation Overview

Earlier this year, a customer engaged the Cyderes’ Investigations team after receiving multiple alerts from their EDR that malware had been detected on an isolated EC2 server in their DMZ. Our team immediately requested a forensic image of the server to determine how the malware got into the system and what else may have occurred on the server.

One of the first actions we take in a forensics investigation is to pull the Windows event logs from the system image. These event logs often reveal new indicators of compromise (IOC) that point us in the right direction. In this case, we requested the 1TB image, but wanted the Windows event logs exported first due to the large image size—and that’s all we needed.

Parsing Through Windows Event Logs

The extent of the compromise became apparent after running the logs through some of Eric Zimmerman’s forensics tools for parsing Windows event logs. In particular, the Microsoft-Windows-PowerShell/Operation proved very useful.  From this, we identified a malicious ‘.bat’ file from an IP address three months prior from those logs alone.

Image of Microsoft-Windows-PowerShell/Operation event log
Figure 1: Microsoft-Windows-PowerShell/Operation

We also identified the frequent use of PowerShell over the next three months to download files from the internet, to include AnyDesk and netcat.  The System event logs confirmed that AnyDesk was installed early in the compromise.

Image of Windows event log
Figure 2: System event log

But we weren’t finished with the PowerShell logs just yet. Further analysis revealed that the threat actor was using PowerShell commands to pass variables to an external IP address. 

Image of PowerShell event log
Figure 3: PowerShell log

One last finding from the Security event logs was the creation of an account called ‘oldadministrator’. 

Image of Windows event log
Figure 4: Security event log

What About EDR Solutions?

Some of you may be asking, why didn’t you leverage the customer’s EDR tool to find all this information? The reason is simple, and unique to this circumstance: The EDR agent was not installed on the server during the time of the compromise. 

We were able to leverage the EDR to retroactively pull the event logs. In this case, however, the EDR only grabbed the Security, System, Application and Hardware logs, not the Microsoft-Windows-PowerShell/Operation

For organizations that do not have an EDR solution or don’t have it deployed on every endpoint, forwarding event logs to a SIEM—either yours or your MSSP’s—can be an effective alternative. This method also enables you to add more fidelity to your logging and help your Incident Responders. Forwarding these additional logs is fairly easy. Plus, you can prioritize systems that are deemed high value and/or vulnerable if resource constraints are a factor.

While Sysmon was not used in this particular engagement, it can also enable you to add fidelity to your logging. It logs to Windows events and provides detailed information on process creation, network connections, registry changes, and file modifications, to name a few.

The Lesson: Windows Event Log Forwarding is Essential

This investigation was not groundbreaking, but there was a clear lesson to be learned: Windows event log forwarding to a SIEM is crucial.

And not just the ‘standard’ event logs (i.e., Security, Application, System, etc.) but also some of the ‘Operational’ logs like PowerShell/Operation and the ‘TerminalServices’ logs like RDPClient/Operational, RemoteConnectionManager/Operational and LocalSessionManager/Operational. 

In this case, the client went days without knowing the extent of the compromise—or even what IOCs they should be looking for—because of this misstep. With this simple practice in place, that response time could have been reduced to a few short hours.


Take the first step in transforming your cybersecurity program

Enterprise security teams are adapting to meet evolving business needs. With six global Security Operations Centers, emerging technology partners and a dedicated team of security specialists, Cyderes is well-positioned to be your organization’s trusted advisor in cybersecurity. We’ll help you understand your risk exposure, increase your visibility and ROI, and proactively hunt for the latest threats.