Every SOC analyst and detection engineer has felt it. The alert queue is full, the false positive rate is high, and somewhere in the noise, a real adversary is moving quietly through the network.
Signatures handle known and previously seen threats, and they do it quickly. Another commonly used detection engine, anomaly detection, catches statistical deviations from a learned baseline. Anomaly detection is often also called behavior-based detection because it looks for deviations in behavior. Both are necessary. But there is still a detection gap between them: The attacker who knows your tools, deliberately stays under your thresholds, and uses legitimate protocols to blend in. That attacker does not have a known fingerprint, and their behavior is close enough to normal that an anomaly model may not trigger until it is too late.
To close that gap, you need a different detection capability: behavior-based detection built on detecting tactics, techniques, and procedures (TTPs). This is also where implementing Detection-as-Code makes the most sense. It is the layer most vendors lack, either capability or they deliver as a black box that cannot be inspected, tuned, or trusted.
Signatures are fast and provide high-confidence alerts against known and documented threats. They are also designed to work as a reactive solution. A signature encodes something previously seen, named, and cataloged. An attacker who recompiles malware, rotates infrastructure, or leverages built-in system tools walks straight through this defense.
Anomaly detection solves a different problem. It builds a baseline of normal behavior and flags statistically significant deviations. It does not need a prior description of "bad," only a confident model of "normal." While that makes it valuable for detecting novel or unknown threats, the challenge is that it requires time to build a reliable baseline, often up to 31 days, and without a way to validate deviations as malicious, it can generate noise that strains analyst capacity. Neither method on its own answers the question: Is this specific sequence of actions a known attacker technique?
That is the problem TTP-based behavioral detection is built to solve.
Where signatures match artifacts and anomaly detection flags deviations, TTP-based behavioral detection actively hunts for specific, well-researched sequences of attacker behavior mapped directly to the MITRE ATT&CK framework. It does not wait for a baseline to mature or for a signature to exist. It detects what attackers do, not just what they leave behind.
The mechanics matter here. The foundation that makes this possible is the Zeek® event-driven scripting language. It parses network traffic and fires events on meaningful protocol behaviors. Scripts then evaluate those events against defined behavioral thresholds that represent known attacker techniques, such as credential dumping, lateral movement using Remote Desktop Protocol (RDP), command-and-control (C2) beaconing, DNS exfiltration patterns, and more. Results are logged in structured, queryable files: conn.log, http.log, dns.log, weird.log, and others. Correlating additional events increases alert confidence scores, and the analyst receives a single, high-fidelity alert that maps directly to the attacker's progression through the kill chain.
While we usually think of anomaly detection when we refer to behavior-based detection, the key difference here is determinism. A TTP-based detection does not ask, "Is this unusual?" It asks, "Does this match the known behavior of a previous attack, like credential-access or lateral-movement technique?" That means it can find those behaviors even when they are reused in new attacks. That produces fewer alerts with higher confidence, and it gives analysts the attacker's narrative rather than a possibly isolated data point to investigate from scratch.
The durability advantage is equally significant. An attacker can update a binary to have a new hash in seconds and rotate to a new domain in minutes. Changing their fundamental technique is expensive, because the technique is the attack. To move laterally, they have a limited set of tools to move across the network. TTP-based logic targets the part of the kill chain they cannot avoid without abandoning the objective.
TTP-based behavioral detection is not a replacement for the other layers. It is the layer that makes the whole stack more effective.
A mature multi-layered detection architecture typically employs detection engines like these:
Each layer handles what the others cannot. Signatures are fast but reactive. Anomaly detection is broad but requires time and tuning. TTP-based behavioral detection is the precise, timely, technique-focused layer that sits between them: it does not need a prior signature to exist, and it does not need weeks to establish a baseline before it becomes effective, focusing on known types of behavior used in attacks.
Most vendors who offer behavioral detection deliver it as a proprietary AI model you cannot examine. You see the alert, but you do not see why it triggered. You cannot tune it for your environment, verify that it actually maps to the ATT&CK technique it claims to detect, or understand why it fired.
That is the black-box problem, and it matters most in the exact detections where you need to trust the output: high-confidence alerts on evasive threats and lateral movement, including C2 and credential-access activity that may require a significant response.
Corelight's TTP-based behavioral detection is built on Zeek scripting. The alerts generated from these scripts explain why they triggered, providing both evidence and detection logic. SOC analysts can easily understand exactly what conditions triggered the alert and respond appropriately for their environment.
In addition to the Corelight-provided collections, you can bring custom Zeek scripts from the community or write your own, and they run on the same engine as the provided detections. For a detection engineering team committed to Detection-as-Code practices, this capability is the difference between a platform you own and a service you rent.
The underlying telemetry reinforces this. Corelight sensors transform raw network traffic into high-fidelity, structured Zeek logs across 70+ protocol data types, including east-west traffic, encrypted sessions, and ICS/OT environments that endpoint tools cannot see. Every entity is assigned a unique identifier (UID) at ingestion. That UID links related events (DNS queries, TLS handshakes, file transfers, and authentication attempts, and more) into one corroborated narrative. A behavioral alert arrives already stitched to the evidence needed to validate, escalate, or close it, with no manual cross-console correlation required.
Writing TTP-based detections from scratch against relevant ATT&CK techniques is a significant investment. Corelight Collections solve this with curated packages of Zeek-powered detections, enrichments, and analytical scripts. Each collection targets a specific security domain and is built using the same open foundation as the platform itself.
Collections combine both IOC-based and TTP-based detection in a single package. They scan for known-bad artifacts while simultaneously analyzing attacker behavior patterns, casting a wider net across both documented and emerging threats. When a detection from a Collection fires, it does not raise a generic flag. It generates an alert enriched with the full network evidence: connection logs, file details, DNS context, and the specific behavioral indicators that triggered the alert.
Here is what each Collection delivers.
Core Collection. The foundational package included with every Corelight subscription. It detects evasive and lateral movement mapped to MITRE ATT&CK techniques in the areas of Server Message Block (SMB) and DCE-RPC traffic, port scanning, cryptomining, HTTP stalling, and long connections. The package also features enrichments like Community ID for cross-tool pivoting, DNS hostname annotation in conn.log, POST data capture, and Windows version identification. It also provides data reduction and traffic shunting options to lower Security Information and Event Management (SIEM) ingestion costs by up to 30%.
C2 Collection. Focused specifically on identifying the communication channels attackers use to control compromised systems. It provides over 50 detections for known C2 activity, including traffic from frameworks like Cobalt Strike and Sliver, mapped to MITRE ATT&CK C2 techniques. It combines behavioral analysis of beaconing patterns, connection timing, and byte-ratio anomalies with IOC-based detection, catching C2 hiding inside legitimate protocols where signatures fail to detect.
Encrypted Traffic Collection. Addresses the visibility challenge created by the fact that most attacker traffic is now encrypted. Rather than requiring decryption, this Collection analyzes metadata, handshake properties, and behavioral characteristics of TLS, SSH, and RDP sessions. It includes analytics like JA3 client fingerprinting to detect non-standard clients, and it surfaces C2, malware, and unusual data transfers without the privacy and performance overhead of decryption.
Entity Collection. Brings clarity to complex environments by correlating network activity back to specific assets: users, devices, hosts, services, certificates, and domains. It identifies 80+ applications, generates hourly subnet summaries, and pre-aggregates entity activity logs so analysts can answer "who did what, where, and when" without manually querying large datasets. This context is essential for uncovering evasive threats, lateral movement, and privilege escalation.
ICS/OT Collection. Tailored for industrial control systems (ICS) and operational technology (OT) environments where standard IT monitoring tools cannot decode industrial protocols. It identifies and analyzes protocols including Modbus, DNP3, and EtherCAT, detects policy violations, and enriches logs with context unique to supervisory control and automation systems, bridging the visibility gap between IT and OT security.
Analyzers Collection. Extends visibility across more than ten additional network protocols, covering areas such as VPNs (OpenVPN, WireGuard, IPsec), directory services (LDAP), file sharing (SMB), and event notification protocols (SSDP, GENA). By generating enriched logs for these protocols, it surfaces lateral movement and unauthorized access in administrative and file-sharing traffic that would otherwise be invisible.
Each Collection runs on Corelight's open Zeek framework, which means every detection it generates is backed by the full corresponding network evidence. When an alert fires, you have the complete connection log, any file transfer details, DNS queries, and the behavioral indicators that triggered it, all linked by UID into a single investigative thread. That is what transforms a detection from a flag into evidence.
The case for TTP-based behavioral detection is not that it replaces everything else. It is that without it, your stack has a gap attackers know how to exploit.
Signatures handle the known efficiently. Anomaly detection surfaces deviations you did not anticipate. TTP-based detection provides the precise, timely, technique-focused layer in between: it evaluates what attackers are doing right now against a framework of known malicious behavior, without waiting for a signature to exist or a baseline to mature. Built on Zeek scripting and packaged into production-ready collections covering C2, encrypted traffic, entity visibility, ICS/OT, and beyond, it is the layer that gives your detection program coverage where evasive adversaries operate.
Corelight automatically maps your alerts against MITRE ATT&CK, giving teams a clearer understanding of the threat. It helps fill the gaps in detecting evasive threats, C2, lateral movement, and exfiltration where signatures fail and anomaly models can take weeks to learn and become effective. That is where TTP-based detection earns its place, and where Corelight gives you immediate coverage backed by evidence you can trust.
Take the next step and get a demo of the Corelight Open NDR platform.