An alert fires at 2 a.m. A workstation is talking to an IP address nobody in the company recognizes. Is that an indicator of compromise or an indicator of attack? The label you attach changes what you do next: sweep the estate for patient attackers, or contain a host that is being used right now.

Both terms show up in threat reports, vendor dashboards and incident calls. They are not synonyms, and treating them as one thing is one of the fastest ways to build a detection program that either floods you with noise or misses an intrusion entirely.

What an Indicator of Compromise Actually Is

An indicator of compromise is a piece of forensic evidence that something has already gone wrong. It is a leftover: an artifact you can search for in logs and files after the fact.

Typical examples include a malicious IP address or domain, a file hash, a registry key created by malware, a named pipe, a suspicious user agent string, or an email subject line used in a phishing campaign.

Because IOCs describe what happened, they are most useful during and after an incident. If you know the attacker used a specific domain for command and control, you can search three months of DNS logs for every host that resolved it. That is retro-hunting, and it is one of the highest-value things an IOC gives you.

The weakness is shelf life. Hashes, domains and IPs are cheap for an attacker to change, and hosting providers recycle addresses within weeks. Blocking last month's phishing domain tomorrow proves nothing except that you are thorough.

Common IOC types

• File hashes (MD5, SHA-1, SHA-256) of known malicious files
• IP addresses and domains tied to command-and-control or staging
• URLs used in phishing or payload delivery
• Registry keys, scheduled task names, service names and mutexes
• Email artifacts: sender addresses, subject lines, attachment names

What an Indicator of Attack Looks Like

An indicator of attack describes behavior and intent rather than a specific artifact. It answers "what is the adversary trying to do right now?" instead of "which file did they use?"

Examples: a word processor spawning a command shell. PowerShell making an outbound connection minutes after a user opens an attachment. A service account suddenly authenticating to twenty workstations. A credential dumping utility reading the memory of a security process.

None of those observations include an IP, a domain or a hash. That is the point. An attacker who swaps tooling overnight still has to achieve the same outcomes, and the behavioral signature tends to survive the swap.

IOAs also live mostly in the present tense. They are built to fire while activity is happening, which is why they matter for real-time detection and containment.

The Difference, Stated Plainly

An IOC is the fingerprint left on the window. An IOA is the hand testing the handle.

One is evidence of a completed act. The other is a warning of one in progress. Both are useful, but they serve different jobs.

• Timing: IOCs are post-incident artifacts; IOAs are in-flight behavior.
• Durability: IOCs decay as attackers rotate infrastructure; IOAs stay relevant as long as the technique works.
• False positives: IOC matching is precise but narrow; IOA rules are broader and need tuning.
• Best use: IOCs for scoping and retro-hunting; IOAs for detection engineering and triage.

There is a useful way to think about this that many analysts pick up early: the more an indicator depends on one specific tool, the easier it is for an attacker to change and the less pain it causes them. Behavioral indicators sit higher up that ladder, because changing behavior means changing how they operate.

Two Scenarios, Side by Side

A phishing email reaches a finance mailbox

IOC work: you extract the sender domain, the attachment hash and the payload URL, then search your mail gateway and proxy logs for other recipients who received the same message.

IOA work: you write a rule that alerts when a mail client spawns a scripting interpreter, or when a document opens and writes an executable to a temporary directory. That rule fires on the next campaign too, even if every domain and hash is new.

A server starts behaving oddly

IOC work: you find a suspicious binary, hash it, and check whether that hash appears on any other host in the fleet.

IOA work: you correlate the process tree, network connections and authentication events to see whether that binary is just the last step in a chain that includes privilege escalation and lateral movement. That tells you how far the attacker got, not just where they landed.

Where Each Belongs in Your Workflow

Use IOCs when you are scoping an incident, hunting through historical logs, writing block rules for infrastructure you trust, or sharing findings with peers through a threat intelligence platform or sector group.

Use IOAs when you are building detections that need to survive, tuning endpoint or network monitoring, or making fast containment calls during triage. If an alert shows a browser launching a remote access tool, you do not need the tool's hash to decide the host needs isolating.

Most mature teams run both. The practical pattern is simple: behavior catches what matters, and artifacts tell you how far the problem spread.

Mistakes worth avoiding

• Blocking every IOC you receive without checking its age, its source, or whether it is a shared cloud address half your business depends on.
• Writing IOA rules so broad that every admin script triggers them, then disabling the rule after a week of noise.
• Confusing indicators with vulnerabilities or tactics. A CVE is a weakness, a TTP is a method, an IOC is an artifact.
• Never expiring anything. An indicator list with no review date becomes an archaeology project.

A Simple Starting Point

1. Collect IOCs from each incident and from feeds you trust. Tag each one with a confidence level, a source and an expiry date.
2. Turn high-confidence IOCs into retrospective searches across at least 30 to 90 days of logs, not just blocklist entries.
3. Pick two or three behaviors you know attackers need, such as a scripting engine starting from an office application, and build detections around them.
4. Document what each detection is supposed to catch and who owns it. Untended rules rot quietly.
5. Review monthly. Retire what has not fired, tune what fires too much, promote what works.

Start with behavior if you can only do one thing, because it is the part that keeps paying out. Then layer IOCs on top for scoping and speed. Together they cover both the moment of attack and the mess it leaves behind.

Photo: Bibek ghosh / Pexels