Indicators of Compromise and TTPs: Turning Threat Evidence into Detection

Indicators of compromise and adversary TTPs answer different defensive questions. An indicator can tell you what specific artifact or pattern to search for. A TTP can explain what the adversary is trying to achieve and how the activity works. Neither is automatically superior, and neither becomes a reliable detection simply because it appears in a threat report.

Effective CTI preserves the context that gives an indicator meaning, extracts behavior without claiming more specificity than the evidence supports, and works with defenders to turn both into testable analytics. The result is layered coverage: current artifacts provide speed and precision, while behavioral detections provide resilience when infrastructure and files change.

This guide explains the complete path from observable evidence to operational detection. It covers terminology, indicator quality, decay, ATT&CK mapping, telemetry selection, analytic design, validation, false positives, sharing, and coverage measurement. For the wider role of this evidence in intelligence, see What Is Cyber Threat Intelligence?.

Start With Precise Vocabulary

An observable is something that can be observed or measured: an IP address, file hash, domain, email sender, registry value, certificate, process command, service creation, authentication event, or cloud API action. An observable is not inherently malicious.

An indicator is an analytic construct that describes how one or more observables may indicate malicious or compromised activity. It may be a simple value, a pattern, or a contextual rule. The statement “203.0.113.10 is an IP address” is data. The statement “connections to this address during the observation window may indicate command-and-control activity associated with this campaign” is an indicator judgment.

An indicator of compromise, or IOC, is an indicator associated with evidence that a compromise or malicious action may have occurred. The term is often used loosely for any suspicious artifact. Analysts should resist that shortcut because the word “compromise” can imply more than the evidence supports.

A tactic represents an adversary objective or the reason behind an action, such as gaining initial access, persisting, collecting information, or exfiltrating data.

A technique describes a general method used to achieve an objective. A sub-technique describes a more specific form of that method when the evidence supports it.

A procedure is the concrete implementation observed in a particular operation: the command, tool, sequence, parameters, account, or workflow used to perform the technique.

A detection is logic that evaluates telemetry to identify activity of interest. It includes data requirements, analytic conditions, context, tuning, validation, response, and maintenance. An indicator or technique description may inspire a detection, but is not one by itself.

An Indicator Without Context Is Easy to Misuse

Consider a domain observed during an intrusion. Before treating it as an IOC, ask:

• Provenance: who observed it, and was the source direct or repeating another report?
• Time: when did the activity occur, when was it collected, and is it still active?
• Role: did it host phishing, redirect traffic, deliver a payload, resolve command-and-control, or merely share infrastructure?
• Control: was it attacker-registered, compromised, rented, shared, or legitimate infrastructure being abused?
• Scope: is it tied to one sample, intrusion, campaign, actor cluster, or broad service?
• Confidence: how strongly does the evidence support the malicious association?
• Pattern: is the intended match an exact value, subdomain, URL path, certificate property, or combination?
• Lifetime: when should the indicator be reviewed or expire?
• Handling: can it be shared, and are victim or source details sensitive?
• Use: should it block, alert, enrich, hunt, or remain an investigative lead?

A match inherits none of this context automatically. A shared cloud IP used for one malicious session should not be permanently blocked for every user. A hash can identify one exact file but miss every rebuilt variant. A domain that was malicious last month may now be sinkholed, suspended, or reassigned.

Indicator quality is therefore not a property of the string alone. It is the quality of the claim surrounding the string and its fitness for the intended defensive action.

Indicator Decay, Expiration, and Confidence

Indicators have different lifetimes. A cryptographic hash remains a precise identifier for one file, but an attacker can rebuild the file instantly. An IP address can be reassigned within hours. A domain may remain under actor control for months but change roles. A certificate or registration pattern may expose related infrastructure longer, though legitimate sharing can weaken precision.

Do not assign one universal expiration period. Review or expiry should consider:

• artifact type and infrastructure volatility;
• whether the actor controls, rents, compromises, or merely transits the asset;
• first and last malicious observation;
• continuing sightings from independent sources;
• campaign status and adversary behavior;
• false-positive and blocking cost;
• remediation, suspension, sinkholing, or reassignment;
• whether the indicator is still useful for historical investigation even if it should no longer alert.

Separate status from confidence. An indicator can be high-confidence but expired for real-time blocking. It can be current but low-confidence and appropriate only for enrichment. Useful states may include candidate, active, monitoring, expired, revoked, benign, false positive, and historical.

Preserve history rather than deleting every retired artifact. Analysts investigating an older event need to know what the infrastructure meant during that period. The correct question is often not “Is this domain malicious?” but “What was this domain doing, under whose control, at the time relevant to my case?”

TTPs Provide Behavioral Context That Outlives Individual Artifacts

Attackers can replace an IP, domain, filename, or hash cheaply. Changing a reliable operating method may require new access, tooling, testing, operator training, or risk. This makes behavior valuable for durable defense.

A TTP-based assessment might explain that an actor:

