RFC 9424
Indicators of Compromise (IoCs) and Their Role in Attack Defence
Indicators of Compromise (IoCs) and Their Role in Attack Defence 🎀
RFC 9424 💖 is an Informational document from the IETF, dated August 2023. It is not a standards-track spec, it's published just for info. Its ISSN is 2070-1721. The header has no Obsoletes or Updates lines, so this one doesn't replace or update anything. 🦋
The authors are K. Paine (Splunk Inc.), O. Whitehouse (Binary Firefly), J. Sellwood (no affiliation listed in the header), and A. Shaw (UK National Cyber Security Centre). Such a team! 👑
Abstract ✨
Cyber defenders constantly lean on Indicators of Compromise (IoCs) to spot, trace, and block bad activity on networks or endpoints. This doc covers the basics, the upsides, the operational limits, and recommendations for using IoCs. The big point is that IoCs need to be detectable inside implementations of Internet protocols, tools, and technologies, both when they're first discovered and when they're used for detection. It's basically a foundation for tackling operational challenges in network security. 🌸
Status of This Memo 🧾
This document is not an Internet Standards Track specification. It's published for informational purposes. 💅
It's a product of the Internet Engineering Task Force (IETF) and reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, so see Section 2 of RFC 7841 for that. 🔥
For the current status, errata, and feedback, check https://www.rfc-editor.org/info/rfc9424. 🌈
Copyright Notice 🌸
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this doc. 🧚 Code Components pulled from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as the Revised BSD License describes. 🫶
Table of Contents 🗺️
1. Introduction
2. Terminology
3. IoC Fundamentals
3.1. IoC Types and the Pyramid of Pain
3.2. IoC Lifecycle
3.2.1. Discovery
3.2.2. Assessment
3.2.3. Sharing
3.2.4. Deployment
3.2.5. Detection
3.2.6. Reaction
3.2.7. End of Life
4. Using IoCs Effectively
4.1. Opportunities
4.1.1. IoCs underpin and enable multiple layers of the modern
defence-in-depth strategy.
4.1.2. IoCs can be used even with limited resources.
4.1.3. IoCs have a multiplier effect on attack defence efforts
within an organisation.
4.1.4. IoCs are easily shared between organisations.
4.1.5. IoCs can provide significant time savings.
4.1.6. IoCs allow for discovery of historic attacks.
4.1.7. IoCs can be attributed to specific threats.
4.2. Case Studies
4.2.1. Cobalt Strike
4.2.1.1. Overall TTP
4.2.1.2. IoCs
4.2.2. APT33
4.2.2.1. Overall TTP
4.2.2.2. IoCs
5. Operational Limitations
5.1. Time and Effort
5.1.1. Fragility
5.1.2. Discoverability
5.1.3. Completeness
5.2. Precision
5.2.1. Specificity
5.2.2. Dual and Compromised Use
5.2.3. Changing Use
5.3. Privacy
5.4. Automation
6. Comprehensive Coverage and Defence-in-Depth
7. IANA Considerations
8. Security Considerations
9. Conclusions
10. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🌟
This doc walks through the different types of IoCs and how they get used well in attack defence (a lot of people call it "cyber defence"). 🛡️ It brings in ideas like the Pyramid of Pain [PoP] and the IoC lifecycle, so you can see how IoCs can build a broad range of defences. You'll also get suggestions for folks implementing IoC-based controls, plus the potential operational limitations to watch out for. 👀
There are two case studies showing how useful IoCs are for detecting and defending against real attacks. One is about an intrusion set ("a set of malicious activity and behaviours attributed to one threat actor") called "APT33". The other is about an attack tool called "Cobalt Strike". 💀 This doc is not a full report on either one. It's meant to be read next to publicly published reports (cyber intel folks call these "open-source material") on those threats, like [Symantec] and [NCCGroup] respectively. 📚
2. Terminology 💅
Attack defence: The work of keeping an environment cyber secure by preventing, detecting, and responding to attempted and successful cyber intrusions. 🦋 A successful defence can come from blocking, monitoring, and responding to adversarial activity at the network, endpoint, or application levels.
Command and control (C2) server: An attacker-controlled server used to talk to compromised machines, send them commands, and receive data from them. 🕷️ The traffic between a C2 server and compromised hosts is called "command and control traffic".
Domain Generation Algorithm (DGA): The algorithm malware strains use to periodically generate domain names (via algorithm). 🧩 Malware may use DGAs to work out where to send C2 traffic, instead of relying on a pre-assigned list of static IP addresses or domains. Those are easier to block once they've been pulled out of the malware or otherwise linked to it.
Kill chain: A model that conceptually breaks a cyber intrusion down into attack stages, from reconnaissance all the way through to carrying out the attacker's objectives. 🔗 It helps defenders think about, discuss, plan for, and implement controls against each discrete phase of an attacker's activity [KillChain].
Tactics, Techniques, and Procedures (TTPs): The way an adversary does things in the kill chain: the choices they make, methods they follow, tools and infrastructure they use, protocols they employ, and commands they run. 🎭 If they're distinct enough, parts of an attacker's TTPs can become specific IoCs, almost like a fingerprint.
Control (as defined by US NIST): A safeguard or countermeasure set up for an information system or organisation to protect the confidentiality, integrity, and availability of its information. It's meant to meet a set of defined security requirements [NIST]. 🔐
3. IoC Fundamentals ✨
(Part 1 of 7 done! Part 2 picks up right here 🎀)
3.1. IoC Types and the Pyramid of Pain 🔺
Okay bestie, so IoCs (indicators of compromise) are basically observable clues about an attacker and what they're doing 🕵️♀️. That includes their tactics, techniques, and procedures, plus the tools and infrastructure they use. You can spot these clues on the network or on an endpoint (a host) 💻. Depending on how confident you are, they help defenders proactively block bad traffic or code execution 🚫, figure out whether an intrusion actually happened 👀, or link what they found to a known intrusion set 🧩. That link can point toward more places to investigate 🔍. IoCs get deployed to firewalls and other security control points by adding them to the list of indicators the control point looks for in the traffic it's monitoring 🛡️. When they're tied to malicious activity, these are some protocol-related IoCs that are lowkey iconic:
- IPv4 and IPv6 addresses in network traffic
- Fully Qualified Domain Names (FQDNs) in network traffic, DNS resolver caches, or logs
- TLS Server Name Indication values in network traffic
- Code-signing certificates in binaries
- TLS certificate information (such as SHA256 hashes) in network traffic
- Cryptographic hashes (e.g., MD5, SHA1, or SHA256) of malicious binaries or scripts when calculated from network traffic or file system artefacts
- Attack tools (such as Mimikatz [Mimikatz]) and their code structure and execution characteristics
- Attack techniques, such as Kerberos Golden Tickets [GoldenTicket], that can be observed in network traffic or system artefacts
The common IoC types stack up into a Pyramid of Pain [PoP] 🔺💖, and it's the go-to map for prevention, detection, and mitigation. Each type's spot in the pyramid shows how much "pain" a typical adversary goes through to change the activity that creates that artefact 😖. The higher the pain (towards the top), the less likely they are to change that part of what they do, and the longer the IoC will keep pointing at that attacker's intrusion set 🎯. In other words, the higher up it sits, the less fragile it is for the defender 💪. The PoP usually runs from hashes all the way up to TTPs. The pain goes from "oops, I just recompile my code" 🙄 to "I have to build a whole new attack strategy" 😭. There are other kinds of IoC too, and they could be added to an extended version of the PoP if that would help a defender understand and talk about the intrusion sets that matter most to them 🌈.
/\
/ \ MORE PAIN
/ \ LESS FRAGILE
/ \ LESS PRECISE
/ TTPs \
/ \ / \
============== |
/ \ |
/ Tools \ |
/ \ |
====================== |
/ \ |
/ Network/Host Artefacts \ |
/ \ |
============================== |
/ \ |
/ Domain Names \ |
/ \ |
====================================== |
/ \ |
/ IP Addresses \ |
/ \ \ /
==============================================
/ \ LESS PAIN
/ Hash Values \ MORE FRAGILE
/ \ MORE PRECISE
======================================================
Figure 1Let's start at the very bottom, the least painful level 🪨. That's hashes of malicious files. They're super easy for a defender to collect, and they can be deployed to firewalls or endpoint protection to block malicious downloads or stop code from running 🚧. Sure, IoCs aren't the only way to do this blocking, but they're a quick, convenient, and nonintrusive method ✨. Hashes are precise detections for individual files based on their binary content 🎯. The catch? An adversary only has to recompile code, or make some trivial change to the file content, to get a different hash value 😤.
Next up are IP addresses and domain names 🌐. You can block interactions with these, but the false positive rates vary (that's when non-malicious traffic gets misidentified as malicious; see Section 5) 🙃. They also usually cause more pain for an adversary to get around than file hashes do 😬. The attacker may have to change IP ranges, find a new provider, and change their code too (for example, if the IP address is hard-coded rather than resolved) 💅. Domain names are kinda similar, but sometimes threat actors register them specifically to masquerade as a particular organisation, or to falsely imply or claim an association that will look convincing or misleading to their targets 🎭. Registering new domain names is now unlikely to be prohibitive or distracting for lots of attackers, so honestly the extra pain is pretty small. It's just a bit more of a hassle to pick unregistered but appropriate domain names for those purposes 🫠.
Network and endpoint artefacts are harder to change 💀. Think of a malware's beaconing pattern on the network, or the modified timestamps of files touched on an endpoint. They're tied directly to the attack that's happening, and sometimes the attacker doesn't even control them directly 🙈. That said, more sophisticated attackers use TTPs or tooling that gives them flexibility at this level (like Cobalt Strike's malleable command and control [COBALT]), or a way to mask some artefacts (see [Timestomp]) 🦹♀️.
Tools and TTPs make up the top two levels of the pyramid 👑. These levels describe a threat actor's methodology, which is basically the way they pull off the attack ✨. The tools level is about the software (and less often, hardware) used to conduct the attack. The TTPs level covers all the other parts of the attack strategy 📋. IoCs at these levels are more complicated and complex. For example, they can include the details of how an attacker deploys malicious code to do reconnaissance on a victim's network, pivots laterally to a valuable endpoint, and then downloads a ransomware payload 😱. TTPs and tools take a ton of effort for a defender to diagnose, but they're fundamental to the attacker and the campaign, which makes them incredibly painful for the adversary to change 🥵.
How discoverable IoCs are shows up in the numbers of IoCs in AlienVault, an open threat intelligence community [ALIENVAULT] 📊. As of January 2023, AlienVault had:
- Groups (i.e., combinations of TTPs): 631
- Malware families (i.e., tools): ~27,000
- URL: 2,854,918
- Domain names: 64,769,363
- IPv4 addresses: 5,427,762
- IPv6 addresses: 12,009
- SHA256 hash values: 5,452,442
The domain name count is totally out of sync with the others, which go down as you climb the PoP 🤔. This discrepancy warrants further research 🔬. Contributing factors might be the use of DGAs, plus the fact that threat actors use domain names to masquerade as legitimate organisations, so they have extra incentive to keep creating new domain names as the old ones get identified and confiscated 🎀.
3.2. IoC Lifecycle 🔁
To be useful to defenders, IoCs must first be discovered, assessed, shared, and deployed 🚀. When a logged activity is identified and correlated to an IoC, that detection sets off a reaction from the defender. That reaction may include an investigation, which could lead to more IoCs being discovered, assessed, shared, and deployed 🧠. The cycle keeps going until an IoC is determined to be no longer relevant, and then it's removed from the control space 🗑️.
3.2.1. Discovery 🔎
IoCs are first discovered through manual investigation or automated analysis 🤖. They can turn up in a range of sources, including at endpoints and in the network (on the wire) 🧵. They must either be extracted from logs monitoring protocol packet captures, code execution, or system activity (for hashes, IP addresses, domain names, and network or endpoint artefacts), or be determined through analysis of attack activity or tooling 🧪. Sometimes discovery is reactive, where IoCs from past or current attacks get identified from the traces they left behind 🕰️. Discovery can also be proactive hunting for potential future IoCs, extrapolated from knowledge of past events. For example, you might identify attacker infrastructure by watching domain name registration patterns 👀.
Here's the crucial bit: for an IoC to be discovered, the indicator has to be extractable from the Internet protocol, tool, or technology it's associated with 💅. Spotting a particular exchange (or a sequence of exchanged messages) related to an attack is of limited benefit if the indicators can't be extracted. And even if they can be extracted, it's a problem if they can't later be linked to a related exchange of messages or artefacts in the same protocol or a different one 🔗. If it's not possible to determine the source or destination of malicious attack traffic, you won't be able to identify and block subsequent attack traffic either 🚫. Not me needing this to be said twice 😭.
3.2.2. Assessment 🧐
Defenders may treat different IoCs differently, depending on the quality of the IoC and the defender's needs and capabilities ⚖️. For example, they may place different amounts of trust in IoCs based on their source, freshness, confidence level, or the associated threat 💫. These decisions rely on contextual information gathered at the point of discovery or provided when the IoC was shared 📦.
An IoC without context is not much use for network defence 😩. But an IoC delivered with context is a whole different story ✨. That context could include the threat actor it relates to, its role in an attack, the last time it was seen in use, its expected lifetime, or other related IoCs 📝. With that, a network defender can make an informed choice about how to use it to protect their network. They could simply log it, actively monitor it, or outright block it 🛡️💖.
3.2.3. Sharing ✨
Okay so once an IoC has been discovered and assessed, it's giving most helpful energy when it's deployed in a way that has a broad impact on detecting or disrupting threats, or when it gets shared at scale so loads of people and orgs can defend themselves 🛡️💖. An IoC can be shared individually (with appropriate context) in an unstructured way, or it can be packaged up with a bunch of other IoCs in a standardised format like Structured Threat Information Expression [STIX], Malware Information Sharing Platform (MISP) core [MISPCORE], OpenIOC [OPENIOC], or Incident Object Description Exchange Format (IODEF) [RFC7970] 🧚. That lets it travel through a structured feed, like one built on Trusted Automated Exchange of Intelligence Information [TAXII], or through a Malware Information Sharing Platform [MISP] 🌸.
Now, some security companies and membership-based groups (often called "Information Sharing and Analysis Centres (ISACs)" or "Information Sharing and Analysis Organizations (ISAOs)") sell paid intelligence feeds full of IoCs, but there are also tons of free sources 🎀. You can get them from individual security researchers, small trust groups, national government cyber security organisations, and international Computer Emergency Response Teams (CERTs) 🌈. Whoever the sharer is, they usually say how far the receiver can pass the IoCs along, using frameworks like the Traffic Light Protocol [TLP] 🚦. At its simplest, it goes like this 👇:
TLP:CLEAR: the receiver may share with anyone.TLP:GREEN: the receiver may share within the defined sharing community.TLP:AMBER+STRICT: the receiver may share within their organisation and their clients.TLP:AMBER: the receiver may share just within their organisation.TLP:RED: the receiver may not share with anyone outside the original specific IoC exchange 💀.
3.2.4. Deployment 🔥
Okay, this part is so important. For IoCs to give you defence-in-depth (see Section 6) and survive different points of failure, you have to deploy them correctly 💅. Different IoCs catch malicious activity at different layers of the network stack and at different stages of an attack. So deploying a range of them gives you layers of defence at each security control, which stacks up the benefits of using multiple security controls as part of a defence-in-depth solution 🧁. The network security controls and endpoint solutions need sufficient privilege and sufficient visibility to detect IoCs and act on them, no excuses 🙈. Wherever IoCs exist, they need to be made available to security controls and associated apparatus so they can be deployed quickly and widely 🚀. IoCs can be manually assessed after they're discovered or received, but there's a huge advantage in automatically ingesting, processing, assessing, and deploying them from logs or intelligence feeds out to the right security controls 🤩. And since not all IoCs are the same quality, confidence in the IoCs from each threat intelligence feed should be considered when deciding whether to deploy them automatically like this ⚖️.
IoCs can be especially effective at mitigating malicious activity when they're deployed in security controls with the broadest impact 👑. That could happen if developers of security products or firewalls add support for distributing and consuming IoCs directly in their products, so each user doesn't have to do it themselves. The whole user base gets the threat addressed at once, in a machine-scalable and automated manner 🦋. Within an enterprise, it could also happen by making sure the control points with the widest aperture (for example, enterprise-wide DNS resolvers) can act automatically based on IoC feeds 🌟.
3.2.5. Detection 👀
Security controls with deployed IoCs keep an eye on their relevant control space, and when they spot an IoC in monitored logs or on network interfaces, they trigger a generic or specific reaction 🚨.
3.2.6. Reaction 💥
The reaction to an IoC's detection can vary depending on factors like the capabilities and configuration of the control it's deployed in, the assessment of the IoC, and the properties of the log source where it was detected 🧐. For example, a connection to a known botnet C2 server might mean there's a problem, but it doesn't guarantee one, especially if that server is a compromised host that's still doing some other legit stuff 🙃. Common reactions include event logging, triggering alerts, and blocking or terminating the source of the activity 🛑.
3.2.7. End of Life 🥀
How long an IoC stays useful really depends on things like its initial confidence level, fragility, and precision (more on that in Section 5) 💜. Sometimes IoCs get automatically "aged" based on their initial characteristics, so they reach end of life at a predetermined time ⏳. Other times, an IoC gets invalidated because the threat actor's TTPs shifted (e.g., due to a new development or their discovery), or because a defender took remediation action 🧹. End of life can also happen for reasons totally unrelated to attack or defence, like when a third-party service the attacker used changes or goes offline 🫠. Whatever the cause, IoCs should be removed from detection at the end of their life to reduce the likelihood of false positives 🗑️✨.
4. Using IoCs Effectively 👑
4.1. Opportunities 🌈
IoCs give cyber defenders a whole bunch of opportunities as part of a modern defence-in-depth strategy 💖. It doesn't matter how big an organisation is, because IoCs can be an effective, scalable, and efficient defence mechanism against classes of attack from the latest threats, or against specific intrusion sets that struck in the past 🧚.
4.1.1. IoCs underpin and enable multiple layers of the modern defence-in-depth strategy. 🧱
Firewalls, Intrusion Detection Systems (IDSs), and Intrusion Prevention Systems (IPSs) all use IoCs to identify and mitigate threats across networks 🔍. Antivirus (AV) and Endpoint Detection and Response (EDR) products deploy IoCs via catalogues or libraries to supported client endpoints 💻. Security Incident Event Management (SIEM) platforms compare IoCs against aggregated logs from different sources -- network, endpoint, and application 📊. Of course, IoCs don't address every attack defence challenge, but they form a vital tier of any organisation's layered defence 🫶. Some types of IoC may be present across all of those controls, while others may only be deployed in certain layers of a defence-in-depth solution 🎯. Also, IoCs relevant to a specific kill chain may only reflect activity from a certain phase, so they need to be combined with other IoCs or mechanisms for complete coverage of the kill chain as part of an intrusion set 🔗.
Here's an example 🍓: open-source malware can be deployed by lots of different actors, each with their own TTPs and infrastructure. But if the actors use the same executable, the hash of that executable file stays the same. That hash can be deployed as an IoC in endpoint protection to block execution no matter which actor, infrastructure, or other TTPs are involved 🔒. Now say that defence fails in a specific case. For example, an actor recompiles the executable binary and produces a unique hash. Other defences can still stop them from progressing further through their attack. For instance, blocking known malicious domain name lookups prevents the malware from calling out to its C2 infrastructure 🛡️.
Then there's another malicious actor who keeps changing their tools and infrastructure (and so the indicators associated with the intrusion set) across different campaigns, but whose access vectors stay consistent and well-known 🦋. In this case, that access TTP can be recognised and defended against proactively, even when it's unclear what the intended subsequent activity will be 🕵️♀️. For example, if their access vector consistently exploits a vulnerability in software, regular and estate-wide patching can stop the attack from happening at all 🩹. But if those preemptive measures fail, other IoCs observed across multiple campaigns may be able to stop the attack at later stages in the kill chain 🏁.
4.1.2. IoCs can be used even with limited resources. 🌱
IoCs are inexpensive, scalable, and easy to deploy, which makes them especially beneficial for smaller entities, particularly when they're exposed to a significant threat 🤍. Picture a small manufacturing subcontractor in a supply chain making a critical, highly specialised component 🏭. They could be an attractive target, because compromising them would have a disproportionate impact on both the supply chain and the prime contractor 😬. It may be reasonable to assume this small manufacturer has only basic security (whether internal or outsourced). And while they likely have comparatively fewer resources than larger partners to manage the risks they face, they can still leverage IoCs to great effect 💪. Small entities like this can deploy IoCs for baseline protection against known threats, without access to a well-resourced, mature defensive team or the threat intelligence relationships needed to perform resource-intensive investigations 🥰. Some level of expertise is still needed at a small company to deploy IoCs successfully, but using IoCs doesn't require the same intensive training as more subjective controls, like those using machine learning. Those need further manual analysis of identified events to verify whether they're actually malicious 🧠. So a major part of the appeal of IoCs is that they can offer some level of protection to organisations across all kinds of resource capability, maturity, and sophistication 🌟.
4.1.3. IoCs have a multiplier effect on attack defence efforts within an organisation. ✖️
Individual IoCs can provide widespread protection that scales nicely for defenders across an organisation or ecosystem 🌊. Inside a single organisation, blocking one IoC might protect thousands of users, and depending on the IoC type, that blocking can happen across multiple security controls watching lots of different kinds of activity within networks, endpoints, and applications 🙌. The prime contractor from our earlier example can supply IoCs to the small subcontractor, which uplifts that smaller entity's defensive capability while protecting the prime contractor's own interests at the same time 🤝.
Multiple organisations may benefit from directly receiving shared IoCs (see Section 4.1.4), but they can also benefit from IoCs being applied in services they use 📬. Take an ongoing email-phishing campaign. Individual organisations can monitor, discover, and deploy IoCs for it quickly and easily 🏃♀️. But if those IoCs are deployed quickly through a mechanism like a protective DNS filtering service, it gets even more effective ✨. An email campaign might be mitigated before some organisations' recipients ever click the link, or before some malicious payloads can call out for instructions 🛑. That way, other parties get protected without direct sharing of IoCs with those organisations, or any additional effort from them 🫧.
4.1.4. IoCs are easily shared between organisations. 🎁
okay so IoCs are SO easy to pass around, it's honestly iconic 💖 They can be written as plain text (sometimes in hexadecimal 🧚), which means people swap them in emails, blog posts, or technical reports all the time, just a few at a time. ✨
And then there are standards, like the ones in Section 3.2.3, that give everyone well-defined formats for sharing huge collections or regular sets of IoCs along with all the context 🫶 Finding one IoC can be a lot of work, but once it's shared through well-established routes, that single IoC might protect thousands of organisations and all the users inside them. 😭 Quick sharing = blanket coverage. Sysadmins at tiny companies and massive ones, teams and solo people, can all go and set up their own defences on their networks. main character energy for the whole internet 👑
4.1.5. IoCs can provide significant time savings. ⏰
not only do you save time by sharing IoCs (nobody has to redo the same investigation 🙃), but automatic deployment at scale is also seamless for lots of enterprises 🔥 When automatic deployment is working well, orgs and users get blanket protection with minimal human intervention and minimal effort, which is kind of the whole goal of attack defence 💅 Being able to do this quickly and at scale matters a lot when you're dealing with agile threat actors who change their intrusion set often, and so change the relevant IoCs too. 💀
Now picture protecting a complicated network WITHOUT automatic deployment. You'd be manually updating every single endpoint and network device, consistently and reliably, to the same security state 😵 That means finding all the assets and devices, polling logs and system info, and checking patch levels by hand. It's a LOT of work and it needs skilled analysts and engineers. It's still worth investing effort into efficient IoC deployment and into cutting false positives when you deploy IoCs widely, but the cost is way smaller than manually updating everything reliably. Legacy systems can be especially complicated, or even impossible, to update. 🦖
4.1.6. IoCs allow for discovery of historic attacks. 🕵️♀️
so a defender can take IoCs they just got and check them against historic data, like logged DNS queries or email attachment hashes, to hunt for signs of past compromise 👀 This doesn't just help build a clear picture of old attacks, it also lets you do retrospective mitigation of the effects of earlier intrusions. 🙌 The catch is that this only works if the historic data hasn't been tampered with itself (for example by a technique like Timestomp [Timestomp]) and if it isn't incomplete because of data retention policies. Still, it's super valuable for detecting and remediating past attacks, so don't sleep on it 🧐
4.1.7. IoCs can be attributed to specific threats. 🎯
ngl this one is a whole vibe. Modern security controls like firewall filtering or EDR always come with a trade-off between breadth of protection and costs. Those costs include the risk of false positives (see Section 5.2), staff time, and pure financial cost 💸 Organisations can use threat modelling and information assurance to assess and prioritise risk from identified threats, and decide how they'll mitigate or accept each one 📋 Context that ties IoCs to specific threats or actors, shared right alongside the IoCs, helps orgs focus their defences on particular risks 🎀 Receivers generally expect this context, because it gives them the freedom and capability to choose their own risk appetite, security posture, and defence methods 💜
Sharing that context alongside IoCs is easier partly thanks to the formats in Section 3.2.3, so it's way simpler to track malicious actors across campaigns and targets 🧚 Making this context before you share can take seriously intensive analytical effort, plus specialist tools and training 😩 At its simplest, you document sets of IoCs from multiple instances of the same attack campaign. For example, you might have multiple unique payloads (so distinct file hashes) coming from the same source and connecting to the same C2 server 🍓 A more complicated approach is to cluster similar combinations of TTPs seen across multiple campaigns over a period of time. Pair that with detailed malware reverse engineering and target profiling, overlaid on a geopolitical and criminal backdrop, and you can infer attribution to a single threat actor. 🔍✨
4.2. Case Studies 📚
the next two case studies show how IoCs can be identified in relation to threat actor tooling (first one) and a threat actor campaign (second one) 🎀 They also highlight how cyber defenders can actually use those IoCs. 💅
4.2.1. Cobalt Strike 🐍
Cobalt Strike [COBALT] is a commercial attack framework used for penetration testing 💼 It has an implant framework (beacon), a network protocol, and a C2 server. The beacon and network protocol are highly malleable, which means an attacker can easily change how the protocol looks "on the wire" so it blends in with legit traffic 🫠 They do this by making sure the traffic conforms to the protocol specification, e.g., HTTP. The proprietary beacon supports TLS encryption layered over a custom encryption scheme based on a public-private keypair 🔐 The product also supports other techniques, like domain fronting [DFRONT], trying to dodge obvious passive detection by static network signatures of domain names or IP addresses 🙈 Domain fronting is used to blend traffic to a malicious domain in with traffic coming from a network that's already talking to a non-malicious domain regularly over HTTPS. sneaky, but make it make sense 😤
4.2.1.1. Overall TTP 🧩
A beacon configuration describes how the implant should operate and how it communicates with its C2 server. This config also carries ancillary info, such as the Cobalt Strike user licence watermark 🏷️
4.2.1.2. IoCs 🧾
Tradecraft has been developed to fingerprint C2 servers based on how they respond to specific requests 🔎 Once a server is identified, its beacon configurations can be downloaded and the associated infrastructure addresses extracted as IoCs. iconic workflow 🙌
The resulting mass IoCs for Cobalt Strike are:
- IP addresses of the C2 servers
- domain names used
Whilst these IoCs need to be refreshed regularly (because they're so easy to change 🙄), the authors' experience of protecting public sector organisations shows they're effective at disrupting threat actor operations that use Cobalt Strike 💪
These IoCs can be used to check historical data for evidence of past compromise, and deployed to detect or block future infection in a timely manner. That helps prevent the loss of user and system data 🛡️💖
4.2.2. APT33 🦋
Unlike the first case study, this one is about a current campaign by the threat actor APT33, also known as Elfin and Refined Kitten (see [Symantec]) 👀 The industry has assessed APT33 to be a state-sponsored group [FireEye2], and yet IoCs still gave defenders an effective tool against such a powerful adversary 😤 The group has been active since at least 2015 and targets a range of sectors, including petrochemical, government, engineering, and manufacturing 🏭 Activity has been seen across the globe, but mostly in the USA and Saudi Arabia 🌍
4.2.2.1. Overall TTP 🎭
honestly the techniques this actor uses are pretty low-key sophisticated, considering they're state-sponsored 💀 Typically, APT33 does spear phishing (sending targeted malicious emails to a limited number of pre-selected recipients) with document lures that imitate legit publications 📰 When a user interacts with a lure, the initial payload runs and APT33 gets initial access 🚪 Once they're inside a target network, APT33 tries to pivot to other machines to gather documents and get administrative credentials 🔑 In some cases, users get tricked into giving up credentials, which are then used with Ruler [RULER], a freely available tool that allows exploitation of an email client 📧 The attacker, holding a target's password, uses Ruler to access the target's mail account and embeds a malicious script that triggers when the mail client is next opened. That executes malicious code, often additional malware pulled from the Internet (see [FireEye]) 😱
Sometimes APT33 deploys a destructive tool that overwrites the master boot record (MBR) of the hard drives in as many PCs as possible 💥 This kind of tool is called a wiper. It causes data loss and renders devices unusable until the operating system is reinstalled 🫠 In some cases the actor uses administrator credentials to run execution across a big chunk of a company's IT estate at once. If that isn't possible, they may first try to spread the wiper manually, or use worm-like capabilities against unpatched vulnerabilities on networked computers 🐛
4.2.2.2. IoCs 📦
After investigations by a partnership of industry and the UK's National Cyber Security Centre (NCSC), a set of IoCs was compiled and shared with both public and private sector organisations 🤝 That way network defenders could search for them in their networks. Detecting these IoCs is likely indicative of APT33 targeting, and could indicate potential compromise and later use of destructive malware 😬 Defenders could also start processes to block these IoCs to foil future attacks. This set of IoCs comprised:
- 9 hashes and email subject lines
- 5 IP addresses
- 7 domain names
In November 2021, a joint advisory about APT33 [CISA] was issued by the Federal Bureau of Investigation (FBI), the Cybersecurity and Infrastructure Security Agency (CISA), the Australian Cyber Security Centre (ACSC), and NCSC 📢 It outlined recent exploitation of vulnerabilities by APT33, gave a thorough overview of observed TTPs, and shared even more IoCs:
- 8 hashes of malicious executables
- 3 IP addresses
5. Operational Limitations ⚖️
the different IoC types come with a set of trade-offs for defenders, between the risk of false positives (misidentifying non-malicious traffic as malicious) and the risk of failing to identify attacks 🙃 The attacker's relative pain of modifying attacks to subvert known IoCs, as discussed using the PoP in Section 3.1, inversely correlates with how fragile the IoC is and how precisely it identifies an attack 📉 Research is needed to elucidate the exact nature of these trade-offs between pain, fragility, and precision 🔬
5.1. Time and Effort ⏳
5.1.1. Fragility
Okay so, remember Section 3.1? The PoP is lowkey about two things at once: how fragile an IoC is for the defender, and how much pain it causes the attacker 💅. The less painful it is for the attacker to change an IoC, the more fragile that IoC is as a defence tool 🫶. Making a hash for the malicious file attachments used as lures in a phishing campaign is pretty easy, and you can push those hashes out through AV or an email gateway security control 📧. But those hashes are super fragile, and they can (and honestly often will) get changed between campaigns 😭. Malicious IP addresses and domain names can also change between campaigns, but it happens less often because managing infrastructure is way more painful than swapping out files 🏗️. So IP addresses and domain names may give you a less fragile detection capability 🦋.
This doesn't mean the fragile types are worthless, though 🙅♀️. First, there's no guarantee a fragile IoC will change. If a known IoC doesn't get changed by the attacker but also wasn't blocked, then the defender missed a chance to stop the attack in its tracks 💀. Second, even inside one IoC type, fragility varies depending on context ✨. The file hash of a phishing lure doc (with a particular theme and a specific staging server link) may be more fragile than the file hash of a remote access trojan payload the attacker uses after initial access. That payload may in turn be more fragile than the file hash of an attacker-controlled post-exploitation reconnaissance tool that doesn't connect directly to the attacker's infrastructure 🔍. Third, some threats and actors are more capable of changing things, or more inclined to, than others 🌈. So the fragility of an IoC for one actor can be very different from the fragility of the same type of IoC for another.
Ultimately, fragility is a defender's concern. It affects how well each IoC keeps working over time, and it will factor into decisions about end of life ⏳. Still, it shouldn't stop you from adopting individual IoCs unless you have seriously strict resource constraints that force you to down-select which IoCs get deployed 🎀. More usually, defenders researching threats will try to find IoCs with varying fragilities for a particular kill chain. That gives them the best chance of ongoing detection with the investigative effort they have (see Section 5.1.2), while still keeping precision (see Section 5.2) 👑.
5.1.2. Discoverability
Before IoCs can be used in attack defence, they have to be discovered first, either through proactive hunting or reactive investigation 🕵️♀️. As noted in Section 3.1, IoCs in the tools and TTPs levels of the PoP take intensive effort and research to find 😩. But it's not just the IoC's type that decides how discoverable it is. The sophistication of the actor, their TTPs, and their tooling all play a big role. So does whether the IoC is pulled from logs after the attack or extracted from samples or infected systems earlier 🧠.
Here's an example. On an infected endpoint, you might be able to identify a malicious payload and then extract relevant IoCs, like the file hash and its C2 server address 🔎. If the attacker used the same static payload the whole time, that one file hash covers every instance 💖. But if the attacker diversified their payloads, that hash can be more fragile, and other hashes may need to be discovered from other samples used on other infected endpoints 🥲. Meanwhile, the attacker may have just hard-coded configuration data into the payload, in which case the C2 server address is easy to recover 🍓. Or the address might be stored in an obfuscated persistent configuration inside the payload (e.g., within its source code or associated resource) or inside the infected endpoint's file system (e.g., using alternative data streams [ADS]). That's way more effort to discover 😤. And if the attacker is storing the configuration in memory only, or relying on a DGA to generate C2 server addresses on demand, pulling out the C2 server address can require a memory dump or running or reverse engineering the DGA. All of that adds even more effort 🫠.
If the malicious payload has already talked to its C2 server, you may be able to find that C2 server address IoC in network traffic logs more easily 📡. But once again, lots of things can make discoverability harder. One is the growing use of HTTPS for malicious traffic, which means C2 communications blend in with legitimate traffic and can be tricky to spot 🙈. Some malware also hides its real destinations by using alternative DNS resolution services (e.g., OpenNIC [OPENNIC]), by using encrypted DNS protocols such as DNS-over-HTTPS [OILRIG], or by transforming the resolved IP addresses to work out the real C2 server address encoded in the DNS response [LAZARUS] 🥷.
5.1.3. Completeness
Most of the time, the list of indicators from an activity, or found in a malware sample, is pretty short. So it only adds to the total set of all indicators in a limited, finite way 🧩. A classic example is when static indicators for C2 servers turn up in a malware strain. Sharing, deploying, and detecting usually won't be hugely affected by adding one more incident's or one more sample's worth of those 🙌. But discovering a DGA is a different story. That means reimplementing the algorithm and then running it to generate a possible list of domains 😵. Depending on the algorithm, that can produce really massive lists of indicators, which might cause performance degradation, especially during detection 🐢. So in some cases, a pragmatic call has to be made: go for reasonable coverage of the possible indicator values, instead of chasing theoretical completeness of a list of every possible value 💅✨.
5.2. Precision
5.2.1. Specificity
Alongside pain and fragility, you can also think about the PoP's levels in terms of how precise a defence can be 🎯. The false positive rate usually goes up as we climb the pyramid toward less specific IoCs 📈. A hash value identifies one particular file, like an executable binary. And given a suitable cryptographic hash function, false positives are effectively nil. (By "suitable", we mean one with preimage resistance and strong collision resistance 🔐.) Compare that to IoCs in the upper levels, like some network artefacts or tool fingerprints. Those may apply to various malicious binaries, and even benign software might share the same identifying characteristics 😬. For example, threat actor tools making web requests may be identified by the user-agent string in the request header. But that value could be the same as the one legitimate software uses, either because the attacker picked it or because they used a common library 🙃.
It shouldn't surprise anyone that the more specific an IoC is, the more fragile it is 🌸. As things change, they move outside that specific focus. Less fragile IoCs can be really desirable for their robustness and longevity, but you have to balance that against the higher chance of false positives that comes with being broader ⚖️. One way to find that balance is to group indicators and use them in combination. Two low-specificity IoCs for a particular attack might each carry a chance of false positives. But when they're observed together, they can give you much more confidence that you've accurately detected the relevant kill chain 🫶.
5.2.2. Dual and Compromised Use
As noted in Section 3.2.2, the context of an IoC, like the way the attacker uses it, can also affect how precisely that IoC detects an attack 🔍. An IP address representing an attacker's staging server, which the attack chain uses to download later payloads, is a precise IP address for attacker-owned infrastructure 🎯. But it gets less precise if that IP address is tied to a cloud-hosting provider and gets reassigned from one user to another all the time ☁️. And it gets even less precise if the attacker compromised a legitimate web server and is abusing the IP address alongside its ongoing legitimate use 😳.
Same vibe with file hashes. A hash for an attacker's custom remote access trojan will be very precise 💜. But a hash for a common enterprise remote administration tool will be less precise, depending on whether the defender's organisation usually uses that tool for legitimate system administration 🛠️. These dual-use indicators are super context specific, so you have to think about both whether they're usually used legitimately and how they're being used in that particular situation 🧐. Like, using the remote administration tool might be totally legit for support staff during working hours, but not so much for non-support staff, especially if it's seen outside that employee's usual working hours 🌙.
For reasons like these, context is extremely important when sharing and using IoCs 💅.
5.2.3. Changing Use
When it comes to IP addresses, the growing adoption of cloud services, proxies, virtual private networks (VPNs), and carrier-grade Network Address Translation (NAT) is increasing the number of systems associated with any one IP address at the same moment ☁️🔀. This ongoing shift in how IP addresses get used is kinda reducing their specificity (at least for specific subnets or individual addresses). It's also "side-stepping" the pain threat actors would otherwise feel if they had to change IP addresses 😅.
5.3. Privacy
Like we said in Section 3.2.2, context is critical for effective detection using IoCs 🔑. But sometimes defenders feel uneasy about privacy concerns when it comes to how much to share about a cyber intrusion, and with whom 🫣. For example, defenders might generalise the IoCs' description of the attack by stripping out context so it's easier to share. But that can mean an incomplete set of IoCs gets shared, or IoCs get shared without any clear indication of what they represent or how they're involved in an attack 🙈. The sharer will weigh that privacy trade-off when they generalise an IoC, and they should keep in mind that losing context can seriously reduce how useful the IoC is to the people they share with 📉.
The authors have seen that self-censoring by sharers seems more common and more extensive when sharing IoCs into groups with more members 👥. It also happens more when the group has a broader range of perceived member expertise, especially when the lower bound stretches well below the sharer's own perceived expertise 🤏. And it's more common in groups that don't maintain strong trust between members 💔. Trust tends to be strongest where members interact regularly, have common backgrounds, expertise, or challenges, meet behavioural expectations (like following defined handling requirements and not misrepresenting the material they share), and reciprocate the sharing and support they receive 🫶🌈. [LITREVIEW] points out that many of these factors are tied to the human role in Cyber Threat Intelligence (CTI) sharing 🧚.
5.4. Automation ⚙️
okay so IoCs can be super effective for orgs of all sizes and resource levels (remember Section 4.1.2 🫶), but automation is what makes them work at scale 🔥. That means ingesting, processing, assessing, and deploying them automatically. Manual oversight and investigation might still be needed now and then 💅, but relying on manual processing and searching only really works at small scale or for the occasional case 🙈.
Automation also makes it way easier to correlate IoC detections across different log sources and network monitoring interfaces, at different times and in different physical locations ✨. So the response can be tailored to the number and overlap of detections from one intrusion set, and the context can be shown right alongside the detection when alerts are generated for a defender to review 💖. Manual processing and searching may be no less accurate (although IoC transcription errors are a common problem during busy incidents, in the experience of the authors 😭), but the correlation and cross-referencing needed to get the same level of situational awareness is way more time-consuming ⏳.
A third important thing to think about with manual processing is the longer-phase monitoring and adjustment needed to age out IoCs as they become irrelevant or, even more crucially, inaccurate 🧹. Manual setups usually have to just include or exclude an IoC, since anything more granular is time-consuming and complicated to manage 😵💫. Automations, on the other hand, can support a gradual reduction in confidence scoring 📉. That way IoCs can keep contributing without individually knocking out a detection as their specificity drops 🌈.
6. Comprehensive Coverage and Defence-in-Depth 🏰
IoCs give defenders a range of options across the PoP's layers 🪜, letting them balance precision and fragility to get high-confidence detections that are practical and useful 🎯. Broad coverage of the PoP matters because it lets defenders choose between high-precision-but-fragile options and more robust-but-less-precise indicators, depending on what's available 💅. As fragile indicators get changed, the more robust IoCs keep detection going and allow for faster rediscovery 🔁. That's why it's so important to collect as many IoCs as possible across the whole PoP, so defenders have options 🫶.
Near the top of the PoP, TTPs identified through anomaly detection and machine learning are more likely to have false positives 🙃. That gives lower confidence and, crucially, needs better-trained analysts to understand and implement the defences 🧠. But these are super painful for attackers to change 😤, so when they're tuned appropriately, they provide a robust detection 💜. Hashes, down at the bottom, are precise and easy to deploy 🎯, but they're fragile, and malicious actors can easily change them within and across campaigns 🫠.
Endpoint Detection and Response (EDR) or Antivirus (AV) are often the first port of call for protection from intrusion 🛡️, but endpoint solutions aren't a panacea 🙅♀️. One issue is that there are many environments where it isn't possible to keep them updated or, in some cases, to deploy them at all 😭. For example, the Owari botnet, a Mirai variant [Owari], exploited Internet of Things (IoT) devices where such solutions could not be deployed 🤖. Because of gaps like these, where endpoint solutions can't be relied on, a defence-in-depth approach is commonly advised, using a blended approach that includes both network and endpoint defences 🧩.
If an attack happens, the best case is that an endpoint solution detects and prevents it ✅. If it doesn't, there could be lots of good reasons 🤷♀️. The endpoint solution might be quite conservative and aim for a low false-positive rate, it might not have ubiquitous coverage, or it might only be able to defend the initial step of the kill chain [KillChain]. In the worst cases, the attack specifically disables the endpoint solution, or the malware is brand new and so won't be recognised 💀.
In the middle of the pyramid, IoCs related to network information (such as domains and IP addresses) can be particularly useful 🌸. They allow for broad coverage without requiring every single endpoint security solution to be updated, since they may be detected and enforced in a more centralised manner at network choke points (such as proxies and gateways) 🚪. That makes them especially useful in contexts where ensuring endpoint security isn't possible, such as Bring Your Own Device (BYOD), Internet of Things (IoT), and legacy environments 📱. It's important to note that these network-level IoCs can also protect users of a network against compromised endpoints when they're used to detect the attack in network traffic, even if the compromise itself passes unnoticed 👀. For example, in a BYOD environment, enforcing security policies on the device can be difficult, so non-endpoint IoCs and solutions are needed to allow detection of compromise even with no endpoint coverage 🫶.
One example of how network-level IoCs provide a layer of a defence-in-depth solution is Protective DNS (PDNS) [Annual2021], a free and voluntary DNS filtering service provided by the UK NCSC for UK public sector organisations [PDNS]. In 2021, this service blocked access to more than 160 million DNS queries (out of 602 billion total queries) for the organisations signed up to the service [ACD2021] 🤯. That included hundreds of thousands of queries for domains associated with Flubot, Android malware that uses DGAs to generate 25,000 candidate command and control domains each month (these DGAs [DGAs] are a type of TTP) 🦠.
IoCs such as malicious domains can be put on PDNS straight away and then used to prevent access to those known malicious domains across the entire estate of over 925 separate public sector entities that use NCSC's PDNS 🏛️. Coverage can be patchy with endpoints, as the roll-out of protections isn't uniform or necessarily fast 🐢. However, if the IoC is on PDNS, a consistent defence is maintained for devices using PDNS, even if the device itself isn't immediately updated 💪. This offers protection whether the context is a BYOD environment or a managed enterprise system 🎀. PDNS provides the most front-facing layer of defence-in-depth solutions for its users, but other IoCs, like Server Name Indication values in TLS or the server certificate information, also provide IoC protections at other layers 🍰.
Similar to the AV scenario, large-scale services face risk decisions around balancing threat against business impact from false positives ⚖️. Organisations need to be able to stay more conservative with their own defences while still benefiting from them 🧁. For instance, a commercial DNS filtering service is intended for broad deployment, so it will have a risk tolerance similar to AV products 💼. DNS filtering intended for government users (e.g., PDNS), on the other hand, can be more conservative but will still have a relatively broad deployment if it's intended for the whole of government 🏛️. A government department or specific company might accept the risk of disruption and arrange firewalls or other network protection devices to completely block anything related to particular threats, regardless of the confidence 🔒, but rely on a DNS filtering service for everything else 🫧.
Other network defences can make use of this blanket coverage from IoCs, like middlebox mitigation, proxy defences, and application-layer firewalls, but they're out of scope for this document 🙅. Large enterprise networks are likely to deploy their own DNS resolution architecture and possibly TLS inspection proxies, and they can deploy IoCs in these locations 🏢. However, in networks that choose not to, or don't have the resources to, deploy these sorts of mitigations, DNS goes through firewalls, proxies, and possibly a DNS filtering service. It doesn't have to be unencrypted, but these appliances must be able to decrypt it to do anything useful with it, like blocking queries for known bad URIs 🔐.
Covering a broad range of IoCs gives defenders a wide range of benefits 🎁. They're easy to deploy, they provide a high enough confidence to be effective, at least some will be painful for attackers to change, and their distribution around the infrastructure allows for different points of failure. Overall, they enable defenders to disrupt bad actors 💥. The combination of these factors cements IoCs as a particularly valuable tool for defenders with limited resources 👑.
7. IANA Considerations 📭
This document has no IANA actions. 🌷
8. Security Considerations 🚨
This document is all about system security, so buckle up 😤. However, when poorly deployed, IoCs can lead to over-blocking, which may present an availability concern for some systems 💀. While IoCs preserve privacy on a macro scale (by preventing data breaches), research could be done to investigate the impact on privacy from sharing IoCs, and improvements could be made to minimise any impact found 🔍. The creation of a privacy-preserving method of sharing IoCs that still allows both network and endpoint defences to provide security and layered defences would be an interesting proposal 🦋.
9. Conclusions 🎉
IoCs are versatile and powerful, no cap 💪. They underpin and enable multiple layers of the modern defence-in-depth strategy 🧱. They're easy to share, which gives a multiplier effect on attack defence efforts, and they save vital time ⏰. Network-level IoCs offer protection, which is especially valuable when an endpoint-only solution isn't sufficient 🌐. These properties, along with their ease of use, make IoCs a key component of any attack defence strategy, and particularly valuable for defenders with limited resources 💖.
For IoCs to be useful, they don't have to be unencrypted or visible in networks, but it is crucial that they be made available, along with their context, to the entities that need them 🔑. It's also important that this availability and eventual usage cope with multiple points of failure, as per the defence-in-depth strategy, of which IoCs are a key part 🫶.
10. Informative References ✨
Okay bestie, here's the reading list 📚. Every source is listed exactly as written so you can go find the originals and check them yourself 🧐
[ACD2021] UK NCSC, "Active Cyber Defence - The Fifth Year", May
2022, <https://www.ncsc.gov.uk/files/ACD-The-Fifth-Year-
full-report.pdf>.
[ADS] Microsoft, "File Streams (Local File Systems)", January
2021, <https://docs.microsoft.com/en-
us/windows/win32/fileio/file-streams>.
[ALIENVAULT]
AlienVault, "AlienVault: The World's First Truly Open
Threat Intelligence Community",
<https://otx.alienvault.com/>.
[Annual2021]
UK NCSC, "NCSC Annual Review 2021: Making the UK the
safest place to live and work online", 2021,
<https://www.ncsc.gov.uk/files/
NCSC%20Annual%20Review%202021.pdf>.
[CISA] CISA, "Iranian Government-Sponsored APT Cyber Actors
Exploiting Microsoft Exchange and Fortinet Vulnerabilities
in Furtherance of Malicious Activities", November 2021,
<https://www.cisa.gov/uscert/ncas/alerts/aa21-321a>.
[COBALT] "Cobalt Strike", <https://www.cobaltstrike.com/>.
[DFRONT] Infosec, "Domain Fronting", April 2017,
<https://resources.infosecinstitute.com/topic/domain-
fronting/>.
[DGAs] MITRE, "Dynamic Resolution: Domain Generation Algorithms",
2020, <https://attack.mitre.org/techniques/T1483/>.
[FireEye] O'Leary, J., Kimble, J., Vanderlee, K., and N. Fraser,
"Insights into Iranian Cyber Espionage: APT33 Targets
Aerospace and Energy Sectors and has Ties to Destructive
Malware", September 2017,
<https://www.mandiant.com/resources/blog/apt33-insights-
into-iranian-cyber-espionage>.
[FireEye2] Ackerman, G., Cole, R., Thompson, A., Orleans, A., and N.
Carr, "OVERRULED: Containing a Potentially Destructive
Adversary", December 2018,
<https://www.mandiant.com/resources/blog/overruled-
containing-a-potentially-destructive-adversary>.
[GoldenTicket]
Mizrahi, I. and Cymptom, "Steal or Forge Kerberos Tickets:
Golden Ticket", 2020,
<https://attack.mitre.org/techniques/T1558/001/>.
[KillChain]
Lockheed Martin, "The Cyber Kill Chain",
<https://www.lockheedmartin.com/en-us/capabilities/cyber/
cyber-kill-chain.html>.
[LAZARUS] Kaspersky Lab, "Lazarus Under The Hood",
<https://media.kasperskycontenthub.com/wp-
content/uploads/sites/43/2018/03/07180244/
Lazarus_Under_The_Hood_PDF_final.pdf>.
[LITREVIEW]
Wagner, T., Mahbub, K., Palomar, E., and A. Abdallah,
"Cyber Threat Intelligence Sharing: Survey and Research
Directions", January 2019, <https://www.open-
access.bcu.ac.uk/7852/1/Cyber%20Threat%20Intelligence%20Sh
aring%20Survey%20and%20Research%20Directions.pdf>.
[Mimikatz] Mulder, J., "Mimikatz Overview, Defenses and Detection",
February 2016, <https://www.sans.org/white-papers/36780/>.
[MISP] "MISP", <https://www.misp-project.org/>.
[MISPCORE] Dulaunoy, A. and A. Iklody, "MISP core format", Work in
Progress, Internet-Draft, draft-dulaunoy-misp-core-format-
16, 26 February 2023,
<https://datatracker.ietf.org/doc/html/draft-dulaunoy-
misp-core-format-16>.
[NCCGroup] Jansen, W., "Abusing cloud services to fly under the
radar", January 2021,
<https://research.nccgroup.com/2021/01/12/abusing-cloud-
services-to-fly-under-the-radar/>.
[NIST] NIST, "Glossary - security control",
<https://csrc.nist.gov/glossary/term/security_control>.
[OILRIG] Cimpanu, C., "Iranian hacker group becomes first known APT
to weaponize DNS-over-HTTPS (DoH)", August 2020,
<https://www.zdnet.com/article/iranian-hacker-group-
becomes-first-known-apt-to-weaponize-dns-over-https-doh/>.
[OPENIOC] Gibb, W. and D. Kerr, "OpenIOC: Back to the Basics",
October 2013, <https://www.fireeye.com/blog/threat-
research/2013/10/openioc-basics.html>.
[OPENNIC] "OpenNIC", <https://www.opennic.org/>.
[Owari] UK NCSC, "Owari botnet own-goal takeover", 2018, <https://
webarchive.nationalarchives.gov.uk/ukgwa/20220301141030/
https://www.ncsc.gov.uk/report/weekly-threat-report-8th-
june-2018>.
[PDNS] UK NCSC, "Protective Domain Name Service (PDNS)", August
2017, <https://www.ncsc.gov.uk/information/pdns>.
[PoP] Bianco, D., "The Pyramid of Pain", March 2013,
<https://detect-respond.blogspot.com/2013/03/the-pyramid-
of-pain.html>.
[RFC7970] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
November 2016, <https://www.rfc-editor.org/info/rfc7970>.
[RULER] MITRE, "Ruler",
<https://attack.mitre.org/software/S0358/>.
[STIX] OASIS Cyber Threat Intelligence (CTI), "Introduction to
STIX", <https://oasis-open.github.io/cti-
documentation/stix/intro>.
[Symantec] Symantec, "Elfin: Relentless Espionage Group Targets
Multiple Organizations in Saudi Arabia and U.S.", March
2019, <https://www.symantec.com/blogs/threat-intelligence/
elfin-apt33-espionage>.
[TAXII] OASIS Cyber Threat Intelligence (CTI), "Introduction to
TAXII", <https://oasis-open.github.io/cti-
documentation/taxii/intro.html>.
[Timestomp]
MITRE, "Indicator Removal: Timestomp", January 2020,
<https://attack.mitre.org/techniques/T1099/>.
[TLP] FIRST, "Traffic Light Protocol (TLP)",
<https://www.first.org/tlp/>.Acknowledgements 💖
Huge thanks to everyone across the IETF and IRTF communities who has been helping make cyber defence better 🫶 you're literally the reason this stuff works 🌈
Authors' Addresses 🎀
Kirsty Paine
Splunk Inc.
Email: kirsty.ietf@gmail.com
Ollie Whitehouse
Binary Firefly
Email: ollie@binaryfirefly.com
James Sellwood
Email: james.sellwood.ietf@gmail.com
Andrew Shaw
UK National Cyber Security Centre
Email: andrew.s2@ncsc.gov.uk📦 where this page comes from
- ietf: rfc9424 2023-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms