IOC vs IOA: What’s the Difference and Why It Matters

⚡ Quick Answer: IOC vs IOA in 30 Seconds

An Indicator of Compromise (IOC) is forensic evidence that a breach has already occurred – a digital fingerprint left after an attacker has been in your systems. An Indicator of Attack (IOA) is behavioural evidence that an attack is actively in progress – it detects what an attacker is doing right now, regardless of the tools or malware they use. The key difference is timing: IOCs are retrospective (past); IOAs are real-time (present). IOCs answer ‘what happened?’ IOAs answer ‘what is happening?’

✍️ About This Guide

Written by the threat intelligence and incident response team at CodeHyper, a Sydney-based managed IT and cybersecurity provider. Our team detects and responds to security incidents for Australian businesses, working with both IOC-based SIEM rules and IOA-based EDR platforms in production environments. Statistics cited are sourced from the ASD Annual Cyber Threat Report 2023–24, CrowdStrike’s 2026 Global Threat Report, Verizon’s 2025 Data Breach Investigations Report, and SANS 2025 Cyber Threat Intelligence Survey.

The average time to detect a data breach in Australia is 194 days. Nearly six months of an attacker moving through systems, escalating privileges, exfiltrating data, and establishing persistence – while the organisation has no idea anything is wrong. By the time a breach is discovered, it is almost always too late to prevent the damage; the focus shifts entirely to containment and recovery.

The reason this detection gap exists is that most organisations rely primarily on Indicators of Compromise (IOCs) – static, signature-based detection that looks for known bad things: malicious file hashes, known malicious IP addresses, suspicious domain names. IOC-based detection is fundamentally retrospective. It tells you a breach happened after the attacker has already established a foothold.

The more powerful – but less understood – approach is Indicators of Attack (IOAs): behaviour-based detection that identifies what an attacker is doing in real time, regardless of the specific tools or malware used. IOAs detect intent and technique, not artefacts. They can stop an attack before data is exfiltrated, before ransomware is deployed, before a domain controller is compromised.

This guide covers both concepts comprehensively – what they are, how they work, the types of each, how they map to the MITRE ATT&CK framework and the Pyramid of Pain, a real-world attack scenario showing both in action, and the tools Australian businesses use to implement each. For immediate security assessment, explore our managed cybersecurity services or our cybersecurity gap analysis.

What Is an Indicator of Compromise (IOC)?

An Indicator of Compromise (IOC) is a piece of forensic evidence – a digital artefact – that suggests a system or network has been breached or accessed without authorisation. IOCs are the traces that attackers leave behind: the equivalent of muddy footprints, fingerprints, and discarded tools at a crime scene.

The key characteristic of an IOC is that it is retrospective. An IOC confirms something has already happened. It does not, by itself, prevent or detect an attack in real time – it is discovered during forensic investigation, log analysis, or threat intelligence correlation after the fact. IOCs are the foundation of incident response and threat intelligence – they help you understand what happened, how the attacker got in, what data was accessed, and how to prevent the same attack from succeeding again.

The Four Categories of IOC with Concrete Examples

IOCs fall into four main categories. Understanding each type is essential for building comprehensive detection coverage.

IOC Category	What It Identifies	Concrete Examples	Detection Tool
File-Based IOCs	Malicious files present on the system – identified by their cryptographic signature or name	MD5/SHA-256 hash of a known ransomware executable; filename ‘svchost.exe’ in C:\Temp (not the legitimate location); macro-enabled Word document with specific embedded code	Antivirus, EDR, file integrity monitoring
Network-Based IOCs	Suspicious or malicious network activity – connections to known bad infrastructure	Outbound connections to a known command-and-control (C2) IP address; DNS queries to a domain registered 48 hours ago with a DGA pattern; unexpected data transfer to a foreign IP at 2:00 AM	Firewall logs, IDS/IPS, DNS filtering, SIEM
Host-Based IOCs	Suspicious changes to endpoint configuration or state that indicate attacker activity	New scheduled task created by a non-IT account; registry key modification at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run; new local admin account ‘svc_backup’ created without IT ticket	EDR, Windows Event Logs, SIEM, endpoint monitoring
Behavioural IOCs	Patterns of user or system behaviour that deviate from established baselines	User account logging in from a country it has never accessed from before; database account reading 10,000+ records in a single session; privileged account active at 3:00 AM when the employee never works night shifts	UEBA, SIEM with anomaly detection, EDR

