In one sentence
An IOA describes what an attacker is doing rather than what they left behind — a sequence of actions such as "a document opens a shell that downloads and executes a file" — so it detects the technique regardless of which hash, IP or domain is used this time.
Why it matters
An IOC tells you an intrusion you already know about has recurred. An IOA tells you an intrusion is happening, including one nobody has seen before, because it matches on the behaviour rather than the artefact. The attacker can recompile the malware and rent a new server in an afternoon; they cannot easily stop needing to run code, escalate privileges, dump credentials and move laterally. Those steps are the top of the Pyramid of Pain and the whole of the ATT&CK matrix.
In practice, IOA is the term EDR vendors use for their behavioural rules, and it is the design principle behind Sigma: a rule that says Word spawned PowerShell with -enc fires on every macro-phishing campaign of the last decade, whatever the payload.
IOC vs IOA, concretely
| IOC | IOA | |
|---|---|---|
| Answers | "Has this happened here?" | "Is this kind of thing happening here?" |
| Example | SHA-256 9f86d0…; domain evil-cdn[.]example | winword.exe → powershell.exe -enc → outbound HTTPS to a never-seen host within 30 s |
| Lifetime | Days to weeks; dies when the attacker retools | Years; dies when the technique does |
| False positives | Low per indicator, high in aggregate (stale feeds) | Need tuning per environment (admins use PowerShell too) |
| Where it lives | Blocklists, threat-intel platforms, retro-hunts | EDR rules, Sigma rules, SIEM correlation |
| Needs | The value | Telemetry rich enough to see the behaviour: process creation with parent and command line, network connections by process, script-block logs |
The last row is the practical constraint. You cannot detect "Office spawned a shell" if your endpoints only send the Security log's 4688 events without command lines. Sysmon (Event IDs 1 process create with hashes and parent, 3 network connection, 7 image load, 8 CreateRemoteThread, 10 process access, 11 file create, 22 DNS query) and PowerShell script-block logging (4104) are the usual minimum for Windows.
Try it yourself hands-on
Turn one IOA — "an Office application spawns a command interpreter" (ATT&CK T1566.001 → T1059) — into telemetry and a rule.
- Check you would even see it. In the Windows Event ID Lookup, compare 4688 (Security: process creation — parent process and command line only with extra audit policy) against Sysmon Event ID 1 (parent image, command line, hashes, user, by default). The second is what the IOA needs.
- Open the Sysmon Config Builder. Add a ProcessCreate rule:
ParentImageends with\WINWORD.EXE,\EXCEL.EXE,\POWERPNT.EXE,\OUTLOOK.EXE— include. Add a NetworkConnect rule forImageending in\powershell.exe— include. Export the XML; it validates against the Sysmon schema and goes into your endpoint baseline. - Write the detection in the Sigma Rule Builder: log source process_creation, product windows; selection
ParentImage|endswith: '\WINWORD.EXE'andImage|endswithone of\cmd.exe,\powershell.exe,\wscript.exe,\mshta.exe; level high; tagsattack.execution,attack.t1059,attack.initial_access,attack.t1566.001. Export to your SIEM's dialect (Splunk SPL, QRadar AQL or Sentinel KQL). - Tune before enforcing: run it for a week. The finance team's macro that legitimately launches a script will fire; add its exact command line as a
filterrather than loosening the selection.
You now have a detection that will catch the next macro campaign with no IOC at all — and the Sysmon events to investigate it when it does.
Common misreadings
- IOAs are not free of false positives; they trade fewer misses for more tuning. Budget the tuning.
- Vendor "IOA" is a marketing word too. Ask which telemetry a behavioural rule uses; if the answer is "our cloud", you cannot reason about its blind spots.
- Both, not either. IOCs give fast retro-hunting after a report; IOAs give durable detection. A mature SOC runs both and feeds confirmed IOA hits back as IOCs.