"IOC formats" covers two different things — and you need both. The first is the atomic indicator type: the shape of a single piece of evidence, such as an IPv4 address, a domain, a URL, an email address, or a file hash (MD5, SHA1, SHA256). The second is the structured exchange format that packages those indicators for storage and sharing — STIX 2.1 (JSON) is the dominant machine-to-machine standard, carried over the TAXII protocol, while OpenIOC (Mandiant's legacy XML), MISP JSON, YARA rules, Sigma rules, and plain CSV/text round out what modern tools support. YARA describes file and memory signatures; Sigma describes log-detection signatures; CSV and plain text remain the simplest and most widely consumed formats of all.
That is the summary an AI overview gives you. What it can't give you is the part that actually matters when you are wiring up a feed: which format to reach for, what context each one can and can't carry, and how the raw indicator types map onto the exchange standards. This guide covers both layers — the full taxonomy of indicator types, then the serialization formats that move them between tools.
The structured threat-intel formats at a glance
Before the taxonomy of individual indicator types, here is the layer most people actually mean by "format" — the standards that serialize IOCs for sharing between platforms:
| Format | What it is | Structured? | Best used for |
|---|---|---|---|
| STIX 2.1 | JSON language describing indicators, malware, actors, and their relationships (a graph model) | Yes (rich, graph) | The de-facto standard for automated sharing across enterprises, ISACs, and government |
| TAXII 2.1 | RESTful transport protocol that moves STIX bundles via collections/channels | N/A (transport) | Delivering STIX feeds machine-to-machine; pairs with STIX, not a data format itself |
| OpenIOC | Mandiant's XML format using boolean AND/OR logic to combine indicators | Yes (XML) | Legacy intelligence; import-only for most new workflows |
| MISP JSON | Native event format of the open-source MISP platform | Yes (rich) | Community sharing and correlation when both sides run MISP |
| YARA | Rule language matching strings and byte patterns in files and memory | Yes (rules) | Classifying and hunting malware samples on disk and in memory |
| Sigma | Generic, vendor-neutral signature format for log events | Yes (rules) | SIEM detection; converts to Splunk/Elastic/Sentinel queries |
| CSV | One indicator per row, columns for type/context | Semi | Bulk import/export and quick blocklist feeds; universally readable |
| Plain text | Newline-delimited list of raw indicators | No | Fast, human-eyeball exchange and firewall blocklists; carries no context |
Which should you use? For automated machine-to-machine sharing, STIX 2.1 over TAXII 2.1. To match files, YARA; to match logs, Sigma. For a quick human hand-off, a defanged CSV or plain-text list. Treat OpenIOC as read-only legacy.
The rest of this article catalogs the atomic indicator types that fill those formats — the raw material every feed is built from.
Overview of IOC Format Categories
Indicators of Compromise come in many formats, each serving different purposes in threat detection and incident response. Understanding the complete range of supported IOC formats helps security teams effectively extract, validate, and utilize threat intelligence. IOC formats fall into several broad categories based on the type of infrastructure or artifact they represent.
Modern IOC extraction tools support dozens of specific formats across these categories. Some tools specialize in specific IOC types relevant to particular domains, while comprehensive tools handle the full spectrum of common indicators. The choice of tool depends on your organization's specific threat landscape and the types of IOCs most relevant to your security operations.
Network-Based IOCs
Network indicators represent malicious infrastructure and activity patterns observed on networks and the internet.
IPv4 Addresses: The most common network IOC, IPv4 addresses identify specific servers or devices involved in malicious activity. When threat reports mention "192.168.100.50 was observed connecting to malware command and control infrastructure," that IP becomes an IOC suitable for network blocking and threat hunting. IPv4 addresses appear in firewall logs, proxy data, and threat reports with high frequency.
IPv6 Addresses: As IPv6 adoption increases, IPv6 addresses are becoming more common IOCs. While less prevalent than IPv4 currently, IPv6 addresses serve the same function—identifying malicious servers and devices. Modern extraction tools should support both full and compressed IPv6 notation to handle various representation formats.
Domain Names: Registered domain names used for malicious purposes appear frequently as IOCs. A threat report might identify "malicious-site.com" or "command-control.net" as domains communicating with compromised systems. Domain IOCs are valuable for DNS sinkholing, proxying, and firewall blocking. They're more stable than IP addresses since domains can remain associated with malicious activity even when the underlying infrastructure changes.
URLs: Complete URLs including the protocol and path represent more specific IOCs than domains alone. "hxxp://malicious.com/malware/payload.exe" specifies not just a domain but the specific malicious resource. URL IOCs are particularly valuable for web proxy filtering and content delivery network (CDN) bypass detection.
Subdomains: Threat actors frequently use specific subdomains for command and control or malicious content delivery. IOCs might specify "c2.malicious.com" or "payload.exfil.domain.net" rather than just the root domain. Subdomain-specific IOCs allow more granular filtering and detection.
URLs with Authentication: Some URLs include authentication credentials in the format "http://username:password@domain.com/path". These appear in threat intelligence when analyzing attacker-controlled web servers or compromised legitimate sites. Extraction tools must handle the additional complexity of embedded credentials.
DNS and Domain-Based IOCs
DNS-specific indicators capture patterns in domain resolution and registration data.
DNS Query Names: Indicators can represent domains that systems query for in DNS requests. When malware queries for "update.malware.com" or "c2-server.evil.org", these DNS names become IOCs observable in DNS logs. Many SIEM systems and network monitoring tools can detect these DNS queries even if the resolution fails.
Nameservers: Threat actors sometimes register multiple malicious domains pointing to the same nameservers. Identifying suspicious nameservers like "ns1.bulletproof-hosting.net" allows detection of entire families of malicious domains. Some extraction tools recognize nameserver IOCs as infrastructure indicators.
Mail Exchange Records: Malicious domains might use specific mail exchange (MX) servers. While less common as standalone IOCs, MX record information helps characterize malicious infrastructure. Some threat reports include MX servers as part of domain descriptions.
DNS A Records: The IPv4 addresses that domain names resolve to represent another form of IOC. A threat report might identify that "malicious.com resolves to 192.168.100.50." This creates two separate IOCs—the domain and the IP address.
File-Based IOCs
File indicators help identify potentially malicious or suspicious files in your environment.
MD5 Hashes: The MD5 cryptographic hash produces 32-character hexadecimal strings representing file content. While MD5 is cryptographically broken and shouldn't be used for security purposes, it remains widely used in threat intelligence due to historical prevalence. A threat report identifying "malware.exe with MD5 d41d8cd98f00b204e9800998ecf8427e" provides a reliable IOC for file matching.
SHA1 Hashes: SHA1 produces 40-character hashes and is more collision-resistant than MD5, though also cryptographically deprecated. SHA1 hashes appear frequently in threat intelligence from established sources and continue to be useful for file identification despite cryptographic limitations.
SHA256 Hashes: SHA256 is the current industry standard for file hashing, producing 64-character hashes. Modern threat intelligence sources preferentially use SHA256, and security tools increasingly focus on this format. SHA256 hashes provide better collision resistance and broader compatibility with modern threat intelligence platforms.
SSDEEP Fuzzy Hashes: SSDEEP produces fuzzy hashes that can match similar files rather than exact file matches. Represented as strings like "3072:abc123+def456:xyz789", fuzzy hashes help identify variants and modified versions of malware. Not all tools support fuzzy hashes, but specialized malware analysis platforms often include this capability.
Import Hash (Imphash): Imphash represents the hash of a binary's imported functions, providing an indicator that survives minor code changes and recompilation. Imphash helps identify malware families that reuse common libraries or infrastructure code. Security researchers increasingly use Imphash for malware categorization.
PE File Section Hashes: Beyond full-file hashes, threat researchers sometimes specify hashes of specific executable sections. These section hashes help identify code-only changes versus data changes in malware variants.
ICS/SCADA Firmware Hashes: In industrial control environments, firmware hashes for PLC devices and SCADA systems represent critical IOCs for detecting compromised industrial equipment.
Email-Based IOCs
Email represents a significant attack vector, producing numerous IOC types.
Email Addresses: Sender or recipient email addresses from phishing campaigns or compromised accounts become IOCs. "attacker@malicious.com" or compromised employee addresses identify email infrastructure involved in attacks.
Email Subject Lines: Specific subject line patterns from phishing campaigns can serve as IOCs. Complex email filtering rules might block messages with exact or pattern-matched subject lines associated with known campaigns.
Message IDs: Email message IDs provide unique identifiers for specific messages. These are particularly valuable in incident response when identifying which emails reached which mailboxes.
SMTP Server IPs: The IP addresses of mail servers sending malicious emails become IOCs when identified. These help mail administrators identify compromised mail servers or attacker infrastructure.
Authentication Records: SPF, DKIM, and DMARC record information characterizes email infrastructure. Threat reports might identify spoofed domains using specific DKIM keys or SPF configurations.
Email Headers: Specific header values or patterns indicate phishing emails. The X-Originating-IP header showing an unusual geolocation, for instance, might indicate a compromised account.
Behavioral and Pattern-Based IOCs
Beyond specific artifacts, some IOCs represent behavioral patterns and tactics.
File Paths and Registry Keys: Windows registry keys and file paths represent malware indicators. "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\MalwareName" or "C:\Windows\System32\drivers\etc\hosts" modifications indicate malicious activity.
Process Command Lines: Specific command line arguments or patterns indicate malicious execution. "powershell.exe -encodedcommand
Mutex Names: Malware often creates mutual exclusion objects (mutexes) to ensure only one instance runs. Identifying specific mutex names like "Global\MalwareFamily_Mutex" allows detection of malware instances.
User Agent Strings: Web-based malware and backdoors use specific user agent strings in HTTP requests. Identifying these strings helps detect malicious web traffic.
SSL Certificate Fingerprints: TLS certificate fingerprints represent another IOC type. A specific certificate SHA256 hash or serial number identifies an attacker's certificate infrastructure.
TLS/SSL JA3 Fingerprints: JA3 fingerprints capture SSL/TLS client behavior, enabling detection of specific malware families communicating through HTTPS. These fingerprints represent unique combinations of SSL parameters.
Geolocation Patterns: Impossible travel detection—logins from two geographically distant locations in an impossibly short timeframe—represents a behavioral IOC indicating account compromise.
Document and Archive IOCs
File containers like Office documents and archives produce specialized IOCs.
OLE Embedded Stream Objects: Microsoft Office documents contain OLE streams that malware exploits. Threat researchers identify suspicious OLE streams as IOCs.
Macro Signatures: Office document macros contain signatures that analysts extract. Identifying specific macro IOCs helps detect macro-based malware delivery.
Archive File Contents: Threat reports might identify specific files within ZIP archives or other compressed containers. These nested file IOCs help identify suspicious archives.
Archive Passwords: Some threat intelligence identifies specific passwords used to protect malicious archives. This information helps automated tools properly extract and analyze suspicious archives.
Mobile and Platform-Specific IOCs
Different platforms produce platform-specific IOC formats.
Android Package Names: Mobile malware analysis produces Android package names (APKs) as IOCs. "com.example.malicious" identifies specific Android applications.
iOS Bundle IDs: Apple ecosystem malware produces bundle identifiers as IOCs. These iOS-specific identifiers work similarly to Android package names.
macOS Bundle Identifiers: macOS malware similarly uses bundle identifiers to identify suspicious applications.
Windows Shortcut (LNK) File Indicators: Malicious LNK files contain specific attributes that serve as IOCs. File size, target path, or embedded icon information can identify suspicious shortcuts.
Custom and Proprietary IOC Formats
Different security platforms and threat intelligence sources develop proprietary IOC formats for specialized use cases.
Shodan Fingerprints: Shodan search engine IOCs identify specific services or configurations. "http.server:Apache/2.4.1" might identify vulnerable servers in attack patterns.
YARA Rules: YARA rules describe strings and byte-sequence patterns that match malicious content inside files and process memory. While more sophisticated than a single atomic indicator, a YARA rule functions as a portable IOC in malware analysis and threat-hunting workflows — you ship the rule, and any engine that speaks YARA can scan for the family it describes. (See the structured-formats table above for how YARA compares to Sigma, which does the same job for log events.)
Sigma Rules: Sigma is the log-detection counterpart to YARA. A Sigma rule is a generic, vendor-neutral description of a suspicious log event that a converter translates into a concrete SIEM query — Splunk, Elastic, or Microsoft Sentinel. Sharing detection logic as Sigma lets analysts publish a single rule that everyone can run regardless of which SIEM they operate.
STIX Objects: STIX (Structured Threat Information Expression) is the dominant machine-readable standard for packaging threat intelligence. STIX 2.1 uses JSON to represent indicators, malware, threat actors, and — crucially — the relationships between them, so an IOC arrives with context (confidence, validity window, attribution) rather than as a bare string. STIX bundles are typically distributed over the TAXII protocol.
IOC Format Support in Modern Tools
Comprehensive IOC extraction tools should support:
- All IPv4 and IPv6 address formats
- Domain names and subdomains
- URLs with various protocols
- All common hash types (MD5, SHA1, SHA256)
- Email addresses and headers
- File paths and registry keys
- Process command lines and mutex names
- SSL/TLS certificates and fingerprints
- Mobile-specific indicators
- And increasingly, machine-readable formats like STIX/TAXII
If you are pulling indicators out of a threat report or paste of raw text, extract, normalize, and defang them first — then export to CSV, STIX, or a blocklist. The tool below does the extraction and normalization step in the browser:
Format Conversion and Normalization
Modern threat intelligence workflows require converting between formats. An IP address might need to be represented in CIDR notation, a domain name converted to punycode for internationalized domains, or a hash converted between uppercase and lowercase representations.
Good IOC extraction tools include format normalization capabilities, ensuring consistency across different representation styles. This reduces false negatives from format mismatches and improves threat detection effectiveness.
Conclusion
The diversity of IOC formats reflects the complexity of modern threat landscapes and the many ways malicious actors leverage infrastructure. Comprehensive understanding of supported IOC formats enables security teams to effectively extract, validate, and utilize threat intelligence. Modern extraction tools should handle traditional network-based IOCs, file indicators, email artifacts, behavioral patterns, and emerging format types. As threats evolve and new attack vectors emerge, new IOC formats continually appear, requiring threat intelligence platforms to remain current with evolving indicator standards and formats.