@night 1803 access accessdata active directory admissibility ads aduc aim aix ajax alex levinson alissa torres amcache analysis anjp anssi answer key antiforensics apfs appcompat appcompatflags applocker april fools argparse arman gungor arsenal artifact extractor attachments attacker tools austin automating automation awards aws azure azuread back to basics backstage bam base16 best finds beta bias bitcoin bitlocker blackbag blackberry enterprise server blackhat blacklight blade blanche lagny book book review brute force bsides bulk extractor c2 carved carving case ccdc cd burning ceic cfp challenge champlain chat logs Christmas Christmas eve chrome cit client info cloud forensics command line computer forensics computername conference schedule consulting contest cool tools. tips copy and paste coreanalytics cortana court approved credentials cryptocurrency ctf cti summit cut and paste cyberbox Daily Blog dbir deep freeze defcon defender ata deviceclasses dfa dfir dfir automation dfir exposed dfir in 120 seconds dfir indepth dfir review dfir summit dfir wizard dfrws dfvfs dingo stole my baby directories directory dirty file system disablelastaccess discount download dropbox dvd burning e01 elastic search elcomsoft elevated email recovery email searching emdmgmt Encyclopedia Forensica enfuse eric huber es eshandler esxi evalexperience event log event logs evidence execution exfat ext3 ext4 extended mapi external drives f-response factory access mode false positive fat fde firefox for408 for498 for500 for526 for668 forenisc toolkit forensic 4cast forensic lunch forensic soundness forensic tips fraud free fsutil ftk ftk 2 full disk encryption future gcfe gcp github go bag golden ticket google gsuite guardduty gui hackthebox hal pomeranz hashlib hfs honeypot honeypots how does it work how i use it how to howto IE10 imaging incident response indepth information theft infosec pro guide intern internetusername Interview ios ip theft iphone ir itunes encrypted backups jailbreak jeddah jessica hyde joe sylve journals json jump lists kali kape kevin stokes kibana knowledgec korman labs lance mueller last access last logon lateral movement leanpub libtsk libvshadow linux linux forensics linux-3g live systems lnk files log analysis log2timeline login logs london love notes lznt1 mac mac_apt macmini magnet magnet user summit magnet virtual summit mari degrazia mathias fuchs md viewer memorial day memory forensics metaspike mft mftecmd mhn microsoft milestones mimikatz missing features mlocate mobile devices mojave mount mtp multiboot usb mus mus 2019 mus2019 nccdc netanalysis netbios netflow new book new years eve new years resolutions nominations nosql notifications ntfs ntfsdisablelastaccessupdate nuc nw3c objectid offensive forensics office office 2016 office 365 oleg skilkin osx outlook outlook web access owa packetsled paladin pancake viewer path specification pdf perl persistence pfic plists posix powerforensics powerpoint powershell prefetch psexec py2exe pyewf pyinstaller python pytsk rallysecurity raw images rdp re-c re-creation testing reader project recipes recon recursive hashing recycle bin redteam regipy registry registry explorer registry recon regripper remote research reverse engineering rhel rootless runas sample images san diego SANS sans dfir summit sarah edwards saturday Saturday reading sbe sccm scrap files search server 2008 server 2008 r2 server 2012 server 2019 setmace setupapi sha1 shadowkit shadows shell items shellbags shimcache silv3rhorn skull canyon skype slow down smb solution solution saturday sop speed sponsors sqlite srum ssd stage 1 stories storport sunday funday swgde syscache system t2 takeout telemetry temporary files test kitchen thanksgiving threat intel timeline times timestamps timestomp timezone tool tool testing training transaction logs triage triforce truecrypt tsk tun naung tutorial typed paths typedpaths uac unc understanding unicorn unified logs unread updates usb usb detective usbstor user assist userassist usnjrnl validation vhd video video blog videopost vlive vmug vmware volatility vote vss web2.0 webcast webinar webmail weekend reading what are you missing what did they take what don't we know What I wish I knew whitfield windows windows 10 windows 2008 windows 7 windows forensics windows server winfe winfe lite winscp wmi write head xboot xfs xways yarp yogesh zimmerman zone.identifier

What did they take when they left? Part 3 - Where did it go and what did they take?

Howdy Reader,

In the prior posts in this series we've talked about how to determine if our suspect burned a CD and then what programs he ran before he left. In this post we will discuss ways our suspect could have taken out of the system and how we can find out what they took. There are several options available to someone who wants to take data depending on the environment they are in. They could burn a cd (which we talked about before), send out an email via their companies servers, send out an email via a webmail service, copy the data to a external drive, copy data to another network location or upload data to a web based file hosting service are the most common. Any combination of these methods can be used so we have two challenges:

  1. We need to determine what method or methods they used to take data from the system
  2. We need to determine what files they took using these methods


Method 1 – Email via corporate servers

  1. How did they take data from the system

