{"id":8860,"date":"2021-12-18T21:30:00","date_gmt":"2021-12-18T19:30:00","guid":{"rendered":"https:\/\/tajdini.net\/blog\/?p=8860"},"modified":"2022-03-23T21:54:22","modified_gmt":"2022-03-23T19:54:22","slug":"incident-response-without-windows-event-logs","status":"publish","type":"post","link":"https:\/\/tajdini.net\/blog\/dfir-and-incident-response\/incident-response-without-windows-event-logs\/","title":{"rendered":"Incident Response without Windows Event Logs"},"content":{"rendered":"\n

This post discuss some Digital Forensics and Incident Response (DFIR) techniques you can leverage when you encounter an environment without Windows event logs<\/strong>.<\/p>\n\n\n\n

Where are the logs?<\/h1>\n\n\n\n

at work, we regularly respond to security incidents with ineffective logging<\/strong> and auditing for the purposes of a cyber incident. In some cases, organisations we encounter don\u2019t have any recognisable SIEM or centralised log repository. In others, organisations with otherwise sufficient logging have seen adversaries intentionally manipulate the logs on an endpoint to prevent analysis<\/strong> \u2013 sometimes even wiping them entirely.\u00a0<\/p>\n\n\n\n

Clearing the event logs on a Windows machine is trivial. It is a recognised behaviour of adversaries [T1070.001<\/a>] who wish to evade and frustrate investigators\u2019 efforts to unravel the TTPs of a malicious campaign. Without the event logs on a machine, you cannot use beautiful tools like Chainsaw<\/a> to easily piece together the story for your client.\u00a0<\/p><\/blockquote>\n\n\n\n

Thankfully, our guidance is relevant to all situations where logs are unavailable to support an investigation. <\/p>\n\n\n\n

Log-less investigations<\/h1>\n\n\n\n

For the rest of this post, I would like us to operate under a log-free paradigm \u2013 where the event logs cannot be utilized in an investigation<\/strong>. I\u2019d like us to discuss three<\/strong> DFIR techniques that you can easily deploy when next conducting analysis on a machine that an adversary has tampered with. The machine may or may not have the required logs, or you may not trust the evidence \u2013 meaning we must verify past events through other means.\u00a0\u00a0<\/p>\n\n\n\n

As we do not have the permanency that event logs offer, we are left with volatile forensic data. Simply put, if you do not get to most forensic data as quickly as possible then it may be gone forever<\/strong>. If the machine is rebooted, the data can be lost; if the machine is left on and is used, many pieces of forensic evidence may be overwritten and lost forever.<\/p>\n\n\n\n

There are many techniques for digital forensics. To understand and deploy the more advanced tools, there are many wise sages who I would recommend, such as Richard Davis\u2019 13Cubed<\/a>. In particular, there are three (or four, if you\u2019re feeling brave<\/strong>) post-log techniques I consider to have a low barrier<\/strong> to entry in terms of technical capability, have general resiliency<\/strong> to adversarial manipulation, and are relevant<\/strong> to Windows endpoints and servers:<\/p>\n\n\n\n