The IOC Lifecycle

IOCs are not permanent – they have a lifecycle that security teams must manage actively.

Discovery: An IOC is identified – through incident response, threat intelligence feeds, dark web monitoring, or internal log analysis
Assessment: The IOC is validated against your environment – is this IP address actually communicating with your systems? Is this file hash present on your endpoints?
Deployment: The IOC is operationalised – pushed to your SIEM as a detection rule, added to firewall blocklists, or added to EDR threat intelligence feeds
Detection and Response: The deployed IOC triggers alerts when matching activity is detected; security teams investigate and respond
End of Life: The IOC is retired when it is no longer accurate or relevant – attackers change infrastructure constantly. IP addresses rotate. Malware hashes are recompiled. A 12-month-old IOC for a C2 IP address is often pointing at infrastructure the attacker abandoned long ago

This lifecycle limitation is critical to understand: IOCs expire rapidly. CrowdStrike research shows attackers now achieve lateral movement within 72 minutes of initial access – often before IOC-based detection systems have been updated with the relevant indicator. This is precisely why IOAs were developed.

What Is an Indicator of Attack (IOA)?

An Indicator of Attack (IOA) is behavioural evidence that an attack is currently in progress. Rather than looking for known bad artefacts (as IOCs do), IOAs detect the actions, techniques, and sequences of behaviour that an attacker must perform to achieve their objectives – regardless of the specific tools, malware, or infrastructure used.

The critical distinction: IOAs detect intent and method; IOCs detect evidence. An IOA fires when a process attempts to dump LSASS memory – it doesn’t matter whether the tool used is Mimikatz, a custom script, or a legitimate admin tool being abused. The behaviour (reading the LSASS process memory to extract credentials) is the IOA. The specific tool’s hash is the IOC.

This distinction is what makes IOAs effective against two categories of attack that IOC-based detection struggles with:

Zero-day attacks: Attacks using previously unknown malware have no known hash, no known C2 IP, no known IOC. But they still require an attacker to follow recognisable attack patterns – they must establish initial access, escalate privileges, and move laterally. These behaviours are IOAs
Living-off-the-Land (LotL) attacks: Attacks using legitimate Windows tools (PowerShell, WMI, PsExec) leave no malware on disk for IOC detection to find. But the sequence of actions – a legitimate admin tool running at an unusual time, spawning a child process, connecting outbound – is an IOA

How IOAs Work: The Attack Chain Perspective

IOAs are most powerful when understood in the context of the complete attack chain. Every successful attack – from phishing email to ransomware deployment – follows a sequence of steps that the attacker must complete to achieve their objective. Each step in that sequence is a potential IOA detection point.

Using the MITRE ATT&CK framework as the reference model, here is how IOAs map to attack tactics:

