an academic's view to incident response

An academic’s view toincident response

Mar�n Schmiedecker, fr333k

OverviewChallengesDo’s and Don’tsWhat can I do to be prepared?peekaTorrent

2/64

Mar�n who?$whoami:

• Mar�n Schmiedecker• researcher at SBA Research, Vienna• digital forensics!• online privacy & network security• @Fr333k

3/64

https://twitter.com/Fr333k

Goals of this talk• introduc�on to incident response• (past &) current challenges• talk about things that work• also, how things can blow up in your face

4/64

What is Incident Response?Companies fail to detect intrusions:

• Ashley Madison• Hacking Team• RSA• Google, Opera�on Aurora• (Stuxnet)

5/64

What is Incident Response?

6/64

What is Incident Response?

Things like:• something happened, no clue what exactly• got an alert from some box• this is weird ...

7/64

What is Incident ResponseGoals:

• react to security-related events• containment, preven�on

Ideally:• Live forensics under �me preassure• move faster than the a�acker• remotely, without the need to physically get there

8/64

What is Incident Response

9/64

Context of Academia

Academia

10/64

Academia

11/64

Academia

Science vs. engineering:• reviewers in tough posi�on• where does one start, the other stop?• is scien�ficly published engineering a thing?

12/64

AcademiaQues�on the security narra�ves:

• evidence-based1 science?• plenty of FUD!• fast field!

but:• crea�vity!• independence!1See also Hanno’s excellent talk on this topic at 33c3 13/64

https://twitter.com/hanno/status/814190651554299904

Academia

14/64

Academia

Standards and references:• RFC 3227: Guidelines for Evidence Collec�on and Archiving• NIST SP 800-86: Guide to Integra�ng Forensic Techniquesinto Incident Response

• things like “Order of Vola�lty’, write blocker, ...

15/64

Challenges

Challenges

16/64

Challenges

Paper from 2010 by Simson Garfinkel:• “Golden Age of Digital Forensics” ended• has been: rather simple challenges• RAM, networks possible• focus on office and mul�media files

17/64

ChallengesObserved upcoming issues:

• flash storage• lack of �me (== storage sizes)• cloud• encryp�on• mul�ple devices• broader diversity

18/64

ChallengesS�ll a problem:

• storage capacity!• hash, copy, hash & hash• $$$: special hardware for that• takes ages• esp. on slow interfaces

19/64

Challenges

20/64

Challenges

Engineering efforts:• data de-duplica�on (NSRL RDS)• iden�fy file fragments, 2015 [1]• “si�ing collectors”, 2015 [2]• specific access op�miza�ons, 2016 [3]

21/64

Challenges

Is not inspec�ng everything really an op�on?• probably not!

22/64

Challenges

Encryp�on:• “Properly implemented strong crypto systems are one ofthe few things that you can rely on.”• usage is increasing• both on devices and on the wire

23/64

Challenges

S�ll:• can be bypassed• can be fingerprin�ed• also, traffic analysis2

2Recent Cisco Whitepaper on “Encrypted Traffic Analysis” 24/64

Challenges

Heterogeneity:• long tail is problema�c• rest is for the commercialworld

25/64

ChallengesCloud Forensics is a lie!

26/64

ChallengesCloud Forensics is either:

• remote access for IaaS, or• funky, non-publicly described API for SaaS

But:• both usable• APIs need fidelling• commercial tools available

27/64

Challenges

GDPR:• May 2018!• will be interes�ng!• valid consent, right of erasure & access, ...• in par�cular for larger companies

28/64

Do’s and Don’ts

Incident Response

29/64

Incident Response

30/64

Incident Response

Why RAM?• RAM has all the juicy stuff• processes, network connec�ons, ...• non-reproducible!• vola�lity is great!

31/64

Incident Response

A�erwards:• inspect machine• e.g. Sysinternal Tools• however, your milage may vary• avoid file writes!

32/64

Incident Response

33/64

Incident Response

34/64

Incident Response

35/64

Incident Response

Best-case:• one machine• no lateral movement• contained in �me

36/64

Incident Response

Reality is different!• 1TB of RAM?• en�re networks? VLANs?• 10G+ network links?• terabytes of storage?

