DCART - CyberWeek TRACK 2...§ python_log\python_log.dcart Collection §Performed on completed trace...
Transcript of DCART - CyberWeek TRACK 2...§ python_log\python_log.dcart Collection §Performed on completed trace...
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!