MITRE ATT&CK Tactic	Example IOA Detection
Initial Access (TA0001)	Office application spawning a child process (PowerShell, cmd) after a document is opened – indicating macro execution
Execution (TA0002)	PowerShell executing with encoded command strings, downloading content from the internet, or running in a hidden window
Persistence (TA0003)	New scheduled task, autorun registry key, or Windows service created by a non-standard process or user account
Privilege Escalation (TA0004)	Process attempting to access LSASS memory; UAC bypass technique; token impersonation by a non-privileged process
Defence Evasion (TA0005)	Process injection into a legitimate Windows process (svchost.exe, explorer.exe); timestomping; disabling Windows Defender real-time protection
Credential Access (TA0006)	Bulk reading of credential stores; NTLM hash capture; large volume of authentication failures followed by a success
Discovery (TA0007)	Rapid port scanning of internal network from a user workstation; AD enumeration queries; unusual file system traversal
Lateral Movement (TA0008)	Remote service creation across multiple hosts; unusual RDP connections between workstations (workstation-to-workstation lateral movement)
Collection (TA0009)	Large volume of file reads from file servers; database dump operations; bulk email access from an account that doesn’t normally do this
Command and Control (TA0011)	Beaconing traffic – regular, short HTTP/HTTPS connections to external IP at consistent intervals (e.g., every 60 seconds)
Exfiltration (TA0010)	Large outbound data transfer to a cloud service or external IP, especially at unusual hours; DNS tunnelling pattern
Impact (TA0040)	Mass file rename or extension change (ransomware encryption behaviour); volume shadow copy deletion; audit log clearing

The power of this perspective: even if an attacker uses a completely new, zero-day malware tool, they still have to traverse these MITRE ATT&CK stages. Their behaviour across these stages is detectable through IOA-based systems – particularly EDR platforms and SIEM correlation rules built around behavioural patterns rather than static signatures.

IOC vs IOA: Direct Comparison

Characteristic	IOC (Indicator of Compromise)
Timing	Retrospective – confirms a breach has already occurred
What it detects	Known bad artefacts: hashes, IPs, domains, registry keys
Primary question answered	‘What happened?’ – forensic confirmation of compromise
Effectiveness vs zero-days	Limited – no known artefact exists for unknown malware
Effectiveness vs LotL attacks	Low – no malware files dropped = no file-based IOC
False positive rate	Low for known bad; misses unknown threats
Lifecycle	Short – attackers rotate infrastructure quickly; IOCs expire
Primary use case	Incident response, threat hunting, threat intelligence sharing
Requires	Threat intelligence feeds, hash/IP/domain blocklists, SIEM signatures
Australian tool example	Microsoft Sentinel IOC matching, ASD threat intelligence feeds
Best analogy	Finding muddy footprints after the burglar has left

The Pyramid of Pain: Where IOCs and IOAs Fit

The Pyramid of Pain – developed by security researcher David Bianco – is one of the most important frameworks for understanding the relative value of different types of threat intelligence indicators. It shows which indicators are most valuable to detect and act on, based on how difficult they are for an attacker to change.

The core insight is counterintuitive: the easier an indicator is to find, the easier it is for an attacker to change it. If you block a malicious IP address, the attacker spins up a new server. If you detect a specific malware hash, the attacker recompiles the binary. But if you detect and disrupt how an attacker operates – their TTPs – you force them to fundamentally change their methodology, which is expensive, time-consuming, and often beyond the capability of commodity attackers.

Pyramid Level (Bottom to Top)	Indicator Type
Level 1 – Hash Values	Specific MD5/SHA-1/SHA-256 file hashes
Level 2 – IP Addresses	Specific malicious IP addresses (C2 servers, attacker infrastructure)
Level 3 – Domain Names	Malicious domain names (phishing sites, C2 domains)
Level 4 – Network/Host Artefacts	Specific network traffic patterns, registry keys, file paths left by specific malware
Level 5 – Tools	Specific attacker tools (Mimikatz, Cobalt Strike, BloodHound)
Level 6 – TTPs (Tactics, Techniques, and Procedures)	How the attacker operates – their methodology, sequences, and techniques
Level 7 – Adversary Behaviour	Deep understanding of a specific threat actor’s complete operational pattern

The practical implication for Australian businesses: most security tools focus on the bottom three levels (hashes, IPs, domains) – these are the easiest to implement but the least effective against sophisticated attackers. Moving detection capability up the Pyramid of Pain toward TTPs is the most impactful security investment a security team can make. This is precisely what MITRE ATT&CK-aligned IOA detection achieves.

