Practical steps to help be ready to investigate a compromise. A presentation delivered to the College IT Conference 2025.
Following on from:
- Practical steps to help mitigate the risk of Zero-Day vulnerabilities.
- All of this has happened before. All of this will happen again (MITRE ATT&CK).
As a presentation on YouTube: https://www.youtube.com/watch?v=dWX5vqk6EJ0
By James Preston of ANSecurity.
Personal blog at myworldofit.net.
- Have direction on the creation of a logging policy.
- Understand the utility of logging in the context of incident response.
- Be able to identify useful log sources.
- Have options on how to obtain and store your logs.
- Be ready to log!
- Provide a 'quick start' point in a direction for effective logging.
- https://www.cisecurity.org/
- https://cas.docs.cisecurity.org/en/latest/source/Controls8/
- https://www.cisecurity.org/insights/white-papers/audit-log-management-policy-template-for-cis-control-8
- https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations
- https://www.cisecurity.org/cis-benchmarks
From the CIS Benchmarks
From the CIS Benchmarks
To answer questions, such as:
- Sophos detected a malicious program on a computer - where did it come from?
- Based on the data in a threat intel report have we been impacted?
- What files have been copied to the Internet from a computer?
But also...
- To identify the root cause of an incident (non-security related!).
- To comply with regulations.
- Generally a 'good idea'.
Perhaps most of all so that you don't have to use sentences like:
- "fined for a breach that put personal information of 79,404 people at risk"
- "The unidentified hackers"
- "The security measures of Advanced's subsidiary fell seriously short of what we would expect from an organisation processing such a large volume of sensitive information," Mr Edwards said.
- "There is no excuse for leaving any part of your system vulnerable," Mr Edwards added.
From: BBC News - NHS software provider fined £3m over data breach after ransomware attack
- Deception and honeypots.
- Log review.
Validato, manual exfiltration, and Microsoft Defender EDR
- New application process.
- DNS requests.
- URL requests.
- New/modified file and registry keys.
- Loading of drivers.
- Reading specific file types (e.g. .docx/.pdf/.xlsx).
- Script/command line interface use.
- https://github.com/sophoslabs/IoCs.
- https://github.com/PaloAltoNetworks/Unit42-Threat-Intelligence-Article-Information.
- https://www.ncsc.gov.uk/section/keep-up-to-date/malware-analysis-reports.
- URLs.
- File hashes (MD5/SHA1/SHA256).
- File names and paths.
- IP addresses.
- Domains.
- AppLocker blocked the execution of a new application.
- Excessive requests to unauthorised web or file sharing services.
- Break glass account used... careful about to hit that rabbit hole.
- Minimum 90 days for all logs.
- Target as long as you can (365 days wouldn't be abnormal) for high value logs.
- Deploy sysmon everywhere.
- Increase the minimum local retention for Event Logs.
- ~2GB limit for 'live'.
- NXLog CE and Winlogbeat.
- Direct out of Event Logs.
- Read file system.
- rsyslog.
- imklog.
- imjournal.
- Read file system (e.g. for Apache).
- Syslog.
- Common Event Format (CEF).
- API connectors.
- Normally some kind of agent required that connects into the cloud service and downloads logs on a routine.
- Sophos SIEM integration script.
From LimaCharlie.
- Local storage.
- Centralised storage.
- https://graylog.org/.
- Lots of options out there based on Elasticsearch or OpenSearch.
- Consider 'cloud' options.
- Perhaps just as a relay for end-user devices working remotely.
- In an emergency and you don't have anything setup:
- Network appliances don't always support both/either.
- May need to use some form of logging 'proxy'.
- If running a 'cloud' logging service the importance is even greater.
- Don't underestimate a threat actors resourcefulness, easy to generate sufficient logs to overwhelm a system or inject malicious content into logs.
- Network level access controls to the log system.
- Authentication to the log system.
- Dependencies on systems that may be offline in an incident (compute, storage, networking, authentication).
- Place the server(s) in a dedicated 'logging' network.
- Restrict access into that network with a network firewall, broadly allow connections to the ports that logging agents talk to, restrict by source network/IP/user/device access to the management interface.
- Dedicated physical server or servers (3 smaller nodes in a cluster is better than a single node by itself).
- Strong authentication (phishing resistant) as the 'day to day' access, with a fallback to local authentication with a strong (long) passphrase.
- Firewall traffic logs - VERY high volume, low relative value.
- DNS logs - high volume, low-medium relative value.
- But.... DNS is encrypted now.
- Command line logs - low-medium volume, high relative value.
- Previously unseen application launched (or attempted to) - low volume, high relative value.
- Volume (TBs of logs!) is often the main problem.
- Bulk file transfer of text files.
- Not uncommon to grant read-only access to the centralised log store.
- Export from >X<Search to JSON.
- Export with backup feature and then import.
Validato, Microsoft Defender, LimaCharlie EDR
VirusTotal, wordpress_shell.php, LimaCharlie EDR.
- Talk with senior leadership about establishing a formal policy for logging.
- Then take that policy and turn it into practice/procedure.
- Find 1 (or 3!) old(er) servers (desktops), fill them with disks (8TB SSDs are cheap), configure a logging stack of your choice.
- Get firewall, web server, AV agent, and authentication logs flowing into them.
- Review options for an EDR service.
- LimaCharlie really is a great entry point, try it out on some web servers and go snooping!
- Do maintenance! Don't let that logging system run out of disk space!
- Check all log sources are sending logs.
- Routine check that the times of systems are in sync.
- Conduct audit log reviews.
- Perform some 'malicious' activities and then check that the logs you expect were captured.
- Use threat intel reports.
But a good defence is still a good defence.
- Build a culture of reporting abnormal events.
- Install AV everywhere, including on Linux web servers!
- MFA (or even better strong authentication) everything!
- Decrypt!
- Inbound (where you own the private key already).
- Outbound (where you generate new trusted certificates on the fly for services that you don't have the private key for).
- Configure outbound filtering!
- Block access to remote access tools (legitimate and otherwise).
- Strict outbound filtering from services that allow connections from untrusted networks/devices.
- Test your backups!
