IOCs are Dead - Long Live IOCs! (RSA USA 2016)

Slide 1

Slide 1 text

SESSION ID: IOCs are Dead - Long Live IOCs! AIR-F03 Ryan Kazanciyan Chief Security Architect Tanium  @ryankaz42

Slide 2

Slide 2 text

Yours truly, circa 2010 2 https://buildsecurityin.us-cert.gov/sites/default/ files/RyanKazanciyan-APTPanel.pdf

Slide 3

Slide 3 text

IOCs as adver@sed 3 Human-readable, machine- consumable Capture a broad set of forensic arHfacts Foster informaHon sharing Provide context around threats Do beLer than “signatures”

Slide 4

Slide 4 text

Five years later… 4

Slide 5

Slide 5 text

IOC quality and sharing in 2016 5

Slide 6

Slide 6 text

My own point of reference 2009 - 2015: Inves@gator Large-scale, targeted aLacks Designed, tested, and applied IOCs for proacHve and reacHve hunHng 6 2015 - Present: Builder Designing an EDR plaSorm that includes IOC detecHon Helping orgs build self- sustaining, scalable “hunHng” capabiliHes

Slide 7

Slide 7 text

The erosion of indicator-based detec@on 7 Brittle indicators - short shelf-life Poor quality control in threat data feeds Hard to build effective homegrown IOCs Indicator detection tools are inconsistent IOCs applied to limited scope of data

Slide 8

Slide 8 text

“IOCs” vs. “threat data” vs. “intelligence” IOCs are structured threat data Threat data != threat intelligence Threat intelligence provides context and and analysis Threat intelligence is ineﬀecHve without quality threat data 8

Slide 9

Slide 9 text

#RSAC IOCs are briUle

Slide 10

Slide 10 text

Verizon DBIR 2015: Most shared IOC types 10 Source: Verizon DBIR 2015

Slide 11

Slide 11 text

IOCs in the APTnotes data set 11 0 2500 5000 7500 10000 141 5,083 9,096 2,237 6,639 2,512 350 248 CVE E-Mail URL Hosts IP Hashes Registry File Name Derived from over 340 threat reports (2006 - 2015) archived on https://github.com/kbandla/APTnotes

Slide 12

Slide 12 text

This will never keep pace… 12 Source: Verizon DBIR 2015

Slide 13

Slide 13 text

Short lifespan of C2 IPs and domains Malicious sites co-located on virtual host server IPs Low barrier to host malicious content on legiHmate providers 13 The problem extends beyond ﬁle hashes

Slide 14

Slide 14 text

Sheer volume does not solve the problem 2007: Bit9 FileAdvisor tracked 4 billion unique files, catalog grew by 50 million entries per day 2009: McAfee Global Threat Intelligence tracked reputaHon data for 140 million IP addresses, handling 50 million file lookups per day 2011: Symantec Insight tracked tens of billions of linkages between users, files, web sites 14

Slide 15

Slide 15 text

Seven years of progress? 15 “…an intelligence-led approach to security will be key in detecting the most sophisticated threats and responding to them quickly and effectively.” “…innovating to provide predictive security. This approach comprises interconnected security technology at multiple layers in the technology stack, backed by global threat intelligence. Predictive security will allow security products to intelligently block attacks much sooner than is currently possible…”

Slide 16

Slide 16 text

#RSAC Paid IOCs != quality IOCs

Slide 17

Slide 17 text

Have you assessed your feeds? 17 Jon Oltsik / ESG, http://www.networkworld.com/article/2951542/cisco-subnet/measuring-the-quality-of-commercial-threat-intelligence.html

Slide 18

Slide 18 text

My (incredibly scien@ﬁc) methodology Chose two top-Her paid threat feed services Retrieved the most recent ~20 indicators from each Spent 15 minutes eyeballing their contents 18

Slide 19

Slide 19 text

What are you paying for? 19 Too speciﬁc - malware hash AND’d with a ﬁlename (Real IOC from a commercial feed)

Slide 20

Slide 20 text

What are you paying for? 20 Too speciﬁc - LNK ﬁles are unique per-system (Real IOC from a commercial feed)

Slide 21

Slide 21 text

What are you paying for? 21 Too noisy - matches component of legi@mate soiware (Real IOC from a commercial feed)

Slide 22

Slide 22 text

#RSAC Building good IOCs is hard

Slide 23

Slide 23 text

Challenges with IOC development 23 Easy to build high-ﬁdelity IOCs (may yield high false-negaHves) Hard to build robust IOCs (may yield higher false- posiHves) Easy to build IOCs that don’t evaluate properly (tools have inconsistent matching logic) “Pyramid of Pain”, David Bianco  http://detect-respond.blogspot.co.uk/2013/03/the-pyramid-of-pain.html

Slide 24

Slide 24 text