For context: the ASD’s Essential Eight addresses many Pyramid of Pain Level 5 and 6 controls through Application Control (blocks attacker tools) and Restrict Administrative Privileges (makes TTPs like credential theft and lateral movement far harder to execute). These controls work precisely because they target behaviour and capability, not specific artefacts.

IOC and IOA in Action: A Step-by-Step Attack Scenario

The best way to understand the difference between IOCs and IOAs is to follow a realistic attack scenario and see when each type of indicator fires. The scenario below is based on attack patterns commonly observed in Australian breaches, including the credential-theft and lateral movement techniques used in the Medibank and Optus incidents.

The scenario: A business email compromise (BEC) attack escalating to ransomware against a medium-sized Australian professional services firm.

The Attack Timeline and When Each Indicator Fires

Attack Stage	What Happens / What the Attacker Does
Day 1 – Phishing Email Delivered	Attacker sends spear-phishing email with a macro-enabled Excel document to the CFO. The document appears to be from a known supplier.
Day 1 – Macro Executes	CFO opens the document and enables macros. Excel spawns a PowerShell child process with an encoded command string.
Day 1 – C2 Beacon Established	The PowerShell script downloads a small agent, which begins beaconing to an attacker-controlled cloud service every 60 seconds.
Day 3 – Credential Harvesting	Attacker uses the CFO’s session to run Mimikatz via reflective DLL injection, harvesting NTLM hashes from LSASS memory.
Day 4 – Lateral Movement	Using harvested credentials, attacker authenticates to 3 other servers via pass-the-hash, accessing the backup server and a file server.
Day 7 – Backup Deletion	Attacker deletes shadow copies and disables Windows backup services via vssadmin and wbadmin commands.
Day 7 – Ransomware Deployment	Ransomware binary deployed via remote service creation across 23 endpoints. Encryption begins.
Day 8 – Discovery	IT notices encrypted files, ransom note. Incident response begins.

This scenario illustrates the fundamental problem with IOC-only security: the IOC fires on Day 7 when the ransomware binary is first seen. The IOAs fired on Day 1 when the macro executed – six days earlier, before any data was encrypted or backups were destroyed. An organisation with IOA-based detection and a responsive security team has a realistic opportunity to stop this attack at the Excel stage. An organisation relying only on IOCs will discover the breach on Day 8 surrounded by encrypted files.

�� Case Study: How IOA Detection Stopped a BEC Attack at an Adelaide Healthcare Provider

Case Study Snapshot

The Situation

A 55-person Adelaide healthcare administration company managing patient billing and records for a network of allied health clinics contacted CodeHyper following a security alert that their existing security platform had flagged but their internal IT coordinator was uncertain how to interpret. The alert had been generated at 11:23 AM on a Tuesday – three hours after the initial phishing email was delivered.

The IOA Alert That Triggered the Response

Microsoft Defender for Endpoint had generated a high-severity behavioural alert: ‘Office application launched a process that performed suspicious network activity’. Specifically: Microsoft Excel had spawned a cmd.exe child process, which executed a PowerShell command with a Base64-encoded string that made an outbound HTTP request to an IP address in Eastern Europe.

This is a pure IOA – no IOC was involved. The IP address was not in any known threat intelligence feed. The PowerShell command used no known malicious hash. The Excel document itself had no known malicious hash. Every IOC check returned clean. But the behaviour – Office spawning a child process that executed encoded PowerShell making an external connection – is one of the most unambiguous attack IOAs in the entire MITRE ATT&CK library (T1059.001 – PowerShell, following T1566.001 – Spearphishing Attachment).

The Response

CodeHyper’s security team received the escalated alert at 11:41 AM – 18 minutes after the initial IOA fired. The response sequence:

