June 22, 2022

Logging to Enable Forensics

Common Questions:

When was I compromised? or Was I compromised?

How did the threat actor get into my environment?

What did the attacker access? What did the attacker take from the environment?

There is no doubt you would want to answer the above questions when you hear about a new vulnerability or learn that your environment was compromised.

Throughout this blog post I will highlight a few takeaways you should consider when reviewing logging implementations for the first time. It is important to realize that logging is a marathon and not a sprint; enabling logging, testing, and detection are big efforts that may take a lot of time to implement.

Critical Log Sources for Forensic Investigations:

Firewall, NetFlow, VPN, DHCP, IDS/IPS, Endpoint Logs (Event Logs, PowerShell Logs),Application Logs, Cloud Applications (Okta, O365, etc.), and EDR/AV/Security Tool Logs.

Note: Logging levels are an important piece of the process (IE: Firewall logs with capturing packet sizes, specific windows event IDs, etc.).

Initial Access:

Firewall, VPN, IDS/IPS are important log sources for understanding when initial access occurred. Firewall logs are a commonly a challenge to retrieve in most ransomware cases due to limited logs or no retention. These logs will be requested immediately to ensure they aren’t lost due to log rotation.

Exfiltration and Command and Control (“C2”):

Firewall and NetFlow logs are crucial for visibility into egress traffic, specifically using packet sizes to identify high data transfers and determine how much data has been exfiltrated. Web proxy logs can also show certain upload sites were used for exfiltration as well as identify C2 domains/URLs and the commands being sent. DNS resolution logs that can be searched to identify which hosts resolveda given domain name, and what IP address that domain name resolved to, can also be helpful.

Endpoint Logging:

PowerShell, Windows Security Logs, and Application Logs are also helpful in the investigation and can provide more context into actions taken by the threat actor. The longer the log retention time, the more insight the forensic team may have. If these logs are not consolidated in a SIEM or other centralized destination, forensics will run triage scripts on the hosts to pull these logs. If there is an EDR already deployed, depending on the retention rate and the EDR, the collection process may be bypassed.

Detection Based Logging:

The log sources that assist with the investigation are just as important for detection-based logging.

Firewall, NetFlow, VPN, IDS/IPS, Endpoint Logs (Event Logs, PowerShell Logs), Application Logs, EDR/AV/Security Tool Logs.

Leveraging the MITRE ATT&CK framework (reference screen shot snippet below) is a good starting point for ensuring you have logging/detections in place.

Conti - https://attack.mitre.org/software/S0575/

Ryuk - https://attack.mitre.org/software/S0446/

You can then identify steps during each attack phase (i.e., Initial Access – Lateral Movement – Defense Evasion – Discover – Command and Control – Impact) to detect activity. The objective would be to prevent the attacker from getting to theexfiltration or impact phase via automated means first.

One recommendation is to use pre-existing Sigma rules (examples below). These are not fully comprehensive, however they are a good starting point and can be referenced as an example of how to build detections:

Finally – Log Retention!

Store logs in a SIEM or passed to a vendor for retention. Having the ability to search the logs on demand would also be preferred for the team monitoring your environment.

Network Logs (e.g., DHCP lease logs, DNS, Flow, etc.)

Minimum 30days – Recommended 1 Year

Security Logs

AV/EDR Data– Minimum 90 days – Recommended 1 Year

IDS/IPS Alert Data – 90 days – Recommended 1 Year

Incident Records - Forever

Access Logs (e.g., Authentication for AD, Database logs, Firewall, VPN, Web Server, E-mail Logins,etc.)

Minimum 90 days – Recommended 1 Year

Application Logs (Web Server, SQL, etc.)

Minimum 90 days – Recommended 1 Year

Nice to have:

Network Capture Data (PCAPs)

Since log retention has efficiency and cost impacts, consider the following techniques to right-size the retention strategy to fit your organization’s unique parameters. Not only will this help your technical teams operate more efficiently and control costs, but it will also demonstrate a proactive and well-reasoned approach to audit logging when auditors come knocking to review your process.

As part of incident after action reviews, assess the role that logs played in the process. Were the right data sources logged? Did available information go back far enough? When reviewing log data, did analysts notice extraneous types of information that could be stored for a shorter time, or not necessary to be logged at all?

Execute Red Team / Blue team exercises to work hands-on with the log data you collect, simulating a variety of incident scenarios. This will identify gaps in logging and help to ensure that the data you are collecting and storing, at significant expense, is useful.

Look at each element critically and consider whether customizing the parameters for capture and retention of that element would yield efficiency or cost savings.

  • For example, how many times have gigabytes worth of “packet denied” logs on an external-facing firewall been helpful? Maybe you could avoid logging that event completely.
  • On the other hand, being able to tie an internal IP address to a hostname through DHCP logs could be useful several years down the road.
  • You might log Process Tracking events on Windows systems. If you have an EDR that provides similar capabilities, do you really need to retain the Process Tracking events?
  • In a final example, consider firewall or NetFlow logs, where the high volume of events can swell retained log storage requirements. If you were to scrutinize these logs, you may find large numbers of records related to normal traffic, e.g., application servers with static IPs in a data center talking to database servers. Retaining those records for a short time only, or not retaining them at all, may make room for other logs that are more useful to analysts.

 For more information or if you need help with a current incident, contact MOXFIVE at ask@moxfive.com or use our Contact form.

Michael Rogers

Michael Rogers is a Sr. Director of Technical Advisory Services at MOXFIVE where he provides strategic advisory services and solutions to large enterprises during and after impactful incidents. He holds a master’s degree in cyber security and is accredited through SANS for the GCFA, GCIA, GDAT, and GOSI certifications. He has had a wide range of experience from building and managing global Security Operation Centers, Threat Hunting Teams, DevOps Teams, and Infrastructure Teams.

Experts predict there will be a ransomware
attack every 11
seconds in 2021.
from Cybercrime Magazine
Our mission is to minimize the business impact of cyber attacks. 


Incident Response

MOXFIVE provides the clarity and peace of mind needed for attack victims during the incident response process. Our platform approach enables victims of attacks to work with a Technical Advisor who provides the expertise and guidance needed in a time of crisis, and facilitates the delivery of all technical needs required, consistently and efficiently.

Learn More

Business Resilience

With experience on the front lines responding to incidents daily, MOXFIVE Technical Advisors have the unique ability to connect the dots between business, information technology, and security objectives to help you quickly identify the gaps and build a more resilient environment.

Learn More