Running aground on a robust IOC 24 Too broad - may match on uncommon but legi@mate binaries How much Hme do your analysts have to conHnuously build, test, and reﬁne IOCs like this?

Slide 25

Slide 25 text

Inconsistencies in IOC detec@on tools 25 FileItem TaskItem ServiceItem EventLogItem ... ✅ ❌ ❌ ✅ ? {…} {…} OR AND {…} {…} AND OR {…} {…} ✅ ❌ ✅ ? ✅ Supported Observables Logic Handling Data Normalization x86 or x64? HKEY_CURRENT_USER %SYSTEMROOT% HKEY_USERS\{SID} \system32\ \SysWoW64\ \WoW6432Node\ \Windows\ STIX & CybOX have a few tools to help with this: maec-to-sHx python-cybox/normalize.py

Slide 26

Slide 26 text

Issues speciﬁc to OpenIOC What happens when you try to turn a proprietary tool’s unique output schema into a “standard”… 26 ProcessItem/PortList/PortItem/process “File PE Detected Anomalies” FileItem/PEInfo/DetectedEntryPointSignature/Name “Process Port Process” FileItem/PEInfo/DetectedAnomalies/string “File EntryPoint Sig Name”

Slide 27

Slide 27 text

Issues speciﬁc to OpenIOC Example: Registry evidence in OpenIOC 27 Key: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run Value: Backdoor Data: C:\path\to\malware.exe RegistryItem/Path: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Backdoor RegistryItem/KeyPath: \SOFTWARE\Microsoft\Windows\CurrentVersion\Run RegistryItem/Value: C:\path\to\malware.exe RegistryItem/ValueName: Backdoor RegistryItem/Text: C:\path\to\malware.exe

Slide 28

Slide 28 text

#RSAC Broadening the scope of endpoint indicator usage

Slide 29

Slide 29 text

Focusing on scope of data, not tools What are you matching your endpoint IOCs against? What’s your cadence of detecHon? Where are your gaps? 29 Data at Rest  (Files on disk, registry) Workstations Servers Historical Activity  (Telemetry, logs, alerts, historical data) EXE Current Activity  (Processes, Network   Connections, Memory)

Slide 30

Slide 30 text

Matching on SIEM / centralized logging 30 Most common endpoint data in SIEM: AnH-virus / anH-malware alerts (all systems) Event log data (subset of systems - usually servers) Resource impact of large- scale event forwarding & storage limits endpoint coverage & scope of data Data at Rest  (Files on disk, registry) Workstations Servers Historical Activity  (Telemetry, logs, alerts, historical data) EXE Current Activity  (Processes, Network   Connections, Memory)

Slide 31

Slide 31 text

Matching on forensic telemetry Process execuHon, ﬁle events, network connecHons, registry changes Preserves historical data, short-lived events Expensive to centralize in large environments Limited scope of data for IOC matching 31 Workstations Servers Historical Activity  (Telemetry, logs, alerts, historical data) EXE Current Activity  (Processes, Network   Connections, Memory) Data at Rest  (Files on disk, registry)

Slide 32

Slide 32 text

Matching on live endpoints PotenHally the broadest set of available data ConsideraHons Endpoint impact Availability Time-to-assess Scalability 32 Data at Rest  (Files on disk, registry) Workstations Servers Historical Activity  (Telemetry, logs, alerts, historical data) EXE Current Activity  (Processes, Network   Connections, Memory)

Slide 33

Slide 33 text

The ideal combina@on Goal: Maximize the value of briLle IOCs Telemetry for eﬃciency, historical data On-endpoint to maximize current state & at-rest data Increase cadence as tools & resources permit Don’t take shortcuts on scope of coverage! 33

Slide 34

Slide 34 text

“I only need to check important systems” 34 CredenHals can be harvested from anywhere on a Windows network No need to run malicious code on admin systems or DCs By the Hme they get to “crown jewels”, aLackers are already authenHcaHng with legiHmate accounts Source: https://adsecurity.org/?p=1729 An example of why this fails:

Slide 35

Slide 35 text

#RSAC Shrinking the detec@on gap

Slide 36

Slide 36 text

Doing beUer with what we've got Source:  hLps://www.digitalshadows.com/blog-and-research/another-sans-cyber-threat-intelligence-summit-is-in-the-books/ 36 "The desire to take a technical feed and simply dump it into our security infrastructure doesn’t equate to a threat intelligence win... You cannot get more relevant threat intelligence than what you develop from within your own environment. This should then be enriched with external intelligence" -Rick Holland, Forrester, 2016 CTI Summit

Slide 37

Slide 37 text

My own point of reference As an inves@gator:   Rela@ve eﬃcacy of IOCs vs. methodology & outlier analysis over @me 37 0 20 40 60 80 2010 2011 2012 2013 2014 2015 IOCs Methodology   & outlier analysis (Rough approximation for the sake of having a pretty graph)

