Late Investigation Using Archive Logs
A financial services firm uses FortiAnalyzer 7.4 with 14-day analytics retention and a 1-year archive of raw logs. On 3 March, the SOC receives a tip that a finance workstation at 10.20.8.44 may have been compromised on 10 February. FortiAnalyzer has FortiGate, FortiProxy, and FortiMail logs in a single ADOM. The workstation used DHCP and the address was reassigned on 20 February. The SOC wants to know what happened, whether data left, and how to preserve evidence. A normal log search for the IP over 30 days returns nothing because analytics retention is 14 days; archive logs exist but are not indexed for normal search. The team has no documented playbook for archive retrieval.
1. How should the SOC investigate using archive logs, and what limitations and evidence-handling steps apply?
Read the worked answer
Do not start by searching only the hot analytics store; it cannot see 10 February. Identify where the archive lives and how this FortiAnalyzer build exposes it. Archive logs are typically raw and not fully indexed, so normal Log View queries may not work; export the relevant time window and device logs to a forensic workstation, then parse there. Preserve evidence: record the export time, source, ADOM, time range, and a SHA-256 hash; keep the original archive untouched; work from copies. Document every access. Limitations: archive may be incomplete if forwarding failed, timestamps may be in different zones, and raw archive may lack parsed fields. If needed, restore a copy into a lab FortiAnalyzer or SIEM for indexed search rather than altering production.
2. What queries and pivots should be used to build a timeline, and how does DHCP affect attribution?
Read the worked answer
Build a timeline around the IP, but validate the DHCP lease first. Pull DHCP server logs for 10 February to map 10.20.8.44 to a MAC, hostname, and user; if FortiGate is the DHCP server, query its DHCP logs. Then search FortiGate traffic and VPN, FortiProxy web, and FortiMail logs for srcip or dstip 10.20.8.44 in the relevant window. Pivot on user, hostname, MAC, and destination IPs and domains. Look for large outbound sentbyte, unusual categories, deny events, and mail attachments. Because the IP was reassigned on 20 February, do not attribute later events to the original host. Correlate with endpoint and AD logs. If archive parsing is weak, export to a SIEM and use field extraction.
3. What automation and process changes should be made to prevent this gap in future investigations?
Read the worked answer
After the investigation, close the gap. Increase analytics retention for high-value ADOMs to at least the investigation window, or forward all logs to a SIEM with hot search; archive alone is not enough. Test archive retrieval quarterly and measure restore time. Add a documented playbook with roles, evidence handling, DHCP lookup, and escalation. Automate a daily check for log-forwarding failures and license or disk alarms. For critical subnets, reserve DHCP or use fixed addressing for servers, and ensure DHCP logs are retained as long as the firewall logs. Finally, add an automation alert for large outbound transfers from finance hosts, but tune it to avoid the false-positive trap.