TTP-based behavioral detection fills the gap between signatures and anomalies

At a glance

What this is: Corelight’s analysis says the real detection gap sits between signature matching and anomaly detection, where attackers use legitimate protocols and low-and-slow behaviour to stay under thresholds.

Why it matters: This matters because SOC and detection engineering teams need detections they can validate, tune, and trust when adversaries are deliberately avoiding known fingerprints and obvious anomalies.

By the numbers:

• Anomaly detection often needs up to 31 days to build a reliable baseline, according to Corelight.

Context

SOC teams rarely fail because they lack telemetry. They fail when the detection stack cannot distinguish known threats, abnormal behaviour, and attacker tradecraft that deliberately looks ordinary. Detection engineering matters here because the operational problem is not just volume, but whether detections are explainable enough to support response, tuning, and coverage validation.

Signatures, anomaly models, and behaviour-based techniques each solve a different part of the problem. The article’s core point is that TTP-focused detection closes the gap left when an adversary avoids both known indicators and obvious statistical outliers, which is why this topic sits squarely at the intersection of SOC operations and detection governance.

Key questions

Q: What breaks when signature and anomaly detection are the only controls in place?

A: Teams lose the middle layer that identifies attacker tradecraft when the adversary is not using a known fingerprint and is not noisy enough to stand out statistically. That creates a blind spot for low-and-slow movement, legitimate protocol abuse, and living-off-the-land behaviour. The practical failure is not absence of telemetry, but absence of technique-level interpretation.

Q: Why do evasive attackers defeat common detection models so often?

A: They change the wrapper, not the method. Recompiled malware, rotated infrastructure, and built-in admin tools can bypass artifact matching, while traffic that stays close to normal may never trigger an anomaly model. The risk rises when detection logic cannot recognise the underlying technique across different implementations.

Q: What should organisations measure to know whether behavioural detection is working?

A: They should measure whether the platform flags abnormal sequences across email, identity, and SaaS activity before the attacker completes a fraudulent action. Useful signals include token reuse across impossible combinations of device and location, unusual remote-tool usage, and payment or file activity that does not match the account’s normal behaviour.

Q: Should SOC teams prioritise ATT&CK-mapped detections over broader anomaly models?

A: They should treat them as complementary, not competing. ATT&CK-mapped detections are better for precise, high-confidence identification of known techniques, while anomaly models help surface unknown or unusual behaviour. The right sequencing is to use technique-based coverage for the highest-risk paths and anomaly detection where behavioural novelty matters most.

Technical breakdown

Why signatures miss evasive attacker tradecraft

Signatures detect known artifacts, such as hashes, rules, or previously catalogued patterns. They are efficient, but they are also brittle because attackers can recompile malware, rotate infrastructure, or use built-in tools to avoid a previously seen fingerprint. In that model, the detection logic is anchored to the object, not the behaviour. When the object changes, the control breaks. That is why signature-only coverage is useful for speed but weak against tradecraft that is intentionally adaptive. Practical implication: track which adversary techniques still have only artifact-based coverage. See the Detection Engineering Guide.

Practical implication: Use signature coverage for known threats, but do not treat it as sufficient against living-off-the-land activity or tool rotation.

How behaviour-based detection maps to ATT&CK techniques

TTP-based behavioural detection looks for sequences of actions that match attacker techniques rather than isolated anomalies or static indicators. In the article’s model, Zeek parses network events and scripts evaluate those events against thresholds associated with techniques such as credential dumping, RDP-based lateral movement, DNS exfiltration, and C2 beaconing. This is more deterministic than anomaly detection because it asks whether the observed traffic aligns with a known adversary method. The result is a higher-confidence alert tied to a kill-chain stage, not a vague statistical exception. Practical implication: align detections to ATT&CK techniques and validate that each one produces explainable evidence. See the Breach and Attack Simulation (BAS) Guide.

Practical implication: Map detections to ATT&CK techniques so analysts can see which attacker method triggered the alert and why.

Why explainability matters in detection-as-code

A black-box behavioural model can surface an alert without revealing the conditions that caused it, which leaves analysts unable to tune, verify, or trust the outcome. Detection-as-Code changes that by making the logic inspectable, versionable, and testable like any other control. The article’s architecture uses structured logs, linked entity context, and script-level logic so an alert arrives with the evidence needed to investigate. That matters because high-confidence detections are most valuable when they can be audited and adapted to local traffic patterns. Practical implication: build detections you can explain to analysts and re-run in testing, not just consume as vendor output.

Practical implication: Treat detection logic as code so teams can inspect, tune, and regression-test it before relying on it operationally.

NHI Mgmt Group analysis

