Monday, May 20, 2013

CEIC 2013 and the public beta of the NTFS TriForce

Greetings Reader!,
                              Thanks to all of you who came in person to my presentation at CEIC this morning, we had a mountain of information to show you and you kept up! We had a standing room only session and lots of great questions were asked.  I'm going to try google drive for all my hosting of session materials this time, I hope it works well!

We had a lot of fun today, we walked attendee's through data structure, four labs showing how to use the Triforce to solve four different forensic scenarios and how to use libvshadow in windows to expose shadow copies that you can extract the $MFT, $Logfile and $USNJRNL::$J from!

I'll be posting blog entries in the next two weeks giving walk throughs of each of the labs and more fun data for everyone to try out our new tool on.

Lastly, its time for the public beta of the TriForce. Please click on the link below to download it and get updated on new versions that we will be releasing as we get closer to a defined product.


Here is the link to the public beta signup:
https://docs.google.com/forms/d/1GzOMe-QHtB12ZnI4ZTjLA06DJP6ZScXngO42ZDGIpR0/viewform


Here are my slides from today:
https://docs.google.com/file/d/0B_mjsPB8uKOARWdvdGRsQlh6V1E/edit?usp=sharing

Here is a link to the labs from today:
https://docs.google.com/file/d/0B_mjsPB8uKOAekQwTmQwYWoyY3M/edit?usp=sharing

Here is a link to the demo video today:
http://www.youtube.com/watch?v=5it4EenSaok&feature=youtu.be&a

Here is a link to download the windows compiled version of libvshadow:
https://docs.google.com/file/d/0B_mjsPB8uKOAMTRrcVJWbC01YzQ/edit?usp=sharing


Saturday, April 27, 2013

NCCDC 2013 Lessons Learned


Hello readers,

For those who are not familiar, the National Collegiate Cyber Defense Competition (NCCDC) is held once a year in San Antonio, Texas. The 10 winning teams from regionals held across the united states come to San Antonio to prove their abilities against an active and aggressive attacker  while at the same time completing business objectives and dealing with simulated customers/users. It's only open to teams of college students and they train through the year and begin the qualification process in late winter.

 I am the captain of the NCCDC red team and have been for 7 years now and in those 7 years we've expanded and grown as a red team to deliver what I would like to think is a unique and compelling experience to the student teams.

On of my redteamers, Alex Levinson, posted a blog with his takeaways from being a CCDC bad guy. You can read it here: https://alexlevinson.wordpress.com/2013/04/24/ccdc-2013-red-team-feedback/

Raphael Mudge gives a more thorough accounting of this years tricks in his write up: http://blog.strategiccyber.com/2013/04/24/national-ccdc-red-team-fair-and-balanced/

I thought I would follow up as promised and give a break down that goes beyond the slide show I posted in the previous post. When I give my redteam debrief I try to collect the screenshots from around the redteam that best illustrate the mistakes that we see made during the competition. As I write this post I've realized its important that I detail more about what we do at national ccdc as a red team for those of you that have never  experienced our welcoming redteam hospitality. As the red team captain I have several duties:

1. Set the strategy for this years attacks
2. Make sure the best possible volunteers are located and brought in to bring the best possible redteam to bear against teams shown to be capable enough to survive the other redteams on their journey.
3. Restrict access to the redteam room to prevent distractions
4. The assignment of redteam members to teams
5. Make a room full of usually solo penetration testers work together and follow my plan
6. Talk to tour groups as they are escorted into the redteam room to explain how we operate, our plan and to prevent them from distracting the redteam.
7. To force communication and cooperation across the different redteam members so all student teams receive the same love.
8. To assist in cultivating custom toolkits, backdoors and tools and get communication started before the event so that everyone knows what is possible.
9. To enforce the rules of the competition to make sure no redteam member voids the provisions put in place to insure a fair contest.
10. To make sure the students meet their redteam members and that they hopefully learn something from the experience.
11. Facilitate requests between the redteam and the gold team
12. Take care of my own assigned student team in making sure I leave behind my own presents.
13. Make sure all the red team members fill out their incident submissions

