rfc9424.original.xml   rfc9424.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml2rfc.tools.ietf.org. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml2rfc.tools.ietf.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
etf-opsec-indicators-of-compromise-04" ipr="trust200902" obsoletes="" updates=""
submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="tru
e" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.12.0 -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902 " number="9424" docName="draft-ietf-opsec-indicators-of-compromise-04" obsoletes ="" updates="" submissionType="IETF" consensus="true" xml:lang="en" tocInclude=" true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="Indicators of Compromise">Indicators of Compromise (IoCs)
if the and Their Role in Attack Defence</title>
full title is longer than 39 characters --> <seriesInfo name="RFC" value="9424"/>
<title abbrev="Indicators of Compromise">Indicators of Compromise (IoCs) and
Their Role in Attack Defence</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-opsec-indicators-of-comp
romise-04"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Kirsty Paine" initials="K." surname="Paine"> <author fullname="Kirsty Paine" initials="K." surname="Paine">
<organization>Splunk Inc.</organization> <organization>Splunk Inc.</organization>
<address> <address>
<email>kirsty.ietf@gmail.com</email> <email>kirsty.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Ollie Whitehouse" initials="O." surname="Whitehouse"> <author fullname="Ollie Whitehouse" initials="O." surname="Whitehouse">
<organization>Binary Firefly</organization> <organization>Binary Firefly</organization>
<address> <address>
skipping to change at line 76 skipping to change at line 40
<address> <address>
<email>james.sellwood.ietf@gmail.com</email> <email>james.sellwood.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Andrew Shaw" initials="A." surname="Shaw"> <author fullname="Andrew Shaw" initials="A." surname="Shaw">
<organization>UK National Cyber Security Centre</organization> <organization>UK National Cyber Security Centre</organization>
<address> <address>
<email>andrew.s2@ncsc.gov.uk</email> <email>andrew.s2@ncsc.gov.uk</email>
</address> </address>
</author> </author>
<date year="2023"/> <date year="2023" month="August"/>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2
rfc will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area> <area>General</area>
<workgroup>OPSEC</workgroup> <workgroup>OPSEC</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. --
>
<keyword>IoC</keyword> <keyword>IoC</keyword>
<keyword>Attack Defence</keyword> <keyword>Attack Defence</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>Cyber defenders frequently rely on Indicators of Compromise (IoCs) to <t>Cyber defenders frequently rely on Indicators of Compromise (IoCs) to
identify, trace, and block malicious activity in networks or on identify, trace, and block malicious activity in networks or on
endpoints. This draft reviews the fundamentals, opportunities, endpoints. This document reviews the fundamentals, opportunities,
operational limitations, and recommendations for IoC use. It highlights th operational limitations, and recommendations for IoC use. It highlights
e the need for IoCs to be detectable in implementations of Internet
need for IoCs to be detectable in implementations of Internet protocols, protocols, tools, and technologies -- both for the IoCs' initial
tools, and technologies - both for the IoCs' initial discovery and their discovery and their use in detection -- and provides a foundation for
use in detection - and provides a foundation for approaches to approaches to operational challenges in network security.</t>
operational challenges in network security.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>This draft describes the various types of Indicator of Compromise (IoC) <t>This document describes the various types of IoCs and how they are
and how they are used effectively in attack defence (often called cyber used effectively in attack defence (often called "cyber defence"). It
defence). It introduces concepts such as the Pyramid of Pain <xref target= introduces concepts such as the Pyramid of Pain <xref target="PoP"
"PoP" format="default"/> format="default"/> and the IoC lifecycle to highlight how IoCs may be
and the IoC lifecycle to highlight how IoCs may be used to provide a broad used to provide a broad range of defences. This document provides
range suggestions for implementers of controls based on IoCs as well as
of defences. This draft provides suggestions for implementers of controls potential operational limitations. Two case studies that demonstrate
based on IoCs, the usefulness of IoCs for detecting and defending against real-world
as well as potential operational limitations. attacks are included. One case study involves an intrusion set (a set of
Two case studies which demonstrate the usefulness of IoCs for detecting malicious activity and behaviours attributed to one threat actor) known
and defending against real world attacks are included. One case study invo as "APT33", and the other involves an attack tool called "Cobalt Strike".
lves an intrusion set This
(a set of malicious activity and behaviours attributed to one threat actor document is not a comprehensive report of APT33 or Cobalt Strike and is
) known as APT33 and the other an intended to be read alongside publicly published reports (referred to as
attack tool called Cobalt Strike. This document is not a comprehensive rep "open-source material" among cyber intelligence practitioners) on these
ort of threats (for example, <xref target="Symantec" format="default"/> and
APT33 or Cobalt Strike and is intended to be read alongside publicly publi <xref target="NCCGroup" format="default"/>, respectively). </t>
shed
reports (referred to as open source material among cyber intelligence prac
titioners) on
these threats (for example, <xref target="Symantec" format="default"/> and
<xref target="NCCGroup" format="default"/>, respectively). </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>Attack defence: the activity of providing cyber security to an <dl newline="true" spacing="normal">
environment through the prevention, detection and response to <dt>Attack defence:</dt><dd>The activity of providing cyber security to
an environment through the prevention of, detection of, and response to
attempted and successful cyber intrusions. A successful defence can be attempted and successful cyber intrusions. A successful defence can be
achieved through the blocking, monitoring and response to adversarial achieved through blocking, monitoring, and responding to
activity at a network, endpoint or application levels. </t> adversarial activity at the network, endpoint, or application levels. </dd
<t>Command and control (C2) server: an attacker-controlled server used >
to communicate with, send commands to and receive data from compromised <dt>Command and control (C2) server:</dt><dd> An attacker-controlled
machines. Communication between a C2 server and compromised hosts is server used to communicate with, send commands to, and receive data from
called command and control traffic.</t> compromised machines. Communication between a C2 server and compromised
<t>Domain Generation Algorithm (DGA): used in malware strains to periodica hosts is called "command and control traffic".</dd>
lly generate domain names (via algorithm). <dt>Domain Generation Algorithm (DGA):</dt><dd>The algorithm used in
Malware may use DGAs to compute a destination for C2 traffic, rather than malware strains to periodically generate domain names (via algorithm).
relying on a pre-assigned list of static IP addresses or domains that can Malware may use DGAs to compute a destination for C2 traffic rather
be than relying on a pre-assigned list of static IP addresses or domains
blocked more easily when extracted from, or otherwise linked to, the malwa that can be blocked more easily when extracted from, or otherwise linked
re.</t> to, the malware.</dd>
<t>Kill chain: a model for conceptually breaking down a cyber intrusion in <dt>Kill chain:</dt><dd>A model for conceptually breaking down a cyber
to intrusion into stages of the attack from reconnaissance through to
stages of the attack from reconnaissance through to actioning the attacker actioning the attacker's objectives. This model allows defenders to
's think about, discuss, plan for, and implement controls to defend against
objectives. This model allows defenders to think about, discuss, plan for, discrete phases of an attacker's activity <xref target="KillChain"
and format="default"/>.</dd>
implement controls to defend discrete phases of an attacker's activity <dt>Tactics, Techniques, and Procedures (TTPs):</dt><dd>The way an
<xref target="KillChain" format="default"/>.</t> adversary undertakes activities in the kill chain -- the choices made,
<t>Tactics, Techniques, and Procedures (TTPs): the way an adversary undert methods followed, tools and infrastructure used, protocols employed, and
akes commands executed. If they are distinct enough, aspects of an attacker's
activities in the kill chain - the choices made, methods followed, tools a TTPs can form specific IoCs as if they were a fingerprint.</dd>
nd <dt>Control (as defined by US NIST):</dt><dd>A safeguard or
infrastructure used, protocols employed, and commands executed. If they ar countermeasure prescribed for an information system or an organisation
e designed to protect the confidentiality, integrity, and availability of
distinct enough, aspects of an attacker's TTPs can form specific Indicator its information and to meet a set of defined security
s of requirements <xref target="NIST" format="default"/>. </dd>
Compromise (IoCs), as if they were a fingerprint.</t> </dl>
<t>Control (as defined by US NIST): a safeguard or countermeasure prescrib
ed for an
information system or an organisation designed to protect the
confidentiality, integrity, and availability of its information and to mee
t a
set of defined security requirements. <xref target="NIST" format="default"
/>. </t>
</section> </section>
<section anchor="what" numbered="true" toc="default"> <section anchor="what" numbered="true" toc="default">
<name>IoC Fundamentals</name> <name>IoC Fundamentals</name>
<section anchor="sec-pop" numbered="true" toc="default"> <section anchor="sec-pop" numbered="true" toc="default">
<name>IoC Types and the Pyramid of Pain</name> <name>IoC Types and the Pyramid of Pain</name>
<t>Indicators of Compromise (IoCs) are observable artefacts <t>IoCs are observable artefacts relating to an attacker or their
relating to an attacker or their activities, such as their tactics, activities, such as their tactics, techniques, procedures, and
techniques, procedures, and associated tooling and infrastructure. associated tooling and infrastructure. These indicators can be
These indicators can be observed at network or endpoint (host) observed at the network or endpoint (host) levels and can, with varying
levels and can, with varying degrees of confidence, help network degrees of confidence, help network defenders to proactively block
defenders to proactively block malicious traffic or malicious traffic or code execution, determine a cyber intrusion
code execution, determine a cyber intrusion occurred, or associate occurred, or associate discovered activity to a known intrusion set
discovered activity to a known intrusion set and thereby potentially and thereby potentially identify additional avenues for
identify additional avenues for investigation. IoCs are deployed to fire investigation. IoCs are deployed to firewalls and other security
walls control points by adding them to the list of indicators that the
and other security control points by adding them to the list of indicato control point is searching for in the traffic that it is monitoring.
rs that
the control point is searching for in the traffic that it is monitoring.
When associated with malicious activity, the following are some examples of protocol-related IoCs: When associated with malicious activity, the following are some examples of protocol-related IoCs:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>IPv4 and IPv6 addresses in network traffic.</li> <li>IPv4 and IPv6 addresses in network traffic</li>
<li>Fully qualified domain names (FQDNs) in network traffic, DNS resol <li>Fully Qualified Domain Names (FQDNs) in network traffic, DNS
ver caches or logs.</li> resolver caches, or logs</li>
<li>TLS Server Name Indication values in network traffic.</li> <li>TLS Server Name Indication values in network traffic</li>
<li>Code signing certificates in binaries.</li> <li>Code-signing certificates in binaries</li>
<li>TLS certificate information (such as SHA256 hashes) in network tra <li>TLS certificate information (such as SHA256 hashes) in network
ffic.</li> traffic</li>
<li>Cryptographic hashes (e.g. MD5, SHA1 or SHA256) of malicious binar <li>Cryptographic hashes (e.g., MD5, SHA1, or SHA256) of malicious
ies or scripts when calculated from network traffic or file system artefacts.</l binaries or scripts when calculated from network traffic or file
i> system artefacts</li>
<li>Attack tools (such as Mimikatz <xref target="Mimikatz" format="def <li>Attack tools (such as Mimikatz <xref target="Mimikatz"
ault"/>) and their code structure format="default"/>) and their code structure and execution
and execution characteristics.</li> characteristics</li>
<li>Attack techniques, such as Kerberos golden tickets <xref target="G <li>Attack techniques, such as Kerberos Golden Tickets <xref
oldenTicket" format="default"/> which can be observed in network traffic or syst target="GoldenTicket" format="default"/>, that can be observed in
em artefacts.</li> network traffic or system artefacts</li>
</ul> </ul>
<t>The common types of IoC form a 'Pyramid of Pain' <xref target="PoP" f <t>The common types of IoC form a Pyramid of Pain <xref target="PoP"
ormat="default"/> that informs format="default"/> that informs prevention, detection, and mitigation
prevention, detection, and mitigation strategies. Each IoC type's strategies. The position of each IoC type in the pyramid represents how
place in the pyramid represents how much 'pain' a typical adversary much
experiences as part of changing the activity that produces that "pain" a typical adversary experiences as part of changing the
artefact. The greater pain an adversary experiences (towards the top) activity that produces that artefact. The greater pain an adversary
the less likely they are to change those aspects of their activity experiences (towards the top), the less likely they are to change
and the longer the IoC is likely to reflect the attacker's intrusion those aspects of their activity and the longer the IoC is likely to
set - i.e., the less fragile those IoCs will be from a defender's reflect the attacker's intrusion set (i.e., the less fragile those
perspective. The layers of the PoP commonly range from hashes up to IoCs will be from a defender's perspective). The layers of the PoP
TTPs, with the pain ranging from simply recompiling code to creating commonly range from hashes up to TTPs, with the pain ranging from
a whole new attack strategy. Other types of IoC do exist and could be simply recompiling code to creating a whole new attack strategy. Other
included in an extended version of the PoP should that assist the types of IoC do exist and could be included in an extended version of
defender to understand and discuss intrusion sets most relevant to them. the PoP should that assist the defender in understanding and
</t> discussing intrusion sets most relevant to them.</t>
<figure anchor="pop_diagram"> <figure anchor="pop_diagram">
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
/\ /\
/ \ MORE PAIN / \ MORE PAIN
/ \ LESS FRAGILE / \ LESS FRAGILE
/ \ LESS PRECISE / \ LESS PRECISE
/ TTPs \ / TTPs \
/ \ / \ / \ / \
============== | ============== |
/ \ | / \ |
/ Tools \ | / Tools \ |
/ \ | / \ |
skipping to change at line 230 skipping to change at line 194
/ \ | / \ |
====================================== | ====================================== |
/ \ | / \ |
/ IP Addresses \ | / IP Addresses \ |
/ \ \ / / \ \ /
============================================== ==============================================
/ \ LESS PAIN / \ LESS PAIN
/ Hash Values \ MORE FRAGILE / Hash Values \ MORE FRAGILE
/ \ MORE PRECISE / \ MORE PRECISE
====================================================== ======================================================
]]></artwork>
]]></artwork>
</figure> </figure>
<t>On the lowest (and least painful) level are hashes of malicious files
. <t>On the lowest (and least painful) level are hashes of malicious
These are easy for a defender to gather and can be deployed to firewalls files. These are easy for a defender to gather and can be deployed to
or endpoint protection to block malicious downloads or prevent code firewalls or endpoint protection to block malicious downloads or
execution. While IoCs aren't the only way for defenders to do this prevent code execution. While IoCs aren't the only way for defenders
kind of blocking, they are a quick, convenient, and unintrusive method. to do this kind of blocking, they are a quick, convenient, and
Hashes are precise detections for individual files based on their binary nonintrusive method. Hashes are precise detections for individual
content. To subvert this defence, however, an adversary need only files based on their binary content. To subvert this defence, however,
recompile code, or otherwise modify the file content with some trivial an adversary need only recompile code, or otherwise modify the file
changes, to modify the hash value.</t> content with some trivial changes, to modify the hash value.</t>
<t>The next two levels are IP addresses and domain names. Interactions <t>The next two levels are IP addresses and domain names. Interactions
with these may be blocked, with varying false positive rates with these may be blocked, with varying false positive rates
(misidentifying non-malicious traffic as malicious, see (misidentifying non-malicious traffic as malicious; see <xref
<xref target="sec-operational-limitations" format="default"/>), target="sec-operational-limitations" format="default"/>), and often
and often cause more pain to an adversary to subvert than file hashes. cause more pain to an adversary to subvert than file hashes. The
The adversary may have to change IP ranges, find a new provider, and adversary may have to change IP ranges, find a new provider, and
change their code (e.g., if the IP address is hard-coded, rather than change their code (e.g., if the IP address is hard-coded rather than
resolved). A similar situation applies to domain names, but in some case resolved). A similar situation applies to domain names, but in some
s threat actors have specifically registered these to masquerade as a particular cases, threat actors have specifically registered these to masquerade
organisation or to otherwise falsely imply or claim an association that will be as a particular organisation or to otherwise falsely imply or claim an
convincing or misleading to those they are attacking. While the process and cos association that will be convincing or misleading to those they are
t of registering new domain names are now unlikely to be prohibitive or distract attacking. While the process and cost of registering new domain names
ing to many attackers, there is slightly greater pain in selecting unregistered, are now unlikely to be prohibitive or distracting to many attackers,
but appropriate, domain names for such purposes.</t> there is slightly greater pain in selecting unregistered, but
<t>Network and endpoint artefacts, such as a malware's beaconing pattern appropriate, domain names for such purposes.</t>
on the network or the modified timestamps of files touched on an endpoin <t>Network and endpoint artefacts, such as a malware's beaconing
t, pattern on the network or the modified timestamps of files touched on
are harder still to change as they relate specifically to the attack an endpoint, are harder still to change as they relate specifically to
taking place and, in some cases, may not be under the direct control the attack taking place and, in some cases, may not be under the
of the attacker. However, more sophisticated attackers use TTPs or direct control of the attacker. However, more sophisticated attackers
tooling that provide flexibility at this level (such as Cobalt Strike's use TTPs or tooling that provides flexibility at this level (such as
malleable command and control <xref target="COBALT" format="default"/>) Cobalt Strike's malleable command and control <xref target="COBALT"
or a means by which some artefacts format="default"/>) or a means by which some artefacts can be masked
can be masked (see <xref target="Timestomp" format="default"/>).</t> (see <xref target="Timestomp" format="default"/>).</t>
<t>Tools and TTPs form the top two levels of the pyramid; these levels
describe a threat actor's methodology - the way they perform the attack. <t>Tools and TTPs form the top two levels of the pyramid; these levels
The tools level refers specifically to the software (and less frequently describe a threat actor's methodology -- the way they perform the
hardware) used to conduct the attack, whereas the TTPs level picks up on attack. The tools level refers specifically to the software (and less
all the other aspects of the attack strategy. IoCs at these levels are frequently, hardware) used to conduct the attack, whereas the TTPs
more complicated and complex - for example they can include the details level picks up on all the other aspects of the attack strategy. IoCs
of how an attacker deploys malicious code to perform reconnaissance of at these levels are more complicated and complex -- for example, they
a victim's network, that pivots laterally to a valuable endpoint, and can include the details of how an attacker deploys malicious code to
then downloads a ransomware payload. TTPs and tools take perform reconnaissance of a victim's network, pivots laterally to
intensive effort to diagnose on the part of the defender, but they are a valuable endpoint, and then downloads a ransomware payload. TTPs and
fundamental to the attacker and campaign and hence incredibly painful tools take intensive effort to diagnose on the part of the defender,
for the adversary to change.</t> but they are fundamental to the attacker and campaign and hence
<t>The variation in discoverability of IoCs is indicated by the numbers incredibly painful for the adversary to change.</t>
of IoCs in the open threat intelligence community Alienvault <xref targe
t="ALIENVAULT" format="default"/>. <t>The variation in discoverability of IoCs is indicated by the
As of January 2023, Alienvault contained: numbers of IoCs in AlienVault, an open threat intelligence community
<xref target="ALIENVAULT" format="default"/>. As of January 2023,
AlienVault contained:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Groups (i.e., combinations of TTPs): 631</li> <li>Groups (i.e., combinations of TTPs): 631</li>
<li>Malware families (i.e., tools): ~27,000</li> <li>Malware families (i.e., tools): ~27,000</li>
<li>URL: 2,854,918</li> <li>URL: 2,854,918</li>
<li>Domain names: 64,769,363</li> <li>Domain names: 64,769,363</li>
<li>IPv4 addresses: 5,427,762</li> <li>IPv4 addresses: 5,427,762</li>
<li>IPv6 addresses: 12,009</li> <li>IPv6 addresses: 12,009</li>
<li>SHA256 hash values: 5,452,442</li> <li>SHA256 hash values: 5,452,442</li>
</ul> </ul>
<t>The number of domain names appears out of sync with the other counts, <t>The number of domain names appears out of sync with the other
which counts, which reduce on the way up the PoP. This discrepancy warrants
reduce on the way up the PoP. This discrepancy warrants further research further research; however, contributing factors may be the use of DGAs
; and the fact that threat actors use domain names to masquerade as
however, contributing factors may be the use of DGAs and the fact that t legitimate organisations and so have added incentive for
hreat creating new domain names as they are identified and confiscated.</t>
actors use domain names to masquerade as legitimate organisations and so
have
added incentive for creating new domain names as they are identified and
confiscated.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IoC Lifecycle</name> <name>IoC Lifecycle</name>
<t>To be of use to defenders, IoCs must first be discovered, assessed, s <t>To be of use to defenders, IoCs must first be discovered, assessed,
hared, shared, and deployed. When a logged activity is identified and
and deployed. When a logged activity is identified and correlated to an correlated to an IoC, this detection triggers a reaction by the
IoC defender, which may include an investigation, potentially leading to
this detection triggers a reaction by the defender which may include an more IoCs being discovered, assessed, shared, and deployed. This cycle
investigation, potentially leading to more IoCs being discovered, assess continues until the IoC is determined to no longer be
ed, relevant, at which point it is removed from the control space.</t>
shared, and deployed. This cycle continues until such time that the IoC
is
determined to no longer be relevant, at which point it is removed from t
he
control space.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Discovery</name> <name>Discovery</name>
<t>IoCs are discovered initially through manual investigation or <t>IoCs are discovered initially through manual investigation or
automated analysis. They can be discovered in a range of sources, automated analysis. They can be discovered in a range of sources,
including at endpoints and in the network (on the wire). They must eit including at endpoints and in the network (on the wire). They must
her be either be extracted from logs monitoring protocol packet captures,
extracted from logs monitoring protocol packet captures, code executio code execution, or system activity (in the case of hashes, IP
n or addresses, domain names, and network or endpoint artefacts) or be
system activity (in the case of hashes, IP addresses, domain names, determined through analysis of attack activity or tooling. In some
and network or endpoint artefacts), or be determined through analysis cases, discovery may be a reactive process, where IoCs from past or
of attack activity or tooling. In some cases, discovery may be a current attacks are identified from the traces left behind. However,
reactive process, where IoCs from past or current attacks are discovery may also result from proactive hunting for potential
identified from the traces left behind. However, discovery may also future IoCs extrapolated from knowledge of past events (such as from
result from proactive hunting for potential future IoCs extrapolated identifying attacker infrastructure by monitoring domain name
from knowledge of past events (such as from identifying attacker registration patterns).</t>
infrastructure by monitoring domain name registration patterns).</t>
<t>Crucially, for an IoC to be discovered, the indicator must be extra <t>Crucially, for an IoC to be discovered, the indicator must be
ctable from extractable from the Internet protocol, tool, or technology it is
the internet protocol, tool, or technology it is associated with. Iden associated with. Identifying a particular exchange (or sequence of
tifying a exchanged messages) related to an attack is of limited benefit if
particular exchange (or sequence of exchanged messages) related to an indicators cannot be extracted or, once they are extracted, cannot
attack is of be subsequently associated with a later related exchange of messages
limited benefit if indicators cannot be extracted, or, once they are e or artefacts in the same, or in a different, protocol. If it is not
xtracted, cannot possible to determine the source or destination of malicious attack
be subsequently associated with a later related exchange of messages o traffic, it will not be possible to identify and block subsequent
r artefacts in the attack traffic either.</t>
same, or in a different, protocol. If it is not possible to tell the s
ource or
destination of malicious attack traffic, it will not be possible to id
entify and
block subsequent attack traffic either.</t>
</section> </section>
<section anchor="sec-assessment" numbered="true" toc="default"> <section anchor="sec-assessment" numbered="true" toc="default">
<name>Assessment</name> <name>Assessment</name>
<t>Defenders may treat different IoCs differently, depending on the Io <t>Defenders may treat different IoCs differently, depending on the
Cs' quality IoCs' quality and the defender's needs and capabilities. Defenders
and the defender's needs and capabilities. Defenders may, for example, may, for example, place differing trust in IoCs depending on their
place differing trust in IoCs depending on their source, freshness, co source, freshness, confidence level, or the associated threat. These
nfidence decisions rely on associated contextual information recovered at the
level, or the associated threat. These decisions rely on associated co point of discovery or provided when the IoC was shared.</t>
ntextual information recovered at the point of <t>An IoC without context is not much use for network defence. On
discovery or provided when the IoC was shared.</t> the other hand, an IoC delivered with context (for example, the
<t>An IoC without context is not much use for network defence. On the threat actor it relates to, its role in an attack, the last time it
other was seen in use, its expected lifetime, or other related IoCs)
hand, an IoC delivered with context (for example the threat actor it r allows a network defender to make an informed choice on how to use
elates it to protect their network (for example, simply log it,
to, its role in an attack, the last time it was seen in use, its expec actively monitor it, or outright block it).</t>
ted
lifetime, or other related IoCs) allows a network defender to make an
informed choice on how to use it to protect their
network - for example, whether to simply log it, actively monitor it,
or
out-right block it.</t>
</section> </section>
<section anchor="sec-sharing" numbered="true" toc="default"> <section anchor="sec-sharing" numbered="true" toc="default">
<name>Sharing</name> <name>Sharing</name>
<t>Once discovered and assessed, IoCs are most helpful when deployed <t>Once discovered and assessed, IoCs are most helpful when deployed
in such a way to have a broad impact on the detection or disruption in such a way to have a broad impact on the detection or disruption
of threats, or shared at scale so many individuals and organisations of threats or shared at scale so many individuals and
can defend themselves. An IoC may be shared organisations can defend themselves. An IoC may be shared
individually (with appropriate context) in an unstructured manner or m individually (with appropriate context) in an unstructured manner or
ay be may be packaged alongside many other IoCs in a standardised format,
packaged alongside many other IoCs in a standardised format, such as S such as Structured Threat Information Expression <xref target="STIX"
tructured format="default"/>, Malware Information Sharing Platform (MISP) core
Threat Information Expression <xref target="STIX" format="default"/>, <xref target="I-D.dulaunoy-misp-core-format" format="default"/>,
MISP OpenIOC <xref target="OPENIOC" format="default"/>, and Incident
Core <xref target="MISPCORE" format="default"/>, OpenIOC <xref target= Object Description Exchange Format (IODEF) <xref target="RFC7970"
"OPENIOC" format="default"/> format="default"/>. This enables distribution via a structured feed,
and IODEF <xref target="RFC7970" format="default"/>. This enables dist such as one implementing Trusted Automated Exchange of Intelligence
ribution via a Information <xref target="TAXII" format="default"/>, or through a
structured feed, such as one implementing Trusted Automated Exchange o Malware Information Sharing Platform <xref target="MISP"
f Intelligence format="default"/>.</t>
Information <xref target="TAXII" format="default"/>, or through a Mal
ware Information Sharing <t>While some security companies and some membership-based groups
Platform <xref target="MISP" format="default"/>.</t> (often dubbed "Information Sharing and Analysis Centres (ISACs)" or
<t>While some security companies and some membership-based groups ( "Information Sharing and Analysis Organizations (ISAOs)") provide paid
often intelligence feeds containing IoCs, there are various free IoC
dubbed Information Sharing and Analysis Centres (ISACs) or Information sources available from individual security researchers up through
Sharing and Analysis Organizations (ISAOs)) provide paid intelligence small trust groups to national governmental cyber security
feeds organisations and international Computer Emergency Response Teams
containing IoCs, there are various free IoC sources available from ind (CERTs). Whoever they are, sharers commonly indicate the extent to
ividual which receivers may further distribute IoCs using frameworks like
security researchers up through small trust groups to national governm the Traffic Light Protocol <xref target="TLP" format="default"/>. At
ental its simplest, this indicates that the receiver may share with anyone
cyber security organisations and international Computer Emergency Resp (TLP:CLEAR), share within the defined sharing community (TLP:GREEN),
onse share within their organisation and their clients
Teams (CERTs). Whomever they are, sharers commonly indicate the extent (TLP:AMBER+STRICT), share just within their organisation
to which (TLP:AMBER), or not share with anyone outside the original specific
receivers may further distribute IoCs using frameworks like the Traffi IoC exchange (TLP:RED).</t>
c Light Protocol
<xref target="TLP" format="default"/>. At its simplest, this indicates
that the receiver may
share with anyone (TLP:CLEAR), share within the defined sharing commun
ity (TLP:
GREEN), share within their organisation and their clients (TLP:AMBER+S
TRICT), share
just within their organisation (TLP:AMBER), or not share with anyone
outside the original specific IoC exchange (TLP:RED).</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Deployment</name> <name>Deployment</name>
<t>For IoCs to provide defence-in-depth (see <xref target="depth" form <t>For IoCs to provide defence-in-depth (see <xref target="depth"
at="default"/>) format="default"/>) and so cope with different points of failure,
and so cope with different points of failure, correct deployment is im correct deployment is important. Different IoCs will detect
portant. malicious activity at different layers of the network stack and at
Different IoCs will detect malicious activity at different layers of t different stages of an attack, so deploying a range of IoCs enables
he network layers of defence at each security control, reinforcing the benefits
stack and at different stages of an attack, so deploying a range of Io of using multiple security controls as part of a defence-in-depth
Cs enables solution. The network security controls and endpoint solutions where
layers of defence at each security control, reinforcing the benefits o they are deployed need to have sufficient privilege, and sufficient
f using visibility, to detect IoCs and to act on them. Wherever IoCs exist,
multiple security controls as part of a defence-in-depth solution. The they need to be made available to security controls and associated
network security controls and endpoint solutions where they are deploy apparatus to ensure they can be deployed quickly and widely. While
ed need to IoCs may be manually assessed after discovery or receipt,
have sufficient privilege, and sufficient visibility, to detect IoCs a significant advantage may be gained by automatically ingesting,
nd to act processing, assessing, and deploying IoCs from logs or intelligence
on them. Wherever IoCs exist they need to be feeds to the appropriate security controls. As not all IoCs are of
made available to security controls and associated apparatus to ensure the same quality, confidence in IoCs drawn from each threat
they can intelligence feed should be considered when deciding whether to
be deployed quickly and widely. While IoCs may be manually assessed af deploy IoCs automatically in this way.</t>
ter discovery <t>IoCs can be particularly effective at mitigating malicious
or receipt, significant advantage may be gained by automatically inges activity when deployed in security controls with the broadest
ting, impact. This could be achieved by developers of security products or
processing, assessing, and deploying IoCs from logs or intelligence fe firewalls adding support for the distribution and consumption of
eds to the IoCs directly to their products, without each user having to do it,
appropriate security controls. As not all IoCs are of the same quality thus addressing the threat for the whole user base at once in a
, confidence machine-scalable and automated manner. This could also be achieved
in IoCs drawn from each threat intelligence feed should within an enterprise by ensuring those control points with the
be considered when deciding whether to deploy IoCs automatically in th widest aperture (for example, enterprise-wide DNS resolvers) are able
is way.</t> to act automatically based on IoC feeds.</t>
<t>IoCs can be particularly effective at mitigating malicious activity
when deployed in security controls with
the broadest impact. This could be achieved by developers of security
products
or firewalls adding support for the distribution and consumption of Io
Cs directly to
their products, without each user having to do it - thus addressing th
e threat
for the whole user base at once in a machine scalable and automated ma
nner. This could also be acheived
within an enterprise by ensuring those control points with the widest
aperture, for example
enterprise-wide DNS resolvers, are able to act automatically based on
IoC feeds.</t>
</section> </section>
<section anchor="sec-ioc-detection" numbered="true" toc="default"> <section anchor="sec-ioc-detection" numbered="true" toc="default">
<name>Detection</name> <name>Detection</name>
<t>Security controls with deployed IoCs monitor their relevant control <t>Security controls with deployed IoCs monitor their relevant
space and control space and trigger a generic or specific reaction upon
trigger a generic or specific reaction upon detection of the IoC in mo detection of the IoC in monitored logs or on network interfaces.</t>
nitored logs or on network interfaces.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Reaction</name> <name>Reaction</name>
<t>The reaction to an IoC's detection may differ depending on factors <t>The reaction to an IoC's detection may differ depending on
such factors such as the capabilities and configuration of the control it
as the capabilities and configuration of the control it is deployed in is deployed in, the assessment of the IoC, and the properties of the
, the log source in which it was detected. For example, a connection to a
assessment of the IoC, and the properties of the log source in which i known botnet C2 server may indicate a problem but does not guarantee
t was it, particularly if the server is a compromised host still
detected. For example, a connection to a known botnet C2 performing some other legitimate functions. Common reactions
server may indicate a problem but does not guarantee it, particularly include event logging, triggering alerts, and blocking or
if the
server is a compromised host still performing some other legitimate fu
nctions.
Common reactions include event logging, triggering alerts, and blockin
g or
terminating the source of the activity.</t> terminating the source of the activity.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>End of Life</name> <name>End of Life</name>
<t>How long an IoC remains useful varies and is dependent on factors <t>How long an IoC remains useful varies and is dependent on factors
including initial confidence level, fragility, and precision of the Io including initial confidence level, fragility, and precision of the
C IoC (discussed further in <xref target="sec-operational-limitations"
(discussed further in <xref target="sec-operational-limitations" forma format="default"/>). In some cases, IoCs may be automatically
t="default"/>). "aged" based on their initial characteristics and so will reach end
In some cases, IoCs may be of life at a predetermined time. In other cases, IoCs may become
automatically 'aged' based on their initial characteristics and so wil invalidated due to a shift in the threat actor's TTPs (e.g.,
l resulting from a new development or their discovery) or due to
reach end of life at a predetermined time. In other cases, IoCs may remediation action taken by a defender. End of life may also come
become invalidated due to a shift in the threat actor's TTPs (e.g., about due to an activity unrelated to attack or defence, such as
resulting from a new development or their discovery) or due to remedia when a third-party service used by the attacker changes or goes
tion offline. Whatever the cause, IoCs should be removed from detection
action taken by a defender. End of life may also come about due to an at the end of their life to reduce the likelihood of false
activity unrelated to attack or defence, such as when a third-party positives.</t>
service used by the attacker changes or goes offline. Whatever the cau
se,
IoCs should be removed from detection at the end of their life to redu
ce
the likelihood of false positives.</t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Using IoCs Effectively</name> <name>Using IoCs Effectively</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Opportunities</name> <name>Opportunities</name>
<t>IoCs offer a variety of opportunities to cyber defenders as part of a <t>IoCs offer a variety of opportunities to cyber defenders as part of
modern defence-in-depth strategy. No matter the size of an organisation, a modern defence-in-depth strategy. No matter the size of an
IoCs can provide an effective, scalable, and efficient defence mechanism organisation, IoCs can provide an effective, scalable, and efficient
against classes of attack from the latest threats or specific intrusion defence mechanism against classes of attack from the latest threats or
sets which may have struck in the past.</t> specific intrusion sets that may have struck in the past.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IoCs underpin and enable multiple layers of the modern defence-i <name>IoCs underpin and enable multiple layers of the modern defence-i
n-depth strategy</name> n-depth strategy.</name>
<t>Firewalls, Intrusion Detection Systems (IDS), and Intrusion Prevent <t>Firewalls, Intrusion Detection Systems (IDSs), and Intrusion
ion Systems Prevention Systems (IPSs) all employ IoCs to identify and mitigate
(IPS) all employ IoCs to identify and mitigate threats across networks threats across networks. Antivirus (AV) and Endpoint Detection and
. Anti-Virus Response (EDR) products deploy IoCs via catalogues or libraries to
(AV) and Endpoint Detection and Response (EDR) products deploy IoCs vi supported client endpoints. Security Incident Event Management
a catalogues (SIEM) platforms compare IoCs against aggregated logs from various
or libraries to supported client endpoints. Security Incident Event Ma sources -- network, endpoint, and application. Of course, IoCs do not
nagement address all attack defence challenges, but they form a vital tier
(SIEM) platforms compare IoCs against aggregated logs from various sou of any organisation's layered defence. Some types of IoC may be
rces - present across all those controls while others may be deployed only
network, endpoint, and application. Of course, IoCs do not address all in certain layers of a defence-in-depth solution. Further, IoCs
attack relevant to a specific kill chain may only reflect activity
defence challenges - but they form a vital tier of any organisation's performed during a certain phase and so need to be combined with
layered other IoCs or mechanisms for complete coverage of the kill chain as
defence. Some types of IoC may be present across all those controls wh part of an intrusion set.</t>
ile others
may be deployed only in certain layers of a defence-in-depth solution. <t>As an example, open-source malware can be deployed by many
Further, different actors, each using their own TTPs and
IoCs relevant to a specific kill infrastructure. However, if the actors use the same executable, the
chain may only reflect activity performed during a certain phase and s hash of the executable file remains the same, and this hash can be
o need to be deployed as an IoC in endpoint protection to block execution
combined with other IoCs or mechanisms for complete coverage of the ki regardless of individual actor, infrastructure, or other TTPs.
ll chain as part of an intrusion set.</t> Should this defence fail in a specific case, for example, if an actor
<t>As an example, open source malware can be deployed by many differen recompiles the executable binary producing a unique hash, other
t actors, defences can prevent them progressing further through their attack,
each using their own TTPs and infrastructure. However, if the actors u for instance, by blocking known malicious domain name lookups and
se the same thereby preventing the malware calling out to its C2 infrastructure.</
executable, the hash remains the same and this IoC can be deployed in t>
endpoint <t>Alternatively, another malicious actor may regularly change their
protection to block execution regardless of individual actor, infrastr tools and infrastructure (and thus the indicators associated with
ucture, or the intrusion set) deployed across different campaigns, but their
other TTPs. Should this defence fail in a specific case, for example i access vectors may remain consistent and well-known. In this case,
f an actor this access TTP can be recognised and proactively defended against,
recompiles the executable binary producing a unique hash, other defenc even while there is uncertainty of the intended subsequent
es can activity. For example, if their access vector consistently exploits
prevent them progressing further through their attack - for instance, a vulnerability in software, regular and estate-wide patching can
by blocking prevent the attack from taking place. However, should these
known malicious domain name look-ups and thereby preventing the malwar preemptive measures fail, other IoCs observed across multiple
e calling out campaigns may be able to prevent the attack at later stages in the
to its C2 infrastructure.</t> kill chain.</t>
<t>Alternatively, another malicious actor may regularly change their t
ools and
infrastructure (and thus the indicators associated with the intrusion
set) deployed across different
campaigns, but their access vectors may remain consistent and well-kno
wn. In this
case, this access TTP can be recognised and proactively defended again
st even while
there is uncertainty of the intended subsequent activity. For example,
if their
access vector consistently exploits a vulnerability in software, regul
ar and
estate-wide patching can prevent the attack from taking place. Should
these
pre-emptive measures fail however, other IoCs observed across multiple
campaigns
may be able to prevent the attack at later stages in the kill chain.</
t>
</section> </section>
<section anchor="sec-limited-resources" numbered="true" toc="default"> <section anchor="sec-limited-resources" numbered="true" toc="default">
<name>IoCs can be used even with limited resources</name> <name>IoCs can be used even with limited resources.</name>
<t>IoCs are inexpensive, scalable, and easy to deploy, making their us <t>IoCs are inexpensive, scalable, and easy to deploy, making their
e use particularly beneficial for smaller entities, especially where
particularly beneficial for smaller entities, especially where they ar they are exposed to a significant threat. For example, a small
e manufacturing subcontractor in a supply chain producing a critical,
exposed to a significant threat. For example, a small manufacturing highly specialised component may represent an attractive target
subcontractor in a supply chain producing a critical, highly specialis because there would be disproportionate impact on both the supply
ed chain and the prime contractor if it were compromised. It may be
component may represent an attractive target because there would be reasonable to assume that this small manufacturer will have only
disproportionate impact on both the supply chain and the prime contrac basic security (whether internal or outsourced), and while it is likel
tor y
if it were compromised. It may be reasonable to assume that this small to have comparatively fewer resources to manage the risks that it
manufacturer will have only basic security (whether internal or outsou faces compared to larger partners, it can still leverage IoCs to
rced) great effect. Small entities like this can deploy IoCs to give a
and while it is likely to have comparatively fewer resources to manage baseline protection against known threats without having access to a
the well-resourced, mature defensive team and the threat intelligence
risks it faces compared to larger partners, it can still leverage IoCs relationships necessary to perform resource-intensive
to investigations. While some level of expertise on the part of such a
great effect. Small entities like this can deploy IoCs to give a basel small company would be needed to successfully deploy IoCs, use of
ine IoCs does not require the same intensive training as needed for more
protection against known threats without having access to a well-resou subjective controls, such as those using machine learning, which
rced, require further manual analysis of identified events to verify if
mature defensive team and the threat intelligence relationships necess they are indeed malicious. In this way, a major part of the appeal
ary of IoCs is that they can afford some level of protection to
to perform resource-intensive investigations. While some level of expe organisations across spectrums of resource capability, maturity, and
rtise sophistication.</t>
on the part of such a small company would be needed to successfully de
ploy
IoCs, use of IoCs does not require the same intensive training as need
ed for
more subjective controls, such as those using machine learning which r
equire
further manual analysis of identified events to verify if they are ind
eed malicious.
In this way, a major part of the appeal of IoCs is
that they can afford some level of protection to organisations across
spectrums of resource capability, maturity, and sophistication.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IoCs have a multiplier effect on attack defence effort within an <name>IoCs have a multiplier effect on attack defence efforts within
organisation</name> an organisation.</name>
<t>Individual IoCs can provide widespread protection that scales effec <t>Individual IoCs can provide widespread protection that scales
tively effectively for defenders across an organisation or
for defenders across an organisation or ecosystem. Within a single org ecosystem. Within a single organisation, simply blocking one IoC may
anisation, simply blocking one IoC may protect thousands of users, and that blocking may be performed
protect thousands of users and that blocking may be performed (dependi (depending on the IoC type) across multiple security controls
ng on monitoring numerous different types of activity within networks,
the IoC type) across multiple security controls monitoring numerous di endpoints, and applications. The prime contractor from our earlier
fferent example can supply IoCs to the small subcontractor and thus further
types of activity within networks, endpoints, and applications. The pr uplift that smaller entity's defensive capability while protecting its
ime contractor elf and its interests at the same
from our earlier example can supply IoCs to the small subcontractor an time.</t>
d so <t>Multiple organisations may benefit from directly receiving
further uplift that smaller entity's defensive capability and at the s shared IoCs (see <xref target="sec-easy-sharing"
ame format="default"/>), but they may also benefit from the IoCs'
time protect itself and its interests.</t> application in services they utilise. In the case of an ongoing
<t>Multiple organisations may benefit through directly receiving email-phishing campaign, IoCs can be monitored, discovered, and
shared IoCs (see <xref target="sec-easy-sharing" format="default"/>), deployed quickly and easily by individual organisations. However, if
but they they are deployed quickly via a mechanism such as a protective
may also benefit through the IoCs' application in DNS filtering service, they can be more effective still -- an email
services they utilise. In the case of an ongoing email phishing campai campaign may be mitigated before some organisations' recipients ever
gn, click the link or before some malicious payloads can call out for
IoCs can be monitored, discovered, and deployed quickly and easily by instructions. Through such approaches, other parties can be
individual organisations. However, if they are deployed quickly via a protected without direct sharing of IoCs with those organisations or
mechanism such as a protective DNS filtering service, they can be more additional effort.</t>
effective still - an email campaign may be mitigated before some
organisations' recipients ever click the link or before some malicious
payloads can call out for instructions. Through such approaches other
parties
can be protected without direct sharing of IoCs with those organisatio
n, or additional effort.</t>
</section> </section>
<section anchor="sec-easy-sharing" numbered="true" toc="default"> <section anchor="sec-easy-sharing" numbered="true" toc="default">
<name>IoCs are easily shared between organisations</name> <name>IoCs are easily shared between organisations.</name>
<t>IoCs can also be very easily shared between individuals and organis <t>IoCs can also be very easily shared between individuals and
ations. Firstly, IoCs are easy to organisations. First, IoCs are easy to distribute as they can be
distribute as they can be represented concisely as text (possibly in h represented concisely as text (possibly in hexadecimal) and so are
exadecimal) frequently exchanged in small numbers in emails, blog posts, or
and so are frequently exchanged in small numbers technical reports. Second, standards, such as those mentioned in
in emails, blog posts, or technical reports. Secondly, standards, such <xref target="sec-sharing" format="default"/>, exist to provide
as those well-defined formats for sharing large collections or regular sets
mentioned in <xref target="sec-sharing" format="default"/>, exist to p of IoCs along with all the associated context. While discovering one
rovide IoC can be intensive, once shared via well-established routes, that
well-defined formats for sharing large collections or regular sets of individual IoC may protect thousands of organisations and thus all
IoC along of the users in those organisations. Quick and easy sharing of IoCs gi
with all the associated context. While ves blanket
discovering one IoC can be intensive, once shared via well-established coverage for organisations and allows widespread mitigation in a
routes timely fashion -- they can be shared with systems administrators,
(as discussed in <xref target="sec-assessment" format="default"/>) tha from small to large organisations and from large teams to single
t individual IoC may, further, protect individuals, allowing them all to implement defences on their
thousands of organisations and so all of their users. Quick and easy s networks.</t>
haring of IoCs gives blanket
coverage for organisations and allows widespread mitigation in a timel
y fashion
- they can be shared with systems administrators, from small to large
organisations and from large teams to single individuals, allowing the
m all to
implement defences on their networks.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IoCs can provide significant time savings</name> <name>IoCs can provide significant time savings.</name>
<t>Not only are there time savings from sharing IoCs, saving duplicati
on <t>Not only are there time savings from sharing IoCs, saving
of investigation effort, but deploying them automatically at scale is duplication of investigation effort, but deploying them
seamless for many enterprises. Where automatic deployment of IoCs is automatically at scale is seamless for many enterprises. Where
working well, organisations and users get blanket protection with mini automatic deployment of IoCs is working well, organisations and
mal users get blanket protection with minimal human intervention and
human intervention and minimal effort, a key goal of attack defence. minimal effort, a key goal of attack defence. The ability to do
The ability to do this at scale and at pace is often vital when respon this at scale and at pace is often vital when responding to agile
ding to threat actors that may change their intrusion set frequently and
agile threat actors that may change their intrusion set frequently and hence change the relevant IoCs. Conversely, protecting a complex
so the network without automatic deployment of IoCs could mean manually
relevant IoCs also change. Conversely, protecting a complex network wi updating every single endpoint or network device consistently and
thout reliably to the same security state. The work this entails
automatic deployment of IoCs could mean manually updating every single (including locating assets and devices, polling for logs and system
endpoint or information, and manually checking patch levels) introduces
network device consistently and reliably to the same security state. T complexity and a need for skilled analysts and engineers. While it
he is still necessary to invest effort both to enable efficient IoC
work this entails (including locating assets and deployment and to eliminate false positives when widely deploying
devices, polling for logs and system information, and manually checkin IoCs, the cost and effort involved can be far smaller than the work
g entailed in reliably manually updating all endpoint and network
patch levels) introduces complexity and a need for skilled analysts an devices. For example, legacy systems may be
d engineers. particularly complicated, or even impossible, to update.</t>
While it is still necessary to invest effort both to enable efficient
IoC deployment, and to eliminate false
positives when widely deploying IoCs, the cost and effort involved
can be far smaller than the work entailed in reliably manually
updating all endpoint and network devices. For example, particularly
on legacy systems that may be particularly complicated, or even
impossible, to update.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IoCs allow for discovery of historic attacks</name> <name>IoCs allow for discovery of historic attacks.</name>
<t>A network defender can use recently acquired IoCs in conjunction wi <t>A network defender can use recently acquired IoCs in conjunction
th with historic data, such as logged DNS queries or email attachment
historic data, such as logged DNS queries or email attachment hashes, hashes, to hunt for signs of past compromise. Not only can this
to technique help to build a clear picture of past attacks, but it
hunt for signs of past compromise. Not only can this technique help to also allows for retrospective mitigation of the effects of any
build up a clear picture of past attacks, but it also allows for previous intrusion. This opportunity is reliant on historic data not
retrospective mitigation of the effects of any previous intrusion. Thi having been compromised itself, by a technique such as Timestomp
s <xref target="Timestomp" format="default"/>, and not being
opportunity is reliant on historic data not having been compromised it incomplete due to data retention policies, but it is nonetheless
self, valuable for detecting and remediating past attacks.</t>
by a technique such as Timestomp <xref target="Timestomp" format="defa
ult"/>, and not being
incomplete due to data retention policies, but is nonetheless valuable
for
detecting and remediating past attacks.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IoCs can be attributed to specific threats</name> <name>IoCs can be attributed to specific threats.</name>
<t>Deployment of various modern security controls, such as firewall fi <t>Deployment of various modern security controls, such as firewall
ltering filtering or EDR, come with an inherent trade-off between breadth of
or EDR, come with an inherent trade-off between breadth of protection protection and various costs, including the risk of false positives
and (see <xref target="sec-precision" format="default"/>), staff time,
various costs, including the risk of false positives (see <xref target and pure financial costs. Organisations can use threat modelling and
="sec-precision" format="default"/> ), information assurance to assess and prioritise risk from identified
staff time, and pure financial costs. Organisations can use threat mod threats and to determine how they will mitigate or accept each of
elling them. Contextual information tying IoCs to specific threats or
and information assurance to assess and prioritise risk from identifie actors and shared alongside the IoCs enables organisations to focus
d threats their defences against particular risks. This contextual information
and to determine how they will mitigate or accept each of them. Contex is generally expected by those receiving IoCs as it allows them the
tual technical freedom and capability to choose their risk appetite,
information tying IoCs to specific threats or actors and shared alongs security posture, and defence methods. The ease of sharing this
ide contextual information alongside IoCs, in part due to the formats
the IoCs enables organisations to focus their defences against particu outlined in <xref target="sec-sharing" format="default"/>, makes it
lar easier to track malicious actors across campaigns and
risks. This contextual information is generally expected by those rece targets. Producing this contextual information before sharing IoCs
iving IoCs as it can take intensive analytical effort as well as specialist tools and
allows them the technical freedom and capability to choose their training. At its simplest, it can involve documenting sets of IoCs
risk appetite, security posture and defence methods. The ease of shari from multiple instances of the same attack campaign, for example,
ng this from multiple unique payloads (and therefore with distinct file
contextual information alongside IoCs, in part due to the formats outl hashes) from the same source and connecting to the same C2 server. A
ined in more complicated approach is to cluster similar combinations of TTPs
<xref target="sec-sharing" format="default"/>, makes it easier to trac seen across multiple campaigns over a period of time. This can be
k malicious used alongside detailed malware reverse engineering and target
actors across campaigns and targets. Producing this contextual informa profiling, overlaid on a geopolitical and criminal backdrop, to
tion infer attribution to a single threat actor.</t>
before sharing IoCs can take intensive analytical effort as well as sp
ecialist
tools and training. At its simplest it can involve documenting sets of
IoCs
from multiple instances of the same attack campaign, say from multiple
unique
payloads (and therefore with distinct file hashes) from the same sourc
e and
connecting to the same C2 server. A more complicated approach is to cl
uster
similar combinations of TTPs seen across multiple campaigns over a per
iod of
time. This can be used alongside detailed malware reverse engineering
and target
profiling, overlaid on a geopolitical and criminal backdrop, to infer
attribution
to a single threat actor.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Case Studies</name> <name>Case Studies</name>
<t>The following two case studies illustrate how IoCs may be identifie <t>The following two case studies illustrate how IoCs may be
d identified in relation to threat actor tooling (in the first) and a
in relation to threat actor tooling (in the first) and a threat acto threat actor campaign (in the second). The case studies further
r highlight how these IoCs may be used by cyber defenders.</t>
campaign (in the second). The case studies further highlight how the
se
IoCs may be used by cyber defenders.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Cobalt Strike</name> <name>Cobalt Strike</name>
<t>Cobalt Strike <xref target="COBALT" format="default"/> is a commerc <t>Cobalt Strike <xref target="COBALT" format="default"/> is a
ial attack commercial attack framework used for penetration testing that
framework used for penetration testing that consists of an implant framework (beacon), a network protocol, and a
consists of an implant framework (beacon), network protocol, and a C C2 server. The beacon and network protocol are highly malleable,
2 server. meaning the protocol representation "on the wire" can be easily
The beacon and network protocol are highly malleable, meaning the pr changed by an attacker to blend in with legitimate traffic by
otocol ensuring the traffic conforms to the protocol specification, e.g.,
representation 'on the wire' can be easily changed by an attacker to HTTP. The proprietary beacon supports TLS encryption overlaid with a
blend in custom encryption scheme based on a public-private keypair. The
with legitimate traffic by ensuring the traffic conforms to the prot product also supports other techniques, such as domain fronting
ocol specification <xref target="DFRONT" format="default"/>, in an attempt to avoid
e.g. HTTP. The proprietary beacon supports TLS encryption obvious passive detection by static network signatures of domain
overlaid with a custom encryption scheme based on a public-private k names or IP addresses. Domain fronting is used to blend traffic to a
eypair. malicious domain with traffic originating from a network that is
The product also supports other techniques, such as domain fronting already communicating with a non-malicious domain regularly over
<xref target="DFRONT" format="default"/>, HTTPS.</t>
in attempt to avoid obvious passive detection by static network sign
atures of domain names or
IP addresses. Domain fronting is used to blend traffic to a maliciou
s domain in with traffic
originating from a network to an already regularly communicated with
domain over HTTPS.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Overall TTP</name> <name>Overall TTP</name>
<t>A beacon configuration describes how the implant should operate a <t>A beacon configuration describes how the implant should operate
nd communicate and communicate with its C2 server. This configuration also
with its C2 server. This configuration also provides ancillary infor provides ancillary information such as the Cobalt Strike user
mation such as licence watermark.</t>
the Cobalt Strike user's licence watermark.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IoCs</name> <name>IoCs</name>
<t>Tradecraft has been developed that allows the fingerprinting of C <t>Tradecraft has been developed that allows the fingerprinting of C
2 servers based 2 servers
on their responses to specific requests. This allows the servers to based on their responses to specific requests. This
be identified allows the servers to be identified, their beacon configurations
and then their beacon configurations to be downloaded and the associ to be downloaded, and the associated infrastructure addresses to
ated be extracted as IoCs.</t>
infrastructure addresses extracted as IoCs.</t>
<t>The resulting mass IoCs for Cobalt Strike are: <t>The resulting mass IoCs for Cobalt Strike are:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>IP addresses of the C2 servers</li> <li>IP addresses of the C2 servers</li>
<li>domain names used</li> <li>domain names used</li>
</ul> </ul>
<t>Whilst these IoCs need to be refreshed regularly (due to the ease <t>Whilst these IoCs need to be refreshed regularly (due to the
of which they ease of which they can be changed), the authors' experience of
can be changed), the authors' experience of protecting public sector protecting public sector organisations shows that these IoCs are
organisations effective for disrupting threat actor operations that use Cobalt
show these IoCs are effective for disrupting threat actor operations
that use Cobalt
Strike.</t> Strike.</t>
<t>These IoCs can be used to check historical data for evidence of p <t>These IoCs can be used to check historical data for evidence of
ast compromise, past compromise and deployed to detect or block future
as well as deployed to detect or block future infection in a timely infection in a timely manner, thereby contributing to preventing
manner, thereby the loss of user and system data.</t>
contributing to preventing the loss of user and system data.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>APT33</name> <name>APT33</name>
<t>In contrast to the first case study, this describes a current campa
ign by <t>In contrast to the first case study, this describes a current
the threat actor APT33, also known as Elfin and Refined Kitten (see <x campaign by the threat actor APT33, also known as Elfin and Refined
ref target="Symantec" format="default"/>). Kitten (see <xref target="Symantec" format="default"/>). APT33 has
APT33 has been assessed by industry to be a state-sponsored group <xre been assessed by the industry to be a state-sponsored group <xref targ
f target="FireEye2" format="default"/>, et="FireEye2" format="default"/>; yet, in
yet in this case study, IoCs still gave defenders an effective tool ag this case study, IoCs
ainst such still gave defenders an effective tool against such a powerful
a powerful adversary. The group has been active since at least 2015 an adversary. The group has been active since at least 2015 and is
d is known known to target a range of sectors including petrochemical,
to target a range of sectors including petrochemical, government, engi government, engineering, and manufacturing. Activity has been seen
neering, in countries across the globe but predominantly in the USA and
and manufacturing. Activity has been seen in countries across the glob Saudi Arabia.</t>
e, but
predominantly in the USA and Saudi Arabia.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Overall TTP</name> <name>Overall TTP</name>
<t>The techniques employed by this actor exhibit a relatively low le <t>The techniques employed by this actor exhibit a relatively low
vel of level of sophistication, considering it is a state-sponsored group.
sophistication considering it is a state-sponsored group; typica Typically, APT33 performs spear phishing (sending targeted
lly, APT33 malicious emails to a limited number of pre-selected recipients)
performs spear phishing (sending targeted malicious emails to a with document lures that imitate legitimate publications. User
limited number interaction with these lures executes the initial payload and
of pre-selected recipients) with document lures that imitate leg enables APT33 to gain initial access. Once inside a target
itimate network, APT33 attempts to pivot to other machines to gather
publications. User interaction with these lures executes the ini documents and gain access to administrative credentials. In some
tial payload and cases, users are tricked into providing credentials that are then
enables APT33 to gain initial access. Once inside a target netwo used with Ruler <xref target="RULER" format="default"/>, a freely
rk, APT33 attempts available tool that allows exploitation of an email client. The
to pivot to other machines to gather documents and gain access t attacker, in possession of a target's password, uses Ruler to
o administrative access the target's mail account and embeds a malicious script
credentials. In some cases, users are tricked into providing cre that will be triggered when the mail client is next opened,
dentials that are resulting in the execution of malicious code (often additional
then used with RULER <xref target="RULER" format="default"/>, a malware retrieved from the Internet) (see <xref target="FireEye"
freely available tool that allows exploitation of an email format="default"/>).</t>
client. The attacker, in possession of a target's password, uses <t>APT33 sometimes deploys a destructive tool that overwrites the
RULER to access the master boot record (MBR) of the hard drives in as many PCs as
target's mail account and embeds a malicious script which will b possible. This type of tool, known as a wiper, results in data
e triggered when the loss and renders devices unusable until the operating system is
mail client is next opened, resulting in the execution of malici reinstalled. In some cases, the actor uses administrator
ous code credentials to invoke execution across a large swathe of a
(often additional malware retrieved from the Internet) company's IT estate at once; where this isn't possible, the actor
(see <xref target="FireEye" format="default"/>).</t> may first attempt to spread the wiper manually or use
<t>APT33 sometimes deploys a destructive tool which overwrites the m worm-like capabilities against unpatched vulnerabilities
aster boot on the networked computers.</t>
record (MBR) of the hard drives in as many PCs as possible. This
type of tool,
known as a wiper, results in data loss and renders devices unusa
ble until the
operating system is reinstalled. In some cases, the actor uses a
dministrator
credentials to invoke execution across a large swathe of a compa
ny's IT estate at
once; where this isn't possible the actor may attempt to spread
the wiper first
manually or by using worm-like capabilities against unpatched vu
lnerabilities on
the networked computers.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IoCs</name> <name>IoCs</name>
<t>As a result of investigations by a partnership of industry and th <t>As a result of investigations by a partnership of the industry
e UK's National and the UK's National Cyber Security Centre (NCSC), a set of IoCs
Cyber Security Centre (NCSC), a set of IoCs were compiled and shar were compiled and shared with both public and private sector
ed with both public organisations so network defenders could search for them in their
and private sector organisations so network defenders could search networks. Detection of these IoCs is likely indicative of
for them in their APT33 targeting and could indicate potential compromise and
networks. Detection of these IoCs is likely indicative of APT33 ta subsequent use of destructive malware. Network defenders could
rgeting and could also initiate processes to block these IoCs to foil future
indicate potential compromise and subsequent use of destructive ma attacks. This set of IoCs comprised:
lware. Network
defenders could also initiate processes to block these IoCs to foi
l future attacks.
This set of IoCs comprised:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>9 hashes and email subject lines</li> <li>9 hashes and email subject lines</li>
<li>5 IP addresses</li> <li>5 IP addresses</li>
<li>7 domain names</li> <li>7 domain names</li>
</ul> </ul>
<t>In November 2021, a joint advisory concerning APT33 <xref target= <t>In November 2021, a joint advisory concerning APT33 <xref
"CISA" format="default"/> target="CISA" format="default"/> was issued by the Federal Bureau of
was issued by Federal Bureau of Investigation (FBI), the Cybersec Investigation (FBI), the Cybersecurity and Infrastructure Security
urity and Infrastructure Agency (CISA), the Australian Cyber Security Centre (ACSC), and
Security Agency (CISA), the Australian Cyber Security Centre (ACS NCSC. This outlined recent exploitation of vulnerabilities by
C), and NCSC. This outlined APT33, providing a thorough overview of observed TTPs and
recent exploitation of vulnerabilities sharing further IoCs:
by APT33, providing a thorough overview of observed TTPs, as well
as sharing further IoCs:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>8 hashes of malicious executables</li> <li>8 hashes of malicious executables</li>
<li>3 IP addresses</li> <li>3 IP addresses</li>
</ul> </ul>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec-operational-limitations" numbered="true" toc="default"> <section anchor="sec-operational-limitations" numbered="true" toc="default">
<name>Operational Limitations</name> <name>Operational Limitations</name>
<t>The different IoC types inherently embody a set of trade-offs for defen <t>The different IoC types inherently embody a set of trade-offs for
ders defenders between the risk of false positives (misidentifying
between the risk of false positives (misidentifying non-malicious traffi non-malicious traffic as malicious) and the risk of failing to identify
c as attacks. The attacker's relative pain of modifying attacks to subvert
malicious) and the risk of failing to identify attacks. The attacker's r known IoCs, as discussed using the PoP in <xref
elative target="sec-pop" format="default"/>, inversely correlates with the
pain of modifying attacks to subvert known IoCs, as discussed using the fragility of the IoC and with the precision with which the IoC
Pyramid of identifies an attack. Research is needed to elucidate the exact nature
Pain (PoP) in <xref target="sec-pop" format="default"/>, inversely corre of these trade-offs between pain, fragility, and precision.</t>
lates with the fragility of the IoC and
with the precision with which the IoC identifies an attack. Research is
needed to
elucidate the exact nature of these trade-offs between pain, fragility,
and precision.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Time and Effort</name> <name>Time and Effort</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Fragility</name> <name>Fragility</name>
<t>As alluded to in <xref target="sec-pop" format="default"/>, the Pyr <t>As alluded to in <xref target="sec-pop" format="default"/>, the
amid of Pain can be thought of in terms of PoP can be thought of in terms of fragility for the defender as well
fragility for the defender as well as pain for the attacker. The as pain for the attacker. The less painful it is for the attacker to
less painful it is change an IoC, the more fragile that IoC is as a defence tool. It
for the attacker to change an IoC, the more fragile that IoC is is relatively simple to determine the hash value for various
as a defence tool. malicious file attachments observed as lures in a phishing campaign
It is relatively simple to determine the hash value for various and to deploy these through AV or an email gateway security
malicious file control. However, those hashes are fragile and can (and often will)
attachments observed as lures in a phishing campaign and to depl be changed between campaigns. Malicious IP addresses and domain
oy these through names can also be changed between campaigns, but this may happen
AV or an email gateway security control. However, less frequently due to the greater pain of managing infrastructure
those hashes are fragile and can (and often will) be changed bet compared to altering files, and so IP addresses and domain names may
ween campaigns. provide a less fragile detection capability.</t>
Malicious IP addresses and domain names can also be changed betw <t>This does not mean the more fragile IoC types are
een campaigns, but worthless. First, there is no guarantee a fragile IoC will change,
this may happen less frequently due to the greater pain of manag and if a known IoC isn't changed by the attacker but wasn't blocked,
ing infrastructure compared to then the defender missed an opportunity to halt an attack in its
altering files, and so IP addresses and domain names may provide tracks. Second, even within one IoC type, there is variation in
a less fragile detection capability.</t> the fragility depending on the context of the IoC. The file hash of
<t>This does not mean the more fragile IoC types are worthless. Firstl a phishing lure document (with a particular theme and containing a
y, there is no specific staging server link) may be more fragile than the file hash
guarantee a fragile IoC will change, and if a known IoC isn't ch of a remote access trojan payload the attacker uses after initial
anged by the attacker access. That in turn may be more fragile than the file hash of an
but wasn't blocked then the defender missed an opportunity to ha attacker-controlled post-exploitation reconnaissance tool that
lt an attack in its doesn't connect directly to the attacker's infrastructure. Third,
tracks. Secondly, even within one IoC type, there is variation i some threats and actors are more capable or inclined to change than
n the fragility others, and so the fragility of an IoC for one may be very different
depending on the context of the IoC. The file hash of a phishing to an IoC of the same type for another actor.</t>
lure document (with <t>Ultimately, fragility is a defender's concern that impacts the
a particular theme and containing a specific staging server link ongoing efficacy of each IoC and will factor into decisions about
) may be more fragile end of life. However, it should not prevent adoption of individual
than the file hash of a remote access trojan payload the attacke IoCs unless there are significantly strict resource constraints that
r uses after initial demand down-selection of IoCs for deployment. More usually,
access. That in turn may be more fragile than the file hash of a defenders researching threats will attempt to identify IoCs of
n attacker-controlled post-exploitation varying fragilities for a particular kill chain to provide the
reconnaissance tool that doesn't connect directly to the attacke greatest chances of ongoing detection given available investigative
r's infrastructure. Thirdly, some threats and effort (see <xref target="sec-discoverability" format="default"/>)
actors are more capable or inclined to change than others, and s and while still maintaining precision (see <xref
o the fragility of an target="sec-precision" format="default"/>).</t>
IoC for one may be very different to an IoC of the same type for
another actor.</t>
<t>Ultimately, fragility is a defender's concern that impacts the ongo
ing efficacy of
each IoC and will factor into decisions about end of life. Howev
er, it should not
prevent adoption of individual IoCs unless there are significant
ly strict resource
constraints that demand down-selection of IoCs for deployment. M
ore usually, defenders
researching threats will attempt to identify IoCs of varying fra
gilities for a
particular kill chain to provide the greatest chances of ongoing
detection given
available investigative effort (see <xref target="sec-discoverab
ility" format="default"/>) and while still maintaining
precision (see <xref target="sec-precision" format="default"/>).
</t>
</section> </section>
<section anchor="sec-discoverability" numbered="true" toc="default"> <section anchor="sec-discoverability" numbered="true" toc="default">
<name>Discoverability</name> <name>Discoverability</name>
<t>To be used in attack defence, IoCs must first be discovered through <t>To be used in attack defence, IoCs must first be discovered
proactive through proactive hunting or reactive investigation. As noted in
hunting or reactive investigation. As noted in <xref target="sec <xref target="sec-pop" format="default"/>, IoCs in the tools and
-pop" format="default"/>, IoCs in the tools and TTPs levels of the PoP require intensive effort and research to
TTPs levels of the PoP require intensive effort and research to discover. However, it is not just an IoC's type that impacts its
discover. However, discoverability. The sophistication of the actor, their TTPs, and
it is not just an IoC's type that impacts its discoverability. T their tooling play a significant role, as does whether the IoC is
he sophistication of retrieved from logs after the attack or extracted from samples or
the actor, their TTPs, and their tooling play a significant role infected systems earlier.</t>
, as does whether the <t>For example, on an infected endpoint, it may be possible to
IoC is retrieved from logs after the attack or extracted from sa identify a malicious payload and then extract relevant IoCs, such as
mples or infected the file hash and its C2 server address. If the attacker used the
systems earlier.</t> same static payload throughout the attack, this single file hash
<t>For example, on an infected endpoint it may be possible to identify value will cover all instances. However, if the attacker
a malicious diversified their payloads, that hash can be more fragile, and other
payload and then extract relevant IoCs, such as the file hash an hashes may need to be discovered from other samples used on other
d its C2 server infected endpoints. Concurrently, the attacker may have simply
address. If the attacker used the same static payload throughout hard-coded configuration data into the payload, in which case the C2
the attack this server address can be easy to recover. Alternatively, the address
single file hash value will cover all instances. If, however, th can be stored in an obfuscated persistent configuration
e attacker within either the payload (e.g., within its source code or associated
diversified their payloads, that hash can be more fragile and ot resource) or the infected endpoint's file system (e.g., using
her hashes may need alternative data streams <xref target="ADS" format="default"/>),
to be discovered from other samples used on other infected endpo thus requiring more effort to discover. Further, the attacker may be
ints. Concurrently, storing the configuration in memory only or relying on a
the attacker may have simply hard-coded configuration data into DGA to generate C2 server addresses on
the payload, in demand. In this case, extracting the C2 server address can require a
which case the C2 server address can be easy to recover. Alterna memory dump or the execution or reverse engineering of the DGA, all
tively, the address of which increase the effort still further.</t>
can be stored in an obfuscated persistent configuration either w <t>If the malicious payload has already communicated with its C2
ithin the payload server, then it may be possible to discover that C2 server address
(e.g., within its source code or associated resource) or the inf IoC from network traffic logs more easily. However, once again,
ected endpoint's multiple factors can make discoverability more challenging, such as
filesystem (e.g., using alternative data streams <xref target="A the increasing adoption of HTTPS for malicious traffic, meaning C2
DS" format="default"/>) and thus requiring more communications blend in with legitimate traffic and can be
effort to discover. Further, the attacker may be storing the con complicated to identify. Further, some malwares obfuscate their
figuration in intended destinations by using alternative DNS resolution services
memory only or relying on a domain generation algorithm (DGA) to (e.g., OpenNIC <xref target="OPENNIC" format="default"/>), by using
generate C2 server encrypted DNS protocols such as DNS-over-HTTPS <xref
addresses on demand. In this case, extracting the C2 server addr target="OILRIG" format="default"/>, or by performing transformation
ess can require a operations on resolved IP addresses to determine the real C2 server
memory dump or the execution or reverse engineering of the DGA, address encoded in the DNS response <xref target="LAZARUS"
all of which format="default"/>.</t>
increase the effort still further.</t>
<t>If the malicious payload has already communicated with its C2 serve
r, then it
may be possible to discover that C2 server address IoC from netw
ork traffic logs
more easily. However, once again multiple factors can make disco
verability more
challenging, such as the increasing adoption of HTTPS for
malicious traffic - meaning C2 communications blend in with legi
timate
traffic, and can be complicated to identify. Further,
some malwares obfuscate their intended destinations by using alt
ernative DNS
resolution services (e.g., OpenNIC <xref target="OPENNIC" format
="default"/>),
encrypted DNS protocols such as DNS-over-HTTPS <xref target="OIL
RIG" format="default"/>, or by performing transformation
operations on resolved IP addresses to determine the real C2 ser
ver address encoded
in the DNS response <xref target="LAZARUS" format="default"/>.</
t>
</section> </section>
<section anchor="sec-completeness" numbered="true" toc="default"> <section anchor="sec-completeness" numbered="true" toc="default">
<name>Completeness</name> <name>Completeness</name>
<t>In many cases the list of indicators resulting from an activity or <t>In many cases, the list of indicators resulting from an activity
discovered or discovered in a malware sample is relatively short and so only
in a malware sample is relatively short and so only adds to the total adds to the total set of all indicators in a limited and finite
set of all manner. A clear example of this is when static indicators for C2
indicators in a limited and finite manner. A clear example of this is servers are discovered in a malware strain. Sharing, deployment, and
when static detection will often not be greatly impacted by the addition of such
indicators for C2 servers are discovered in a malware strain. Sharing, indicators for one more incident or one more sample. However, in the
deployment, case of discovery of a DGA, this
and detection will often not be greatly impacted by the addition of su requires a reimplementation of the algorithm and then execution to
ch indicators generate a possible list of domains. Depending on the algorithm,
for one more incident or one more sample. However, in the case of disc this can result in very large lists of indicators, which may cause
overy of a performance degradation, particularly during detection. In some
domain generation algorithm (DGA) this requires a reimplementation of cases, such sources of indicators can lead to a pragmatic decision
the algorithm being made between obtaining reasonable coverage of the possible
and then execution to generate a possible list of domains. Depending o indicator values and theoretical completeness of a list of all
n the algorithm, possible indicator values.</t>
this can result in very large lists of indicators which may cause perf
ormance degradation,
particularly during detection. In some cases, such sources of indicato
rs can lead to a
pragmatic decision being taken between obtaining reasonable coverage o
f the possible indicator
values and theoretical completeness of a list of all possible indicato
r values.</t>
</section> </section>
</section> </section>
<section anchor="sec-precision" numbered="true" toc="default"> <section anchor="sec-precision" numbered="true" toc="default">
<name>Precision</name> <name>Precision</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Specificity</name> <name>Specificity</name>
<t>Alongside pain and fragility, the PoP's levels can also be consider <t>Alongside pain and fragility, the PoP's levels can also be
ed in considered in terms of how precise the defence can be, with the
terms of how precise the defence can be, with the false positive false positive rate usually increasing as we move up the pyramid to
rate usually less specific IoCs. A hash value identifies a particular file, such
increasing as we move up the pyramid to less specific IoCs. A ha as an executable binary, and given a suitable cryptographic hash
sh value function, the false positives are effectively nil (by "suitable", we
identifies a particular file, such as an executable binary, and mean one with preimage resistance and strong collision resistance).
given a In comparison, IoCs in the upper levels (such as some network
suitable cryptographic hash function the false positives are eff artefacts or tool fingerprints) may apply to various malicious
ectively nil; binaries, and even benign software may share the same identifying
by suitable we mean one with preimage resistance and strong coll characteristics. For example, threat actor tools making web requests
ision resistance. may be identified by the user-agent string specified in the request
In comparison, IoCs in the upper levels (such as some network ar header. However, this value may be the same as that used by
tefacts or tool legitimate software, either by the attacker's choice or through use
fingerprints) may apply to various malicious binaries, and even of a common library.</t>
benign software <t>It should come as no surprise that the more specific an IoC, the
may share the same identifying characteristics. For example, thr more fragile it is; as things change, they move outside of that
eat actor tools specific focus. While less fragile IoCs may be desirable for their
making web requests may be identified by the user-agent string s robustness and longevity, this must be balanced with the increased
pecified in the chance of false positives from their broadness. One way in which
request header. However, this value may be the same as used by l this balance is achieved is by grouping indicators and using them in
egitimate software, combination. While two low-specificity IoCs for a particular attack
either by the attacker's choice or through use of a common libra may each have chances of false positives, when observed together,
ry.</t> they may provide greater confidence of an accurate detection of the
<t>It should come as no surprise that the more specific an IoC the mor relevant kill chain.</t>
e fragile
it is - as things change, they move outside of that specific foc
us. While less
fragile IoCs may be desirable for their robustness and longevity
, this must be
balanced with the increased chance of false positives from their
broadness. One
way in which this balance is achieved is by grouping indicators
and using them in
combination. While two low-specificity IoCs for a particular att
ack may each have
chances of false positives, when observed together they may prov
ide greater
confidence of an accurate detection of the relevant kill chain.<
/t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Dual and Compromised Use</name> <name>Dual and Compromised Use</name>
<t>As noted in <xref target="sec-assessment" format="default"/>, the c <t>As noted in <xref target="sec-assessment" format="default"/>, the
ontext of an IoC, such as the way in which context of an IoC, such as the way in which the attacker uses it,
the attacker uses it, may equally impact the precision with whic may equally impact the precision with which that IoC detects an
h that IoC attack. An IP address representing an attacker's staging server,
detects an attack. An IP address representing an attacker's stag from which their attack chain downloads subsequent payloads, offers
ing server, from a precise IP address for attacker-owned infrastructure. However, it
which their attack chain downloads subsequent payloads, offers a will be less precise if that IP address is associated with a
precise IP address cloud-hosting provider and is regularly reassigned from one user to
for attacker-owned infrastructure. However, it will be less prec another; it will be less precise still if the attacker
ise if that IP compromised a legitimate web server and is abusing the IP address
address is associated with a cloud hosting provider and it is re alongside the ongoing legitimate use.</t>
gularly reassigned
from one user to another; and it will be less precise still if t <t>Similarly, a file hash representing an attacker's custom remote
he attacker access trojan will be very precise; however, a file hash
compromised a legitimate web server and is abusing the IP addres representing a common enterprise remote administration tool will be
s alongside the less precise, depending on whether or not the defender organisation
ongoing legitimate use.</t> usually uses that tool for legitimate system
<t>Similarly, a file hash representing an attacker's custom remote acc administration. Notably, such dual-use indicators are context
ess specific, considering both whether they are usually used
trojan will be very precise; however, a file hash representing a legitimately and how they are used in a particular circumstance.
common enterprise Use of the remote administration tool may be legitimate for support
remote administration tool will be less precise depending on whe staff during working hours but not generally by non-support staff,
ther the defender particularly if observed outside of that employee's usual working
organisation usually uses that tool for legitimate systems admin hours.</t>
istration or not.
Notably, such dual use indicators are context specific both in w <t>For reasons like these, context is very important when
hether they are sharing and using IoCs.</t>
usually used legitimately and in the way they are used in a part
icular circumstance.
Use of the remote administration tool may be legitimate for supp
ort staff during
working hours, but not generally by non-support staff, particula
rly if observed
outside of that employee's usual working hours.</t>
<t>It is reasons such as these that context is so important when shari
ng
and using IoCs.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Changing Use</name> <name>Changing Use</name>
<t>In the case of IP addresses, the growing adoption of cloud services <t>In the case of IP addresses, the growing adoption of cloud
, proxies, virtual services, proxies, virtual private networks (VPNs), and carrier-grade
private networks (VPNs), and carrier grade network address trans Network Address Translation (NAT) are increasing the
lation (NAT) are number of systems associated with any one IP address at the same
ever-increasing the number of systems associated with any one IP moment in time. This ongoing change to the use of IP addresses is
address at the same somewhat reducing the specificity of IP addresses (at least for
moment in time. This ongoing change to the use of IP addresses i specific subnets or individual addresses) while also "side-stepping" t
s somewhat reducing the specificity of IP addresses (at least for specific subne he pain that threat actors would otherwise incur if they
ts or individual addresses) while also 'side- needed to change IP address.</t>
stepping' the pain that threat actors would otherwise incur if t
hey needed to change
IP address.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Privacy</name> <name>Privacy</name>
<t>As noted in <xref target="sec-assessment" format="default"/>, context <t>As noted in <xref target="sec-assessment" format="default"/>,
is critical context is critical to effective detection using IoCs. However, at
to effective detection using IoCs. However, at times, defenders may times, defenders may feel there are privacy concerns with how much and w
feel there are privacy concerns with how much to share ith whom to
about a cyber intrusion, and with whom. For example, defenders may g share about a cyber intrusion. For example, defenders
eneralise the IoCs' description of the attack, may generalise the IoCs' description of the attack by removing context
by removing context to facilitate sharing. This generalisation can r to facilitate sharing. This generalisation can result in an incomplete
esult in an incomplete set of IoCs set of IoCs being shared or IoCs being shared without clear
being shared or IoCs being shared without clear indication of what t indication of what they represent and how they are involved in an
hey represent attack. The sharer will consider the privacy trade-off when
and how they are involved in an attack. The sharer will consider the generalising the IoC and should bear in mind that the loss of context
privacy trade-off when generalising the IoC, can greatly reduce the utility of the IoC for those they share
and should bear in mind that the loss of context can greatly reduce with.</t>
the utility of the IoC for those they share with.</t> <t>In the authors' experiences, self-censoring by sharers appears more
<t>In the authors' experiences, self-censoring by sharers appears more p prevalent and more extensive when sharing IoCs into groups with more
revalent and more extensive when sharing IoCs into groups with more members, into groups with a broader range of perceived member
members, into groups with a broader range of perceived member expert expertise (particularly, the further the lower bound extends below the
ise (particularly, sharer's perceived own expertise), and into groups that do not
the further the lower bound extends below the sharer's perceived own maintain strong intermember trust. Trust within such groups often
expertise), appears strongest where members interact regularly; have common
and into groups that do not maintain strong intermember trust. Trust backgrounds, expertise, or challenges; conform to behavioural
within such groups expectations (such as by following defined handling requirements and
often appears strongest where members: interact regularly; have comm not misrepresenting material they share); and reciprocate the sharing
on backgrounds, and support they receive. <xref target="LITREVIEW" format="default"/>
expertise, or challenges; conform to behavioural expectations (such highlights that many of these factors are associated with the human role
as by following in
defined handling requirements and not misrepresenting material they Cyber Threat Intelligence (CTI) sharing.</t>
share); and
reciprocate the sharing and support they receive. <xref target="LITR
EVIEW" format="default"/> highlights
many of these factors are associated with the human role in Cyber Th
reat Intelligence (CTI) sharing.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Automation</name> <name>Automation</name>
<t>While IoCs can be effectively utilised by organisations of various si <t>While IoCs can be effectively utilised by organisations of various
zes and sizes and resource constraints, as discussed in <xref
resource constraints, as discussed in <xref target="sec-limited-reso target="sec-limited-resources" format="default"/>, automation of IoC
urces" format="default"/>, automation of IoC ingestion, ingestion, processing, assessment, and deployment is critical for
processing, assessment, and deployment is critical for managing them managing them at scale. Manual oversight and investigation may be
at scale. necessary intermittently, but a reliance on manual processing and
Manual oversight and investigation may be necessary intermittently, searching only works at small scale or for occasional cases.</t>
but a reliance <t>The adoption of automation can also enable faster and easier
on manual processing and searching only works at small scale or for correlation of IoC detections across different log sources and
occasional cases.</t> network monitoring interfaces across different times and physical
<t>The adoption of automation can also enable faster and easier correlat locations. Thus, the response can be tailored to reflect the number
ion of IoC and overlap of detections from a particular intrusion set, and the
detections across different log sources and network monitoring inter necessary context can be presented alongside the detection when
faces, across generating any alerts for defender review. While manual processing and
different times and physical locations. Thereby, the response can be searching may be no less accurate (although IoC transcription errors
tailored to reflect the number and overlap of detections from a part are a common problem during busy incidents in the experience of the
icular authors), the correlation and cross-referencing necessary to provide
intrusion set, and the necessary context can be presented alongside the same degree of situational awareness is much more
the detection time-consuming.</t>
when generating any alerts for defender review. While manual process <t>A third important consideration when performing manual processing
ing and searching is the longer phase monitoring and adjustment necessary to effectively
may be no less accurate (although IoC transcription errors are a com age out IoCs as they become irrelevant or, more crucially,
mon problem during inaccurate. Manual implementations must often simply include or
busy incidents in the experience of the authors), the correlation an exclude an IoC, as anything more granular is time-consuming and
d complicated to manage. In contrast, automations can support a gradual
cross-referencing necessary to provide the same degree of situationa reduction in confidence scoring, enabling IoCs to contribute but not
l awareness is individually disrupt a detection as their specificity reduces.</t>
much more time-consuming.</t>
<t>A third important consideration when performing manual processing is
the longer
phase monitoring and adjustment necessary to effectively age out IoC
s as they become
irrelevant or, more crucially, inaccurate. Manual implementations mu
st often simply
include or exclude an IoC, as anything more granular is time-consumi
ng and complicated
to manage. In contrast, automations can support a gradual reduction
in confidence
scoring enabling IoCs to contribute but not individually disrupt a d
etection as their
specificity reduces.</t>
</section> </section>
</section> </section>
<section anchor="depth" numbered="true" toc="default"> <section anchor="depth" numbered="true" toc="default">
<name>Comprehensive Coverage and Defence-in-Depth</name> <name>Comprehensive Coverage and Defence-in-Depth</name>
<t>IoCs provide the defender with a range of <t>IoCs provide the defender with a range of options across the PoP's
options across the Pyramid of Pain's (PoP) layers, enabling them to layers, enabling them to balance precision and fragility to give high
balance precision and fragility to give high confidence detections that confidence detections that are practical and useful. Broad
are practical and useful. Broad coverage of the PoP is important as it coverage of the PoP is important as it allows the defender to choose
allows the defender to choose between high precision but high fragility between high precision but high fragility options and more robust but
options and more robust but less precise indicators depending on availabil less precise indicators depending on availability. As fragile
ity. indicators are changed, the more robust IoCs allow for continued
As fragile indicators detection and faster rediscovery. For this reason, it's important to
are changed, the more robust IoCs allow for continued detection and faster collect as many IoCs as possible across the whole PoP to provide options
rediscovery. For this reason, it's important to collect as many IoCs as po for defenders.</t>
ssible
across the whole PoP to provide options for defenders.</t>
<t>At the top of the PoP, TTPs identified through anomaly detection and <t>At the top of the PoP, TTPs identified through anomaly detection and
machine learning are more likely to have false positives, which gives machine learning are more likely to have false positives, which gives
lower confidence and, vitally, requires better trained analysts to lower confidence and, vitally, requires better trained analysts to
understand and implement the defences. However, these are very painful for understand and implement the defences. However, these are very painful
attackers to change and so when tuned appropriately provide a robust for attackers to change, so when tuned appropriately, they provide a
detection. Hashes, at the bottom, are precise and easy to deploy but are robust detection. Hashes, at the bottom, are precise and easy to deploy
fragile and easily changed within and across campaigns by malicious actors but are fragile and easily changed within and across campaigns by
.</t> malicious actors.</t>
<t>Endpoint Detection and Response (EDR) or Anti-Virus (AV) are often the
first port of call for protection from intrusion, but endpoint solutions <t>Endpoint Detection and Response (EDR) or Antivirus (AV) are often
aren't a panacea. One issue is that there are many environments where it i the first port of call for protection from intrusion, but endpoint
s solutions aren't a panacea. One issue is that there are many
not possible to keep them updated, or in some cases, deploy them at all. F environments where it is not possible to keep them updated or, in some
or cases, deploy them at all. For example, the Owari botnet, a Mirai
example, the Owari botnet, a Mirai variant <xref target="Owari" format="de variant <xref target="Owari" format="default"/>, exploited Internet of
fault"/>, exploited Things (IoT) devices where such solutions could not be deployed. It is
Internet of Things (IoT) devices where such solutions could not be deploye because of such gaps, where endpoint solutions can't be relied on, that
d. a defence-in-depth approach is commonly advised, using a blended
It is because of such gaps, where endpoint solutions can't be relied on, t approach that includes both network and endpoint defences.</t>
hat <t>If an attack happens, then the best situation is that an endpoint
a defence-in-depth approach is commonly advocated, using a blended approac solution will detect and prevent it. If it doesn't, it could be for
h that many good reasons: the endpoint solution could be quite
includes both network and endpoint defences.</t> conservative and aim for a low false-positive rate, it might not have
<t>If an attack happens, then the best situation is that an endpoint solut ubiquitous coverage, or it might only be able to defend the initial step
ion of the kill chain <xref target="KillChain" format="default"/>. In the
will detect and prevent it. worst cases, the attack specifically disables the endpoint solution, or
If it doesn't, it could be for many good reasons: the endpoint solution the malware is brand new and so won't be recognised.</t>
could be quite conservative and aim for a low false-positive rate; it migh
t
not have ubiquitous coverage; or it might only be able to defend the initi
al
step of the kill chain <xref target="KillChain" format="default"/>. In the
worst cases,
the attack specifically disables the endpoint solution or the malware is b
rand new and
so won't be recognised.</t>
<t>In the middle of the pyramid, IoCs related to network information <t>In the middle of the pyramid, IoCs related to network information
(such as domains and IP addresses) can be particularly useful. They allow (such as domains and IP addresses) can be particularly useful. They
for broad coverage, without requiring each and every endpoint security allow for broad coverage, without requiring each and every endpoint
solution to be updated, as they may be detected and enforced in a more security solution to be updated, as they may be detected and enforced in
centralised manner at network choke points (such as proxies and gateways). a more centralised manner at network choke points (such as proxies and
This makes them particular useful in contexts where gateways). This makes them particularly useful in contexts where
ensuring endpoint security isn't possible such as "Bring Your Own Device" ensuring endpoint security isn't possible, such as Bring Your Own
(BYOD), Internet of Things (IoT) and legacy environments. It's important t Device (BYOD), Internet of Things (IoT), and legacy environments. It's
o important to note that these network-level IoCs can also protect users
note that these network-level IoCs can also protect users of a network aga of a network against compromised endpoints when these IoCs are used to
inst compromised detect the attack in network traffic, even if the compromise itself
endpoints when these IoCs are used to detect the attack in network traffic passes unnoticed. For example, in a BYOD environment, enforcing security
, policies on the device can be difficult, so non-endpoint IoCs and
even if the compromise itself passes unnoticed. For example, in a BYOD env solutions are needed to allow detection of compromise even with no
ironment, endpoint coverage.</t>
enforcing security policies on the device can be difficult, so <t>One example of how network-level IoCs provide a layer of a
non-endpoint IoCs and solutions are needed to allow detection of defence-in-depth solution is Protective DNS (PDNS) <xref
compromise even with no endpoint coverage.</t> target="Annual2021" format="default"/>, a free and voluntary
<t>One example of how network-level IoCs provide a layer of a defence-in-d DNS filtering service provided by the UK NCSC for UK public sector
epth solution organisations <xref target="PDNS" format="default"/>. In 2021, this
is Protective DNS (PDNS) <xref target="Annual2021" format="default"/>, a f service blocked access to more than 160 million DNS queries (out of 602
ree and voluntary DNS filtering service provided by billion total queries) for the organisations signed up to the service
the UK NCSC for UK public sector organisations <xref target="PDNS" format= <xref target="ACD2021" format="default"/>. This included hundreds of
"default"/>. In 2021, thousands of queries for domains associated with Flubot, Android malware
this service blocked access to more than 160 million DNS queries (out of 6 that uses DGAs to generate 25,000
02 billion total queries) for the organisations signed up to candidate command and control domains each month (these DGAs <xref
the service <xref target="ACD2021" format="default"/>. This included hundr target="DGAs" format="default"/> are a type of TTP).</t>
eds of thousands of queries for domains <t>IoCs such as malicious domains can be put on PDNS straight away and
associated with Flubot, Android malware that uses domain generation algori can then be used to prevent access to those known malicious domains
thms (DGAs) to generate 25,000 candidate across the entire estate of over 925 separate public sector entities
command and control domains each month - these DGAs <xref target="DGAs" fo that use NCSC's PDNS. Coverage can be patchy with endpoints, as the
rmat="default"/> are a type of TTP.</t> roll-out of protections isn't uniform or necessarily fast. However, if
<t>IoCs such as malicious the IoC is on PDNS, a consistent defence is maintained for devices using
domains can be put on PDNS straight away and can then be used to prevent a PDNS, even if the device itself is not immediately updated. This offers
ccess protection, regardless of whether the context is a BYOD environment or a
to those known malicious domains across the entire estate of over 925 sepa managed enterprise system. PDNS provides the most front-facing layer of
rate defence-in-depth solutions for its users, but other IoCs, like
public sector entities that use NCSC's PDNS. Server Name Indication values in TLS or the server certificate
Coverage can be patchy with endpoints, as the roll-out of protections isn' information, also provide IoC protections at other layers.</t>
t <t>Similar to the AV scenario, large-scale services face risk decisions
uniform or necessarily fast - but if the IoC is on PDNS, a consistent defe
nce is
maintained for devices using PDNS, even if the device itself is not immedi
ately updated.
This offers protection, regardless of whether the context is a BYOD
environment or a managed enterprise system. PDNS provides the most front-f
acing
layer of defence-in-depth solutions for its users, but other IoCs, like Se
rver Name
Indication values in TLS or the server certificate information, also provi
de IoC
protections at other layers.</t>
<t>Similar to the AV scenario, large scale services face risk decisions
around balancing threat against business impact from false positives. around balancing threat against business impact from false positives.
Organisations need to be able to retain the ability to be more conservativ Organisations need to be able to retain the ability to be more
e conservative with their own defences, while still benefiting from
with their own defences, while still benefiting from them. For instance, a them. For instance, a commercial DNS filtering service is intended for
commercial DNS filtering service is intended for broad deployment, so will broad deployment, so it will have a risk tolerance similar to AV
have a risk tolerance similar to AV products; whereas DNS filtering products, whereas DNS filtering intended for government users
intended for government users (e.g. PDNS) can be more conservative, but wi (e.g., PDNS) can be more conservative but will still have a relatively
ll broad deployment if intended for the whole of government. A government
still have a relatively broad deployment if intended for the whole of department or specific company, on the other hand, might accept the risk
government. A government department or specific company, on the other hand of disruption and arrange firewalls or other network protection devices
, to completely block anything related to particular threats, regardless
might accept the risk of disruption and arrange firewalls or other network of the confidence, but rely on a DNS filtering service for everything
protection devices to completely block anything related to particular thre else.</t>
ats,
regardless of the confidence, but rely on a DNS filtering service for <t>Other network defences can make use of this blanket coverage from
everything else.</t> IoCs, like middlebox mitigation, proxy defences, and application-layer
<t>Other network defences can make use of this blanket coverage from IoCs, firewalls, but are out of scope for this document. Large enterprise
like middlebox mitigation, proxy defences, and application layer firewalls networks are likely to deploy their own DNS resolution architecture and
, but possibly TLS inspection proxies and can deploy IoCs in these
are out of scope for this draft. Large enterprise networks locations. However, in networks that choose not to, or don't have the
are likely to deploy their own DNS resolution architecture and possibly resources to, deploy these sorts of mitigations, DNS goes through
TLS inspection proxies, and can deploy IoCs in these locations. However, i firewalls, proxies, and possibly a DNS filtering service; it doesn't
n have to be unencrypted, but these appliances must be able to decrypt it
networks that choose not to, or don't have the resources to, deploy these to do anything useful with it, like blocking queries for known bad
sorts URIs.</t>
of mitigations, DNS goes through
firewalls, proxies and possibly to a DNS filtering service; it doesn't hav <t>Covering a broad range of IoCs gives defenders a wide range of
e benefits: they are easy to deploy;
to be unencrypted, but these appliances must be able to decrypt it to do they provide a high enough confidence to be effective;
anything useful with it, like blocking queries for known bad URIs.</t> at least some will be painful for attackers to change; and
<t>Covering a broad range of IoCs gives defenders a wide range of benefits their distribution around the infrastructure allows for different
: points of failure, and so overall they enable the defenders to disrupt
they are easy to deploy; they provide a high enough confidence to be effec bad actors.
tive; The combination of these factors cements IoCs as a particularly
at least some will be painful for attackers to change; their distribution valuable tool for defenders with limited resources.</t>
around
the infrastructure allows for different points of failure, and so overall
they
enable the defenders to disrupt bad actors. The combination of these facto
rs
cements IoCs as a particularly valuable tool for defenders with limited re
sources.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="Security" numbered="true" toc="default"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This draft is all about system security. However, when poorly deployed,
IoCs can lead to over-blocking which may present an availability concern <t>This document is all about system security. However, when poorly
for some systems. While IoCs preserve privacy on a macro scale (by deployed, IoCs can lead to over-blocking, which may present an
preventing data breaches), research could be done to investigate the availability concern for some systems. While IoCs preserve privacy on a
impact on privacy from sharing IoCs, and improvements could be made to macro scale (by preventing data breaches), research could be done to
minimise any impact found. The creation of a privacy-preserving IoC sharin investigate the impact on privacy from sharing IoCs, and improvements
g could be made to minimise any impact found. The creation of a
method, that still allows both network and endpoint defences to provide privacy-preserving method of sharing IoCs that still allows both network
security and layered defences, would be an interesting proposal.</t> and endpoint defences to provide security and layered defences would be
an interesting proposal.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Conclusions</name> <name>Conclusions</name>
<t>IoCs are versatile and powerful. IoCs underpin and enable multiple <t>IoCs are versatile and powerful. IoCs underpin and enable multiple
layers of the modern defence-in-depth strategy. IoCs are easy to share, layers of the modern defence-in-depth strategy. IoCs are easy to share,
providing a multiplier effect on attack defence effort and they save vital providing a multiplier effect on attack defence efforts, and they save
time. Network-level IoCs offer protection, especially valuable when an vital time. Network-level IoCs offer protection, which is especially
endpoint-only solution isn't sufficient. These properties, along with valuable when an endpoint-only solution isn't sufficient. These
their ease of use, make IoCs a key component of any attack defence strateg properties, along with their ease of use, make IoCs a key component of
y any attack defence strategy and particularly valuable for defenders with
and particularly valuable for defenders with limited resources.</t> limited resources.</t>
<t>For IoCs to be useful, they don't have to be unencrypted or visible in <t>For IoCs to be useful, they don't have to be unencrypted or visible
networks - but crucially they do need to be made available, along with the in networks, but it is crucial that they be made available, along
ir with their context, to entities that need them. It is also important
context, to entities that need them. It is also important that this that this availability and eventual usage cope with multiple points of
availability and eventual usage copes with multiple points of failure, as failure, as per the defence-in-depth strategy, of which IoCs are a key
per the defence-in-depth strategy, of which IoCs are a key part.</t> part.</t>
</section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t> This draft does not require any IANA action.</t>
</section>
<section anchor="Acknowledgements" numbered="true" toc="default">
<name>Acknowledgements</name>
<t>Thanks to all those who have been involved with improving cyber defence
in the IETF and IRTF communities.</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<displayreference target="I-D.dulaunoy-misp-core-format" to="MISPCORE"/>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="ACD2021" target="https://www.ncsc.gov.uk/files/ACD-The- Fifth-Year-full-report.pdf"> <reference anchor="ACD2021" target="https://www.ncsc.gov.uk/files/ACD-The- Fifth-Year-full-report.pdf">
<front> <front>
<title>Active Cyber Defence - The Fifth Full Year</title> <title>Active Cyber Defence - The Fifth Year</title>
<author> <author>
<organization>UK NCSC</organization> <organization>UK NCSC</organization>
</author> </author>
<date year="2022"/> <date month="May" year="2022"/>
</front> </front>
</reference> </reference>
<reference anchor="ADS" target="https://docs.microsoft.com/en-us/windows/w in32/fileio/file-streams"> <reference anchor="ADS" target="https://docs.microsoft.com/en-us/windows/w in32/fileio/file-streams">
<front> <front>
<title>File Streams (Local File Systems)</title> <title>File Streams (Local File Systems)</title>
<author> <author>
<organization>Microsoft</organization> <organization>Microsoft</organization>
</author> </author>
<date year="2018"/> <date month="January" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="ALIENVAULT" target="https://otx.alienvault.com/"> <reference anchor="ALIENVAULT" target="https://otx.alienvault.com/">
<front> <front>
<title>AlienVault</title> <title>AlienVault: The World's First Truly Open Threat Intelligence
Community</title>
<author> <author>
<organization>AlienVault</organization> <organization>AlienVault</organization>
</author> </author>
<date year="2023"/>
</front> </front>
</reference> </reference>
<reference anchor="Annual2021" target="https://www.ncsc.gov.uk/files/NCSC% 20Annual%20Review%202021.pdf"> <reference anchor="Annual2021" target="https://www.ncsc.gov.uk/files/NCSC% 20Annual%20Review%202021.pdf">
<front> <front>
<title>Annual Review 2021</title> <title>NCSC Annual Review 2021: Making the UK the safest place to
live and work online</title>
<author> <author>
<organization>UK NCSC</organization> <organization>UK NCSC</organization>
</author> </author>
<date year="2021"/> <date year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="CISA" target="https://www.cisa.gov/uscert/ncas/alerts/a a21-321a"> <reference anchor="CISA" target="https://www.cisa.gov/uscert/ncas/alerts/a a21-321a">
<front> <front>
<title>Iranian Government-Sponsored APT Cyber Actors Exploiting Micros oft Exchange and Fortinet Vulnerabilities in Furtherance of Malicious Activities </title> <title>Iranian Government-Sponsored APT Cyber Actors Exploiting Micros oft Exchange and Fortinet Vulnerabilities in Furtherance of Malicious Activities </title>
<author> <author>
<organization>CISA</organization> <organization>CISA</organization>
</author> </author>
<date year="2021"/> <date month="November" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="COBALT" target="https://www.cobaltstrike.com/"> <reference anchor="COBALT" target="https://www.cobaltstrike.com/">
<front> <front>
<title>Cobalt Strike</title> <title>Cobalt Strike
</title>
<author> <author>
<organization>Cobalt Strike</organization> <organization></organization>
</author> </author>
<date year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="DFRONT" target="https://resources.infosecinstitute.com/ topic/domain-fronting/"> <reference anchor="DFRONT" target="https://resources.infosecinstitute.com/ topic/domain-fronting/">
<front> <front>
<title>Domain Fronting</title> <title>Domain Fronting</title>
<author> <author>
<organization>InfoSec Resources</organization> <organization>Infosec</organization>
</author> </author>
<date year="2017"/> <date month="April" year="2017"/>
</front> </front>
</reference> </reference>
<reference anchor="DGAs" target="https://attack.mitre.org/techniques/T1483 /"> <reference anchor="DGAs" target="https://attack.mitre.org/techniques/T1483 /">
<front> <front>
<title>Dynamic Resolution: Domain Generation Algorithms</title> <title>Dynamic Resolution: Domain Generation Algorithms</title>
<author> <author>
<organization>MITRE</organization> <organization>MITRE</organization>
</author> </author>
<date year="2020"/> <date year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="FireEye" target="https://www.mandiant.com/resources/blo g/apt33-insights-into-iranian-cyber-espionage"> <reference anchor="FireEye" target="https://www.mandiant.com/resources/blo g/apt33-insights-into-iranian-cyber-espionage">
<front> <front>
<title>Insights into Iranian Cyber Espionage: APT33 Targets Aerospace and Energy Sectors and has Ties to Destructive Malware</title> <title>Insights into Iranian Cyber Espionage: APT33 Targets Aerospace and Energy Sectors and has Ties to Destructive Malware</title>
<author fullname="Jacqueline O'Leary" initials="J." surname="O'Leary"> <author fullname="Jacqueline O'Leary" initials="J." surname="O'Leary">
<organization>FireEye</organization> <organization>FireEye</organization>
</author> </author>
<author fullname="Josiah Kimble" initials="J." surname="Kimble"> <author fullname="Josiah Kimble" initials="J." surname="Kimble">
<organization>FireEye</organization> <organization>FireEye</organization>
</author> </author>
<author fullname="Kelli Vanderlee" initials="K." surname="Vanderlee"> <author fullname="Kelli Vanderlee" initials="K." surname="Vanderlee">
<organization>FireEye</organization> <organization>FireEye</organization>
</author> </author>
<author fullname="Nalani Fraser" initials="N." surname="Fraser"> <author fullname="Nalani Fraser" initials="N." surname="Fraser">
<organization>FireEye</organization> <organization>FireEye</organization>
</author> </author>
<date year="2017"/> <date month="September" year="2017"/>
</front> </front>
</reference> </reference>
<reference anchor="FireEye2" target="https://www.mandiant.com/resources/bl og/overruled-containing-a-potentially-destructive-adversary"> <reference anchor="FireEye2" target="https://www.mandiant.com/resources/bl og/overruled-containing-a-potentially-destructive-adversary">
<front> <front>
<title>OVERRULED: Containing a Potentially Destructive Adversary</titl e> <title>OVERRULED: Containing a Potentially Destructive Adversary</titl e>
<author> <author fullname="Geoff Ackerman" initials="G." surname="Ackerman">
<organization>FireEye</organization> <organization>FireEye</organization>
</author> </author>
<date year="2018"/> <author fullname="Rick Cole" initials="R." surname="Cole">
<organization>FireEye</organization>
</author>
<author fullname="Andrew Thompson" initials="A." surname="Thompson">
<organization>FireEye</organization>
</author>
<author fullname="Alex Orleans" initials="A." surname="Orleans">
<organization>FireEye</organization>
</author>
<author fullname="Nick Carr" initials="N." surname="Carr">
<organization>FireEye</organization>
</author>
<date month="December" year="2018"/>
</front> </front>
</reference> </reference>
<reference anchor="GoldenTicket" target="https://cert.europa.eu/static/Whi
tePapers/UPDATED%20-%20CERT-EU_Security_Whitepaper_2014-007_Kerberos_Golden_Tick <reference anchor="GoldenTicket" target="https://attack.mitre.org/techniqu
et_Protection_v1_4.pdf"> es/T1558/001/">
<front> <front>
<title>Kerberos Golden Ticket Protection</title> <title>Steal or Forge Kerberos Tickets: Golden Ticket</title>
<author fullname="Miguel Soria-Machado" initials="M." surname="Soria-M <author fullname="Itamar Mizrahi" initials="I." surname="Mizrahi">
achado"> <organization>MITRE</organization>
<organization>CERT-EU</organization>
</author>
<author fullname="Didzis Abolins" initials="D." surname="Abolins">
<organization>CERT-EU</organization>
</author>
<author fullname="Ciprian Boldea" initials="C." surname="Boldea">
<organization>CERT-EU</organization>
</author> </author>
<author fullname="Krzysztof Socha" initials="K." surname="Socha"> <author fullname="Cymptom" surname="Cymptom">
<organization>CERT-EU</organization> <organization>MITRE</organization>
</author> </author>
<date year="2014"/> <date year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="KillChain" target="https://www.lockheedmartin.com/en-us /capabilities/cyber/cyber-kill-chain.html"> <reference anchor="KillChain" target="https://www.lockheedmartin.com/en-us /capabilities/cyber/cyber-kill-chain.html">
<front> <front>
<title>The Cyber Kill Chain</title> <title>The Cyber Kill Chain</title>
<author> <author>
<organization>Lockheed Martin</organization> <organization>Lockheed Martin</organization>
</author> </author>
<date year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="LAZARUS" target="https://media.kasperskycontenthub.com/ wp-content/uploads/sites/43/2018/03/07180244/Lazarus_Under_The_Hood_PDF_final.pd f"> <reference anchor="LAZARUS" target="https://media.kasperskycontenthub.com/ wp-content/uploads/sites/43/2018/03/07180244/Lazarus_Under_The_Hood_PDF_final.pd f">
<front> <front>
<title>Lazarus Under The Hood</title> <title>Lazarus Under The Hood</title>
<author> <author>
<organization>Kaspersky Lab</organization> <organization>Kaspersky Lab</organization>
</author> </author>
<date year="2018"/>
</front> </front>
</reference> </reference>
<reference anchor="LITREVIEW" target="https://www.open-access.bcu.ac.uk/78 52/1/Cyber%20Threat%20Intelligence%20Sharing%20Survey%20and%20Research%20Directi ons.pdf"> <reference anchor="LITREVIEW" target="https://www.open-access.bcu.ac.uk/78 52/1/Cyber%20Threat%20Intelligence%20Sharing%20Survey%20and%20Research%20Directi ons.pdf">
<front> <front>
<title>Cyber Threat Intelligence Sharing: Survey and Research Directio ns</title> <title>Cyber Threat Intelligence Sharing: Survey and Research Directio ns</title>
<author fullname="Thomas D. Wagner" initials="T. D." surname="Mulder"> <author fullname="Thomas Wagner" initials="T." surname="Wagner">
<organization>Birmingham City University</organization> <organization>Birmingham City University</organization>
</author> </author>
<date year="2018"/> <author fullname="Khaled Mahbub" initials="K." surname="Mahbub">
<organization></organization>
</author>
<author fullname="Esther Palomar" initials="E." surname="Palomar">
<organization></organization>
</author>
<author fullname="Ali Abdallah" initials="A." surname="Abdallah">
<organization></organization>
</author>
<date month="January" year="2019"/>
</front> </front>
</reference> </reference>
<reference anchor="Mimikatz" target="https://www.sans.org/reading-room/whi tepapers/detection/mimikatz-overview-defenses-detection-36780"> <reference anchor="Mimikatz" target="https://www.sans.org/white-papers/367 80/">
<front> <front>
<title>Mimikatz Overview, Defenses and Detection</title> <title>Mimikatz Overview, Defenses and Detection</title>
<author fullname="Jim Mulder" initials="J." surname="Mulder"> <author fullname="Jim Mulder" initials="J." surname="Mulder">
<organization>SANS Institute Information Security Reading Room</orga nization> <organization>SANS</organization>
</author> </author>
<date year="2016"/> <date month="February" year="2016"/>
</front> </front>
</reference> </reference>
<reference anchor="MISP" target="https://www.misp-project.org/"> <reference anchor="MISP" target="https://www.misp-project.org/">
<front> <front>
<title>MISP</title> <title>MISP</title>
<author> <author>
<organization>MISP</organization> <organization></organization>
</author>
<date year="2019"/>
</front>
</reference>
<reference anchor="MISPCORE" target="https://github.com/MISP/misp-rfc/blob
/master/misp-core-format/raw.md.txt">
<front>
<title>MISP Core</title>
<author>
<organization>MISP</organization>
</author> </author>
<date year="2020"/>
</front> </front>
</reference> </reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.dulauno
y-misp-core-format.xml"/>
<reference anchor="NCCGroup" target="https://research.nccgroup.com/2021/01 /12/abusing-cloud-services-to-fly-under-the-radar/"> <reference anchor="NCCGroup" target="https://research.nccgroup.com/2021/01 /12/abusing-cloud-services-to-fly-under-the-radar/">
<front> <front>
<title>Abusing cloud services to fly under the radar</title> <title>Abusing cloud services to fly under the radar</title>
<author fullname="Wouter Jansen" initials="W." surname="Jansen"> <author fullname="Wouter Jansen" initials="W." surname="Jansen">
<organization>NCC Group</organization> <organization>NCC Group</organization>
</author> </author>
<date year="2021"/> <date month="January" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="NIST" target="https://csrc.nist.gov/glossary/term/secur ity_control"> <reference anchor="NIST" target="https://csrc.nist.gov/glossary/term/secur ity_control">
<front> <front>
<title>Security control - Glossary</title> <title>Glossary - security control</title>
<author> <author>
<organization>US NIST</organization> <organization>NIST</organization>
</author> </author>
<date year="2022"/>
</front> </front>
</reference> </reference>
<reference anchor="OILRIG" target="https://www.zdnet.com/article/iranian-h acker-group-becomes-first-known-apt-to-weaponize-dns-over-https-doh/"> <reference anchor="OILRIG" target="https://www.zdnet.com/article/iranian-h acker-group-becomes-first-known-apt-to-weaponize-dns-over-https-doh/">
<front> <front>
<title>Iranian hacker group becomes first known APT to weaponize DNS-o ver-HTTPS (DoH)</title> <title>Iranian hacker group becomes first known APT to weaponize DNS-o ver-HTTPS (DoH)</title>
<author fullname="Catalin Cimpanu" initials="C." surname="Cimpanu"> <author fullname="Catalin Cimpanu" initials="C." surname="Cimpanu">
<organization>ZDNet</organization> <organization>ZDNet</organization>
</author> </author>
<date year="2020"/> <date month="August" year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="OPENIOC" target="https://www.fireeye.com/blog/threat-re search/2013/10/openioc-basics.html"> <reference anchor="OPENIOC" target="https://www.fireeye.com/blog/threat-re search/2013/10/openioc-basics.html">
<front> <front>
<title>OpenIOC: Back to the Basics</title> <title>OpenIOC: Back to the Basics</title>
<author fullname="Will Gibb" initials="W." surname="Gibb"> <author fullname="Will Gibb" initials="W." surname="Gibb">
<organization>FireEye</organization> <organization>FireEye</organization>
</author> </author>
<date year="2013"/> <author fullname="Devon Kerr" initials="D." surname="Kerr">
<organization></organization>
</author>
<date month="October" year="2013"/>
</front> </front>
</reference> </reference>
<reference anchor="OPENNIC" target="https://www.opennic.org/"> <reference anchor="OPENNIC" target="https://www.opennic.org/">
<front> <front>
<title>OpenNIC Project</title> <title>OpenNIC</title>
<author> <author>
<organization>OpenNIC Project</organization> <organization></organization>
</author> </author>
<date year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="Owari" target="https://www.ncsc.gov.uk/report/weekly-th
reat-report-8th-june-2018"> <reference anchor="Owari" target="https://webarchive.nationalarchives.gov.
uk/ukgwa/20220301141030/https://www.ncsc.gov.uk/report/weekly-threat-report-8th-
june-2018">
<front> <front>
<title>Owari botnet own-goal takeover</title> <title>Owari botnet own-goal takeover</title>
<author> <author>
<organization>UK NCSC</organization> <organization>UK NCSC</organization>
</author> </author>
<date year="2018"/> <date year="2018"/>
</front> </front>
</reference> </reference>
<reference anchor="PDNS" target="https://www.ncsc.gov.uk/information/pdns" > <reference anchor="PDNS" target="https://www.ncsc.gov.uk/information/pdns" >
<front> <front>
<title>Protective DNS</title> <title>Protective Domain Name Service (PDNS)</title>
<author> <author>
<organization>UK NCSC</organization> <organization>UK NCSC</organization>
</author> </author>
<date year="2019"/> <date month="August" year="2017"/>
</front> </front>
</reference> </reference>
<reference anchor="PoP" target="https://detect-respond.blogspot.com/2013/0 3/the-pyramid-of-pain.html"> <reference anchor="PoP" target="https://detect-respond.blogspot.com/2013/0 3/the-pyramid-of-pain.html">
<front> <front>
<title>The Pyramid of Pain</title> <title>The Pyramid of Pain</title>
<author fullname="David J. Bianco" initials="D.J." surname="Bianco"> <author fullname="David Bianco" initials="D." surname="Bianco">
</author> <organization>Enterprise Detection &amp; Response</organization>
<date year="2014"/>
</front>
</reference>
<reference anchor="RFC7970" target="https://datatracker.ietf.org/doc/html/
rfc7970">
<front>
<title>The Incident Object Description Exchange Format Version 2</titl
e>
<author fullname="Roman Danilyw" initials="R." surname="Danilyw">
</author> </author>
<date year="2016"/> <date month="March" year="2013"/>
</front> </front>
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7970.
xml"/>
<reference anchor="RULER" target="https://attack.mitre.org/software/S0358/ "> <reference anchor="RULER" target="https://attack.mitre.org/software/S0358/ ">
<front> <front>
<title>Ruler</title> <title>Ruler</title>
<author> <author>
<organization>MITRE</organization> <organization>MITRE</organization>
</author> </author>
<date year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="STIX" target="https://oasis-open.github.io/cti-document ation/stix/intro"> <reference anchor="STIX" target="https://oasis-open.github.io/cti-document ation/stix/intro">
<front> <front>
<title>STIX</title> <title>Introduction to STIX</title>
<author> <author>
<organization>OASIS Cyber Threat Intelligence</organization> <organization>OASIS Cyber Threat Intelligence (CTI)</organization>
</author> </author>
<date year="2019"/>
</front> </front>
</reference> </reference>
<reference anchor="Symantec" target="https://www.symantec.com/blogs/threat -intelligence/elfin-apt33-espionage"> <reference anchor="Symantec" target="https://www.symantec.com/blogs/threat -intelligence/elfin-apt33-espionage">
<front> <front>
<title>Elfin: Relentless</title> <title>Elfin: Relentless Espionage Group Targets Multiple
Organizations in Saudi Arabia and U.S.</title>
<author> <author>
<organization>Symantec</organization> <organization>Symantec</organization>
</author> </author>
<date year="2019"/> <date month="March" year="2019"/>
</front> </front>
</reference> </reference>
<reference anchor="TAXII" target="https://oasis-open.github.io/cti-documen tation/taxii/intro.html"> <reference anchor="TAXII" target="https://oasis-open.github.io/cti-documen tation/taxii/intro.html">
<front> <front>
<title>TAXII</title> <title>Introduction to TAXII</title>
<author> <author>
<organization>OASIS Cyber Threat Intelligence</organization> <organization>OASIS Cyber Threat Intelligence (CTI)</organization>
</author> </author>
<date year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="Timestomp" target="https://attack.mitre.org/techniques/ T1099/"> <reference anchor="Timestomp" target="https://attack.mitre.org/techniques/ T1099/">
<front> <front>
<title>Timestomp</title> <title>Indicator Removal: Timestomp</title>
<author> <author>
<organization>OASIS Cyber Threat Intelligence</organization> <organization>MITRE</organization>
</author> </author>
<date year="2019"/> <date month="January" year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="TLP" target="https://www.first.org/tlp/"> <reference anchor="TLP" target="https://www.first.org/tlp/">
<front> <front>
<title>Traffic Light Protocol</title> <title>Traffic Light Protocol (TLP)</title>
<author> <author>
<organization>FIRST</organization> <organization>FIRST</organization>
</author> </author>
<date year="2021"/>
</front> </front>
</reference> </reference>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to all those who have been involved with improving cyber
defence in the IETF and IRTF communities.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 151 change blocks. 
1379 lines changed or deleted 1048 lines changed or added

This html diff was produced by rfcdiff 1.48.