A Suricata rule fires on a connection: alert http $HOME_NET any -> $EXTERNAL_NET any (msg:'ET TROJAN Possible Cobalt Strike Beacon'; content:'|00 00 00 00|'; offset:4; depth:4;). The alert shows the source host is the CFO's laptop. What is the correct next analytical step?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal — a single IDS alert is a lead, not a confirmed incident. Pull the full PCAP, decode the HTTP stream, verify the byte pattern against known Cobalt Strike staging, then check the host's other sessions for more command-and-control indicators.
Full Explanation
The correct next step is the PCAP/HTTP-stream verification option: a single IDS alert is a lead, not a confirmed incident; pulling the full PCAP, decoding the HTTP stream, verifying the byte-level pattern against Cobalt Strike signatures, checking for additional command-and-control indicators across all sessions from that host, and then pivoting on host history is proper triage. The immediate wipe-and-reimage option is wrong because reimaging without forensic collection destroys evidence and may be premature. The rule-disable option is wrong because disabling a rule due to the user's seniority introduces blind spots and does not validate whether it is a false positive. The email-the-executive option is wrong because notifying the suspect can tip off an insider threat or a compromised user acting unwittingly.