Glossary

#IOA #incident response #threat intelligence #detection

What is an IOA (Indicator of Attack): spotting a breach by behavior, not traces

An IOA (indicator of attack) spots a breach by the behavior of an attack in progress, not a trace. How it differs from an IOC and how small teams can use it.

Published 2026-06-11 Updated 2026-10-06 7 min read

On this page

Matching breach traces (IOCs) alone can't keep up once attackers change those traces. That's where behavior-based IOAs help. Here's the meaning and how to use them (no attack steps).

IOC vs IOA — a trace of the result vs behavior in progress

IOC (Indicator of Compromise) = a trace of the result

After-the-fact evidence: hashes, IPs, domains
Can be matched mechanically against known-bad — fast
But attackers change it easily
Inherently reactive

IOA (Indicator of Attack) = behavior in progress

The flow of technique: escalation → lateral move → exfiltration
Catches it closer to real time
Hard to change (it's the attack's essence)
Heavier to adopt — needs understanding the mechanics

Why behavior is hard to change

To an attacker, a file hash or IP is disposable. But the flow of "how to attack" is bound to the goal (gain privilege, spread, exfiltrate), so it can't be changed easily.

Flow of technique (IOA, hard to change)

↑ noticed by behavior

Hashes, IPs (IOC, changed in an instant)

Individual traces (bottom) are easy to change. The 'flow' of technique (top) is the attack's essence — hard to change = a longer-lasting indicator.

How even small teams can use it

Even without a dedicated EDR (a product that monitors endpoint behavior), the essence is watching for "behavior that differs from normal."

Know your 'normal'

Understand normal login hours, traffic volume, and which features you use. Without a baseline, you can't spot the 'difference.'

Watch for behavioral anomalies

Bulk sending at odd hours, an unfamiliar resident process, repeated use of admin features you don't normally touch, a burst of login attempts — movements that show the flow of an attack.

On a hit, isolate and investigate

Cut off the affected device/key/token and scope the impact. Record the traces (IOCs) too.

Keep it paired with IOC matching

Use IOAs to notice 'an anomaly happening now,' and IOCs to match 'known-bad.' Use both, not one.

IOA examples by attack stage

An IOA only works once you decide what to watch. Grouping by stage is easiest using MITRE ATT&CK (a public knowledge base that organizes attacker techniques by stage).

Stage	Example behavior	Where to look
Initial access	A burst of failed logins followed by a success; a login from an unusual country or hour	Sign-in logs (Windows events 4625 and 4624, cloud sign-in logs)
Privilege escalation	A rarely used account is added to an admin group	Windows event 4732, cloud permission-change logs
Persistence	A new account, scheduled task or service is created	Events 4720, 4698, 4697
Covering tracks	The audit log is cleared	Event 1102
Talking to the outside	Traffic to the same destination at regular intervals (C2); bulk sending at odd hours	Proxy, DNS and firewall logs; traffic volume over time

Each of these can also happen during normal admin work. Microsoft's own list of events to monitor says medium- and low-criticality events should be investigated when they occur unexpectedly or well above the usual baseline. An IOA is judged not by a single value but by how it differs from normal and how the actions line up.

Real examples: noticed by trace or by behavior?

In the public cases covered on this site, what tipped people off differed from case to case.

Case	What tipped them off	Type
Codecov (2021)	The hash of the distributed script didn't match the official value	IOC (trace matching)
Hugging Face (2026)	According to the company's disclosure, an anomaly-detection pipeline over security telemetry picked up the signal	IOA (behavioral anomaly)

In the Hugging Face case, both companies report that the intruder was an AI agent acting without human direction. Such an actor moves in ways a human can't: it doesn't rest, doesn't pause, and runs the same action in parallel. The newer the attack, and the fewer known traces like hashes or IPs exist for it, the more it's worth noticing it through behavior.

How to check in your own environment

You can start with records that the OS or cloud keeps by default, without a dedicated product.

Windows: in Event Viewer, open "Windows Logs → Security" and filter for the event IDs in the table above. In PowerShell, Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 50 lists recent failed logins (run as administrator)
If nothing is recorded: which audit events Windows keeps by default varies by version and settings. Check "Advanced Audit Policy Configuration" in Group Policy so the events you need are logged
Linux servers: last shows login history; journalctl -u ssh (or sshd, depending on the distribution) or /var/log/auth.log shows successful and failed authentications
Cloud and SaaS: in the admin console's audit and sign-in logs, look for logins from unusual countries or hours, and for permission changes
Keep a baseline: note your usual login counts and traffic volume on weekdays and weekends. Without a baseline, you can't tell what "different from normal" means

This site's view: detecting and preventing are different, so keep both

IOAs are a powerful "notice by behavior" idea, but on this site we recommend not leaning on "noticing" alone. Detection (IOA/IOC) is about after an incident starts; the first goal is a design that doesn't let it start or spread: least privilege, prompt patching (CVE monitoring), phishing-resistant MFA, no plaintext secrets. Since perfect prevention doesn't exist, you need both prevention (stopping it) and detection (noticing via IOA/IOC). Behavior-based IOAs add value by flagging an anomaly a step earlier than trace-matching.

Sources (primary)

MITRE, "ATT&CK Enterprise Tactics" — attack.mitre.org (how attack stages are grouped)
IETF RFC 9424, "Indicators of Compromise (IoCs) and Their Role in Attack Defence" (August 2023) — rfc-editor.org (TTPs are harder to change than traces)
Microsoft Learn, "Appendix L: Events to Monitor" — learn.microsoft.com (event IDs, and investigating against the usual baseline)
Sources for Codecov and Hugging Face are listed in each case article

FAQ

QWhat's the difference between an IOA and an IOC?

An IOC (Indicator of Compromise) is an after-the-fact trace of a breach — a file hash, a destination IP/domain. An IOA (Indicator of Attack) watches the behavior of an attack in progress — the flow of privilege escalation → lateral movement → exfiltration. IOCs are after-the-fact and static; IOAs are closer to real time and behavior-based.

QWhy does an IOA 'last longer'?

Attackers can swap file hashes and IPs in an instant (IOCs go stale fast). But the way an attack works — gain privilege, spread sideways, exfiltrate — is the essence of the attack and isn't easy to change. So the more you watch behavior (IOAs), the longer your defense lasts.

QCan small teams use IOAs?

Even without a high-end EDR product, the idea applies. Its essence is watching for 'behavior that differs from normal' — bulk data sent at odd hours, an unfamiliar resident process, repeated use of admin features you don't normally touch, a burst of login attempts. These can flag an attack's progress earlier than an individual IOC.

QWhat are examples of IOAs?

A successful login right after a burst of failures, admin rights granted to an account that's rarely used, a new account or scheduled task being created, an audit log being cleared, outbound traffic to the same destination at regular intervals, or bulk data sent at odd hours. Each can also happen during normal admin work, so you judge by how it differs from normal and how several actions line up.

QHow do IOAs relate to EDR?

An IOA is the idea of spotting an attack by behavior; EDR is the typical product that automates it on endpoints. EDR records processes, network activity and file operations, and detects the chains of activity that count as IOAs. Without EDR, you can still apply part of the idea using OS audit logs and sign-in logs.

QHow do IOAs relate to TTPs and MITRE ATT&CK?

TTPs are an attacker's tactics, techniques and procedures. MITRE ATT&CK is a public knowledge base that organizes them by stage, such as Initial Access, Privilege Escalation and Command and Control. An IOA is the sign of a TTP actually running. Mapping what you watch to ATT&CK stages makes gaps in your monitoring easier to see.