11:41 AM: Affected workstation isolated from the network via Defender for Endpoint remote isolation. The attacker’s C2 beacon – which had been running for 14 minutes – was severed
11:48 AM: Forensic analysis of the Excel file began. The macro code was extracted and analysed – it was custom-built, explaining why no IOC matched
11:55 AM: The affected user’s Microsoft 365 credentials were forcibly rotated. Active sessions terminated. Entra ID sign-in logs reviewed – no other sessions observed from suspicious locations
12:05 AM: Wider environment scanned for similar IOAs – no other endpoints showed the same behavioural pattern
12:10 PM: Incident contained. The attack stopped at the initial access stage. No credential harvesting, no lateral movement, no data exfiltration

What IOC-Only Detection Would Have Found

Zero. The attacker used entirely custom tooling with no matches in any threat intelligence feed. Had the organisation relied solely on IOC-based detection – which most Australian SMB antivirus solutions provide – the attack would not have been detected until the attacker’s objectives were achieved. At that point, with patient billing records exposed, the organisation would have faced an eligible notifiable data breach under the Privacy Act affecting potentially thousands of patient records.

“We had decent security before this. Antivirus, email filtering, decent patching. But all of that is IOC-based – it’s looking for things it already knows are bad. This attacker used nothing it already knew about. The EDR saved us because it was watching what the software was doing, not what it looked like.” – IT Coordinator, Adelaide Healthcare Administration Firm

When to Use IOC vs IOA Detection: The Decision Framework

The practical question for Australian businesses is not ‘IOC or IOA?’ – it is ‘how do I use both effectively, and where should I prioritise my investment?’ This framework helps answer that.

Scenario	Primary Indicator Type Needed	Why
Known malware spreading across the industry (e.g., active ransomware campaign)	IOC – deploy hashes and IP blocklists immediately	Threat intel feeds provide ready-to-deploy IOCs; fastest deployment for known threats
Zero-day attack or novel malware – no known signature	IOA – behavioural detection is the only option	No IOC exists yet; attacker behaviour is the only detectable signal
LotL attack using only legitimate Windows tools	IOA – detect the abuse pattern, not the tool	Legitimate tools have no malicious hash; only the sequence of actions is suspicious
Investigating a suspected breach after the fact	IOC – forensic artefacts help reconstruct what happened	IOCs provide the evidence trail: what files, what IPs, what persistence mechanisms
Threat hunting for hidden attackers in your environment	Both – IOC matching for known threats + IOA hunting for anomalous behaviour	Best threat hunting combines known bad IOC searches with hypothesis-driven IOA behaviour hunts
Regulatory compliance evidence (Privacy Act, Essential Eight)	IOC for documentation; IOA for prevention evidence	Regulators want to see detection capability; IOA-based EDR demonstrates proactive controls
Protecting against sophisticated nation-state or APT actors	IOA-primary – TTPs change less than tools and infrastructure	APT actors cycle through tools and infrastructure frequently; their behavioural patterns are more stable
Sharing threat intelligence with industry peers or CERT Australia	IOC – standardised formats (STIX/TAXII) share IOC data	IOC data is structured and shareable via standard formats; IOAs are context-specific to your environment

IOC and IOA Detection Tools for Australian Businesses

Understanding the conceptual difference between IOCs and IOAs is one thing; knowing what tools implement each in a typical Australian SMB Microsoft environment is the practical next step. Here is the toolset that CodeHyper deploys for Australian businesses across both categories.

IOC Detection Tools