Slide 38

Slide 38 text

Resemng expecta@ons 38 Categorize and contextualize known threats, streamline response Provide addiHonal layer of automated detecHon Preventative Controls Signature-based detecHon Undetected Threats Threat data & intel feeds Internal analysis Reality Preventative Controls   Threat data & intel feeds   Signature-based detecHon Undetected Threats Expectation Tell you what’s normal in your own environment Exceed the beneﬁts of well-implemented preventaHve controls Close the gap of undetected threats ...but it cannot... High-quality threat data and intelligence can help you…

Slide 39

Slide 39 text

Looking inward to hunt Derive intelligence from what’s “normal” Build repeatable analysis tasks Combine with automated use of IOCs and threat data More is not always beLer! Easy to overwhelm yourself Take on discrete, high-value data sets one at a Hme 39

Slide 40

Slide 40 text

Aligning to the aUack lifecycle 40 What are the "lowest common denominators" across targeted intrusions? What readily-available evidence do they leave behind? What easily-observable outlier condiHons do they create? Conduct Reconnaissance Steal Creden@als & Escalate Privileges Move Laterally Establish & Retain Persistence

Slide 41

Slide 41 text

Example: Hun@ng for Duqu 2.0 41 “In addi@on to crea@ng services to infect other computers in the LAN, aUackers can also use the Task Scheduler to start ‘msiexec.exe’ remotely. The usage of Task Scheduler during Duqu infec@ons for lateral movement was also observed with the 2011 version...” Source: https://securelist.com/files/2015/06/The_Mystery_of_Duqu_2_0_a_sophisticated_cyber espionage_actor_returns.pdf

Slide 42

Slide 42 text

What was the shared IOC? 42

Slide 43

Slide 43 text

How could we do beUer? 43 We could just add a speciﬁc TaskItem to the IOC... …but what about other variants? How can we ﬁnd evidence of other malicious acHvity that abuses the same (incredibly common) lateral movement technique?

Slide 44

Slide 44 text

Example: Lateral command execu@on 44 Scheduled Tasks WinRM & PowerShell PsExec Attacker Methods Other forensic artifacts E Logon & service events Process history Sources of Evidence Accounts used Executed commands, dropped files, etc. Time & frequency Where? When? What? Who? Source & target systems Analysis Criteria Assess outliers

Slide 45

Slide 45 text

Resul@ng stack analysis 45

Slide 46

Slide 46 text

Resul@ng stack analysis 46

Slide 47

Slide 47 text

Resul@ng stack analysis 47

Slide 48

Slide 48 text

Resul@ng stack analysis 48

Slide 49

Slide 49 text

For addi@onal examples 49 “HunHng in the Dark” hLps://speakerdeck.com/ryankaz Includes coverage of: More task analysis ShimCache and process history Service Events WMI event consumers AlternaHve authenHcaHon mechanisms

Slide 50

Slide 50 text

#RSAC Closing thoughts and takeaways

Slide 51

Slide 51 text

PlaSorms MISP  hLp://www.misp-project.org Hubs and exchanges Facebook ThreatExchange  hLps://threatexchange.t.com Standards CybOX 3.0 refactoring and simpliﬁcaHon Evolving standards & plaoorms 51

Slide 52

Slide 52 text

Few eﬀorts to-date - this is diﬃcult! Threat Intelligence Quo@ent Test (Hq-test) StaHsHcal analysis of IPs and domains in threat feeds References:  hLps://github.com/mlsecproject    hLps://defcon.org/images/defcon-22/dc-22-presentaHons/Pinto- Maxwell/DEFCON-22-Pinto-and-Maxwell-Measuring-the-IQ-of-your- threat-feeds-TIQtest-Updated.pdf Quan@ta@ve assessment of threat feeds 52

Slide 53

Slide 53 text

Ask your threat feed vendor 53 Where’s the intel coming from? Professional services Managed security services Partners Honeypots “Open source” data gathering Auto-generated sandbox data  What’s the breakdown of observable types? What QC is in place? Test-cases DocumentaHon Spot-checking

Slide 54

Slide 54 text

Maximize your IOCs & threat data 54 Where are your gaps in endpoint & network visibility? Can you expand the scope of data made available for endpoint IOC matching in your environment? Are your tools and threat data sources fully compa@ble? How quickly are you consuming new threat data? At what scale?

Slide 55

Slide 55 text

Even the best sources of threat data will never keep pace with emerging aLacks Know your network above all Invest in aLack surface reducHon and “hygiene”. It really does make a diﬀerence. Have your investments made you more secure? 55

Slide 56

Slide 56 text

SESSION ID: Thank you! AIR-F03 Ryan Kazanciyan Chief Security Architect Tanium  @ryankaz42