Hypotheses, telemetry, and human judgment: Inside Cisco Talos Threat Hunting

By Ron Scott-Adams

Most security tools operate on a simple principle: If a known-bad pattern appears, fire an alert. This works well enough for many threats, but it fails against adversaries who closely study detection thresholds and deliberately stay under them. 

Cisco Talos Threat Hunting operates on a different principle. Instead of waiting until we’re sure we can cross an alerting threshold, we start with a hypothesis about what specific adversary behavior would look like in the telemetry, and then search for it. Using both AI and human-driven processes, including pioneering hunts built from Talos’ latest threat research, we continuously search for threats that traditional detection misses.

These hunts operate at the leading edge of our intelligence, where patterns are compelling but require expert judgment to distinguish from benign activity. Talos threat analysts provide this judgement to ensure maximum fidelity for your threat landscape. 

This post covers how that works in practice.

Hypothesis-driven hunting vs. alert-driven detection 

A detection rule says, "If X happens, alert." A hunt hypothesis says, "Given this specific threat actor uses these specific techniques, what would those techniques look like in this specific telemetry source?" 

The distinction matters because it inverts the workflow. Detection requires prior knowledge encoded into a rule. Hunting requires only a plausible theory about adversary behavior and the telemetry to test it against. 

Our hypotheses come from multiple sources: active threat intelligence on adversary tradecraft, findings from Cisco Talos Incident Response engagements, and patterns observed across global telemetry from nearly 50 million sensors. When Talos sees a new technique in the wild, we can build a hunt for it before a detection signature exists.

Here are a few examples of these threat hunts:

• Python User-Agent connections to malicious ASN infrastructure. Legitimate Python HTTP requests exist in most environments, but Python calling out to hosting providers with poor reputation scores is a different signal entirely. 
• MSIEXEC User-Agent making connections to suspicious or malicious ASNs. MSIEXEC fetching remote packages is a known living-off-the-land (LOTL) technique. The user-agent string persists in firewall connection logs even when the payload itself is encrypted. 
• Domain generation algorithm (DGA) detection via AI/ML. Algorithmically generated domains have statistical properties (character distribution, entropy, n-gram frequency) that distinguish them from human-registered domains. Our models flag DNS queries that match these patterns. 
• Connections to EVILEMPIRE ASN ranges. Certain autonomous systems have a long, documented history of hosting command-and-control (C2) infrastructure. Outbound connections to these ranges warrant investigation regardless of the specific destination IP. 
• User-Agent and application outliers. Baseline what's normal for an environment, then surface what deviates. A curl binary running on a finance team's workstation at 2am is not the same signal as curl running in a CI/CD pipeline. 
• Endpoint detection and response (EDR) research findings correlated with network indicators of compromise (IOCs). When endpoint telemetry reveals a new threat, the associated network indicators become hunt targets across firewall data for all customers.

Each of these hunts runs continuously. The AI engine executes them at scale, 24 hours a day, across all enrolled customer environments. It surfaces candidates. Then a human analyst investigates.

Case study: KongTuke C2 discovery through multi-domain correlation 

The value of correlating telemetry across security domains is easiest to explain with a real example. During a recent engagement with a customer, Talos analysts identified active KongTuke C2 activity by combining firewall and endpoint data in a way that neither source could have accomplished alone. This is the kind of continual awareness we are seeking to bring to customers everywhere with Talos Threat Hunting.

What the firewall showed 

Cisco Secure Firewall telemetry recorded outbound ConnectionEvents to “144.31.221.82” on port 6060, with a URL path of /capcha9856. This pattern is consistent with a Traffic Direction System (TDS) infection, where a compromised website redirects visitors through a chain of intermediate servers before landing on a malicious payload host. 

The firewall gave us the "what" and "when" — a specific device was reaching out to known-bad infrastructure at a known time. But the firewall alone could not tell us how the connection was initiated or what happened next on the host.

What EDR added 