Microsoft Sentinel (SIEM): aggregates logs from across the Microsoft 365 and Azure environment, applies IOC matching rules, and correlates events. Includes built-in threat intelligence with known malicious IP addresses, domains, and file hashes. Australian businesses can also integrate ASD and ACSC threat intelligence feeds into Sentinel for locally-relevant IOC data
Microsoft Defender for Endpoint (hash and IP blocking): allows deployment of custom indicators – known malicious file hashes, domains, and IP addresses – that are automatically blocked across all enrolled endpoints. Updates automatically from Microsoft’s global threat intelligence network
Microsoft Defender for Office 365 (email-based IOCs): Safe Links and Safe Attachments scan inbound email in real time against known malicious URLs and file hashes, blocking IOC-matched content before it reaches users
ASD and ACSC threat intelligence feeds: The ASD shares threat intelligence including IOCs through its partner programme. Australian businesses eligible for ASD partner access can receive locally-curated IOC data specific to threats targeting Australian organisations
VirusTotal API integration: for incident response and threat hunting, VirusTotal provides hash, domain, and IP lookups against 70+ security vendor databases – useful for rapid IOC triage during investigation

IOA Detection Tools

Microsoft Defender for Endpoint (EDR – behavioural detection): the primary IOA platform for Microsoft-environment businesses. Defender’s behavioural engine monitors all endpoint processes, detects attack technique patterns, and can automatically isolate affected devices. Microsoft aligns its detection rules to MITRE ATT&CK, meaning Defender alerts map directly to specific attack tactics and techniques
Microsoft Defender for Endpoint – Attack Surface Reduction (ASR) rules: a specific set of IOA-aligned policies that block specific attacker techniques at the point of execution – Office applications spawning child processes, LSASS access, unsigned scripts. These are preventive IOAs rather than detective ones
Microsoft Sentinel – behavioural analytics: Sentinel’s UEBA (User and Entity Behaviour Analytics) module builds behavioural baselines and detects anomalies – the classic IOA approach applied to identity and cloud behaviour. Alerts fire when an account behaves differently from its established pattern, regardless of whether the activity matches any known IOC
Microsoft Defender XDR (cross-domain IOA correlation): correlates IOA signals across endpoints, email, identity, and cloud to detect multi-stage attacks that traverse multiple Microsoft environments – the kind of cross-domain attack visibility that catches sophisticated threats

For Australian businesses, the Microsoft 365 Business Premium licence includes Defender for Endpoint Plan 1, Defender for Office 365 Plan 1, and Entra ID P1 – providing meaningful IOA detection capability at SMB-appropriate pricing. Our guide on Microsoft 365 security covers the specific security configurations that maximise IOA detection in a Microsoft 365 environment.

IOC and IOA in the Australian Cybersecurity Context

For Australian businesses, the IOC vs IOA distinction has direct regulatory and operational implications beyond just detection capability.

The Notifiable Data Breaches Scheme and Detection Timing

Under Australia’s Notifiable Data Breaches scheme, organisations must assess and report eligible data breaches as soon as practicable. The 277-day average breach detection time means most Australian businesses are discovering breaches months after personal data has been exfiltrated – triggering retrospective notification obligations that are far more damaging than if the attack had been stopped in progress.

IOA-based detection directly reduces this gap. The Adelaide case study above shows how IOA detection fired 3 hours after initial access rather than days or weeks later. The regulatory and reputational difference between stopping an attack at hour 3 and discovering it at month 9 is enormous – one is a contained incident that never becomes notifiable; the other is a significant data breach with mandatory notification obligations to the OAIC.

The ASD Essential Eight and IOA Alignment

The ASD’s Essential Eight – Australia’s primary cybersecurity framework – contains controls that are directly IOA-aligned, even if not described in those terms. Application Control (Control 1) and Attack Surface Reduction block the specific attack techniques that IOAs detect. Restrict Administrative Privileges (Control 5) removes the credentials that credential-harvesting IOAs target. Multi-Factor Authentication (Control 7) makes credential-based IOAs less successful even when they occur.

This means that businesses implementing the Essential Eight to Maturity Level 2 are simultaneously reducing the success rate of the attack techniques that IOAs detect – making their environment harder to attack while also making the attacks that do occur more visible through IOA detection. The frameworks are complementary: Essential Eight hardens the environment; IOA detection provides visibility.

