Tactics Techniques and Procedures TTP: A 2026 Guide
Tactics, techniques, and procedures are the behavioral language of an adversary: tactics explain why, techniques explain how, and procedures describe the specific implementation. MITRE created the first ATT&CK model in September 2013 and publicly released it in May 2015 with 96 techniques organized across 9 tactics.
That origin matters because TTPs turn scattered security events into an operational model. A suspicious PowerShell process, an unusual cloud login, and a remote administrative connection aren't merely isolated alerts. Together, they can describe a path through an attack, one that a SIEM can detect, investigate, automate, and preserve as compliance evidence.
Table of Contents
- What TTPs Really Mean in Modern Threat Defense
- TTPs Compared to IOCs and Other Indicators
- Mapping TTPs to the MITRE ATT&CK Matrix
- Under-Covered TTP Areas Worth Defending
- Hypothesis-Driven Hunting and SIEM Correlation Rules
- Operationalizing TTPs in a Unified SIEM, SOAR, and XDR
- Tuning, Triage, and Compliance Evidence on One Loop
What TTPs Really Mean in Modern Threat Defense
MITRE designed ATT&CK to document common adversary behavior, particularly the tactics, techniques, and procedures used by advanced persistent threats. The framework has since become a shared language for threat intelligence, detection engineering, incident response, and security validation. MITRE's ATT&CK design and philosophy explains the distinction between techniques and procedures, with procedures representing concrete, observed implementations of techniques.
The three layers defenders need to separate
Tactics describe the adversary's objective. Credential Access, for example, tells you that the actor is trying to obtain authentication material.
Techniques describe the method used to pursue that objective. OS Credential Dumping is more precise than the broad tactic because it identifies the behavior defenders should recognize.
Procedures describe the implementation used by a particular actor or intrusion. MITRE's FAQ gives a concrete example: PowerShell can inject into lsass.exe and scrape LSASS memory to dump credentials. In that example, Credential Access is the tactic, OS Credential Dumping is the technique, and the specific PowerShell activity is the procedure. See MITRE's ATT&CK FAQ for the framework's definition of procedures.
That separation changes how a detection engineer writes rules. A rule that searches for one malicious script hash is tied to a single artifact. A rule that identifies a process accessing LSASS memory, especially when correlated with suspicious PowerShell ancestry and an unusual user context, expresses a behavioral hypothesis.
Practical rule: Map the event to the technique, but preserve the procedure details. The technique gives the rule a durable category. The procedure tells you what to search for, what to suppress, and which actor behaviors deserve escalation.
Indicators can expire quickly as attackers replace payloads, infrastructure, and filenames. A mapped TTP remains useful much longer because the underlying behavior often persists even when the implementation changes. When reading a threat report, extract three answers: what was the actor trying to achieve, how did the actor do it, and what exact implementation appeared in the evidence?
That habit keeps TTPs from becoming decorative ATT&CK tags. It makes them a working vocabulary for SIEM rules, EDR investigations, XDR detections, and incident timelines.
TTPs Compared to IOCs and Other Indicators
Indicators of compromise are valuable, but they're not the same thing as TTPs. A file hash, domain, URL, or IP address identifies an artifact. A TTP describes behavior that may recur across different campaigns, malware families, accounts, and infrastructure.
An IOC is often strongest at the beginning of an investigation. A known hash can support rapid triage. A blocked domain can prevent a connection. A suspicious URL can enrich an alert. But atomic indicators are brittle by design. Once an attacker recompiles a payload, changes infrastructure, or uses a legitimate service, the indicator may no longer help.
TTPs provide the durable detection layer:
- Atomic indicators support speed: Blocklists and enrichment systems can act on known artifacts immediately.
- Behavioral techniques support correlation: SIEM rules can combine process, identity, network, and cloud events into an attack pattern.
- Procedures support precision: Analysts can distinguish an expected administrative action from a suspicious implementation by examining parent process, account, target, timing, and surrounding activity.
- Threat intelligence adds context: Indicators can raise confidence or explain a technique, but they shouldn't replace behavioral coverage.
The common failure mode is an indicator-only SOC that spends its time refreshing feeds and investigating isolated matches. That creates a whack-a-mole cycle. The team reacts to what has already been identified instead of asking what an attacker must do to reach an objective.
| Dimension | TTPs (Behavioral) | IOCs (Atomic) |
|---|---|---|
| What they describe | Adversary objectives, methods, and implementations | Files, addresses, domains, URLs, and other artifacts |
| Primary use | Hunting, correlation, detection engineering, and attack-path analysis | Blocking, enrichment, and rapid triage |
| Durability | Usually survives changes to payloads and infrastructure | Can become obsolete when artifacts change |
| SIEM value | Connects events across data sources | Adds context to individual events |
| Main trade-off | Requires richer telemetry and careful tuning | Easier to deploy but narrower in scope |
The balance matters. Mature teams don't discard IOCs. They use them as enrichment around a TTP-centered detection model. Organizations building that model may also need specialist capability in collection, actor tracking, and analysis, so finding threat intelligence talent can be useful when internal coverage is thin.
The practical position is straightforward: use IOCs for immediate signal, and use TTPs for lasting advantage. That distinction justifies engineering correlation rules and response playbooks instead of investing only in larger blocklists.
Mapping TTPs to the MITRE ATT&CK Matrix
The Enterprise ATT&CK matrix organizes adversary behavior across 14 tactics, spanning the attack lifecycle from Reconnaissance and Initial Access through Impact. The live Enterprise matrix lists 216 techniques and 475 sub-techniques, according to MITRE ATT&CK. The matrix isn't a checklist that every organization must implement equally. It's a catalog that helps defenders identify which behaviors their telemetry can observe and which remain invisible.
The catalog keeps changing because adversaries and defenders keep producing new evidence. A 2025 Google Cloud M-Trends report states that Mandiant added 2 new techniques, 29 new sub-techniques, and 570 additional mapped techniques in 2024. The same report provides a useful reality check on technique prevalence: Command and Scripting Interpreter appeared in 44.6% of observed cases, Obfuscated Files or Information in 37.3%, and Remote Services in 35.3%. Those figures are reported in M-Trends 2025.
Technique mappings need implementation context
A SIEM detection is commonly mapped to the technique level because that gives security teams a stable category for coverage reporting. The procedure is where the rule becomes useful. It captures the command, process relationship, account behavior, cloud action, or system change that an actor used.
For example, a broad Command and Scripting Interpreter mapping isn't enough to build a reliable alert. The rule needs to know which interpreter appeared, what launched it, who ran it, which host was involved, what the command accessed, and whether related events indicate execution, discovery, credential access, or lateral movement.
That distinction also prevents a common reporting mistake. A matrix with a technique marked as covered doesn't prove that the SOC can detect every procedure associated with it. Coverage depends on data quality, collection scope, parser behavior, retention, and the conditions encoded in the rule.
A practical mapping process should answer:
- What data source exposes the behavior?
- Which fields identify the procedure rather than just the technique?
- What benign administrative activity resembles it?
- Which adjacent events increase confidence?
- What action follows a confirmed match?
Teams can use an ATT&CK framework integration to organize those mappings, but the framework doesn't remove the engineering work. It gives that work a consistent vocabulary.
Under-Covered TTP Areas Worth Defending
Many TTP explainers still center on phishing attachments, malicious macros, and endpoint malware. Those examples remain relevant, but they no longer describe the full attack surface of a hybrid environment. Three gaps deserve immediate attention: identity and cloud abuse, telemetry breadth, and pre-execution reconnaissance.
Identity and cloud activity
Red Canary reported that identity attacks were 4x higher year over year, and that three of its top five observed MITRE ATT&CK techniques were cloud-native and identity-enabled, with Cloud Accounts ranked number one. The finding appears in the 2025 Threat Detection Report.
That changes the evidence defenders need. A cloud account used from an unusual context, a new privilege assignment, an atypical consent action, or a burst of access to sensitive resources may provide more signal than a malware scan on a workstation. Identity logs, cloud audit trails, conditional-access decisions, and SaaS activity therefore belong in the same investigation as endpoint process events.
Telemetry breadth
Government guidance cited in MITRE's TTP-Based Hunting paper notes that process monitoring covers 155 techniques, compared with 89 for file monitoring and 85 for command-line parameters. The point isn't that process logs solve detection. They don't. The point is that telemetry choice directly affects how much of the ATT&CK model a SOC can observe.
File monitoring can show what changed. Command-line parameters can reveal intent. Process monitoring adds ancestry, execution context, and relationships between programs. A detection program that collects only one of those views will produce a coverage chart that looks more complete than the actual evidence supports.
Reconnaissance before intrusion
Attackers can learn a great deal before they execute malware or authenticate to a protected system. Automated scanning, exposed services, cloud asset discovery, and repeated probing can reveal where an organization is vulnerable. MITRE's 2025 update explicitly included Reconnaissance in ATT&CK Evaluations for cloud security, while Fortinet reported a record surge in automated scanning as attackers moved earlier in the intrusion process. The change is discussed in MITRE's cloud security evaluation announcement.
A modern program should correlate these areas rather than assign them to separate owners. Identity signals can explain cloud access. Process telemetry can validate endpoint execution. Reconnaissance data can explain why a newly exposed asset becomes the target of a later intrusion.
Hypothesis-Driven Hunting and SIEM Correlation Rules
A TTP-based hunt begins by asking what adversary behavior produced the signal, then works backward to define testable evidence. MITRE's TTP-Based Hunting methodology uses hypotheses, abstract analytics, repeated pivots across data sources, and a hunting analysis space created for the U.S. Cyber Command's Cyber National Mission Force.
A useful hypothesis stays specific enough to test while surviving changes to attacker infrastructure. One example is an adversary using WMI for lateral movement, then creating a process on a remote host under an unusual account context. The hunt should join process creation, authentication, endpoint, and network telemetry instead of matching a single executable name.
Build the rule around behavior
A SIEM correlation rule should join events that express a sequence or relationship. A single indicator can start enrichment, but behavior detection needs context. A rule might require a remote logon, a WMI-related process, an unusual source host, and a destination system that the account rarely accesses. Correlation rules that tie events together are covered in our SIEM correlation rules guide.
Use a repeatable workflow:
- Form the hypothesis: Define the adversary action and its observable evidence.
- Identify data sources: Verify that endpoint, identity, network, or cloud logs contain the required fields.
- Write the correlation: Join events with appropriate time, entity, and context conditions.
- Test historical data: Check whether the logic finds known activity and how much benign activity it catches.
- Run alert-only first: Observe the rule before permitting automated containment.
- Tune with evidence: Adjust exclusions, thresholds, and joins based on analyst outcomes.
Guidance from Hadess on SIEM operations emphasizes specific logic, historical testing, alert-only deployment before automated response, and false-positive tracking for each rule. It identifies 70% false positives as a threshold requiring immediate attention through tuning, exclusions, or replacement with better logic.
Threat intelligence can test whether an identity, domain, or actor profile fits the hypothesis. Teams may consult material on open-source intelligence for verifying profiles for enrichment, while keeping the detection grounded in observed security telemetry.
A sustainable detection connects its rule, triage workflow, response action, and audit trail. UTMStack can keep that context together across SIEM, SOAR, and XDR workflows, so analysts can tune correlation logic before response automation acts.
Operationalizing TTPs in a Unified SIEM, SOAR, and XDR
A TTP mapping has little value if it ends as a spreadsheet row. The useful implementation connects collection, normalization, correlation, triage, response, and evidence. UTMStack provides one example of a unified SIEM, SOAR, and XDR approach for that workflow.
The platform ingests telemetry from cloud services, network devices, and endpoints through APIs, Syslog, NetFlow, and agents. It correlates events in real time before indexing to reduce noise, which matters when a detection depends on relationships between events rather than one log line.
Start with the evidence needed for the technique
The modular stack includes log management, vulnerability scanning, access rights auditing, endpoint protection, dark web monitoring, and file tracking. Those sources address different parts of the TTP problem:
- Endpoint and process data expose execution and persistence behavior.
- Access-rights data helps identify privilege and identity misuse.
- Vulnerability and asset information adds exposure context.
- Network and flow telemetry supports lateral movement and command-and-control analysis.
- File tracking helps identify changes that support defense evasion or persistence.
The objective isn't to collect everything indiscriminately. It's to collect the fields required to test the procedures behind the techniques. A matrix entry marked “covered” should connect to an actual event source, a parser, a rule, an analyst workflow, and a response decision.
Connect detection to triage and containment
Suppose a correlation rule identifies a suspicious cloud account action followed by endpoint access and a remote administrative connection. The rule maps the activity to relevant ATT&CK techniques and creates an alert with the related entities. An integrated large language model can assist with alert triage, summarize the event chain, and help analysts tune the rule to reduce false positives. Human review still matters, particularly before a response action affects a privileged account or production host.
The SOAR layer can then run a predefined or custom playbook. Depending on the organization's approval model, that may involve isolating an endpoint, disabling an account, collecting additional evidence, or notifying an incident channel. The essential design choice is to keep the decision traceable: the triggering behavior, analyst reasoning, response action, and outcome should remain connected.
Organizations evaluating threat detection and response solutions should examine that entire chain, not just the number of integrations. A platform can ingest many sources and still fail if analysts must move between separate consoles to understand an alert or prove what happened.
Preserve compliance evidence as a byproduct
Unified workflows can map detections and collected evidence to CMMC, HIPAA, SOC 2, ISO 27001, PCI, GDPR, and GLBA. The compliance value comes from preserving the operational record, not from attaching a framework label after the incident. Logs, rule logic, alert decisions, response actions, and review history form a more defensible evidence trail when they remain connected.
UTMStack also provides a threat library with more than 30 billion IOC elements. Those elements can enrich a TTP-driven investigation with reputation and context, but they shouldn't replace behavioral detections. The strongest design uses the library to add confidence while the correlation rule explains what the actor did.
Tuning, Triage, and Compliance Evidence on One Loop
The operational advantage of TTP-driven defense appears after the first alert. Analysts tune the detection, hunters test the hypothesis against new data, responders improve the playbook, and compliance teams reuse the same records as evidence. That feedback loop is more valuable than a static ATT&CK coverage report because each function improves the others.
A single investigation can produce several useful outputs:
- Detection evidence: The raw events and normalized fields supporting the technique mapping.
- Tuning evidence: The exclusion, threshold, or condition changed after analyst review.
- Response evidence: The playbook action, approval, execution result, and recovery step.
- Audit evidence: The timestamps, ownership, review history, and control mapping required for HIPAA, GLBA, CMMC, PCI, or ISO 27001 work.
The discipline is simple, but it must be enforced consistently. Start with the ATT&CK techniques that matter most to your environment, map each one to the telemetry and rules that observe it, and verify that the resulting alert can produce evidence an auditor will understand.
A practitioner checklist
- Map your top 20 ATT&CK techniques: Connect each technique to specific SIEM rules, data sources, procedures, and owners.
- Control false positives: Use LLM-assisted triage and rule tuning to push noisy detections below the 70% false-positive threshold described in the SIEM operations guidance.
- Stage response automation: Run new playbooks in alert-only mode before permitting containment or account actions.
- Validate the evidence path: Confirm that every mapped technique produces the logs, alert history, response record, and control mapping an auditor may request.
- Review coverage by environment: Test identity, cloud, endpoint, network, and reconnaissance visibility separately rather than relying on one aggregate score.
A unified, open-source SIEM, SOAR, and XDR platform can keep this loop in one operating model. For mid-sized and enterprise teams, that reduces the friction of maintaining separate consoles for detection, response, threat intelligence, and compliance reporting. UTMStack is backed by Linux Foundation membership and broad integrations, and its open-source licensing model avoids paying per event while supporting a consolidated workflow.
UTMStack combines SIEM detection, SOAR playbooks, XDR telemetry, ATT&CK-aligned correlation, LLM-assisted triage, and compliance evidence management in one platform. Visit UTMStack to evaluate how its unified workflow can help your team turn TTPs into tunable detections, controlled response actions, and audit-ready records.