Behavioural detection becomes a governance problem when vendors hide the logic. If a detection cannot be inspected, tuned, or mapped to a specific attacker technique, analysts inherit alerts without assurance. That weakens trust in the control itself, especially where response decisions depend on confidence rather than volume. The more evasive the adversary, the more important it becomes that detection logic is explainable and testable.

Signatures and anomaly models are necessary, but neither closes the adversary tradecraft gap on its own. Signatures are strong on known artifacts and anomaly models are strong on deviation, yet both can miss an attacker who uses ordinary tools and legitimate protocols. The missing layer is technique-based detection that asks whether the observed sequence matches a known kill-chain pattern. That is the practical reason detection programs need a TTP layer, not just more alerts.

TTP-based detection is the right bridge between network visibility and ATT&CK coverage. The article shows how network telemetry, structured logs, and event correlation can produce evidence that analysts can act on immediately. That is especially relevant where endpoint visibility is incomplete or where east-west movement, encrypted traffic, and administrative protocols carry the risk. Breach and Attack Simulation becomes more effective when detections are measured against attacker techniques rather than generic noise.

Detection-as-Code should be treated as an operational control, not a tooling preference. When rules are inspectable, versioned, and re-testable, SOC teams can measure coverage against real techniques and defend the logic in change review. That shifts detection engineering from vendor trust to governance and repeatability. Practitioners should evaluate whether their current detection stack can survive an attacker who changes the wrapper but not the technique.

Encrypted and east-west traffic expose the limits of perimeter-era thinking. The article’s focus on TLS, SSH, RDP, DNS, and internal movement shows that modern detection has to operate where the traffic looks normal but the sequence does not. That means security teams should invest in evidence-rich detections that bind events to entities, not just packets to rules. For practitioners, visibility without technique context is still an incomplete control.

Read next: Detection Engineering Guide

What this signals

Technique-based detection will become more important as adversaries continue to live inside normal protocol traffic. The practical shift for defenders is away from asking whether behaviour is unusual and toward asking which attacker method the evidence actually matches. That will push SOC teams to measure coverage by technique, not by alert volume, and to demand detections that can be inspected before they are trusted.

TTP visibility is now a programme design issue, not just a detection-engineering issue. When east-west traffic, encrypted sessions, and administrative protocols are where adversaries hide, teams need network evidence that can be correlated back to entities and actions. The programme implication is clear: visibility, evidence quality, and rule explainability have to be governed together, not handled as separate problems.

For practitioners

• Define ATT&CK-mapped detection coverage Inventory which attacker techniques your current signatures, anomaly models, and IOC feeds actually cover, then identify the gaps where technique-based detections are missing.
• Prioritise explainable detections for high-risk techniques Make credential access, lateral movement, and command-and-control the first techniques you cover with logic that analysts can inspect and test.
• Validate behavioural logic before relying on it Run detections through controlled testing and review the underlying conditions, not just the alert outcome, so false confidence does not become operational debt.
• Correlate network evidence to the affected entity Tie DNS, TLS, file transfer, and authentication events back to a single host, user, or service so an alert arrives with enough context to investigate efficiently.

Key takeaways

• The article’s central argument is that neither signatures nor anomaly detection fully closes the gap against evasive adversaries operating under normal-looking traffic patterns.
• The most useful control layer is technique-level detection that maps observed actions to attacker tradecraft and gives analysts evidence they can inspect.
• Detection programmes need explainable logic, not black-box alerts, if they are going to support confident triage and reliable coverage validation.

Related NHI Mgmt Group resources: Detection Engineering Guide · Breach and Attack Simulation (BAS) Guide · Security Operations Metrics Guide · Top 10 SOC Challenges

Key terms

• Ttp-Based Detection: Technique-focused detection is the practice of identifying attacker behaviour by matching actions to known tactics, techniques and procedures rather than relying on a file hash or a statistical anomaly. It is most useful when adversaries change tools but keep the same operational method.
• Detection as code: A method of managing detection logic like software, using version control, testing, and deployment pipelines. It improves change control and rollback discipline, which is especially useful when AI helps generate or tune rules that will be deployed into production.
• Anomaly Detection: Anomaly detection is the use of rules, statistics, or behavioural models to identify access patterns that differ from the expected baseline. In identity programmes, it helps surface compromised credentials, misuse of service accounts, and suspicious changes in authentication or access behaviour.
• Kill Chain: A kill chain is a sequence that describes how an attacker progresses from initial activity to objective completion. In business logic abuse, it helps defenders trace how automation, fraud, and manipulation move through stages so they can place controls earlier in the attack path and improve response consistency.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.