The ASD Cyber Threat Report and IOC Sharing

The ASD’s Annual Cyber Threat Report – which recorded 87,400 cybercrime reports in 2023–24 – includes IOC data shared through the ACSC’s threat intelligence programme. Australian businesses that participate in ASD’s partner programme receive locally-relevant IOC data that covers threats specifically targeting Australian industries and government. This is particularly valuable for businesses in healthcare, financial services, and critical infrastructure – the sectors most targeted in Australia’s threat landscape.

IOC Tells You What Happened. IOA Tells You What’s Happening Now.

The 194-day average Australian breach detection time is not a technology problem – it is a detection strategy problem. Organisations relying on IOC-based detection are playing retrospective forensics while attackers are actively operating in their environments. IOA-based detection, aligned to MITRE ATT&CK and deployed through modern EDR platforms, changes the detection timeline from months to minutes.

The most effective security programmes use both. IOCs provide threat intelligence context and help confirm breaches post-incident. IOAs provide the real-time detection that stops attacks before they achieve their objectives. In 2026, with 82% of attacks using malware-free, LotL techniques that generate no traditional IOC signals, IOA-based behavioural detection is no longer optional – it is the primary defence layer.

At CodeHyper, we implement and manage both IOC and IOA detection for Australian businesses – deploying Microsoft Defender for Endpoint’s behavioural engine, configuring Sentinel with both IOC matching rules and UEBA behavioural analytics, and aligning detection coverage to MITRE ATT&CK and the ASD Essential Eight. Our managed cybersecurity services include 24/7 monitoring with a human-reviewed response to high-confidence IOA alerts – so you don’t discover a breach at month nine.

Start with our cybersecurity gap analysis to understand your current detection coverage across both IOC and IOA capabilities, or contact us today to discuss your threat detection strategy.

Frequently Asked Questions: IOC vs IOA

What is the main difference between an IOC and an IOA?

The primary difference is timing and approach. An Indicator of Compromise (IOC) is forensic evidence that a breach has already occurred – it is retrospective, looking for known bad artefacts like malicious file hashes, IP addresses, or registry modifications. An Indicator of Attack (IOA) is behavioural evidence that an attack is currently in progress – it detects what an attacker is doing right now, regardless of the specific tools used. IOCs answer ‘what happened?’ IOAs answer to ‘what is happening?’

Can IOAs detect zero-day attacks?

Yes – and this is one of their most important advantages over IOC-based detection. Zero-day attacks use previously unknown malware or exploit techniques, meaning no known IOC (hash, IP, domain) exists for them. However, zero-day attacks still require an attacker to follow recognisable behaviour patterns – executing code, escalating privileges, moving laterally, exfiltrating data. These behaviour patterns are IOAs, and they fire regardless of whether the specific tool or malware has been seen before.

What is a Living-off-the-Land (LotL) attack and why do IOAs detect it better?

A Living-off-the-Land attack uses legitimate, built-in Windows tools – PowerShell, WMI, PsExec, Task Scheduler – rather than custom malware to conduct attacks. These tools have no malicious hash, generate no traditional IOC signal, and often bypass antivirus entirely. IOA-based detection identifies LotL attacks because it watches what the tool does rather than what it is – PowerShell executing encoded commands and making external connections at 2:00 AM is an IOA regardless of the fact that PowerShell itself is legitimate software.

What is the Pyramid of Pain and how does it relate to IOC and IOA?

The Pyramid of Pain (developed by David Bianco) shows which indicators are most valuable based on how difficult they are for attackers to change. At the bottom are IOC-focused indicators: file hashes (trivial to change), IP addresses (easy), and domain names (easy to moderate). At the top are IOA-focused indicators: tools, tactics, techniques, and procedures (TTPs) – which are very hard and expensive for attackers to change. Focusing detection at the top of the pyramid forces attackers to fundamentally rethink their methodology, rather than simply regenerating a new IP address or recompiling a binary.

