M a r k M a g e r , S e n i o r I n f o r m a t i o n S e c u r i t y E n g i n e e r @ E l a s t i c

DCART:Decoup led Components fo r Au tomated Ransomware Tes t i ng

h t t p s : / / c y b e r w e e k . a e

2

About me

Mark Mager• Senior Information Security Engineer @ Elastic• Reverse engineering• Malware analysis• Software development• Ransomware protection research

• Previous talks on decryptor development and ransom note detection

• Twitter - @magerbomb

3

Table of Contents• Ransomware Overview• Typical testing approach• Improved testing approach• Event data collection• Analysis• Demo• Automation• Limitations• Future Work• Conclusion

4

Ransomware Overview

• Malicious software that degrades / denies access to data• Commonly will encrypt individual files throughout file system

• Other types are out of scope for this research

• Common file extensions are typically targeted• PDF, DOC, XLS, TXT, PDF…

5

Common File Modification Patterns

• Overwrite• sample.doc => sample.doc

• Overwrite and rename with same extension• sample.doc => sample.encrypted.doc

• Overwrite and rename with different name / extension• sample.doc => encryptedfile1234.teslacrypt

• Delete original, create new encrypted file w/ same extension• DELETE sample.doc | CREATE 1234.encrypted.doc

• Delete original, create new encrypted file w/ different extension• DELETE sample.doc | CREATE 1234.encrypted

6

Behavioral Ransomware Detection – Typical Approach

• Agent running in the background• Collect data on all relevant file events

• ETW or minifilter• Analyze each event for anomalies• Generate an alert once activity is deemed malicious

7

Behavioral Ransomware Detection - Testing

• Start agent• Detonate ransomware sample• Monitor / log debug output• Determine if sample will be detected

8

Behavioral Ransomware Detection – Testing Limitations

• How long?• Time or number of files?

• Lack of repeatability• Non-deterministic• Environment can change each time

• Background processes / services• Overhead of retesting

• Revert, revert, revert…• Manual process• If codebase changes, time to retest!

9

Improved Testing Approach

• Event traces!• Refined event schema• Detonate ransomware once

• Generate event trace• No need to repeat same test

• Feed event trace into offline analysis component• Produce score pertaining to anomalous activity

• Filter out extra noise where necessary• Refactor / adjust analysis codebase as needed• Save event traces for automated re-testing

10

Proposed POC Framework

§ In near real-time§ Performant

Listen for events

§ Process§ Operation§ Path§ Contents

Collect data

§ Performed on completed trace files

§ Automation*

Analyze data

11

Event Trace Format

• Objective: collect and store bare minimum amount of data needed• Additional data points will be derived during analysis

• Process• Operation• Path(s)• Contents

12

Event Data Collection Approaches

• watchdog, fsmonitor, etc.• ReadDirectoryChanges API does not provide PID

• Process Monitor• PML format is undocumented• Can’t read a direct stream of events

• Stream stored in virtual memory by default• Backing files in PML format

• Sysmon• Support for capturing file create events• But no support for file write events

13

Event Data Collection Approaches

• File access auditing• No external components required• Too noisy• Cumbersome setup• Slow

• ETW• pywintrace• fibratus• pywindowsthingies• Inconsistent results

• Could not obtain an accurate stream of all relevant events

14

Event Data Collection Approaches

• Minifilter driver• Most performant• Most complex and unstable• Risk of failure: HIGH

15

Updated POC Framework

§ Log events to disk• Process• Operation• Path(s)

§ driver_log\driver_log.dcart

§ NO additional file reads

Minifilter Driver

§ Tails the driver log§ Obtains file

contents§ Serialize event

data + contents§ Write serialized

data to disk§ python_log\python_log.dcart

Collection

§ Performed on completed trace files

Analysis

16

Analysis Objectives

• Read in event trace file• Deserialize events in order• Analyze each event as it is deserialized• Produce a score indicating likelihood of malicious activity based off

of analysis of each event• Compare score to a predetermined threshold• Output score and final determination

17

Initial Analysis Metrics

• Entropy• Short definition

• Measurement of randomness of the data• Entropy ranges

• Encrypted data is typically very high• Compressed data (ZIP, 7z, docx) will be high• ASCII data (txt, html, css) will be lower

• Looking for general trend of numerous files exceeding their typical ranges

18

Initial Analysis Metrics

• Header• Common extensions with standard formats provide high value• Do first x bytes match known magic byte sequences?

19

Initial Analysis Metrics

• Renames• If file is renamed, look at its previous extension…

• test.docx => test.ransomextension• Evaluate contents with regards to previous extension

20

DEMO

21

Automation

• Store all traces in a central repository• Periodically run the latest analysis codebase against all traces• Track results over time to ensure no changes in efficacy or

22

Limitations

• Need to adapt analysis to cover different techniques• Spawning multiple processes for encryption

• LockerGoga• Deleting files and writing them to a single archive

• Rarely seen• Skipping the first X bytes before encrypting

• Not very prominent• Encryption that does not introduce higher entropy

• Rarely seen• Reliance on python could lead to corrupt or interrupted event traces

23

Future Work

• Still need to post the source code on github!• Twitter: @magerbomb

• Clean up the driver code• Needs A LOT of work

• Speed up performance on collector script• Process protection for collector• Log exfiltration• Automated method for pulling down magic bytes• Event trace sample corpus• Parse CSV / XML from procmon

24

Conclusion

• Decoupling components allows for maximum flexibility• As long as event data format remains the same…

• Archive event traces for automated testing and validation• Detonate only once!

25

Thanks!