1. sends a link to a reverse-proxy credential page;
2. captures credentials and a session token;
3. registers an additional authentication method;
4. creates a malicious application consent;
5. searches mail and file repositories;
6. exports selected data through a legitimate cloud service.

This sequence supplies more defensive opportunities than the phishing domain alone. Email, identity, audit, application, and data-access telemetry can each reveal part of the operation.

Behavior is not automatically unique. PowerShell, remote services, scheduled tasks, cloud storage, and administrative APIs have legitimate uses. The analyst must preserve procedure detail—the user, parent process, command structure, target, timing, sequence, privilege, resource, and surrounding events—so detection engineers can distinguish malicious implementation from normal administration.

TTPs can also change. Public reporting, defensive pressure, access constraints, new platforms, and operator turnover all affect tradecraft. Behavioral intelligence needs timestamps, campaign scope, confidence, and maintenance just as indicators do.

Map to MITRE ATT&CK at the Specificity the Evidence Supports

MITRE ATT&CK provides a shared vocabulary for adversary behavior. It helps analysts compare reporting, organize observations, communicate procedures, identify data needs, and discuss coverage. The map is useful only when grounded in evidence.

Use this mapping method:

1. Describe the observed procedure first. Record what happened in plain language with the relevant objects, sequence, and evidence.
2. Identify the adversary objective. What was the action meant to accomplish at that point in the intrusion?
3. Select the technique that best matches the behavior. Do not choose a technique because the suspected actor has used it before.
4. Use a sub-technique only when implementation evidence supports it. More specific is not more accurate if details are missing.
5. Record uncertainty and alternatives. One observation can sometimes fit more than one interpretation.
6. Keep the procedure detail. A technique ID alone discards the exact evidence detection needs.

ATT&CK is not an intrusion checklist. Actors do not have to use every technique in a tactic, and telemetry will not expose every action. A product that maps many techniques is not necessarily more complete.

Most importantly, an ATT&CK mapping does not prove detection coverage. A technique can contain many implementations across operating systems, identities, cloud services, containers, and network devices. Coverage exists only for procedures the organization can observe and analytics it has tested.

Translate Intelligence Into a Detection Hypothesis

Detection engineering begins with a hypothesis, not a technique label.

A useful hypothesis states:

• the adversary behavior and objective;
• the specific procedure or variations to detect;
• why the behavior is relevant to the organization;
• affected platforms, identities, assets, or services;
• the events the behavior should produce;
• available telemetry and known blind spots;
• legitimate activities that may look similar;
• expected response when the analytic matches.

For example, “detect scheduled tasks” is too broad. A stronger hypothesis might focus on a new scheduled task created by an unusual user or parent process, executing from a user-writable directory, shortly after an externally sourced document or remote session, on endpoints where that administrative pattern is rare.

The CTI analyst contributes adversary procedure, variants, prevalence, targeting, timing, and relevance. The detection engineer contributes data semantics, query logic, baselines, performance, test methods, deployment, and maintenance. The responder contributes triage context and action. Durable detection requires all three perspectives.

If the required telemetry does not exist, record a visibility gap rather than claiming coverage. The gap can support a logging, retention, sensor, or architecture decision. If the organization does not operate the affected platform, record the intelligence as not currently applicable and define a review trigger rather than creating a useless analytic.

Validate, Tune, and Maintain the Analytic

A detection is not complete when the query runs. It needs evidence that it finds the intended behavior at acceptable cost.

Validation should include known-positive data, controlled tests, representative benign activity, variations of the procedure, and confirmation that the required fields are populated across the intended environment. A test that checks one exact command proves only that one implementation is detectable.

Tuning should add meaningful context rather than suppressing broad categories blindly. Allowlisting an administrative tool globally may hide malicious use. Prefer scope such as approved users, hosts, parents, paths, time windows, signed configurations, change records, and expected destinations.

Triage guidance should explain why the analytic exists, which evidence to collect, how to distinguish expected use, which related behaviors to search for, and when to escalate. Without it, a technically correct analytic can create inconsistent responses.

Maintenance needs an owner, review date, version history, performance measures, data dependencies, change triggers, and retirement criteria. Revisit the analytic when platforms change, telemetry schemas move, attackers vary the procedure, false positives drift, or incident lessons reveal a blind spot.

Metrics should distinguish volume from value. Alert count alone says little. Useful measures include validated detection rate, precision, time to triage, incidents found, procedure variants covered, environmental coverage, data health, and whether the analytic creates an actionable response.

Measure Coverage at the Procedure and Data Level

A heat map showing a colored ATT&CK technique can create false confidence. Coverage should answer five questions:

1. Relevance: which threat behaviors matter to the organization’s technologies, sector, geography, and likely adversaries?
2. Observability: which data sources can reveal each procedure, and where are those sources deployed and retained?
3. Analytic reach: which procedure variations does each detection identify?
4. Validation: when and how was the analytic tested, and what evidence shows it works?
5. Response: does a match lead to a defined, timely, and effective action?