Pivoting to Cisco Secure Endpoint data for the same DeviceIP, we pulled the full process history around the time of the connection. The endpoint telemetry revealed:

1. A cmd.exe process spawning powershell.exe with an -EncodedCommand parameter containing a Base64-encoded payload 
2. The decoded payload executing Invoke-WebRequest to fetch a file named script.ps1, dropping it into the user's ApplicationData directory 
3. A separate curl.exe process making requests to the same C2 infrastructure the firewall had flagged 
4. Post-execution cleanup via Remove-Item, attempting to delete traces of the downloaded script

Why neither source alone was sufficient 

The firewall saw an outbound connection to a suspicious IP. That's useful, but not conclusive on its own. Hundreds of legitimate services might generate similar connection patterns. The EDR saw obfuscated PowerShell execution. That's suspicious, but without the network context confirming the destination was a known C2 server, it could be a false positive from an overzealous admin script. 

Together, they told a complete story: initial compromise via TDS redirect, payload delivery through encoded PowerShell, C2 communication confirmed by both endpoint process tree and network connection logs, and active evidence of anti-forensics (file cleanup). This is a confirmed intrusion with clear remediation steps, not an ambiguous alert requiring hours of analyst triage. 

Broader sweep 

Once we had the process hashes and file paths from EDR, we searched across the full customer environment for other hosts exhibiting the same behavior. This turned a single finding into a scoped understanding of how far the compromise had spread.

How AI and human analysts divide the work 

Talos Threat Hunting runs on a hybrid model where each component does what it's best at. 

The AI engine handles volume and persistence. It executes hundreds of hunt hypotheses continuously across all customer environments. It applies statistical models (DGA detection, behavioral baselining, anomaly scoring) to telemetry streams at a scale no analyst team could match. Its job is to reduce the search space by taking the full volume of telemetry and surfacing the subset that warrants human attention. 

Human analysts handle context and judgment. A statistical anomaly is not the same as a confirmed threat. Analysts validate findings by correlating across data sources, applying knowledge of the customer's environment, and making determinations that require understanding adversary intent. When an analyst confirms a finding, the customer receives a written notification explaining what was observed, why it matters, how it maps to known techniques (MITRE ATT&CK or equivalent), and specific remediation guidance. 

This is not "AI finds threats and humans approve them." The AI surfaces candidates from a space too large for humans to search manually. Humans then do investigative work that AI cannot always reliably perform: understanding whether a particular behavior is malicious or benign given the full operational context of that specific environment.

The feedback loop: Hunting improves detection 

Every confirmed finding is first reported to the customer, then evaluated for a second question: “Should this have been caught by automated detection?” 

If the answer is yes, that means a detection gap exists. Maybe a rule needs tuning, a sensor configuration needs adjustment, or the customer's policy allows something that creates unnecessary exposure. In each case, the finding feeds back into product improvement or customer-specific configuration recommendations.

This creates a cycle: Intelligence drives hypotheses, hypotheses drive hunts, hunts produce findings, findings improve detection, and better detection raises the bar for what qualifies as "between the alerts." The space we hunt in gets harder to exploit over time. 

What this means for your security team 

If you have a mature SOC, this covers the ground your team is not currently reaching. These hypotheses are built from global threat intelligence, executed continuously, across telemetry your analysts may not have time to proactively search. The findings are validated before they reach you, so they add signal without adding noise. 

If you are running a lean security operation, this provides a hunting capability that would otherwise require dedicated headcount, specialized tooling, and the institutional knowledge to know what "normal" looks like well enough to spot deviations. 

Either way, the output is not more alerts. It's written findings with context, mapped to adversary techniques, with clear next steps that you can act on directly. To learn more, contact your Cisco account team and explore what’s possible with Cisco Talos.  

Some products or features described may be in various stages of development and offered on a when-and-if available basis. Cisco reserves the right to change delivery timelines and will have no liability for any delays or failures to deliver.  

from Cisco Talos Blog https://ift.tt/XhyNnip
via IFTTT