What is IOA (Indicator of Attack)?

An IOA describes what the attacker has to do; an IOC describes what the attacker happened to use. That difference decides when each one can fire, and the clearest way to see it is one intrusion written down twice.

The intrusion

(Simulated example generated by SOCSimulator Research; the address comes from a documentation range.)

At 09:14 a user in finance opens invoice_0923.docm from an email. The macro runs, and WINWORD.EXE starts powershell.exe -NoProfile -EncodedCommand followed by a base64 block. PowerShell downloads a DLL from 203.0.113.50 into the user's AppData folder and runs it with rundll32.exe. From 09:16 the DLL calls the same address every 60 seconds.

Written as IOCs, the intrusion is a list

• the SHA-256 of invoice_0923.docm,
• the SHA-256 of the DLL,
• the IP 203.0.113.50,
• and the download URL.

Each one is exact and cheap to search. None of them was in any feed at 09:14, because the campaign was new. They fire on the second victim, or on this one in a retro-hunt, once someone has pulled them out of an infected host and shared them. They stop firing the day the attacker rebuilds the document and moves the server.

Written as IOAs, the same intrusion is a set of behaviors

• an Office application starting a script interpreter,
• PowerShell with an encoded command line,
• a DLL written into a user profile and loaded by rundll32,
• and a process calling out on a fixed interval.

None depends on a hash or an address, so the first one can fire at 09:14 on the first victim. MITRE ATT&CK catalogues this opening as User Execution: Malicious File (T1204.002) and notes it is typically observed as follow-on behavior from a spearphishing attachment. The price is noise. Some line-of-business macros legitimately start cmd.exe or PowerShell, so an IOA rule needs an allowlist and an analyst who reads the command line.

Vendors ship IOAs as built-in controls

Microsoft Defender's attack surface reduction rule Block all Office applications from creating child processes (GUID d4f940ab-401b-4efc-aadc-ad5f3c50688a) is the opening of this intrusion turned into a rule. It covers Word, Excel, PowerPoint, OneNote, and Access. In audit mode it records matches as AsrOfficeChildProcessAudited in advanced hunting, and as AsrOfficeChildProcessBlocked once it enforces. Microsoft's own documentation warns that line-of-business apps may start Command Prompt or PowerShell for benign reasons, which is the usual argument for running it in audit before blocking.

To hunt the same IOA yourself in Defender advanced hunting:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "powerpnt.exe", "onenote.exe", "msaccess.exe")
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine

Sort the hits by ProcessCommandLine. An encoded command, a URL, or a path under AppData or Temp is the attack shape. The same script on a file share, run by the same few people on a monthly schedule, is an allowlist candidate, and the ticket should name the macro's owner.

In practice the two work in sequence

The IOA catches the first host. The analyst confirms it, pulls the IOCs out of that host (the document hash, the DLL hash, 203.0.113.50), and searches every other endpoint, mailbox, and proxy log for them. That sweep is how you learn the intrusion reached three hosts instead of one, and it is fast precisely because the indicators are exact. Indicator age, feed confidence, and why a stale IP turns into false positives belong to the IOC side; the IOC entry in this glossary covers them.