In cybersecurity and computer forensics, an indicator of compromise (IoC) is a technical artifact or observable event on a computer network or system that suggests a cyberattack is imminent or in progress, or that a compromise may already have occurred. [1]
Common IoCs include virus signatures, suspicious IP addresses, checksums or hashes of malware files, and malicious URLs or domain names associated with botnet command-and-control servers. The subject line of a malicious email message can also serve as an indicator. [1] Once IoCs are identified through incident response or forensic analysis, they can be used for early detection of future attacks with intrusion detection systems and antivirus software.
Indicator types are sometimes arranged in a "Pyramid of Pain", ranked by how much difficulty an attacker faces in altering the behaviour that generates each one. File hash values form the base, followed by IP addresses, domain names, network and host artefacts, and tools, with tactics, techniques and procedures (TTPs) at the top. Hashes are exact and simple to deploy but can be defeated with trivial changes such as recompiling code, whereas TTPs take defenders considerable effort to identify but are central to an attacker's methods and costly for them to change. [2]
According to RFC 9424, IoCs are used across several layers of defence. Firewalls, intrusion detection systems and intrusion prevention systems use them to identify and block threats on networks. Antivirus and endpoint detection and response products distribute them to the endpoints they protect. SIEM platforms compare them with logs gathered from network, endpoint and application sources. Defenders can also check newly acquired indicators against historical data, such as logged DNS queries or the hashes of email attachments, to uncover past compromises. The document describes IoCs as inexpensive and easy to deploy, which makes them useful to smaller organisations without large security teams. A single indicator shared through established channels can protect many organisations at once. [2]
NIST Special Publication 800-150 lists further uses. These include searching for matching records during an incident investigation, giving extra information to security operations center analysts, educating staff about threats and spotting trends that suggest security controls need to change. How an organisation uses an indicator depends heavily on how far it trusts the source. Indicators from a trusted source may be deployed straight away, while those from an untrusted one may need independent validation or testing first. Tolerance for disruption also matters. Some organisations accept occasionally blocking benign activity, whereas others that put service availability first may only monitor possibly malicious activity. [1]
Several standards and initiatives aim to automate IoC processing and sharing:
RFC 9424 regards automating the ingestion, processing, assessment and deployment of indicators as essential for handling them at scale. Manual processing and searching, it says, works only for small volumes or occasional cases. Automation also makes it easier to correlate detections across different log sources, times and locations. It can reduce confidence in an indicator gradually as the indicator becomes less specific, whereas manual approaches usually just include or exclude it. [2] NIST Special Publication 800-150, published in 2016, described the extraction of indicators as still largely manual and saw clear incentives to automate it. Automation, it says, lets analysts focus on interpreting information rather than on routine data manipulation. [1] The publication favours standard data formats for time-critical exchanges, such as setting up a firewall automatically to block certain traffic, because they reduce the need for human assistance. Unstructured formats such as text documents or email, it says, suit high-level threat reports meant for people rather than machines. It also cautions that adopting particular formats and protocols can demand significant time and resources. The value of that investment can be much reduced if sharing partners require different formats. [1]
Known indicators are often exchanged within the cybersecurity industry, commonly using the Traffic Light Protocol (TLP) to indicate how information may be shared. [5] RFC 9424 describes the labels as ranging from TLP:CLEAR, under which recipients may share with anyone, through TLP:GREEN (within the sharing community) and the two TLP:AMBER labels (within the recipient's organisation, sometimes extended to its clients), to TLP:RED, which bars sharing beyond the original exchange. [2] Other frameworks and standards are also used to support secure information sharing. [6] [7] [8] [9] [10] [11]
NIST Special Publication 800-150 notes that shared indicators can themselves be sensitive. Some, such as file hashes, network port numbers and registry key values, contain little or no personally identifiable information. Network indicators tend to be more sensitive in aggregate, because the relationships between network entities they reveal may allow others to infer users' identities or the security tools an organisation relies on. Before network indicators are shared, the publication recommends anonymising or sanitising any that contain the IP or MAC addresses of target systems, or that could reveal the structure of internal networks. [1]
RFC 9424, an informational document published by the Internet Engineering Task Force in 2023, describes a lifecycle in which indicators are discovered, assessed, shared and deployed. Indicators are found by manual investigation or automated analysis, either by extracting them from logs that record protocol traffic, code execution or system activity, or by analysing attacker tools and behaviour. Defenders weigh each indicator according to its source, freshness, confidence level and the threat it is linked to; an indicator passed on without context, such as the threat actor behind it or its role in an attack, is of little use for network defence. When a deployed indicator is detected, typical responses are logging the event, raising an alert or blocking the activity. Indicators that are no longer relevant, for example because the attacker has changed tactics or a defender has remediated the threat, are retired to reduce false positives. [2]
NIST Special Publication 800-150 describes ideal indicators as timely, relevant, accurate, specific and actionable. A timely indicator reaches recipients quickly enough to leave them time to prepare a response. A relevant one applies to the recipient's operating environment and the threats it faces. Accurate indicators are correct, complete and unambiguous. Specific indicators describe observable events clearly enough to detect threats while limiting false positives and false negatives. Actionable ones come with enough information and context for the recipient to work out a suitable response. The publication notes that in practice an indicator may show only some of these qualities. [1]
RFC 9424 notes that every type of indicator involves a trade-off between the risk of false positives and the risk of missing attacks. Indicators that are cheap for an attacker to change are described as "fragile". For example, hashes of phishing attachments are often altered from one campaign to the next. More specific indicators tend to be more fragile. Broader ones, such as tool fingerprints or some network artefacts, last longer but are more likely to match benign software as well, and combining several low-specificity indicators can raise confidence in a detection. Precision also depends on context. An IP address assigned by a cloud-hosting provider, or one belonging to a legitimate web server the attacker has compromised, is a weaker indicator than one tied to infrastructure the attacker owns. Wider use of cloud services, proxies, VPNs and carrier-grade NAT is also making IP addresses less specific. The document further observes that sharers sometimes strip context from indicators because of privacy concerns, which can greatly reduce their usefulness to recipients. [2]
RFC 9424 gives several examples of indicators in use. In one, investigations by the UK's National Cyber Security Centre (NCSC) working with industry produced a set of indicators linked to the intrusion set known as APT33. The set comprised 9 hashes and email subject lines, 5 IP addresses and 7 domain names. It was shared with public and private sector organisations so that network defenders could look for the indicators in their own networks and block them to prevent future attacks. A joint advisory issued in November 2021 by the Federal Bureau of Investigation, the Cybersecurity and Infrastructure Security Agency, the Australian Cyber Security Centre and the NCSC shared further indicators for the group, including 8 hashes of malicious executables and 3 IP addresses. [2]
The document also cites the NCSC's Protective DNS service, a free DNS filtering service for UK public sector organisations, as an example of network-level indicators adding a layer of defence. Malicious domains can be added to the service straight away, protecting the more than 925 public sector bodies that use it. In 2021 it blocked more than 160 million of the 602 billion DNS queries made by the organisations signed up to it. [2]