In short, I have lots to do over the weekend and over the years I've learned alot from the process. I even did a talk at derbycon lat year about what I've learned: http://www.irongeek.com/i.php?page=videos/derbycon2/david-cowen-running-a-successful-red-team If you are running a red team I recommend you watch it.

So after explaining all of that, here is what I think student teams and the industry in general needs to consider when defending.
1. Reinstall is not the solution for remediation
This idea that reinstalling is the best way to recover from an intrusion is something that is not isolated to CCDC students, its a common trend in the industry. However as a CCDC competitor you are under a microscope with an attacker who knows you have to put that system back up as soon as possible to stop the bleeding.

This in the short term is true, however in the long term (as in the rest of the competition) its a faulty perception. The SLA violation you take for having your services down is the largest continual point disruption we can generate as a redteam, all other actions we take against you are one time/one point deduction activities. We bring a bag of tricks to NCCDC but we don't have the time a real world attacker does to continually generate new tools/new techniques in the span of two days. Once you detect and block our years sneaky du jour you will have effectively blocked us for the rest of the competition in a form that will scale to the rest of your systems. This means that in the long term you can keep us out, keep your systems up and your SLA violations to a minimum.

Failing to do this an reacting to the short term access will just cause the same pain to reoccur. This creates a race between you and the redteam to see who can get back into your system faster once you've restored and then take the system down again .. hopefully before the scoring engine checks for an update and you are just continually seen as being down. The SLA violation grows for each period your down, keeping you down  is a tactic not just a funny thing to do.

2. Logfiles are important and part of a bigger picture of data
Past teams were quite observant of the logs to their external services, current teams have seem to lost the art. Watching logs for the services you are providing externally and for errors and login events will help you go a long way in proactively detecting our accesses, probes and intrusions. Beyond the default logs being created for you, learn how to configure them to add additional information to capture more of what we are doing.

3. You have to understand normal to identify abnormal
This may be the most important bit of advice, and the hardest to understand. You need to have worked with an operating system long enough to know what processes, behaviors, files, activity is part of the actual operating system. The only way to do this is with practice, installing and working with different parts of the operating system and seeing what changes, gets added, gets deleted, gets executed.

Once you've learned what is normal, what accounts should own processes, what ports should be open, what ips defined services should be communicating with, etc... Our activities and especially our persistence will stand out much more. Watching a team launch TCP View while you watch them and they don't notice your connection means they are hoping for some giant flag saying 'HACKER FOUND' rather than understanding what traffic is abnormal/bad.

4. Knowing your operating system outside of a google search is important
I understand we all use google, I use google and other search engines every day. However, if to quickly manage and configure your operating system and its services you have to turn to google then you've created a problem. You should know the system and the commands well enough before competition to be able to secure your system as quickly as possible and bring up new services without us watching you google instructions for the next hour as you stumble.

5. Knowing your applications/services capabilities is the only way to secure them
If you encounter a new application either that you have to install or that you find already running the first things you need to understand are:
1. How to administer it locally
2. Does it have default credentials
3. Does it have remote administration capability
4. Search the documentation for security configuration
5. Find out where the application creates logs and error logs
6. Does it connect to another service/database

Then go back through 1-6 and lock it down. We are doing the same thing on the red team side, after all these things fail to get us in will we then start a code review/known exploit search .

6. Learn some basic Incident Response tools and techniques
Alex Levinson said something particularly insightful one evening over margaritas, "When I was a student I saw CCDC as a system administration contest, but really its an Incident Response contest". I think there is alot of truth to this, most students focus on how to install, configure and setup the operating system. Some students get interested in the red teaming aspect of it, but very few get interested into the forensics and incident response aspect of CCDC.

