OpenIOC Format
OpenIOC is an XML-based framework for encoding indicators of compromise using Boolean logic trees, enabling machine-readable sharing of threat artifacts discovered during incident response investigations.
Continue your mission
OpenIOC is an XML-based framework for encoding indicators of compromise using Boolean logic trees, enabling machine-readable sharing of threat artifacts discovered during incident response investigations.
# OpenIOC Format
OpenIOC (Open Indicators of Compromise) is an XML-based framework originally developed by Mandiant to give incident responders a standardized, machine-readable language for documenting threat artifacts. Before OpenIOC existed, investigators recorded findings in prose reports, spreadsheets, or proprietary formats that could not be directly imported into detection tooling. OpenIOC solves that problem by providing a structured schema where technical observables such as file hashes, registry keys, mutex names, IP addresses, and process behaviors can be encoded with Boolean logic and immediately operationalized inside endpoint scanners, SIEMs, and threat intelligence platforms. The format is open, meaning any organization can adopt and extend it without licensing fees, which has made it a foundational building block in the broader threat intelligence sharing ecosystem.
---
OpenIOC is a formally defined XML schema that encodes the technical characteristics of a known threat into a structured, portable document. Each OpenIOC document, called an IOC, contains metadata about who authored it and when, alongside a logical tree of indicator conditions. Those conditions reference specific observable properties of a compromised system or network, expressed as typed key-value pairs such as FileItem/Md5sum equaling a specific hash value or RegistryItem/KeyPath containing a named persistence key.
OpenIOC is not a threat intelligence feed. It is a format for expressing detection logic, not a source of intelligence. Threat feeds deliver raw data; OpenIOC defines the precise conditions under which that data constitutes a match for a known threat. This distinction matters because analysts sometimes conflate the two, expecting an OpenIOC file to deliver context, attribution, or risk scores. It does none of those things. Its purpose is detection encoding, not intelligence enrichment.
OpenIOC is also distinct from YARA. YARA is a pattern-matching language primarily designed for file and memory scanning, with an emphasis on byte sequences and regular expressions. OpenIOC operates at a higher semantic level, describing system-state conditions across files, registry entries, network artifacts, processes, and services simultaneously. The two formats are complementary: many workflows use OpenIOC to define what a compromise looks like holistically, and YARA rules to scan specific file content referenced within an OpenIOC indicator.
OpenIOC should not be confused with STIX (Structured Threat Information eXpression) or its transport layer TAXII. STIX is a richer format that encodes full threat intelligence objects including actors, campaigns, courses of action, and relationships between them. OpenIOC focuses narrowly on the host and network observables that define a specific threat instance. Many organizations maintain both: OpenIOC for operational scanning, STIX for strategic intelligence sharing.
The framework supports two major versions. Version 1.0 was the original Mandiant release. Version 1.1 introduced minor schema refinements but did not fundamentally alter the logic structure. The community-maintained OpenIOC GitHub repository documents both versions.
---
Every OpenIOC document is an XML file with three primary sections: metadata, the definition tree, and optional reference links. The metadata section records the IOC's unique identifier (a UUID), its author, creation and modification timestamps, a human-readable name, and a short description. This provenance information matters for sharing because it allows receiving organizations to track the original source, manage versioning, and identify duplicate indicators.
The definition tree is where the detection logic lives. It uses a recursive structure of IndicatorItem specifies a document type (the category of system artifact being examined), a search term (the specific property within that artifact), a condition (such as "is," "contains," "matches," or "greater-than"), and a content value (the actual data to match against).
A concrete example clarifies the structure. Suppose an analyst investigating a ransomware incident identifies the following artifacts: a dropper executable with MD5 hash d41d8cd98f00b204e9800998ecf8427e, a persistence registry key at HKLM\Software\Microsoft\Windows\CurrentVersion\Run\UpdateService, and an outbound connection to IP address 198.51.100.44 on TCP port 443. The analyst encodes these as an OpenIOC with a top-level OR node containing three IndicatorItems. Any endpoint that matches any one of these three conditions is flagged as potentially compromised. If the analyst wants to require two conditions simultaneously, they nest them inside an AND node instead. This Boolean flexibility allows OpenIOC to express everything from simple single-indicator checks to complex multi-stage behavioral patterns.
The framework defines a default set of document types and terms covering Windows file system artifacts, registry entries, network connections, running processes, Windows services, DNS queries, user account properties, and more. These terms are defined in a managed dictionary called the IndicatorTerm Repository. Organizations can extend this dictionary with custom terms to cover proprietary telemetry sources. An endpoint detection tool that collects browser extension inventory, for instance, could define a custom document type called BrowserExtensionItem with properties like ExtensionId and Permissions, then author OpenIOC indicators that reference those properties.
Once authored, an OpenIOC file is deployed to a scanning tool. Mandiant's own IOC Finder (now open source) accepts OpenIOC files and scans a Windows host, comparing live system state against the indicator logic and reporting matches. Commercial endpoint detection and response (EDR) platforms including older versions of FireEye Endpoint Agent, Tanium Threat Response, and various SIEM platforms import OpenIOC files for automated alerting. The scanning process works by collecting system-state snapshots (running processes, network connections, file metadata, registry hive data) and evaluating each snapshot against the indicator tree.
A realistic deployment scenario: an incident response team is engaged to investigate a suspected intrusion at a financial services organization. During their forensic examination, they identify a novel backdoor family. The backdoor creates a mutex named Global\MS_TelemetryService_Lock, drops a DLL with a specific import hash, and communicates with a command-and-control server by querying a domain with a distinctive subdomain pattern. The team authors an OpenIOC encoding all three artifacts, with the mutex and DLL import hash joined by AND (both must be present for a definitive match) and the domain pattern added as a separate OR branch for network-layer detection. The IOC is then distributed to the organization's entire endpoint fleet via their EDR platform. Within four hours, the tool returns matches from eleven additional hosts that had been compromised without triggering prior alerts. The OpenIOC file converted an analyst's investigative notes into a fleet-wide detection capability in less than a day.
Implementation considerations include keeping indicator terms as specific as possible to avoid false positives, documenting the confidence level and incident context in the IOC metadata, and establishing a review workflow before deploying IOCs to production systems. Overly broad conditions, such as matching a common system file name without also requiring a hash, will generate noise and erode analyst trust in the detection content.
---
Without a structured format for encoding threat artifacts, investigative knowledge depreciates rapidly. An analyst who documents a compromise in a Word report produces knowledge that is readable by humans but not actionable by machines. The IOCs buried in that report cannot be automatically compared against a fleet of ten thousand endpoints. They cannot be ingested by a SIEM correlation rule. They cannot be shared with a partner organization in a format that their tools can immediately consume. OpenIOC solves this knowledge decay problem by making findings portable and machine-actionable from the moment they are recorded.
The business impact is measurable. Organizations that encode investigative findings into OpenIOC and deploy them enterprise-wide shorten their mean time to detect (MTTD) for related infections. When a threat actor re-uses infrastructure, tooling, or techniques, IOCs from a prior engagement become detection content for the next one. This compounds over time: each investigation adds to a library of detection logic that makes the organization incrementally harder to compromise using known tradecraft.
A concrete historical consequence illustrates the cost of not having this capability. During the 2013 Target breach investigation, indicators of the Citadel malware and the BlackPOS point-of-sale scraper were known to the security community before Target was compromised. Organizations that had structured those indicators as machine-actionable detection content and deployed them to endpoint or network monitoring tools had at least a theoretical opportunity to detect the intrusion earlier. Target's security operations center reportedly did receive automated alerts but lacked the workflow to act on them quickly. Structured, well-documented IOC content alone does not guarantee detection, but it removes a critical bottleneck by ensuring the detection logic is present and active in tooling before an incident escalates.
A common misconception is that OpenIOC indicators have long useful lives. In practice, many host-based IOCs, particularly file hashes, degrade quickly as threat actors modify their tooling. Effective OpenIOC programs treat indicator management as an ongoing operational discipline, not a one-time activity. IOCs must be reviewed for continued relevance, retired when they become obsolete, and updated when new variants are observed. Organizations that maintain a static IOC library without a review cadence often discover that a significant fraction of their detection content matches nothing in the current threat environment.
---
The Cyber Defense Advisors (CDA) Planetary Defense Model (PDM) addresses OpenIOC under the Threat Intelligence Domain (TID). Within the PDM methodology of Predictive Defense Intelligence (PDI), the guiding principle is to see the threat before it sees you. OpenIOC is a direct operational expression of that principle: it converts retrospective forensic findings into forward-looking detection content, closing the gap between what investigators discover and what detection systems can actively hunt for.
CDA's approach to OpenIOC differs from standard deployments in several respects. First, CDA treats IOC authoring as a quality-controlled process rather than an ad hoc analyst activity. Every IOC produced during a CDA-led engagement goes through a structured review that assesses indicator specificity, false-positive risk, and expected decay rate before the file is approved for deployment. This prevents the common failure mode where poorly scoped indicators flood security operations teams with noise and undermine confidence in the detection program.
Second, CDA integrates OpenIOC authoring directly into the incident response workflow rather than treating it as a post-engagement deliverable. Analysts author and validate IOC definitions while an investigation is active, allowing the detection content to be deployed to the client environment during the response rather than weeks later. This reduces dwell time for related infections discovered on other hosts.
Third, CDA maps every OpenIOC indicator to corresponding MITRE ATT&CK techniques, annotating the IOC metadata with the relevant tactic and technique identifiers. This enrichment connects detection content to the broader ATT&CK matrix, enabling clients to understand which portions of the adversary kill chain their IOC library covers and where gaps remain. The result is a detection posture that is measurable, auditable, and continuously improvable rather than a collection of disconnected indicator files.
Fourth, CDA establishes indicator lifecycle management programs for clients, defining review cadences, expiration policies, and escalation paths for IOCs that begin generating high false-positive rates. This transforms OpenIOC from a static artifact into a living component of the client's detection engineering practice.
---
---
---
CDA Theater missions that address topics covered in this article.
Cryptographic technique that encrypts data while preserving its original format and length, enabling protection without breaking legacy system compatibility.
Guide to HTTP/2 security covering binary framing, HPACK compression attacks, rapid reset vulnerability, stream multiplexing risks, and mitigation strategies.
Explanation of Certificate Transparency framework, covering log servers, Signed Certificate Timestamps, monitoring capabilities, and detection of fraudulent certificates.
Written by CDA Editorial
Found an issue? Help improve this article.