Security teams ingest millions of indicators of compromise and still miss intrusions, because the attacker changed an IP address, recompiled a binary or simply logged in with a valid credential. Indicators of compromise (IOCs) are observable artefacts, such as a file hash, IP address or domain, that show a known threat has been present. Indicators of attack (IOAs) are behaviours, such as a web server process spawning a shell or a service principal authenticating from a network it has never used, that show an attack is in progress whatever tools are involved. This guide defines both, explains how they relate to the Pyramid of Pain, shows how to express and share them with STIX 2.1, TAXII and MISP, covers ageing and expiry, and gives identity-specific IOAs for human and non-human identities. It is written for SOC analysts, detection engineers and threat intelligence teams.
Key takeaways
- IOCs answer "has this known thing been here?" They are fast to deploy, precise for retrospective hunting and cheap for an attacker to change.
- IOAs answer "is someone doing something an attacker would do?" They survive tool changes because they describe behaviour, but they need context, baselines and tuning.
- Use both, for different jobs: IOCs for blocking, enrichment and scoping an incident; IOAs for primary detection, especially of valid-account abuse where no malware exists.
- Every indicator needs an expiry: STIX 2.1 gives every Indicator a required
valid_fromand an optionalvalid_until; an IP address from last year's report is mostly noise today. - Identity attacks are mostly IOA problems: token replay, impossible travel and a machine identity used from a new autonomous system rarely come with a hash to match.
Definitions and the core difference
NIST SP 800-150, the Guide to Cyber Threat Information Sharing, describes cyber threat information as including indicators of compromise, the tactics, techniques and procedures (TTPs) threat actors use, recommended actions to detect, contain or block attacks, and findings from incident analysis. IOCs sit at the artefact end of that list; IOAs are detections built on the TTP end. The IOA term itself was popularised by endpoint security vendors and is not defined in a formal standard, so define it in your own detection documentation.
| Dimension | Indicator of compromise (IOC) | Indicator of attack (IOA) |
|---|---|---|
| What it is | An artefact left by known malicious activity | A pattern of behaviour consistent with attacker objectives |
| Typical examples | SHA-256 hash, C2 IP address, phishing domain, mutex, registry key | Office process spawning a script interpreter; mass file renames; new OAuth consent followed by mailbox export |
| Timing | Often after the fact (evidence of compromise) | During the attack (intent and progression) |
| Source | Threat intelligence feeds, incident reports, sandboxes | Detection engineering, ATT&CK techniques, red team findings |
| False positive driver | Shared infrastructure (CDNs, cloud IP ranges, VPN exits) | Legitimate admin and automation behaving like an attacker |
| Shelf life | Hours to months | Years, as long as the technique is used |
| Expressed as | STIX patterns, blocklists, YARA, Suricata signatures | Sigma rules, EDR behavioural rules, SIEM correlation, UEBA models |
| Attacker cost to evade | Low | High: they must change how they operate |
Types of IOCs and how long they last
David J Bianco's Pyramid of Pain ranks indicators by how much pain denying them causes an adversary: hash values, IP addresses, domain names, network and host artefacts, tools, and TTPs at the top. The higher you detect, the more the attacker must change. See the Pyramid of Pain Guide.
| IOC type | Examples | Typical useful life | Best use | Main pitfall |
|---|---|---|---|---|
| File hashes | SHA-256, SHA-1, MD5 of a sample | Until the next build; polymorphic malware changes per victim | Retrospective hunts, EDR blocklists, scoping | One recompile defeats it; never rely on MD5 alone for blocking |
| IP addresses | C2 servers, scanning sources, exfiltration hosts | Days to weeks; cloud and VPS addresses are reassigned | Enrichment, short-lived blocking, log scoping | Shared hosting, CDN and VPN exits produce false positives |
| Domains and URLs | Phishing domains, C2 domains, payload URLs | Weeks; newly registered domains rotate quickly | DNS and proxy blocking, email filtering | Compromised legitimate sites cannot simply be blocked |
| Network artefacts | URI patterns, user-agent strings, TLS client fingerprints | Months, until the tool is reconfigured | IDS signatures, proxy detections | Easy to mimic legitimate clients |
| Host artefacts | File paths, registry run keys, mutexes, scheduled task names, service names | Months | EDR queries, YARA rules, forensic triage | Renamed easily by a careful operator |
| Tool signatures | YARA rules matching code structure of a malware family | Months to years | File and memory scanning | Performance cost and tuning effort |
- Atomic, computed and behavioural: a useful working split is atomic indicators (an IP, a domain), computed indicators (a hash, a YARA match) and behavioural indicators (a sequence of actions). The first two are IOCs; the last is the basis of IOAs.
- Context makes an IOC usable: an indicator without first-seen date, source, confidence, associated threat and intended action (block, alert, enrich) cannot be safely automated.
- YARA for files, Sigma for logs: see the YARA Rules Guide and the Sigma Rules Guide.
IOAs as behaviours
An IOA describes what the attacker is trying to achieve, usually mapped to a MITRE ATT&CK technique, and is detected through sequences and context rather than single values.
| IOA | Behaviour to detect | Telemetry | ATT&CK |
|---|---|---|---|
| Password spraying | Few attempts per account across many accounts from one source or ASN | IdP sign-in logs | T1110.003 Password Spraying |
| Valid account from unexpected context | Successful sign-in from new country, ASN or device for a dormant account | IdP and VPN logs | T1078 Valid Accounts |
| Cloud credential abuse | Long-lived key suddenly used for enumeration and policy changes | Cloud audit logs | T1078.004 Cloud Accounts |
| Session or token replay | Same session ID or refresh token used from two networks; token use without matching sign-in | IdP, proxy and application logs | T1539 Steal Web Session Cookie, T1550.001 Application Access Token |
| Command and control beaconing | Regular-interval HTTPS to a rare destination from a server | Proxy, DNS, NetFlow | T1071.001 Web Protocols |
| Ransomware preparation | Mass file rename or rewrite with high entropy, backup deletion | EDR file events | T1486 Data Encrypted for Impact |
- Baselines: most IOAs depend on knowing normal. Build per-entity baselines (usual ASNs, user agents, hours, API calls) before alerting on deviation.
- Sequences beat single events: a new inbox rule is routine; a sign-in from a new ASN followed within minutes by a new inbox rule and a mass download is an attack chain.
- Write IOAs as detection-as-code: version, test and map them to ATT&CK. See the Detection Engineering Guide.
Identity IOAs for human and non-human identities
When the attacker uses a valid credential there is often no malware and no IOC on the endpoint. Identity providers and cloud platforms ship behavioural detections that are, in effect, IOAs. Microsoft Entra ID Protection, for example, documents atypical travel (real-time), impossible travel (offline, via Defender for Cloud Apps), anomalous token, token issuer anomaly, unfamiliar sign-in properties and password spray. Amazon GuardDuty documents UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS, raised when EC2 instance credentials are used from a host outside AWS, and a family of AnomalousBehavior findings for unusual credential access, persistence and exfiltration API calls.
| Identity IOA | Human identity signal | Non-human identity signal |
|---|---|---|
| Location anomaly | Impossible or atypical travel between sign-ins | Service principal, API key or workload credential used from a new ASN, country or a residential or VPN range |
| Token replay | Session cookie used from a second network with no new sign-in | Instance or pod credential used outside its cloud or cluster |
| Client anomaly | New browser or device for a privileged user | New user agent or SDK for a CI token or integration that always uses the same client |
| Dormant credential activity | Leaver or long-inactive account signs in | Unrotated key unused for months starts calling APIs |
| Privilege change | New role assignment outside change windows | New credential or secret added to an application or service principal |
| Volume anomaly | Mass download or export | Enumeration of every bucket, table or repository the identity can reach |
Machine identities are easier to baseline than people: they connect from a small set of networks, with one client, on a schedule. That makes "NHI used from a new ASN" one of the highest-fidelity IOAs available. See the ITDR Guide, the Token and Session Security Guide and the MITRE ATT&CK T1078 Valid Accounts Guide.
Expressing indicators in STIX 2.1
STIX 2.1 separates what was seen (Observed Data), how to detect it (Indicator) and what the behaviour is (Attack Pattern). Per the OASIS STIX 2.1 specification and its JSON schemas, the Indicator object:
- Requires
pattern,pattern_typeandvalid_from; optional properties includevalid_until,indicator_types,kill_chain_phasesandpattern_version. - pattern_type is an open vocabulary:
stix,pcre,sigma,snort,suricata,yara. So a STIX Indicator can carry an IOC (a STIX pattern such as[file:hashes.'SHA-256' = '...']) or an IOA expressed as a Sigma rule. - indicator_types is an open vocabulary:
anomalous-activity,anonymization,benign,compromised,malicious-activity,attribution,unknown. - Relationships: an Indicator
indicatesan Attack Pattern, Malware or Threat Actor, and can bebased-onObserved Data, which is how an IOC is tied to the behaviour it evidences.
Patterning in STIX is used only by the Indicator object. See the STIX and TAXII Guide.
Sharing indicators: TAXII, MISP and communities
| Mechanism | What it does | Practical notes |
|---|---|---|
| TAXII 2.1 | RESTful HTTPS protocol for exchanging CTI, designed for STIX | Discovery at /taxii2/ or DNS SRV taxii2; API Roots group Collections by trust group; media type application/taxii+json;version=2.1; poll incrementally with added_after. Channels (publish-subscribe) are reserved but not specified in 2.1. |
| MISP | Open-source threat intelligence platform for storing, correlating and sharing events and attributes | Sharing groups and distribution levels control reach; exports include STIX 1 and 2, OpenIOC, CSV, Suricata, Snort, Zeek and RPZ; sightings record where an indicator was seen |
| MISP warning lists | Lists of well-known values that cause false positives | Includes cloud provider IP ranges and popular domains; apply before any automated blocking |
| Sector ISACs and national CERTs | Curated community and government feeds | Often higher context and lower volume than commercial bulk feeds |
- Mark handling: label shared indicators with Traffic Light Protocol (TLP) markings and respect the markings you receive.
- Share behaviours, not just artefacts: a Sigma rule or an ATT&CK-mapped description helps a peer far more than a list of IP addresses that will be reassigned next week.
- Feed into the programme: see the Threat Intelligence Guide and the Threat Intelligence Platform Buyer's Guide.
Ageing, scoring and expiry
- Set expiry at ingestion: populate
valid_untilby type when the source does not: for example days for IP addresses on VPS and cloud ranges, weeks for domains, longer for hashes and host artefacts. Treat these as starting values to tune, not standards. - Score confidence and decay it: combine source reliability and age into a score that falls over time unless renewed by new sightings. MISP supports decaying models for this.
- Separate actions by score: high-confidence, fresh indicators can block; medium ones alert; old or low ones only enrich and support retrospective hunts.
- Filter known-good: run every IOC through warning lists and your own allow lists (your egress IPs, SaaS providers, CDNs) before it reaches a blocking control.
- Retro-hunt on arrival: search historical logs for a new IOC across its valid period, which is where IOCs deliver most of their value.
- Retire and record: expired indicators leave blocking controls but stay searchable for investigations.
Choosing where to invest
- Small teams: take curated IOCs from the platform you already run (EDR, email security, DNS filtering) and a sector ISAC, and spend detection effort on a small set of high-fidelity IOAs: password spray, impossible travel for privileged users, NHI from new ASN, shell from web server, mass encryption.
- Larger SOCs: run a TIP or MISP with scoring and expiry, automate retro-hunts, and maintain an ATT&CK-mapped IOA library as detection-as-code with coverage reporting.
- During an incident: IOCs lead. Extract hashes, domains and IPs from the first host and sweep the estate to scope; then write IOAs for the behaviours you observed so the next variant is caught. See the Incident Response Guide.
- When feeds are expensive: measure what each feed actually detects (true positives per month) and drop feeds that only produce blocks on shared infrastructure.
Measuring it
- Percentage of active IOCs with an expiry and confidence score (target 100%).
- True-positive alerts per feed per quarter, and false-positive rate of automated IOC blocks.
- ATT&CK technique coverage of tested IOA detections for your priority threats.
- Median time from IOC receipt to completed retro-hunt.
- Share of confirmed incidents first detected by an IOA rather than an IOC (trend should rise).
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-02 cyber threat intelligence received from sharing forums and sources | IOC and IOA intake |
| NIST CSF 2.0 | DE.AE-02 adverse events analysed; DE.AE-07 threat intelligence integrated into analysis | Enrichment and behavioural detection |
| NIST SP 800-53 Rev. 5 | PM-16 Threat Awareness Program; RA-3(3) Dynamic Threat Awareness; SI-4 System Monitoring | Sharing, threat-informed monitoring |
| ISO/IEC 27001:2022 Annex A | A.5.7 Threat intelligence | Collecting and analysing threat information |
| NIST SP 800-150 | Cyber threat information sharing | Sharing rules and community participation |
| MITRE ATT&CK v20 | T1078, T1078.004, T1110.003, T1539, T1550.001 | IOA library structure |
Common failure patterns
- Bulk feeds straight into blocking: unfiltered IP feeds block cloud ranges and CDNs, the business complains, and automated blocking is switched off entirely.
- Indicators that never expire: blocklists grow to hundreds of thousands of stale entries, slow controls down and generate alerts on reassigned addresses.
- IOC-only detection of credential attacks: in the Snowflake breach attackers logged in with infostealer-harvested passwords, mostly through commercial VPN addresses. VPN IPs alone are noisy; the durable signals were password-only logins to accounts that should have had MFA, dormant credentials becoming active and bulk table copies to temporary stages.
- Ignoring session replay: after CitrixBleed, stolen session cookies stayed valid after patching. A session appearing from a second network without a new sign-in is an IOA that patch status cannot replace, and sessions must be revoked.
- IOAs without baselines: "sign-in from new country" for every user floods the queue; scope to privileged users and NHIs, and use per-entity history.
- No feedback loop: sightings and false positives are never sent back to the TIP, so scores never improve and the same bad indicators keep firing.
Practitioner checklist
- Document your working definitions of IOC and IOA and which tools consume each.
- Require source, confidence, first-seen and
valid_untilon every ingested IOC; set type-based defaults where missing. - Apply MISP warning lists and your own allow lists before any automated block.
- Run automated retro-hunts for new high-confidence IOCs across their valid period.
- Maintain an ATT&CK-mapped IOA library as version-controlled Sigma or SIEM rules, with tests.
- Baseline every NHI (ASN, client, schedule, API set) and alert on use from a new ASN or outside its platform.
- Alert on token or session reuse across networks and include session revocation in response playbooks.
- Share behaviours (Sigma, ATT&CK descriptions) as well as artefacts with your ISAC over TAXII or MISP, with TLP markings.
- Review feed value quarterly by true positives and retire low-value feeds.
Standards and references
- OASIS: STIX Version 2.1
- OASIS: TAXII Version 2.1
- NIST: SP 800-150 Guide to Cyber Threat Information Sharing
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Valid Accounts
- David J Bianco: The Pyramid of Pain
- MISP Project: Features
- Microsoft Learn: What are risk detections? (Entra ID Protection)
Related NHI Mgmt Group resources: Threat Intelligence Guide · Detection Engineering Guide · Pyramid of Pain Guide · Sigma Rules Guide · YARA Rules Guide