Forensics is what I do for a living so maybe I'm a bit bias, but the amount of grief you could save your team and the number of points you could recoup from our attacks is enough to make atleast one person of your team the incident responder. They should focus on the following:
1. Learn how to capture live memory
2. Learn how to use volatility to find possible malware
3. Learn how to scan for alternate data streams
4. Learn how to work with forensic artifacts such as prefetch and the application compatibility cache
5. Learn how to make and scan timelines for malicious activies
6. Capture network traffic and look for us

Doing this does not take as long as you think once you get good at it and in doing so you will be able to identify, detect, respond and eliminate us and our persistence.

Next year will be harder, I warn you now. I have plans blue teams and you are are the center of them. Take this blog post as a warning and be ready.


I'll be doing an AMA on reddit Monday April 29th 2013 at 1:30pm if you want ask questions or you can leave comments below.

Sunday, April 21, 2013

NCCDC 2013 Wrap up

Greetings Reader,
                     Another year and another NCCDC is done. While the red team always wins we are happy to share our victory with this years winner RIT. Every year I present a debrief to the teams that make it to nationals to highlight the common mistakes they make and how they can improve. This years theme was 'Intervention' as we felt the teams overall didn't seem to be improving as we keep escalating our tactics. Here is this years debrief:

http://sdrv.ms/13JOgGg

There was video taken this year and a documentary crew from UTSA. I'll post the video and a more detailed breakdown of our activities this year tomorrow.

Saturday, March 23, 2013

The new book is out!

Well I thought I had another month but it looks like McGraw Hill is faster than I thought!

You can get the print edition here:



and the Kindle edition here:

Since the book is out early its good news for those of you patiently waiting, but its bad news for me... the website isn't done yet!

www.learndfir.com is the new website I'll be using for the new book 'Infosec Pro Guide Computer Forensics' and the 'Hacking Exposed: Computer Forensics' series. I am working on having the full site up as soon as I can with all the links, documents, and forensic images for each of the case example chapters in the new book. I'm also working on youtube videos to show how to work each chase in three different tools:

SIFT
Encase 7
FTK 4 (unless 5 comes out sooner than I expect)

You are welcome to use the images/videos without the book, but to really understand the scope of the case it will really help!

Wish me luck reader, I've got a lot of work to do.

Thursday, March 21, 2013

DFIR Online Tonight 3/21/13 8PM EST

Salutations Reader,
             Tonight myself and my colleague Matthew Seyer will be on DFIR Online. You can find the link to watch here:
http://www.writeblocked.org/index.php/dfironline.html

If you followed our last blog posts you know we have found the pieces to assemble the 'Triforce' and now we are ready to show an alpha of it and the amazing information it can reveal. I hope you can make it tonight but if not I plan to be at the following conferences this year talking about different aspects of our research:

CEIC
SANS DFIR Summit
Paraben Forensic Innovations Conference

Monday, January 7, 2013

NTFS Triforce - A deeper look inside the artifacts

Hello Reader,
            In our last post we discussed at a high level the relationship between the $MFT, $LOGFILE and $USNJRNL. In this post we will go into detail of the structures we can recover from each of the three and how they link allowing us to determine the historical changes made to a file or directory.

$MFT  - The Master File Table is a pretty well understood artifact. MFT structures are fully documented and there are a variety of tools out there for parsing it. With that said, I'm not going into any depth on how the MFT works but instead just highlight the two structures we are interested in.

