idnits 2.17.1 draft-paine-smart-indicators-of-compromise-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 6, 2020) is 1505 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Paine 3 Internet-Draft UK National Cyber Security Centre 4 Intended status: Informational O. Whitehouse 5 Expires: September 7, 2020 NCC Group 6 March 6, 2020 8 Indicators of Compromise (IoCs) and Their Role in Attack Defence 9 draft-paine-smart-indicators-of-compromise-00 11 Abstract 13 Indicators of Compromise (IoCs) are an important technique in attack 14 defence (often called cyber defence). This document outlines the 15 different types of IoC, their associated benefits and limitations, 16 and discusses their effective use. It also contextualises the role 17 of IoCs in defending against attacks through describing a recent case 18 study. This draft does not pre-suppose where IoCs can be found or 19 should be detected - as they can be discovered and deployed in 20 networks, endpoints or elsewhere - rather, engineers should be aware 21 that they need to be detectable (either by endpoint security 22 appliances or network-based defences, or ideally both) to be 23 effective. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 7, 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may not be modified, and derivative works of it may not 58 be created, except to format it for publication as an RFC or to 59 translate it into languages other than English. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 2. What are IoCs? . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Why use IoCs? . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. IoCs can be used even with limited resource . . . . . . . 4 68 3.2. IoCs have a multiplier effect on attack defence effort . 4 69 3.3. IoCs are easily shareable . . . . . . . . . . . . . . . . 5 70 3.4. IoCs can be attributed to specific threat actors . . . . 5 71 3.5. IoCs can provide significant time savings . . . . . . . . 5 72 3.6. IoCs allow for discovery of historic attacks . . . . . . 6 73 3.7. IoCs underpin and enable multiple of the layers of the 74 modern defence-in-depth strategy . . . . . . . . . . . . 6 75 4. Pain, Fragility and Precision . . . . . . . . . . . . . . . . 7 76 4.1. Pyramid of Pain . . . . . . . . . . . . . . . . . . . . . 7 77 4.2. Fragility . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.3. Precision . . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.4. Comprehensive Coverage . . . . . . . . . . . . . . . . . 9 80 5. Defence in Depth . . . . . . . . . . . . . . . . . . . . . . 10 81 6. Case Study: APT33 . . . . . . . . . . . . . . . . . . . . . . 11 82 6.1. Overall TTP . . . . . . . . . . . . . . . . . . . . . . . 12 83 6.2. IoCs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 88 11. Informative References . . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 This draft aims to describe, and illustrate the purpose of, 94 Indicators of Compromise (IoCs), which are widely used in attack 95 defence (often called cyber defence). The concept of the 'Pyramid of 96 Pain' [PoP] will also be introduced to show the properties of the 97 broad range of defences that IoCs can provide. Furthermore, this 98 draft will describe a real intrusion set, APT33, for which IoCs were 99 identified and used for defence. This document is not a 100 comprehensive report of APT33 and is intended to be read alongside 101 APT33 open source material (for example, [Symantec]). 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2. What are IoCs? 111 Indicators of Compromise (IoCs) are artefacts observed about an 112 attacker; their techniques, tactics, procedures or associated tooling 113 and infrastructure. These indicators can be observed at a 114 combination of network or host levels and can, with varying degrees 115 of confidence, help to identify an occurrence of an intrusion or 116 associated activity to a known intrusion set. These IoCs are used by 117 network defenders (blue teams) to protect their networks. Examples 118 of IoCs can include: 120 o IP addresses 122 o domain names 124 o TLS Server Name Indicator values 126 o certificate information 128 o signatures such as binary code patterns and strings 130 o hashes of malicious binaries or scripts 132 o attack tools, such as mimikatz [Mimikatz] 134 o attack techniques, such as Kerberos golden tickets [GoldenTicket] 136 IoCs are often found initially through manual investigation and then 137 shared at scale so a variety of individuals and organisations can 138 defend themselves. They can be found in a range of locations, 139 including in networks and at endpoints, but wherever they exist, they 140 need to be made available to security appliances to ensure that they 141 can be deployed quickly and widely. For IoCs to provide defence-in- 142 depth (see Section 5), which is one of their key strengths, they 143 should be deployed on both the network and on endpoints through 144 solutions that have sufficient privilege to act on them, to cope with 145 different points of failure. 147 IoCs can be of varying quality. An IoC without context is not much 148 use for network defence - a defender could do different things with 149 an IoC (e.g. monitor it, block it, log it) depending on this context. 150 Without the associated context, for example the threat actor it 151 relates to, the last time it was seen in use, its expected lifetime 152 or other related IoCs, the usefulness of an IoC is greatly reduced. 153 On the other hand, an IoC delivered with context is much more useful 154 to a network defender, who can then make an informed choice on how to 155 use it to protect their network. 157 3. Why use IoCs? 159 3.1. IoCs can be used even with limited resource 161 IoCs are scalable and easy to deploy which makes them a really 162 valuable asset for smaller entities. IoCs are also inexpensive to 163 use. For example, take a small manufacturing subcontractor in a 164 supply chain that produces a critical, highly specialised, component. 165 The small manufacturer represents an attractive target because there 166 would be disproportionate impact on both the supply chain and the 167 prime contractor if it were compromised. In addition, it is likely 168 to have comparatively smaller resource to manage the risks it faces. 169 It is reasonable to assume that this small manufacturer will have 170 only basic security (in the form of firewalls, similar network 171 protection devices, or an outsource agreement), however it can still 172 leverage IoCs to great effect. IoCs can be deployed to give a 173 baseline protection against known threats by small entities without 174 access to a significant defensive team or the threat intelligence 175 relationships necessary to perform resource-intensive investigation. 176 In addition, as detailed further in Section 3.2, the prime contractor 177 can also supply IoCs to the subcontractor to provide an uplift in 178 defensive capability in order to protect the prime contractor. 179 Affording some level of protection to organisations across a spectrum 180 of resource, maturity, and sophistication is a major part of the 181 appeal for IoCs. 183 3.2. IoCs have a multiplier effect on attack defence effort 185 The correspondence is one-to-many: simply blocking one IoC may 186 protect thousands of users within an organisation. Discovering one 187 IoC can be intensive, but sharing IoCs via well-established routes 188 such as the Malware Information Sharing Platform (MISP) [MISP] will 189 protect thousands of organisations and end users. The shareability 190 and reproducibility of IoCs is a huge advantage; it allows a threat 191 defender to look for things consistently and automate the process of 192 defending their networks. It doesn't require intensive training (as 193 needed to, for example, manually analyse tipped machine learning 194 events), nor does it require time-intensive resource to deploy IoCs. 196 In the case of an ongoing email phishing campaign, IoCs can be 197 monitored, discovered and deployed quickly and easily. If they are 198 deployed quickly via a mechanism such as a protective DNS filtering 199 service, they can be more effective still, as the same email campaign 200 is mitigated before a recipient clicks the link or before malicious 201 payloads can call out for instructions. While this approach can 202 therefore be faster than some traditional defences, the most 203 important benefit is that other parties can be protected without 204 additional effort. 206 3.3. IoCs are easily shareable 208 This is due to two major factors: firstly, because lists of 209 identifiers are easy to distribute, and secondly, due to standards 210 such as Structured Threat Information Expression (STIX) [STIX] that 211 provide a well-defined format for sharing. This allows IoCs to give 212 blanket coverage for organisations and allow widespread mitigation in 213 a timely fashion. They can be shared with systems administrators - 214 from small to large organisations, from large teams to a single 215 individual - allowing them to implement defences on their network. 217 3.4. IoCs can be attributed to specific threat actors 219 Deployment of various modern system security services, such as 220 endpoint detection and response or firewall filtering, comes with an 221 inherent trade-off between breadth of protection and risk of false 222 positives (see Section 4). An organisation can examine their own 223 risk, impact and threat - they can perform their own information 224 assurance and threat modelling - and work to manage those threats 225 they wish to. This means an organisation can prioritise or accept 226 trade-offs against a subset of malicious actors; tying IoCs to threat 227 actors allows organisations to focus their defences against 228 particular risks. Organisations should have the technical freedom 229 and the capability to choose their risk posture and defence methods. 231 3.5. IoCs can provide significant time savings 233 Not only are there time savings from sharing IoCs, saving duplication 234 of investigation effort, but deploying them automatically at scale is 235 seamless for many enterprises. Where automatic deployment of IoCs is 236 working well, organisations and users get blanket protection with 237 minimal human intervention and minimal effort, a key goal of attack 238 defence. Conversely, protecting a complex network without automatic 239 deployment of IoCs could mean updating every single endpoint or 240 network device consistently and reliably to the same security level. 241 The work this entails (including polling for logs, locating assets 242 and devices, and manually checking patch levels) introduces 243 complexity and a need for skilled analysts. While it is still 244 necessary to invest effort to eliminate false positives when widely 245 deploying IoCs, the cost and effort involved can be far smaller than 246 the work entailed in reliably patching all endpoint and network 247 devices - for example, particularly on legacy systems that may be 248 particularly complicated, or even impossible, to update. 250 3.6. IoCs allow for discovery of historic attacks 252 A network defender can use recently acquired IoCs in conjunction with 253 historic data, such as logged DNS queries or email attachment hashes, 254 to hunt for signs of past compromise. Not only can this technique 255 help to build up a clear picture of past attacks, but it also allows 256 for retrospective mitigation of the effects of any previous 257 intrusion. This use case is reliant on historic data not having been 258 compromised itself, by a technique such as Timestomp [Timestomp], or 259 being incomplete due to third party policies, but is nonetheless 260 valuable for detecting past attacks. 262 3.7. IoCs underpin and enable multiple of the layers of the modern 263 defence-in-depth strategy 265 Firewalls, Intrusion Detection Systems and Security Incident Event 266 Management platforms all employ IoCs to identify and mitigate 267 threats. Anti-Virus (AV) products, as part of a multi-faceted 268 approach, deploy IoCs via catalogues or libraries to all supported 269 client endpoints. Of course, IoCs do not address all attack defence 270 challenges - but they form a vital tier of any organisation's layered 271 defence. 273 As an example, open source malware can be deployed by many different 274 actors, each with their own "Tactics, Techniques and Procedures" 275 (TTPs) and infrastructure. However, if the same executable is used, 276 the hash remains the same - and this IoC can be deployed in endpoints 277 through AV to protect regardless of TTP and infrastructure. Should 278 this defence fail however, other defences can prevent malicious 279 actors progressing further through the attack chain - for instance, 280 by blocking known malicious domain name look-ups and thereby 281 preventing the malware calling out to its command and control 282 infrastructure. 284 A different malicious actor changes the intrusion set deployed across 285 different campaigns, but their access vector remains consistent and 286 well-known. Therefore, this TTP and pattern of activity can be 287 recognised and proactively defended against. For example, if their 288 access vector consistently exploits a vulnerability in software, 289 regular and estate-wide patching can prevent the attack from taking 290 place. Should these pre-emptive measures fail however, other IoCs 291 observed across multiple campaigns can be used to prevent the attack 292 at different stages in the attack chain. Hence, IoCs can underpin 293 multiple layers of any modern defence-in-depth strategy. 295 4. Pain, Fragility and Precision 297 The variety of IoC types inherently embody a set of trade-offs 298 between the risk of false positives (misidentifying non-malicious 299 traffic as malicious) and the risk of failing to identify attacks. 300 The pain of modifying attacks to subvert known IoCs inversely 301 correlates with both the fragility of various IoCs as a tool for 302 attack defence, and the precision with which IoCs identify an attack. 303 Research is needed to elucidate the exact nature of these trade-offs 304 between pain, fragility and precision. 306 4.1. Pyramid of Pain 308 IoCs form a "Pyramid of Pain" [PoP] that can be used for prevention, 309 detection and mitigation. This represents how much pain it is: to an 310 adversary to change and for the defender to gather. The layers of 311 the PoP range from hashes to TTPs and the pain ranges from 312 recompiling code to creating a new attack strategy. 314 On the lowest (and least painful) level are hashes of malicious 315 files. These are easy for a defender to gather and can be given to 316 firewalls, for example, to block malicious downloads. To subvert 317 this defence, an adversary need only recompile code with some trivial 318 changes, thereby changing the hash. IoCs aren't the only route for 319 doing this blocking but are a quick, less intrusive and more 320 convenient method. 322 The next two levels are IPs and domain names. These are blockable, 323 with varying false positive rates (see Section 4.4), and often cause 324 more pain to an adversary to subvert; they may have to change IP 325 ranges, find a new provider, and change their code if the IP address 326 is hard-coded (rather than resolved). Domain names are more granular 327 than IP addresses and are more painful for an adversary to change. 329 /\ 330 / \ MORE PAIN 331 / \ LESS FRAGILE 332 / \ LESS PRECISE 333 / TTPs \ 334 / \ / \ 335 ============== | 336 / \ | 337 / Tools \ | 338 / \ | 339 ====================== | 340 / \ | 341 / network/host artefacts \ | 342 / \ | 343 ============================== | 344 / \ | 345 / domain names \ | 346 / \ | 347 ====================================== | 348 / \ | 349 / IP addresses \ | 350 / \ \ / 351 ============================================== 352 / \ LESS PAIN 353 / Hash values \ MORE FRAGILE 354 / \ MORE PRECISE 355 ====================================================== 357 Figure 1 359 Network and host artefacts, such as changed timestamps of files left 360 on the endpoint (see [Timestomp]) or a beaconing pattern on the 361 network, are harder still to change, as they relate specifically to 362 the attack taking place and may not be under the direct control of 363 the attacker. 365 Tools and TTPs form the top two layers of the pyramid; these layers 366 describe a threat actor's methodology - the way they perform the 367 attack. An example could be deployment of malicious code to perform 368 reconnaissance of a victim's network, which pivots laterally to a 369 valuable endpoint, then downloads a ransomware payload. Tools refer 370 to the software used to conduct the attack, whereas TTPs relate to 371 the broader attack strategy being used. Information on TTPs and 372 Tools take intensive effort to diagnose on the part of the defender, 373 but they are fundamental to the attacker and campaign and hence 374 incredibly painful for the adversary to change. 376 4.2. Fragility 378 For a network defender, the PoP can also be thought of in terms of 379 fragility. The less painful it is for the attacker to change the 380 IoC, the more fragile that IoC is as an attack defence tool. It 381 should be relatively simple to get a hash of the various file 382 attachments (and then deploy this through AV or other means) or to 383 get an email subject for a particular campaign. However, when 384 thinking in terms of fragility, the hash IoCs or email subjects are 385 fragile and can be changed; in reality, they will be changed easily 386 between campaigns. IPs and domain names can also be changed between 387 campaigns, but it is harder - and if the IoCs didn't change but 388 weren't blocked, that's a missed opportunity. 390 4.3. Precision 392 The PoP can be also considered in terms of how precise the defence 393 can be, with the false positive rate roughly increasing as we move up 394 the pyramid. A hash (e.g. MD5, SHA1 or SHA2) can specify a 395 particular executable, so the false positive is nil. On the other 396 hand, TTPs or fuzzier rules may apply to various binaries, and even 397 benign software may share the same identifying methodology. This 398 corresponds with the consequences for fragility mentioned above, as 399 the more precise IoCs, such as hashes, are also the most fragile. 401 4.4. Comprehensive Coverage 403 IoCs provide the defender with a range of options across the PoP 404 layers, balancing between precision and fragility to give high 405 confidence events that are practical and useful. Broad coverage of 406 the PoP is important as it allows the defender to cycle between high 407 precision but high fragility options and more robust but less precise 408 indicators. As fragile indicators are changed, the more robust IoCs 409 allow for continued detection and faster rediscovery. This is why 410 it's important to collect as many IoCs as possible across the whole 411 PoP. 413 At the top of the PoP, TTPs identified through anomaly detection and 414 machine learning are more likely to have false positives, which gives 415 lower confidence and, vitally, requires better trained analysts to 416 understand and implement the defences. Hashes, at the bottom, are 417 precise and easy to deploy but are fragile and easily changed within 418 and across campaigns by malicious actors. 420 In the middle of the pyramid, IoCs related to network information 421 (such as domains and IP addresses) can be particularly useful. They 422 allow for broad coverage, without requiring each and every endpoint 423 security solution to be updated. This means they can shine in 424 contexts where ensuring endpoint security isn't possible such as 425 "Bring Your Own Device" (BYOD), IoT and legacy environments. Using 426 these network level IoCs can also protect against a compromised 427 endpoint as, even if the compromise passes unnoticed, the IoCs can 428 still be checked against network traffic, allowing detection of the 429 attack. For example, in a BYOD environment, enforcing security 430 policies on the device can be difficult, so non-endpoint IoCs and 431 solutions are needed to allow detection of compromise even with no 432 endpoint coverage. 434 Covering a broad range of IoCs gives defenders a wide range of 435 benefits: easy to deploy, high confidence enough to be effective, 436 painful enough to change and disruptive to bad actors. The 437 combination of these factors cements IoCs as a particularly valuable 438 tool for defenders with limited resources. 440 5. Defence in Depth 442 Endpoint Detection and Response (EDR) or Anti-Virus (AV) are often 443 the first port of call for protection from intrusion but aren't a 444 panacea. One issue is that there are many environments where it is 445 not possible to keep them updated, or in some cases, deploy them at 446 all. For example, the Owari botnet, a Mirai variant [Owari], 447 exploited Internet of Things (IoT) devices where such solutions could 448 not be deployed. It is because of such gaps, where endpoint 449 solutions can't be relied on (see [CLESS]), that a defence-in-depth 450 approach is commonly advocated, using a blended approach that 451 includes both network and endpoint defences. 453 If an attack happens, then you hope an endpoint solution will pick it 454 up. If it doesn't, it could be for many good reasons: the endpoint 455 solution could be quite conservative and aim for a low false-positive 456 rate, it might not have ubiquitous coverage or it might only be able 457 to defend the initial step of the kill chain. In the worst cases, 458 the attack specifically disables the endpoint solution or the malware 459 is brand new and so won't be recognised. Going up the pyramid, IP 460 addresses are next, and here we have ACLs (access control lists) that 461 can go on firewalls - or your favourite DNS filtering service for 462 protection. Using IPs will blanket-defend a range of endpoints, from 463 printers [IoT] to "Bring Your Own Device" (BYOD) to capable 464 endpoints. Going further through the pyramid, domains are next - 465 these are more granular. 467 One example of how IoCs provide a layer of a defence-in-depth 468 solution is Protective DNS (PDNS), a free and voluntary DNS filtering 469 service provided by the UK NCSC for UK public sector organisations 470 [PDNS]. In 2018, this service blocked access to 57.4 million DNS 471 queries for 118,527 unique reasons (out of 68.7 billion total 472 queries) for the organisations signed up to the service [ACD2019]. 28 473 million of them were for domain generation algorithms (DGAs), 474 including 15 known DGAs. IoCs such as malicious domains can be put 475 on PDNS straight away and can then be used to prevent access to those 476 known malicious domains across the entire estate of over 460 separate 477 public sector entities that use NCSC's PDNS [Annual2019]. Coverage 478 can be patchy with endpoints, as the roll-out of protections isn't 479 uniform or necessarily fast - but if the IoC is on PDNS, a consistent 480 defence is maintained. This offers protection, regardless of whether 481 the context is a BYOD environment or a managed enterprise system. 482 Other IoCs, like Server Name Indicator values in TLS or the server 483 certificate information, also provide IoC protections. 485 Similar to the AV scenario, large scale services face risk decisions 486 around balancing threat against business impact from false positives. 487 Organisations need to be able to retain the ability to be more 488 conservative with their own defences, while still benefiting from 489 them. For instance, a commercial DNS filtering service is intended 490 for broad deployment, so will have a risk tolerance similar to AV 491 products; whereas DNS filtering intended for government users (e.g. 492 PDNS) can be more conservative, but will still have a relatively 493 broad deployment if intended for the whole of government. A 494 government department or specific company, on the other hand, might 495 accept the risk of disruption and arrange firewalls or other network 496 protection devices to completely block anything related to particular 497 threats, regardless of the confidence, but rely on a DNS filtering 498 service for everything else. 500 Other network defences can make use of this blanket coverage from 501 IoCs, like middlebox mitigation, proxy defences, and application 502 layer firewalls, but they're out of scope for this draft. Note too 503 that DNS goes through firewalls, proxies and possibly to a DNS 504 filtering service; it doesn't have to be unencrypted, but these 505 appliances must be able to decrypt it to do anything useful with it, 506 like blocking queries for known bad URIs. 508 6. Case Study: APT33 510 To contextualise IoCs, we describe a real world case study: a current 511 campaign by the threat actor APT33, also known as Elfin and Refined 512 Kitten (see [Symantec]). APT33 has been assessed by industry to be a 513 state-sponsored group [FireEye], yet in this case study, IoCs still 514 gave defenders an effective tool against such a sophisticated and 515 powerful adversary. The group has been active since at least 2015 516 and is known to target a range of sectors including petrochemical, 517 government, engineering and manufacturing. Activity has been seen in 518 countries across the globe, but predominantly in the USA and Saudi 519 Arabia. 521 6.1. Overall TTP 523 The techniques employed by this actor exhibit a relatively low level 524 of sophistication: typically, spear phishing is used with document 525 lures that imitate legitimate publications. Once inside a target 526 network, the actor will attempt to pivot to other machines to gather 527 documents and gain access to administrative credentials. In some 528 cases, users are tricked into providing credentials that are then 529 used to enable the use of RULER, a freely available tool that allows 530 exploitation of an email client. The attacker, in possession of a 531 target's password, uses RULER to access the target's mail account, 532 and embed a malicious script which will be triggered when the mail 533 client is next opened, resulting in the execution of malicious code 534 (often additional malware retrieved from the Internet) (see 535 [FireEye2]). 537 When a destructive tool is deployed, it relies on overwriting the 538 master boot record (MBR) of the hard drives in as many PCs as 539 possible. This type of tool, known as a wiper, results in data loss 540 and renders devices unusable until the operating system is 541 reinstalled. In some cases, the actor is able to use administrator 542 credentials to invoke execution across a large swathe of a company's 543 IT estate at once; where this isn't possible the actor may attempt to 544 spread the wiper to as many PCs as possible manually, or by using 545 wormlike capabilities against unpatched vulnerabilities on the 546 internal network. 548 6.2. IoCs 550 As a result of investigations by both industry and NCSC in 551 partnership, a set of IoCs were compiled that could then be shared 552 out with government and industry to enable network defenders to 553 search for these indicators in their networks. Detection of these 554 IoCs is likely indicative of APT33 targeting and could indicate 555 potential compromise and subsequent use of destructive malware. 556 Network defenders could also initiate processes to block these IoCs 557 and foil future attacks. This set of IoCs comprised: 559 o 9 fragile indicators including hashes and email subject lines 561 o 5 IP addresses 563 o 7 domains 565 These IoCs mostly cover the bottom few levels of the PoP, with the 566 network level IoCs giving resilience not provided by the fragile 567 indicators. Not only can these IoCs be used to check historical data 568 for evidence of past compromise, but they can also be deployed to 569 block further infection and/or to detect infection in a timely 570 manner, thereby contributing to preventing the loss of user and 571 system data. 573 7. Conclusions 575 IoCs are versatile and powerful. IoCs underpin and enable multiple 576 of the layers of the modern defence-in-depth strategy. IoCs are easy 577 to share, providing a multiplier effect on attack defence effort and 578 they save vital time. Network-level IoCs offer protection, 579 especially valuable when an endpoint-only solution isn't sufficient. 580 These properties, along with their ease of use, make IoCs a key 581 component of any attack defence strategy and particularly valuable 582 for defenders with limited resources. 584 For IoCs to be useful, they don't have to be unencrypted or visible 585 in networks - but crucially they do need to be made available, along 586 with their context, to entities that need them. It is also important 587 that this availability and eventual usage copes with multiple points 588 of failure, as per the defence-in-depth strategy, of which IoCs are a 589 key part. 591 8. Acknowledgements 593 Thanks to all those who have been involved with improving cyber 594 defence in the IETF and IRTF communities. 596 9. IANA Considerations 598 This memo includes no request to IANA. 600 10. Security Considerations 602 This draft is all about system security. 604 11. Informative References 606 [ACD2019] Levy, I. and M. S, "Active Cyber Defence - The Second 607 Year", 2019, . 610 [Annual2019] 611 NCSC, "Annual Review 2019", 2019, 612 . 615 [CLESS] Taddei, A., Wueest, C., Roundy, K., and D. Lazanski, 616 "Capabilities and Limitations of an Endpoint-only Security 617 Solution", 2019, . 620 [FireEye] O'Leary, J., Kimble, J., Vanderlee, K., and N. Fraser, 621 "Insights into Iranian Cyber Espionage: APT33 Targets 622 Aerospace and Energy Sectors and has Ties to Destructive 623 Malware", 2017, . 627 [FireEye2] 628 FireEye, "OVERRULED: Containing a Potentially Destructive 629 Adversary", 2018, . 633 [GoldenTicket] 634 Soria-Machado, M., Abolins, D., Boldea, C., and K. Socha, 635 "Kerberos Golden Ticket Protection", 2014, 636 . 640 [IoT] NCC Group, "Security Impact of IoT on the Enterprise", 641 2019, . 644 [Mimikatz] 645 Mulder, J., "Mimikatz Overview, Defenses and Detection", 646 2016, . 650 [MISP] MISP, "MISP", 2019, . 652 [Owari] NCSC, "Owari botnet own-goal takeover", 2018, 653 . 656 [PDNS] NCSC, "Protective DNS", 2019, 657 . 659 [PoP] Bianco, D., "The Pyramid of Pain", 2014, . 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, 664 DOI 10.17487/RFC2119, March 1997, 665 . 667 [STIX] OASIS Cyber Threat Intelligence, "STIX", 2019, 668 . 671 [Symantec] 672 Symantec, "Elfin: Relentless", 2019, 673 . 676 [Timestomp] 677 OASIS Cyber Threat Intelligence, "Timestomp", 2019, 678 . 680 Authors' Addresses 682 Kirsty Paine 683 UK National Cyber Security Centre 685 Email: kirsty.p@ncsc.gov.uk 687 Ollie Whitehouse 688 NCC Group 690 Email: ollie.whitehouse@nccgroup.com