How do IOAs map to the MITRE ATT&CK framework?

IOAs map directly to MITRE ATT&CK tactics – the framework’s documentation of how attackers operate across the full attack lifecycle. Each MITRE ATT&CK technique describes specific attacker behaviour that, when detected, constitutes an IOA. For example, LSASS memory access (T1003.001 – OS Credential Dumping) is an IOA; Office applications spawning child processes (T1059.001 after T1566.001) is an IOA; volume shadow copy deletion (T1490 – Inhibit System Recovery) is an IOA. Modern EDR platforms like Microsoft Defender for Endpoint explicitly map their behavioural detections to MITRE ATT&CK techniques.

Do I need both IOC and IOA detection?

Yes – both serve different and complementary purposes. IOC detection is fastest at blocking known threats (active ransomware campaigns where hashes are published, known phishing infrastructure) and is essential for incident response and threat intelligence sharing. IOA detection is most effective against unknown, novel, and sophisticated threats. IOC without IOA means you are blind to LotL attacks, zero-days, and any attacker who uses fresh infrastructure. IOA without IOC means you lose the efficiency benefits of quickly blocking known-bad indicators. The strongest security programmes use both.

What tools implement IOA detection in Microsoft 365 environments?

Microsoft Defender for Endpoint is the primary IOA platform for Microsoft-environment businesses. It monitors all endpoint processes in real time, detects behavioural attack patterns aligned to MITRE ATT&CK, and can automatically isolate affected devices upon IOA detection. Microsoft Sentinel’s UEBA (User and Entity Behaviour Analytics) provides IOA capability at the identity and cloud layer. Defender’s Attack Surface Reduction (ASR) rules are preventive IOAs – blocking specific attacker techniques at point of execution. Our guide on responding to alerts in EDR covers how to build effective IOA response workflows in Microsoft Defender environments.

How does IOA detection relate to the ASD Essential Eight?

The ASD Essential Eight’s technical controls directly address the attack techniques that IOAs detect. Application Control (Control 1) prevents execution of the very applications whose execution IOAs detect as suspicious. Restricting Administrative Privileges (Control 5) removes the credentials that credential-harvesting IOAs target. Configuring Macro Settings (Control 3) blocks the Office macro execution that is one of the most common IOA triggers. Implementing the Essential Eight therefore both reduces the attack surface that IOAs monitor and makes the attacks that do occur more detectable. See our Essential Eight checklist for the implementation detail.

What are examples of common IOCs?

Common IOC examples include: file hashes (MD5 or SHA-256) of known malware binaries; IP addresses of known command-and-control servers; malicious domain names used for phishing or C2; specific registry keys created by malware for persistence (e.g., entries in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run); suspicious file paths (e.g., executable files in AppData or Temp directories); email addresses used in phishing campaigns; and SSL/TLS certificate hashes associated with attacker infrastructure.

What are examples of common IOAs?

Common IOA examples include: Office applications (Word, Excel) spawning child processes (PowerShell, cmd.exe); PowerShell executing encoded (Base64) command strings; processes attempting to read LSASS memory (credential harvesting); volume shadow copies being deleted (ransomware preparation); new scheduled tasks or autorun registry keys created by non-IT processes; beaconing network traffic (regular outbound connections at fixed intervals); pass-the-hash authentication from a workstation to servers it doesn’t normally access; and rapid internal port scanning from a user endpoint.

How do I assess my organisation’s IOC and IOA detection coverage?

The best starting point is a gap assessment that maps your current security tools against MITRE ATT&CK to identify which attack techniques you can currently detect and which you cannot. CodeHyper conducts these assessments for Australian businesses as part of our cybersecurity gap analysis service. Alternatively, contact us directly to discuss your current detection stack and where the most significant coverage gaps lie.