An EDR alert flags a workstation sending short outbound HTTPS requests every 30 seconds to several IP addresses. You have full packet capture, but the sessions are TLS encrypted and you have no decryption keys. Which PCAP-derived metadata should you analyze first to characterize the suspicious encrypted sessions?
Select an answer to reveal the explanation.
Short Explanation
Think of encrypted traffic like a sealed envelope: you can't read the letter, but you can still see the stamp and return address. When you're triaging suspicious HTTPS, SNI and JA3-like fingerprints give you those clues without needing keys. That's the quick win before chasing timing or entropy.
Full Explanation
Mechanism: Full packet capture preserves the TLS handshake even when payload decryption is unavailable. The ClientHello can expose Server Name Indication, and JA3-like fingerprints hash TLS version, cipher suites, extensions, and elliptic curve data. Those metadata values let you cluster beaconing sessions, match known malicious TLS clients or servers, and correlate suspicious IP addresses with certificate or domain intelligence without exposing user content. Packet length histograms and inter-packet timing can help confirm periodic beaconing, but they do not identify the remote service or distinguish benign HTTPS from malicious HTTPS. Entropy and destination ports only indicate that traffic is likely encrypted and using HTTPS, which is too generic for triage because normal web browsing looks similar. Recovering HTTP User-Agent strings from encrypted application data assumes plaintext access that TLS prevents unless keys are legitimately available and the traffic is actually HTTP. Exam caveat: CompTIA expects you to choose the least-invasive PCAP artifact that characterizes encrypted sessions, not a technique that requires decryption. Operational check: Filter capture for TLS ClientHello messages, extract SNI and JA3-like hashes, then pivot those values against threat-intel feeds and process context from EDR.