37/64

Incident ResponseHow to get a RAM image:

• Windows: FTK Imager, WinPmem, Redline, De� Linux, ...• Linux: LiME• Mac OS: OSXPmem• all above: Rekall (GRR)• Android: LiME (adb)• iOS: WTF?

38/64

What can I do to beprepared?

Logging

Logs help tremendously!• both network and opera�on system• log remotely & aggregate!• even ne�low informa�on can help• s�ll somewhat tedious

42/64

Logging

Network:• funky hardware can do mirroring• doable on a budget, too• store as pcap or pipe into Security Onion• use stenographer from Google for 10+G

43/64

Logging

Details ma�er:• where to place the tap?• trunks? external towards the modem?• trying to find a balance ...

46/64

LoggingSystem logs:

• ELK stack: Logstash, Kibana• graylog• OSSEC• Windows Event Collector• Splunk• ...

47/64

RemoteRemote:

• physical access not always possibleGoogle GRR:

• built for incident response!• simple ques�ons: PowerShell? Linux Subsystem?

49/64

RemoteGRR deployment:

• most logic is server-side• server generates executables with config• client simply runs it, done• easy with Puppet or others• offline clients run tasks asap when online

50/64

RemoteGRR Pros:

• web GUI• scales very well• allegedly large setups with 100,000+ client machines• configura�on & roll-out easy• long-term supported project

Cons:• privacy and legal implica�ons

51/64

Remote

GRR RAM capabili�es:• remote acquisi�on of RAM• use vola�lity on live RAM• = really, really cool!

52/64

Remoteflow:

• basic work unit in GRR, asynchronous• used for client data acquisi�on• can use e.g. OS API, or Sleuth Kit for file access• wri�en in Python, stored on server

53/64

RemoteHun�ng:

• run flows on en�re or par�al fleets• also on offline machines, once back• or any subset e.g., all machines running Windows• scaleable!• clients check for new flows every 10 mins

54/64

peekaTorrent

peekaTorrent

General idea:• iden�fy file(-fragments) of no interest• leverage publicly shared hash values• more granular than files, but less than sectors

55/64

Soooo much DataWe’d like to ignore:

56/64

peekaTorrentOur approach:

• it’s all in the .torrent• copyright-free!• torrent it, check it, done!• toolchain: bulk extrator & hashdb• published last year at DFRWS 2016 [4]

57/64

peekaTorrent

58/64

peekaTorrent

BitTorrent uses chunking:• all files are concatenated• then split in chunks (=pieces)• most o�en 256kb, (observed 16kb-16mb)• depending on implementa�on and user preference

59/64

peekaTorrent

Benefits:• find deleted & even par�ally overwri�en files• fast! Really fast!• less false-posi�ves• hashdb files can be easily shared

60/64

peekaTorrentCollected data, 1/2:

• in total: 2.65 million torrent files• crawling Piratebay & KAT• mul�ple data dumps• 3.3 billion unique chunk hashes• up to 2.6 PB of data

61/64

peekaTorrentCollected data, 2/2:

• in total: 4.68 million torrent files• using 2 months of DHT crawling• really efficient• 4.5 billion unique chunk hashes• up to 6.5 PB of data

62/64

Sharing is Caring

63/64

Thx for the a�en�on!

Ques�ons?

64/64

[1] Simson L Garfinkel and Michael McCarrin.Hash-based carving: Searching media for complete filesand file fragments with sector hashing and hashdb.Digital Inves�ga�on, 14:S95–S105, 2015.

[2] Jonathan Grier and Golden G Richard.Rapid forensic imaging of large disks with si�ing collectors.Digital Inves�ga�on, 14:S34–S44, 2015.

[3] M Guido, J Bu�ner, and J Grover.Rapid differen�al forensic imaging of mobile devices.Digital Inves�ga�on, 18:S46–S54, 2016.

[4] Edgar Weippl Sebas�an Neuner, Mar�n Schmiedecker.Peekatorrent: Leveraging p2p hash values for digitalforensics. 64/64

Digital Inves�ga�ons, 18(7):149–156, 2016.

64/64