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 more information or if you need help with a current incident, contact MOXFIVE at ask@moxfive.com or use our Contact form.
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
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.
