Choosing tools
On this page
Uncover at scale depends on tools. Each tool family answers a class of question; this page starts from the question and routes it to the family that can answer it. The family-by-family detail lives in the Field reference.
Choosing the right tool for the question
Pick the tool from the question, never the other way around. The pattern is always the same:
Start with the question. What does the analyst actually need to know? “Did this binary run?” “Did this user authenticate to that system?” “Where did this traffic go?“
Identify which tool category can answer it. EDR for process execution. Identity logs for authentication. Network analysis for traffic destination. The mapping is learned deliberately and becomes reflex with practice.
Plan the query order. If the answer requires multiple sources, run the cheapest or most specific query first. SIEM queries that scan everything can wait until the EDR query has narrowed the window.
Document tools and queries used. Audit trail matters for the handoff to Risk, for detection engineering feedback, and for compliance review later.
The mapping, written down:
| Question | First stop | Caveat |
|---|---|---|
| Did it run? | EDR process events (or Sysmon event 1, Windows Security 4688) | Retention window; check sensor health before reading silence as clean |
| Who authenticated, and from where? | IdP sign-in logs (or Windows Security 4624) | A replayed session needs no new sign-in |
| Where did this traffic go? | Proxy and firewall logs, network analysis | Behind a proxy, the firewall sees the proxy, not the host |
| Did data leave? | Proxy, DLP, cloud data events | Prove it where the data crosses a boundary you can observe |
| Is this file or URL malicious? | Hash lookup in the TIP, then a private sandbox | A clean run is weak evidence of benign |
| What changed in the cloud? | CloudTrail and its equivalents, CDR | Data events are often off by default |
| Who received this email, and who clicked? | Message trace, gateway click records | Sent Items can be cleaned; the trace and the audit log cannot |
| Did this happen anywhere else? | SIEM, or the data lake for older windows | Ingest lag and parser failures look like absence |
| Do these alerts belong together? | The XDR incident, then your own join | Check the join keys behind the stitch before inheriting it |
| Is someone abusing an identity, not a machine? | ITDR, IdP risk and audit logs | Tokens already issued to third-party SaaS can outlive a revocation |
| Is someone exploring where nobody legitimate should be? | Deception alerts | Scanners and inventory tools touch decoys too; exclude them at deployment |
| Was this system exposed to what the attacker used? | Vulnerability scanner, with KEV and EPSS | Agentless scans are point-in-time |
| Could the cloud configuration have allowed this? | CSPM | Configuration is not activity; confirm use in the audit log |
| What exactly happened on this host, in a form that holds up? | Targeted collection (Velociraptor, KAPE), then the forensics team | Collection can destroy evidence; preserve first |
| What did an AI assistant or agent do? | Agent action and tool-call logs, MCP gateway logs | The assistant’s own summary is not evidence of what it ran |
Each family’s capabilities and limits are on the Tool families reference page.
The tool families
Fifteen families cover the Uncover phase, each answering a class of question. What each one sees, and where it goes blind, is on the Tool families reference page; the C.A.T. glossary carries the vendor detail.
SIEM
Centralized log search and correlation. The investigation’s primary query window.
EDR
Process trees, command lines, on-host containment.
XDR
Vendor-stitched correlation across endpoint, identity, email, cloud.
ITDR
Attacks on the identity plane: directories, IdPs, tokens, sessions.
Network analysis
Wire-level observation. Catches what endpoint cannot.
Threat intelligence
Enrichment and hypothesis generation.
Deception
Anything that touches deception is suspicious by definition.
Digital forensics
Deep host analysis for confirmed cases.
Sandbox / detonation
Run the suspicious thing safely and watch what it does.
Vulnerability scanners
What is exposed and what is patched.
SOAR
Playbook execution and triage automation.
CSPM
Cloud misconfiguration and exposure visibility.
CDR
Runtime cloud detection: control-plane and workload activity, live.
Data lake
Scalable retention and ML-friendly analytics.
AI assistants and agents
Drafting, enrichment, and query generation, under the admission gate.
For hands-on practice with a SIEM (Splunk) and network analysis (Security Onion), the telemetry labs run one lab per phase on public attack data. AI assistants and agents, including the LLM agents SOAR platforms now embed beside their deterministic playbooks, work under the admission gate on the AI-assisted triage page.
Key takeaway
Tools serve the question, not the other way around. Strong analysts learn the question-to-tool mapping deliberately and reach for the right one at the right step. The common failure is running the same SIEM query against every alert and hoping. The methodology asks for the deliberate choice every time.
Next up
Uncover working example
Four walkthroughs under one standard of evidence: an endpoint intrusion, a benign true positive, a SaaS identity compromise, and a cloud control-plane alert.
See the exampleTechnical details verified . Product names, defaults and retention change; check your own tenant.