Memory Forensics for Incident Response

  • View
    3.837

  • Download
    2

Embed Size (px)

Text of Memory Forensics for Incident Response

  1. 1. Jared Greenhill RSA IR @jared703 Memory Forensics for IR Leveraging Volatility to Hunt Advanced Actors
  2. 2. 2 Copyright 2015 EMC Corporation. All rights reserved. #Bio Member of RSAs IR Team for 2+ years Former malware analyst at US-CERT M.S. Computer Forensics from George Mason University Teaching Grad Level Memory Forensics Course Spring 16 CFRS.GMU.EDU
  3. 3. 3 Copyright 2015 EMC Corporation. All rights reserved. #Agenda Memory Forensics & IR Criticality Case Intro, Overview and Discussion Memory Analysis Volatility Usage and APT Artifacts Pivot from Memory to Disk Based Artifacts Case Summary / Overall Findings / Additional Work
  4. 4. 4 Copyright 2015 EMC Corporation. All rights reserved. #Memory Forensics & IR Criticality Memory triage can provide timely answers in IR & Intrusions. Memory acquisition usually fast due to size The goal is to quickly determine if badness occurred on a host.
  5. 5. 5 Copyright 2015 EMC Corporation. All rights reserved. #Memory Forensics & IR Criticality If yes, what type of badness? Can we map it to our initial detection? Network Hunting, IDS/IPS event, AV hit, 3rd party notification Is there Malware? If so, Commodity or Targeted?
  6. 6. 6 Copyright 2015 EMC Corporation. All rights reserved. #Memory Forensics & IR Criticality Why is this case so critical to IR? Speed of initial triage One memory image broke things open Discovery of critical indicators to sweep across the environment
  7. 7. 7 Copyright 2015 EMC Corporation. All rights reserved. #Memory Forensics & IR Criticality Volatility for IR Specifically: ShimCache parsing Dumping scheduled jobs & artifacts Timelining ($MFT/Registry/Process creation) Dumping Malware from memory
  8. 8. 8 Copyright 2015 EMC Corporation. All rights reserved. #Case Intro In July 2013 a global Non- Profit reached out to us about a FBI notification they received. We asked for Firewall Logs and/or a memory image for a related host if available. We quickly went from knowing little to understanding much more through Memory Forensics and Volatility. Discover New compromises Notification July 2013 Firewall Log Review Develop Network & Host based Signatures Memory Analysis Malware Analysis Host Based Forensics
  9. 9. 9 Copyright 2015 EMC Corporation. All rights reserved. #Memory Forensics & IR Criticality Memory can provide a wealth of critical data: Network Connections Active connections Critical to collect memory when system is on the network Residual connections sometimes exist Malware Injected into a process Can exist in both memory and on disk $MFT can provide context
  10. 10. 10 Copyright 2015 EMC Corporation. All rights reserved. #Case Overview FBI notification came in Early July 2013 (not their 1st). Data exfiltration was likely coming from an IP in their IP space. June 2013 was the timeframe provided.
  11. 11. 11 Copyright 2015 EMC Corporation. All rights reserved. #Overview & History A co-worker and myself reviewed the ASA log structure and greping for outbound data. We discovered ~1 GB of data leaving outbound to 206.205.82.9 through two ~.5GB transactions on June 13th 2013, originating from a suspect internal host
  12. 12. 12 Copyright 2015 EMC Corporation. All rights reserved. #Firewall Log Review grep 'bytes [0-9]{9} SyslogFW.log
  13. 13. 13 Copyright 2015 EMC Corporation. All rights reserved. #Overview & History Shortly after, the client provided memory in the form of a .VMSN file for the Host after our FW log analysis confirmed the FBIs notification. Luckily Nir Izraelis VMSNparser had recently been adopted for the Beta version of Volatility 2.3. in May 2013
  14. 14. 14 Copyright 2015 EMC Corporation. All rights reserved. #Initial Analysis Steps Determine the Server type for correct profile use. Volatility is profile based as data structures vary through OS versions. vol.py f host.raw imageinfo Suggested Profile(s) : Win2003SP0x86, Win2003SP1x86, Win2003SP2x86 (Instantiated with WinXPSP2x86) Image date and time : 2013-07-17 14:51:22 UTC+0000 Image local date and time : 2013-07-17 10:51:22 -0400 Client indicated the host was a Win2k3 SP2 server. Confirmed w/Imageinfo
  15. 15. 15 Copyright 2015 EMC Corporation. All rights reserved. #Initial Analysis Continued Everyone has investigative techniques/bias. I started by looking for Interesting Processes and Network communications related to the 6/13/13 exfil date. vol.py -f host.raw --profile Win2003SP2x86 yarascan --wide -- yara-rules=206.205.82.9 vol.py -f host.raw --profile Win2003SP2x86 pslist Most processes were started on 6/25/13, indicated it could have been rebooted then. The Exfil date was 6/13/13, so we could have lost things in memory during the reboot which likely occurred on 6/25/13 based on process start times. Vol.py -f host.raw --profile Win2003SP2x86 sockets vol.py -f host.raw --profile Win2003SP2x86 connections
  16. 16. 16 Copyright 2015 EMC Corporation. All rights reserved. #Network Connections? Connections were internal/RFC1918, except one - 198.55.120.205:80 connection was legitamate.
  17. 17. 17 Copyright 2015 EMC Corporation. All rights reserved. #Triaging ShimCache ShimCache (AppCompactCache/AppCompatability Reg keys) data resides in the SYSTEM hive Records last execution time (depends on OS) file path, size, last modified time Win XP Registry Key: HKLMSYSTEMCurrentControlSetControlSession ManagerAppCompatibilityAppCompatCache Win 2003/Vista/Win7/Server 2008 Registry Key: HKLMSYSTEMCurrentControlSetControlSession ManagerAppCompatCacheAppCompatCache vol.py -f host.raw --profile Win2003SP2x86 shimcache http://www.mandiant.com/library/Whitepaper_ShimCacheParser.pdf
  18. 18. 18 Copyright 2015 EMC Corporation. All rights reserved. #Triaging ShimCache: APT Problems? It appeared that APT tool activity went back to at least July 2012 with the files set.exe, Gs.exe & MyWce32.exe. Last Modified Path ------------------------------ ---- 2008-11-02 05:02:34 UTC+0000 ??C:WINDOWSaddins1.exe 2010-12-08 10:45:00 UTC+0000 ??C:WINDOWSaddinsgsec1.exe 2010-04-27 14:04:06 UTC+0000 ??C:WINDOWSaddinspsloglist.exe 2010-04-27 15:04:04 UTC+0000 ??C:WINDOWSaddinsPsLoggedon.exe 2010-04-27 15:04:04 UTC+0000 ??C:WINDOWSaddinsPsList.exe 2010-04-27 15:04:06 UTC+0000 ??C:WINDOWSaddinsp.exe 2011-12-08 19:42:16 UTC+0000 ??C:WINDOWSaddinscsss.exe 2011-06-24 20:42:18 UTC+0000 ??C:WINDOWSaddinsAIO_.exe 2011-08-25 21:07:10 UTC+0000 ??C:WINDOWSaddinslssas.exe 2011-08-25 23:29:34 UTC+0000 ??C:WINDOWSaddinssumlist.exe 2012-12-28 15:12:00 UTC+0000 ??C:WINDOWSaddinscssrs.exe
  19. 19. 19 Copyright 2015 EMC Corporation. All rights reserved. #Triaging ShimCache: Contd Redacted_2012_92013-3-27.log file a quick Internet search of the ORG/filename revealed that this person was their China Director. Last Modified Path ------------------------------ ---- 2008-11-02 05:02:34 UTC+0000 ??C:WINDOWSaddins1.exe 2012-05-17 18:31:32 UTC+0000 ??C:WINDOWSaddinsFileTime.exe 2012-07-12 16:49:32 UTC+0000 ??C:RECYCLERgs.exe 2012-08-11 05:08:14 UTC+0000 ??C:WINDOWSaddinswce32.exe 2012-08-28 19:17:52 UTC+0000 ??C:WINDOWSaddinsx.txt 2012-10-17 05:24:36 UTC+0000 ??C:WINDOWSaddinsMyWce32.exe 2013-01-09 12:47:41 UTC+0000 ??c:set.exe 2013-03-11 14:10:10 UTC+0000 ??C:F5mm.exe 2013-03-26 18:09:37 UTC+0000 ??C:WINDOWSaddinsredact_2012_9--2013-3-27.log 2013-03-26 18:10:42 UTC+0000 ??C:WINDOWSaddinserr.log 2013-03-28 21:30:25 UTC+0000 ??C:WINDOWSaddinsx.log 2013-03-28 19:34:51 UTC+0000 ??C:WINDOWSaddinslog.log
  20. 20. 20 Copyright 2015 EMC Corporation. All rights reserved. #Looks like APT At this point we gave the client our initial triage findings: FW logs confirming the FBIs exfil notification: ~1 GB data went out the door on June 13, 2013. ShimCache results: Likely APT tool use based on suspect filenames/locations. Likely exfil w/China Directors name in the filename. Likely active since at least July 2012, possibly since 2008. The client engaged us for IR 3 months later (Oct 2013). I kept focusing on this memory sample
  21. 21. 21 Copyright 2015 EMC Corporation. All rights reserved. #Scheduled Jobs in Memory? Schedlgu.txt Windows Task Scheduler output log from at.exe The output file lists the scheduled jobs executed on a system. Located at C:WindowsTasksSchedlgu.txt Reviewing this file is a quick way to see if jobs executed on a host.
  22. 22. 22 Copyright 2015 EMC Corporation. All rights reserved. #Scheduled Jobs & APT Actors Use the Handles plugin to find the virtual offset of Schedlgu.txt: vol.py -f host.raw --profile Win2003SP2x86 handles | grep -i schedlgu.txt Offset 0x8a744028 1156 0x334 0x12019f File DeviceHarddiskVolume1WINDOWSTasksSchedlgu.txt Use the virtual offset with the filescan plugin to find the physical offset. vol.py -f host.raw --profile Win2003SP2x86 filescan | grep -i schedlgu.txt 0x0a744028 1 1 RW-r-- DeviceHarddiskVolume1WINDOWSTasksSchedLgU.Txt
  23. 23. 23 Copyright 2015 EMC Corporation. All rights reserved. #Scheduled Jobs Contd The physical memory offset of SchedLgU.Txt in memory. We can now use the dumpfile plugin to dump Schedlgu.txt from memory. vol.py -f host.raw --profile=Win2003SP2x86 dumpfiles -Q 0x0a744028 D. This command dumps the Schedlgu.txt (file.None.0x8a7385e0.dat) file from the physical location 0x0a744028 to the working directory. The file sx86.exe was executed successfully on 6/25/13 via AT1.job.
  24. 24. 24 Copyright 2015 EMC Corporation. All rights reserved. #Scheduled Jobs Contd Additional review of Schedlgu.txt yielded more successful file executions and some failures: Set.exe on 1/9/13 @ 9:01AM Successfully executed Log.bat on 9/12/12 @ 2:27AM Failed.
  25. 25. 25 Copyright 2015 EMC Corporation. All rights reserved. #Sc