Coverage is rarely binary. An analytic may cover one Windows procedure but not the analogous cloud or Linux behavior. Telemetry may exist for headquarters but not subsidiaries. A rule may work in a lab but fail because a production sensor omits command-line fields.

Use states such as not relevant, relevant but unobservable, data available, analytic designed, tested, deployed, monitored, degraded, and retired. Record confidence and limitations for each. This turns a static matrix into a defensible engineering plan.

Prioritize gaps by threat relevance, asset criticality, likelihood, existing controls, data feasibility, and response value—not by trying to color every ATT&CK cell.

Share Indicators and TTPs So Others Can Evaluate Them

A shared IOC should include enough context for a recipient to decide whether to block, alert, enrich, hunt, or ignore it. At minimum, provide:

• the observable and exact matching semantics;
• source and collection provenance;
• first seen, last seen, collection, and publication times;
• role in the activity and relevant procedure;
• campaign, malware, or cluster relationship with confidence;
• status, expected lifetime, and review date;
• false-positive and shared-infrastructure considerations;
• handling markings and permitted use;
• recommended defensive use and supporting evidence.

Structured standards can preserve these fields and relationships, but valid syntax does not guarantee shared meaning. Producers and consumers still need common definitions for confidence, labels, object identity, revocation, sightings, and relationship scope.

Share TTPs with concrete procedure examples and data implications. “The actor uses PowerShell” is weak. Describe the execution source, parent, command form, payload handling, privilege, target, sequence, and observed variations. Remove victim-sensitive details that are not needed for defense.

Recipients should retain original provenance when enriching or redistributing intelligence. Otherwise repeated reporting can appear to be independent corroboration and time-bounded claims can become permanent labels.

Understand What Common Intelligence and Detection Formats Are For

Teams often confuse an intelligence format with a detection format. They solve different parts of the workflow.

STIX represents cyber threat intelligence as structured objects and relationships. It can describe indicators, malware, threat actors, campaigns, vulnerabilities, sightings, identities, infrastructure, locations, notes, opinions, markings, and the relationships among them. A valid STIX object carries information; it does not guarantee that the claim is correct or relevant.

TAXII is a protocol for exchanging CTI, commonly organized through API roots and collections. It transports intelligence; it does not determine the quality, modeling choices, or defensive action.

YARA rules identify files, memory, or other content through combinations of strings and conditions. They are useful for malware classification, hunting, and triage. A rule needs representative positive and negative samples, performance testing, versioning, and an explanation of what a match means.

Sigma expresses log-based detection logic in a portable rule format. A Sigma rule still has to be translated and validated against the target platform, field mappings, telemetry quality, and local environment. Portability of syntax is not portability of coverage.

Snort and Suricata rules inspect network traffic. Their value depends on traffic visibility, protocol parsing, encryption, placement, performance, and the network behavior actually available to observe.

SIEM, EDR, identity, cloud, and platform-native analytics implement detections close to their data. These may use proprietary query languages, schemas, and response actions. Preserve the platform-neutral behavior and data requirement alongside the implementation so coverage can survive a tool change.

A mature workflow can use several formats for one intelligence finding: STIX to preserve the indicator and relationships, TAXII to exchange it, YARA to identify related files, a network rule to detect communication, Sigma or native queries to find behavior in logs, and ATT&CK to describe the technique. None replaces the need for evidence, context, validation, ownership, and maintenance.

A Practical IOC-to-TTP Workflow

Use this sequence whenever a report or incident supplies new threat evidence:

1. Preserve the original observation. Record source, time, role, scope, and handling before enrichment changes the record.

2. Validate the artifact. Confirm syntax, resolution, ownership, file identity, or event meaning. Do not detonate unknown files or visit malicious infrastructure outside approved environments and procedures.

3. Establish relevance. Determine whether the organization uses the affected platform, has observed the artifact, resembles targeted victims, or exposes the required access path.

4. Extract the procedure. Explain what the adversary did with the artifact, not merely where it appeared.

5. Map behavior carefully. Select the tactic, technique, and sub-technique only to the specificity supported by evidence.

6. Choose the defensive use. Decide whether the artifact should block, alert, enrich, hunt, remain a lead, or be retained only for historical analysis.

7. Design and test behavioral coverage. Identify telemetry, analytic logic, benign overlap, variations, triage, and gaps.

8. Set maintenance. Assign status, confidence, owner, review date, expiration logic, and triggers for revision.

9. Feed results back to CTI. Sighting data, false positives, incident evidence, and procedure changes should update the intelligence assessment.

The workflow connects tactical speed with analytical discipline. Indicators reveal where to look; TTPs explain what to look for; telemetry shows whether it occurred; incidents reveal how the adversary has changed.

If the evidence becomes part of an actor or campaign claim, apply the standards in Cyber Threat Attribution. Attribution requires a separate assessment; a matching IOC or TTP does not identify an actor by itself.