(Thanks to Mike Wilkinson for making these MFT data structure diagrams I am referencing below. You can find the full version of his NTFS cheat sheet here http://www.writeblocked.org/resources/ntfs_cheat_sheets.pdf)

The first is the File Record shown below:

When a file is created, modified, or deleted this is the structure that gets added, changed, or updated. The field in the upper right at offset 0x08 labeled $Logfile Sequence Number or LSN is how the MFT refers to the most recent change recorded in the $logfile. Each $logfile record has an associated LSN, however the LSN is updated in the file record to correspond to the most recent change. There is no record that I'm aware of that shows what LSNs a file record previously had. The MFT Record Number is a unique identifier for this file record, and if we have a way to link a change to  it then it becomes easy to associate historical changes we recover to indicate which MFT file record they are referencing.

The $USNJrnl keeps the MFT Record Number to indicate which file it is operating on and the Parent Record number to reflect what directory that MFT file record resided in. If a $logfile entry records a change then that change can be easily linked back to the MFT file record number's LSN if it's the last change made to that file record.

The file record however is not the only record/attribute we care about in the MFT for our triforce historical analysis powers, we also care a lot about the Standard Information record shown below:

If a time stamp, owner id or SID of a file changes then it's the standard information block/attribute that gets written to the $logfile and not the entire file record with all its attributes. This was a problem before we found the triforce linkage because as you can see the standard information block does not refer to the file record number. We had to determine which MFT entry a $logfile record was pointing to by either the LSN (which is captured in the Logfile header per recorded change) and hope it hasn't been updated again. Alternatively we could determine the location of the MFT entry by doing some math using the VCN (virtual cluster number) and the MFT cluster ID recorded in the $logfile. Relying on the physical location in the MFT is also problematic because a defrag can remove deleted entries and change the VCN where the entry resides leading to false positives of which $logfile record points to which MFT record.

The good news here is that as you can see at offset 0x40 the standard information attribute does record the update sequence number! The update sequence number in turn will point to the file record number and parent file record number as discussed above. This means that through the link between the $USNJrnl and the $MFT we can associate a change made to the standard information attribute from the $logfile to the $USNJrnl which links back to a specific $MFT file record number. This is a reliable identifier as the file  record number's value does not change based on system activity! This then leads us to the $logfile structures.



$Logfile - Every change recorded in the $logfile starts with a header as shown below:

The LSN here relates back to the file record entry inside the MFT for the change that is being recorded. The  LSN for a file record in the MFT will be updated to reflect the most current $logfile entry for that file. Meaning the LSN for a file will change with every change recorded. That means than any $logfile entry whose recorded change does not reference either the USN or the MFT record number can only have its corresponding MFT record determined by doing a calculation using the recorded VCN seen at offset 0x48 above.

Why does the $logfile record the VCN? The process of repairing the file system using the $logfile is to overlay the data stored in the $logfile over the areas where a transaction failed to complete successfully. This allows the file system to be rolled back (using the undo records) or have a change reapplied (using the redo records) by just overwriting what previously located at those VCNs.

What comes after the LSN record header will vary on what change took place, the $logfile is storing the raw MFT record/attribute that has been modified so any MFT entry could exist in the $logfile. We focus on the File records and the Standard information attribute records as they reveal the most about changes occurring to a file. There are other MFT records/attributes that could be of interest to you and they also exist in the $logfile. Any change made to a MFT record/attribute will be recorded in the $logfile, the hard part is then referencing that logged change to the actual MFT record being modified to know which file record it relates to. So you can imagine that after every LSN header you have a copy of the MFT record/attribute being changed reflecting its before (undo) and after (redo) states.

Since there are no other $logfile structures other than the LSN header, RCRD header and Restart areas we are reliant on what is being recorded by the MFT record being changed to exactly know which file is being modified. When we are lucky (like we are with file records and $standard_information records) we get a link back to a unique file reference number. When we are unlucky (resident data found in $DATA attribute records) we have to rely on some math using the VCN and MFT Cluster index stored in the LSN header to determine what location within the MFT the record is pointing to. It's this possibility for false positives that keeps these records out of the public version of our $logfile parser.

Note: We will go into even more detail of the $logfile structures when we do the big $logfile post which is coming with the tool release I promise.

$USNJrnl - The USNJrnl or Update Sequence Number Journal has a pretty simple structure compared to the rest we've talked about and is fully documented as shown below:

Sorry no fancy hex offset data structure for this yet, just the record structure as taken from Microsoft's documentation of the USNJrnl.  As you can see for purposes of linking back $standard_information structures stored in the $logfile to the MFT we have the matching USN stored here as the sixth element down. Since each USNJrnl entry, and thus each open/close of a file, has a unique USN assigned  we have a great lasting artifact to look for when trying to match $standard_information records back to MFT records. The fourth and fifth items in the record entry link back to the MFT for not only the file record number but also the directory the file was located in as seen in the parent record number.

Taken just on its own the USNJrnl is a fantastic source of historical information that more examiners are beginning to utilize, you can get even more information out if it by taking it a step further. If you were to mine out all the unique USN records into a database table you could group them by file reference number to see all the changes including the renaming of a file or its movement between directories.This is because the MFT file record number (shown in the MSDN screenshot above as a reference number) does not change no matter how many times the file record or attributes change. Renaming a file, moving a file, editing its time stamps, filling it with random data, etc... none of these actions will change the file record number. What utilizing the triforce gets us is more granular details of those attribute changes that only exist in the $logfile extrapolated out through the $USNJrnl to a MFT file record.

Putting it all together - So that was a lot of words up there, if you read the last post you got the same information at a very high level but now you can see at a much deeper level how these things sync up. I don't believe that the developers actually intended this relationship to exist, or else I would expect more syncing for more record types stored in the $logfile, we just again get a happy overlap between what a developer made and what analysis can reveal to us.

If you followed everything I wrote above you will see that using the power of the NTFS triforce we can recover and identify:
1. The change of ownership of a file ($logfile)
2. The change of a file's SID (if that were to happen)  ($logfile)
3. The changing of timestamps ($logfile)
4. The movement of files between directories ($logfile and $USNJrnl)
5. The renaming of files (common during wiping) ($logfile and $USNJrnl)
6. The summary of actions taken against a file ($USNJrnl)
7. The changing of attributes to a file, important for things like tracking hard links to determine CD Burns ($logfile)

We can do all of these with little chance of error thanks to the combination of these three data sources. Additionally we can recover granular historical changes to files. Depending on your location in the DFIR spectrum (from digital forensics analyst, incident responder to malware analyst or all of the above) you will have different uses for this information. We are very excited about thee triforce and we are extending our $logfile parser to include these sources, of which the $MFT integration was already on our roadmap. Getting the full use out all of this information will require a database and were not sure if SQLLite is up to the task, hope to have something workable out there soon.

In the next blog post I'll talk about how to get access to the $USNJrnl, $MFT and $Logfile from volume shadow copies as not all access methods are equal. After that I'll likely move into updating some old 'what did they take' posts to reflect new artifact sources and post the results of our forensic tool tests.


Friday, January 4, 2013

Happy new year, new post The NTFS Forensic Triforce

Feliz Nuevo Ano Reader!,
                                           Thanks for sticking with me and my erratic schedule through 2012. One of my resolutions for 2013 is to get better about regularly blogging and writing about new things we are seeing/doing. The new book is in copyedit at the moment, http://www.amazon.com/Computer-Forensics-Infosec-Guide-Beginners/dp/007174245X/ref=sr_1_21?ie=UTF8&qid=1357249339&sr=8-21&keywords=computer+forensics, not quite sure why they changed the title but it's supposed to be Computer Forensics, A beginner's guide. It's meant for those people who already in IT and moving into a DFIR role either within their company or on their own. I'm actually putting together a series of Youtube videos to go along with it, they'll be found here http://www.youtube.com/learnforensics and I'll be uploading some sample cases to work through that match the book. More on all of that when the book is released though!

Now for why you are (most likely) here, NTFS internal forensics. Over the past year or so if you've been reading or watching me speak you'll know that we've been focused on the $logfile. Since then we've expanded our research into other file systems (we have a working ext3/4 journal parser now that can recover deleted files names and re-associate them with their inodes/metadata) but we are always keeping an eye on NTFS to see what else we can do to expand our knowledge and capabilities. After re-evaluating the USN Journal thanks to Corey Harrell's blog (http://journeyintoir.blogspot.com/2013/01/re-introducing-usnjrnl.html) we've come to recognize that to get a bigger picture our view of previous file system activities can link up to form the NTFS Forensics TRIFORCE! It's dumb I know but it works, see the illustration below.


The $MFT, Master File Table, is always the primary indicator of what the current state of the file system is. If a defrag hasn't run, which windows 7 is very aggressive about and defaults to once a week now for auto defragging (mine is set for every Wednesday but I don't know if that's a default setting), then you can see the deleted/Inactive NTFS file/directory entries prior to the last defrag run. That's not enough for us as forensic investigators though, we need to know more about the prior states of the file system in order to perform our work. So how can we roll back time and see what happened before? A good answer in windows vista/7 systems for many has been shadow copies and shadow copies are amazing for the forensic investigator. What the MFT and the contents of the file system for a shadow copy show you though is the current state of the file system at the time it was capture, a snap shot of the file system. To know what actions took place between snap shots or before snap shots you have to look deeper. The two file system journals, and in this post we are just focusing on file system journals not forensic artifacts that are logging actions related to a specific user activity, that exist are the $logfile and the $USNJrnl.

The $logfile, the primary focus of our initial research, contains the before and afters or undo/redo for each change to the MFT. It contains the full entry of what is being changed (File records, $STDINFO blocks, etc...) and the metadata contained within them (with the exception of resident files on windows 7 journals whose contents appear to be nulled out). The $logfile is great for getting a very granualar level exactly what changes have occurred to a file system.

The $USNJrnl creates a summary of actions taken against a document from the time its opened to the time its closed. The $USNJrnl like the $logfile is circular being that overtime it will be overwritten but like the $logfile if you access the volume shadow copy using libvshadow you can get access to prior backups of it. The $USNJrnl keeps the name of the file being changed, the file id of the file being changed in the MFT, the Parent ID of the directory that contains the file in the MFT and the date the change occured as well as the USN which if the offset into the $USNJrnl where the data regarding the file begins.

Each of these data sources by themselves provide a wealth of information, but all are incomplete without each other. The MFT does not reflect past states, the $USNJrnl does not contain metadata and the $logfile does not always reference a file by name and file id. However, taken together they link up as seen in more detail below to create a view of historical actions like we've never been able to see before:
Ok so what does all that mean?
For any individual file we can determine the following:
     a. What changes have occurred to the file and when
     b. What metadata did the file have before and after each change (modification, creation, access, size, location)
     c. What was a file renamed to?
     d. What files previously existed in a directory?

Who is this useful too?
     1. Malware Analysts you can now see every file system change happening including anti-forensic attempts like time stamp alteration, deletion, renaming and overwriting
    2. Incident Responders you can do the same against attackers who are attempting to hide their activities and track what files they are accessing even if access dates are disabled
    3. Forensic Investigators  - so much more data regarding a suspects activities on the file system including the detection of spoliation
    4. Everyone!

What are the limitations?
   1. Both the $logfile and the $usnjrnl are circular with a max size, so there is a finite amount of data each will keep before it begins to overwrite themselves
   2. If you are using an operating system such as OSX/Linux using the ntfs 3G drivers for writing/accessing a NTFS volume they do not update the $logfile or $usnjrnl for their activities. It will update the $logfile to show that the file system was cleanly mounted though.
   3. Because the $USNJrnl keeps less data than the $logfile its like that the $usnjrnl will contain more historical data than the $logfile

What can you do to make this even better?
   1. If you analyze machines in your environment you can alter the sizes of the $usnjrnl and the $logfile so that they retain much more data.
   2. You can get a copy of our forthcoming NTFS-TRIFORCE parser which will take in data from all three sources to get a complete view of the file system.

More details you say? I'll do that in the next blog post (promise) it's taken too long to just write this one.