How we are able to recreate activities will depend on the email system they have in place. Typically a suspect using this method will be emailing files and forwarding messages to their personal account. The sophistication of the suspect is pretty low in this method but occasionally even these suspects will delete these messages. Every email system has its own particular quirks for the recovery and analysis of messages, enough so that we will have separate posts to deal with each one at a later date. In most cases if a user has deleted the email messages we have three sources of recovery:

  1. Recovery of deleted messages from the local system


    When an email is sent from a suspect's system it is typically saved in the local and possible the server side 'sent' box. How we recover the message depends on how much time has passed since the user deleted the message, what other activity has occurred on the system since that time and whether or not the user purposefully attempted to push the email out of the local email archive.


    i. Messages recovered from the application database structure


    Most email systems have an accompanying client side application (groupwise, outlook, notes) that store the emails they receive into a database like structure. Typically when these emails are deleted they remain within the database like structure until they are flushed out (such as using the outlook compact and repair function). Until that occurs then most of the major commercially available forensic tools (Paraben's email examiner, Encase Forensic, Forensic Toolkit) can recover these deleted messages if they support the file format. If you are looking for a free option you might try the steps outlined here but that could become quite burdensome if you have a large number of messages to recover.

    ii. Messages recovered from the unallocated space

    Depending on the email client used the data will either be in plain text in the unallocated space for easy carving or it may be stored in some binary format such as the case with deleted messages from most outlook pst's. Outlook pst's support a data encoding format known as outlook compressible encryption. When this data is pushed out of the pst structure either over time or through the operation of a compact and repair the message will then exist in the unallocated space but be encoded in OCE. The only tool I know of currently that can search for OCE data in the unallocated space is encase. However the temporary files made by Microsoft Word, which has been the default editor for emails inside of Outlook since at least 2003, are recoverable as plain or Unicode text in the unallocated space.

  2. Recovery of deleted messages from the live server


    Most email servers don't flush out emails from their database when the user deletes them. If you or your IT contact has administrative access to the email server you can ask them to recover recently deleted messages from the live server. In exchange there is what has been called a 'dumpster' functionality that will retain emails for a definable set of days (default of 14 I believe). In groupwise you can recover deleted messages using tools like network email examiner or the salvage utility. In lotus notes you could either check to see if the 'soft delete' option was set and for how long it will retain messages or again use commercial tools. There are not many (any?) open source or free tools for dealing with enterprise email server solutions.


    If the email server has flushed out the message recovering the message from the unallocated space becomes more difficult since I don't know the encoding of the message. If you are dealing with a sendmail/imail server like Iplanet you can recover the messages in the unallocated space through regex searches for headers.


  3. Recovery of deleted messages from backup


    When all else fails you can go to backup, usually tape. Restore the email database for the relevant time intervals to hopefully capture the email it was not purged the same day it was deleted, not very typical. You can restore the tape with either the native software (netbackup, backupexec, arcserve, etc…) or with software that supports your tape format (Ontrack Powercontrols, Quest Recovery Manger for Exchange). Then you will need to access the email database either with the native email server in a recovery environment or with a tool that supports reading the database directly (network email examiner, Ontrack Powercontrols, Quest Recovery Manger for Exchange). Once you've done this you can see if the emails you are looking for exist. This is a very detailed topic on the variances of backup software for the forensic examiner and data available, I plan to make separate posts about each of the major backup formats and tape examination techniques.


  4. What did they take


    Now that we have the email messages we can see what was forwarded and attached to those messages to make a list of those files, email addresses and subject matters. In my job I have no knowledge of internal matters so I have to hand over this data to counsel so they can determine what that was sent to themselves contained relevant data.

Method 2 – Email via webmail

  1. How did they take data from the system


    The first step I would perform is examining the internet history of the user. If they did not clear out their internet history then you can look through it for webmail websites they have been visiting. The majority of webmail services are either free or in the case of a hosted website they own will be using a free webmail package (like squirrel mail). We can use these sites to get unique keywords they display in either the html source of the page or in the rendered page itself to identify specific pages of interest.


    The nature of how we send and receive data to websites dictates what is and is not recoverable. We can recover pages they have viewed, such as the contents of a mailbox/folder . We can see messages received the form to write an email but not the email they wrote. So we can look for the most recent views of their inbox for emails they have sent to themselves with files attached. Many people have said that gmail no longer leaves cached emails for us to recover. This is not in fact true, the move to the ajax model means we no longer have a separate cached page for every email viewed, instead we have to look at the virtual memory (pagefile.sys in windows, the swap partition in unix based systems) to find these email remnants.


  2. What did they take


    Most webmail sites will separately make a pop up or page for attaching files and giving notification of successfully attached files. This is good for us as we can recover each notification page and make a list of what files they sent themselves. In addition some suspects are nice enough to open each email they forwarded to themselves to just make sure they got their files.


There are three more methods to detail, but I don't want to wait another day to get this up. To be continued in part 4.



Post a Comment

  1. Great info, and nice how you've organized it. Keep up the useful posts.

    ReplyDelete
  2. Great info, and nice how you've got it organized. Re your first blogs, yeah, there are more of us out here, wading thru digital trenches.

    ReplyDelete
  3. Great info indeed. How about uploading via file sharing website like MegaUpload, would we be able to identify if the user has successfully uploaded a file? Please advise. Thanks.

    ReplyDelete

[blogger][disqus][facebook][spotim]

Author Name

Contact Form

Name

Email *

Message *

Powered by Blogger.