Since this is a triage question, the goals are to get as much info in as short a time frame as possible. the idea is to cast as wide a net into a computers data as possible and intelligently look at that data for indicators of badness. |
|
i am not going to include every key, subkey, querying lastwrite times/value and how to decode things from the registry or otherwise mundane details. these steps should be automated as much as possible for consistency and efficiency anyways. |
|
the first thing i would do is interview management at the company to find out what kind of usage policies they have: are employees allowed to install whatever software they want? any access controls? who has rights to where? What kind of database was my customers stored in? who has rights to that database? and so on |
|
i would also ask management who their competitors are and then locate their web sites, domain names, etc. |
|
once i had the basic info i would assemble a list of relevant keywords (competitor names, relevant file extensions, etc). i would also look specifically for tools that can be used to connect to the database server and interact with it. this of course changes depending on which database it is (mysql i may look for putty or other terminal programs, oracle = the oracle client, sql server = that client, LinqPad, etc.) |
|
with that basic info in hand i would triage each computer follows: |
|
1. collect basic system information such as when windows was installed, last booted etc. |
|
2. check running processes for things like cloud storage (dropbox, skydrive, teamviewer, other remote access tools) |
|
3. look for any out of the ordinary file shares on the computer that can be used to access the computer from elsewhere on the network |
|
4. check MRU keys for network shares, both mapped and accessed via command line |
|
5. dump DNS cache and compare against keyword lists |
|
6. dump open ports and compare against a list of processes of interest. |
are any remote access tools running? file sharing? |
|
7. Look to see what data, if any, is present on the clipboard. are there any suspicious email addresses or the text of an email or other document? what about a file or a list of files? |
|
8. unpack all prefetch files and see what applications have been executed recently (certainly within the last 30 days, but expand as necessary). again we key in on processes of interest, etc |
|
9. look at all the installed applications on a computer and specifically those installed within the last 30 days |
|
10. dump a list of every USB device ever connected to the machine including make, model and serial #. also reference, when available, the last inserted date of the device. cross reference this list with any issued thumb drives the company provided from interviews. make a note of any drive letters devices were last mounted to. also process and cross reference setupapi.log for devices connected within the last 30 days. |
|
11. dump web browser history for IE, FireFox, Chrome, and Safari and look for keywords, competitor URLs, etc. hone in on last 30 days, but look for keywords thru entire history in case things were initiated previous to the data being exfil'ed. look for hits against cloud storage, VNC, and similar. |
|
12. dump web browser search history including google, yahoo, youtube, twitter, social networks, etc and again filter by last 30 days with keyword hits across all date ranges. Also look for references to file activity such as file:///D:/somePath, etc. |
|
13. dump passwords for browsers (all of them), mail clients, remote access tools, network passwords (RDP, etc). are any webmail addresses saved by the browsers? |
|
14. dump keys from registry including CIDSizeMRU, FirstFolder, LastVisitedMIDMRU, LastVisitedMIDMRULegacy, MUICache, OpenSavePidlMRU, RDP sessions, RecentDocs, TypedPaths, TypedURLs, UserAssist, appcompatcache and of course ShellBags. all of these keys should be checked for keyword hits as before. specifically, look for any USB |
|
15. Look for instant messaging programs and chat history for skype to include who they are talking to, if any files were xfered, and so on. |
|
16. look for any p2p programs that could have been used to xfil data. |
|
17. search the file systems for such things as archives, shortcut files (lnk), evidence eliminator type programs, drive and file wiping programs, etc. cross reference any lnk files with paths used by USB devices and shellbags to get an idea of what kinds of files were kept on any externally connected devices. look inside any archives found (zip, rar, tar, 7zip, etc) for any keywords of interest (like a text file containing my customers). filter based on MAC dates for files and of course look for keyword hits. |
|
18. look at event logs for relevant entries (what is relevant would be determined by how the computers are configured. what kind of auditing is enabled by the network admins, etc). things like remote access and logins, program execution, etc would be key here. |
|
19. time permitting, and based upon the results from above, use a specialized tool to unpack restore points and look for files as outlined above (lnk files, programs installed, etc) |
|
20. look in the recycle bin for files (hey, ive worked plenty of cases where the incriminating evidence was in there!) |
|
21. dump ram and run a quick "strings" against the binary, then look for keywords. going crazy with volatility is beyond triage, so this will suffice. |
|
depending on where the database lives i would triage that system in the same way (if windows based) but if its mysql on linux or something i would review bash history files, sign ins, FTP logs, etc for signs of data being ex-filed. i would look at the database log files for logins and, if available, sql statements executed, errors, etc from the last 30 days. |
|
finally i would ask about and review any web proxy logs or other logging systems the company has to look for suspicious activity. |
|
|
all of this data would be automatically added to a timeline that could then be used to further narrow in on interesting periods of activity on each system. |
|
with all the data collected i would want to start looking for default export names or extensions, keyword hits, and whatnot. the machines that have more indicators would go up on my list of machines to want to image. machines with little to no indicators would be removed from consideration. |
|
|
ShellBags are going to be a key artifact in this case because they contain sooo much good data on Win XP. what other files were on any external devices connected to the systems? do i see the presence of "hacking" tools, ftp clients, putty, etc? are there folders or files indicative of my data or any of my competitors? |
|
|
|
32GB is more than enough space to triage all the computers found at the business as there isnt a ton of need to copy files off the computer. |
|
|
|
now all those steps are a heck of a lot to do manually (and several of them would be near impossible to do by hand), so in my case i would just run osTriage on each computer and it would pull all that info (and more) in a few seconds. add a bit of time to review the results and i would know which machines i wanted to image for a more thorough review. |
|
with that info in hand i would most likely already know who exfi'led the data, but i would still request an image be made of each machine where suspicious activity was found. |
|
(all of those steps could be further unpacked, but since this is a triage based funday question my response is kept in true triage style, fast and just enough of a deep dive to hone in on computers of interest). |