 I am the author of the digital forensics blog and ion forensics which I will wholeheartedly admit that I have not done a very good job of updating lately. There's been a lot of talks going and we've been kind of insanely busy. I'm a certified forensic analyst, I've been in MCSE since the NT4 days and I am a QSA. Here's the agenda for the talk, we're going to go over what Mac times are, where they're stored, what a forensic timeline is, why it's useful, why do it the way that I do it and then a little bit about actually doing it the way that I do it. A new tool that's come out recently that's really just made the way that I do it almost entirely automated and then we're going to get into a little bit of time stamp alteration and time stomping and the reason we're going to do that is because we've done a lot of cases in the spider labs where hackers have been using time stamp alteration to hide malware. So we're going to show you how to defeat time stamp alteration. If we have time, I'm going to try to do some demos where I'm actually going to run through creating a timeline, a super timeline, extracting the master file table and parsing it and showing you guys what some of these modified time stamps look like. We'll go through some of the tools that I'm going to use and then we'll do the conclusion. So Mac B times, what do they stand for? The Mac B times are derived from the file system metadata and they stand for modified, accessed, changed, which in this case means the MFT has been modified, and birth, which is the file creation time. The B is in parentheses because not all the file systems that we work on record a birth time stamp. For the purposes of the presentation, I'm focusing on NTFS. It's still the most common that we're seeing and we're seeing this in a lot of investigations. So where are the time stamps are stored? They're stored in two places. They're both located in the master file table. The first is the dollar standard info attribute or the SI attribute. It stores the file metadata like flags and SID and data about data, the file owner and one set of Mac B time stamps. This is the time stamp that's collected by Windows Explorer when you sort by date or by utilities like FLS and map time and time stamp. All the other utilities related to the display of time stamps. This is where they pull them from, the standard info. And that did come straight from one of the technet blogs. I've got a reference down there at the bottom if you want to read it. The second attribute is the dollar file name attribute or dollar FN contains the file name in Unicode and another set of Mac B time stamps. So it doesn't contain nearly as much information as SI. The important thing there is that it contains a second set of Mac time stamps. So the difference. Standard info can be modified by user level processes like time stamp or any other editor, Perl scripts, things like that. Dollar file name can only be modified by the system kernel. There are no known utilities that can accomplish this. Anti forensic or not. There's nothing out there right now. At least not that I know of. It's possible. Maybe somebody in the room knows. What is a forensic timeline? Forensic timeline is a string of digital events that's sorted into a format that can be easily read and interpreted by human being. Extremely useful in breach investigations. It can contain events from a single source like just the file system or log files, registry hives, event logs, just about anything that you can think of that records some kind of time stamp in the file system can be dumped into a super timeline. And it's really the only way I know if you get that sort of 30,000 foot view of what happened on a particular host around a specific time. So you generate some keywords, you generate some leads, maybe you've identified a piece of malicious software, and you, great, so it happened at 3 p.m. on a Friday. Well, what else was happening on that machine at three o'clock on Friday? You generate a timeline, bump it up, make it a super timeline, add some logs, and all of a sudden you can get an amazing picture of everything that was happening on that machine. So why is it useful? They are infinitely useful at pinpointing all or most intruder activity at a given point in time. It's also an excellent place to actually generate initial case leads and keywords. If you have an idea of what timeframe you might be looking at for a breach, you can just kind of go straight to that period and look at that day or that, you know, those few hours in a timeline. Periods of intruder activity will stick out like a sore thumb. If you, once you start using timelines and actually going through them, you'll see executable births and DLL births in the middle of, you know, the day where there's no, there's nothing else going on. Pretty obvious what's going on there when you see that. And identifying a starting point of intrusion is absolutely invaluable to finding other pieces of malware and kind of more of the total activity that took place on the system, right? So you see, maybe you see some enumeration tools and 15 minutes later, you see some unknown executable and you can go ahead and pull that other executable out there and start looking at what it does and what it is. So when you actually add in the registry timeline info, you get a more complete picture of code being dropped, services being installed. You can even, in some cases, you see hacker activity or intruder activity where they've moved a window and that actually leaves what are called shell bags in the registry. So you can actually tell, you've got proof that there's an interactive session going on. So it's pretty amazing what you can actually see inside of some of these timelines. In some cases, you see definitive proof of the user ID that was used to compromise the system. You might see the NT user got that file or some other files in a particular user profile get updated. So now we get to why we do it my way, right? Everybody's seeing some of the forensic suites that are out there or probably have that will sort stuff into timelines and you can do some of this stuff. It's very limited. My way's fast. It's super easy and it's extremely easy to search. Whether you're more comfortable with command line or the search prompt or the find command, it's amazing how searchable it is. So instead of doing your traditional shotgun forensics where you're looking for anything bad, you can use your scalpel and go after what you're actually looking for and what you wanna find. And it's free, more or less. There's really only one piece of this that I detailed that's not free. The rest of this is open source stuff. I can generate a timeline including full file system data and all the registry hives and search it for keywords, identify altered files before any of the GUI based utilities have even loaded an image or verified it. Sorry to all of you NKC users, you're slow. In a few minutes here if I've got time and I think I will, I'm gonna show you guys how I'm actually doing this stuff. So the first piece of this of doing it my way is the command FLS. This is open source. It's available as part of the Sleuthkit which is a free download, a free download from sleuthkit.org. I highly recommend going out there and checking it out. I've got the command here or a sample command FLS-M name your mount point. This could be slash for root. This could be a D, a C dollar, whatever you want. It really doesn't matter. You're just labeling your drive here. Designate the file system and it supports I think 16 different file systems. Not just NTFS. Recursively you wanna search and then you're gonna point it at either a physical drive by name. So that could be replaced with physical drive seven, physical drive two, whatever you have it plugged in. Or you can point it at a drive letter. You get varying results by pointing at a drive letter and I haven't figured out why. But for simplicity here I just pointed at a Z drive. And then you output it with the greater than two, an actual body file. In this case I just called it FS body file. So and I've got a little detail here about what this command is actually doing. Dash M is just output in a standard format. In this case it's time machine format. Dash C names the mount point and again I said there could be D, could be var, could be root, could be whatever you're working on. Dash F designate the file system type. Dash R you display everything recursively and then point it out at a logical device. And then that the greater than dumps it out to whatever kind of file you wanna call it. Doesn't matter, just whatever you want. Now here's one of the interesting pieces and the piece that's not free. You can actually do this while you're on site using F response. F response will actually let you using some magic and eye scuzzy. It will actually let you mount a local draw or a machine over the network as a local read only drive on your investigative machine. It's pretty amazing piece of software and it is very, very worth it. I don't know if Matt's here, he may actually be here from F response. No, that's too bad. But it's great software and I highly recommend it. It is like I said the only piece of this that's not free. You can obviously also do this against a previously gathered image but F response lets you do it while you're on site instead of sitting there reading a book waiting for an image to finish. FLS can also be running it's a static image or a post-mortem image and you just point it same thing slightly different with a little offset there. FLS-M, name your device and you do have to add an offset sometimes where the actual file system starts. Sometimes it will pick it up by itself, sometimes you have to add the offset dash R so it's recursive again and then you just point it at wherever your image is sitting. So there's your path to image and that could be on a USB drive or on your local drive or wherever your evidence sits. And then again just spit it out to the body file. That sector offset can be found with the MMLS tool which is also free and part of the toolkit very, very easy to use. You can also do this against a split image. If you could have 100 different 001, 002, 334 files you just go 001 space, 002, 003 and it works the same way. Again, the offset's there. So here's what a body file looks like and it's admittedly ugly. It's not user friendly at all. You'd actually have to know how many seconds from 1969 or 1970 is what these numbers here designate for each time stamp. So obviously that's not something that you're gonna wanna look at and try to use. But something interesting to look at here on this slide is this, I have it highlighted in red here. You have this Inet Manager executable and we're gonna see that here again in just a second. So turning FLS output into something that's actually useful in Human Readable is done with the Mac Time Perl script. It's also available as part of the Sleuth Kit. And here's your, here's the sample command again. Perl, mactime.pl-d-b pointed at your body file and again just output it out to a CSV file. The dash D is gonna output it in a common to limited format. So it's really, really easy to use with Excel or OpenOffice or Command Line. You can search it, do whatever you want. And then dash B just designates your path to the body file and you're outputting it to a timeline, FS timeline. So this is probably not gonna show up very well and I apologize, it's hard to catch what a timeline looks like in Excel. But obviously once you've got it full screen on your own machine, it's pretty easy to use. And control F is extremely effective when you're actually looking at this stuff in Excel. So if you could see what I've got up here on the screen is actually some intruder activity that I pulled from a real case. And you can actually see the attacker doing some pinging and trace routing and then actually installing a service and there's some folders showing up here like WinSystem32 memdump and then immediately followed by a whole bunch of Perl P2X TMP files. Pretty scary stuff, not something that you would normally see on a little POS register or back of house server. So kind of a cool example there. So there's your standard file system timeline which can be incredibly useful but you start adding information to it and you really get a much larger picture of what's going on. So call it a super timeline when you start adding more information to it. I like to add the registry times and I don't usually add a lot else. You really get data overload extremely quickly but that being said, sometimes you're not finding a lot. Adding everything you can can be very useful. So obviously you just gotta use your best judgment there. So you can actually add the registry MAC times. They're recorded more or less the same way as the file system timelines and you can do that with reg time. Reg time was not publicly available until fairly recently. It's a Perl script written by Harlan Carvey and it's actually included in the SANS incident response and forensics toolkit and he's also made it available fairly recently on redripper.net. So it is out there. You just really have to kind of look for it. Now we also get to log two timeline which has just about rendered me completely obsolete in the last three weeks. It's great utility was written by Kristen Gunjinson. It adds in at the Windows event logs Dr. Watson logs, IIS logs. There's 32 different modules. There's probably 40 by now. It's been two weeks since I looked. Just about anything that has timestamps in it, it will parse it and dump it out into a body file for you. It's amazing. So thanks a lot, Kristen. Probably gonna lose my job. We'll talk more about it here in a few minutes but it's really good stuff. It's a little difficult to get it working the first time but really, really worth it. So the process. You extract the registry hives from system root Windows system 32 config and the NT user.dat files for each of your respective users. XP, C documents and settings, it's username and in Windows seven it's under C users username. And then it's a very simple pro command again. Perl regtime.pl-m, you're gonna name your hive name. And again, this is just more for so you know which hive you're looking at in the timeline. So HKLM-SAM, security, software, system and that HK user, you can actually add the name of the user whose NT user dat file you're actually parsing, which is pretty cool. Really, really easy obviously to tell which user was doing what when you do that. So, here's adding it to the body file. Perl regtime.pl-m, same command recursively. And then you point it at that actual high file, C cases, registry SAM in this case and then you append it to that body file. And this is kind of important. Notice there's two greater than symbols there. Use one and you truncate your whole file. So, it's kind of important to make sure that you append and not truncate all the work you just did. Using a single will crush the data and always make a copy of the body file before you start messing around. It's just good practice. Just in case, because it happens. You repeat that for each of the high files that you wanna add, the NT user dat files you wanna add and you run Mac time again. And that's pretty much it. Mactime.pl, point it at your body file, spit it out to a super timeline. Here's a nice example of what it actually looks like in text when you actually do a grep search against this. And it's actually got a really nice format. And remember I told you we were gonna see that INET manager again? There's several timestamps here and you see one in 2003, which is really odd because this machine wasn't even built until 2007. But we're gonna see that here in just a second on the next slide, we'll explain that. Then you also see some other interesting files there. You see two paths, System32, INET manager and System32, INET serve with the same executable name. Definitely kind of odd. So, that's alteration. And that's actually a live example of it. There's a couple interesting things there. There's two several locations, right? That I just talked about since System32 and it's also an INET serve. And the binary in System32 is actually memory dumping malware. The date on the binary doesn't fit the rest of the system timeline. Like I said, the server that this image came from originally wasn't even built until 2007. And I've got a highlight there. You see Sunday, November 16th, 2003. And you see that's actually the modified and the birth date. You see the two timestamps. The M and the B is modified and birth, right? So how do we find out if this is just some kind of anomaly or if this has actually been forcibly altered? It's actually easier than it sounds. But before we do that, let's talk about Vincent Lu who actually created the utility called TimeStomp. And this is a little bit older interview, but this is pretty common what he has to say about forensics people in general. So Mr. Lu said, but forensic people don't know how good or bad their tools are. And they're going to court based on evidence gathered with those tools. You should test the validity of tools you're using before you go to court. And that's what we've done. And guess what? These tools can be fooled and we've proven it, right? Well, I agree, I suppose. Tools can be fooled. That's not that hard. Good investigators can't be fooled. I mean, if you see something like this, you gotta dig further, right? You can't just rely on the output of one single thing. You gotta go verify the stuff. Another quote from him says, for any case that relies on digital forensic evidence, Lu says, it would be a cakewalk to come in and blow the case up. I can take any machine and make it look guilty or not guilty, whatever I want. Yeah, I beg to differ. He's wrong. So here's proving him wrong. And we're actually gonna do, we're gonna defeat TimeStomp alteration or at least show you how you can figure it out, right? So here's where that second set of timestamps in the master file table comes in. Dollar file name, right? It's not accessible to anything but the system kernel. As of the writing of this presentation, there is nothing known that can change these attributes on the system short of extracting it, modifying it, and putting it back on a live system. So it's not feasible. It could be done, but there would be, the indicator, it would be a mess. That I guarantee, or I can almost guarantee that the machine wouldn't even work again if you tried to do that. So how do we get to these attributes and make some sense out of the MFT because it's a disaster if you look at it in raw format? This is Harlan Carvey to the rescue again. He's written a script called MFT.pl. It's also available on Redripper.net and this script parses out all the data for both sets of file stamps and dumps it out into a human readable format. It's a great tool and it's fast. So you rip the MFT with again another little pearl command here, pearl MFT.pl pointed at your master file table and dump it out to a text file and that's all there is to it. That outputs a text file that contains all the attributes stored in the standard info and the file name and it dumps them out and it's really easily searchable. I'll show you in a couple of minutes. So a little bit more grep foo and we've got what we need. Strings that file out or anything else that you want to look to actually read through it. grep-c6-i and look for that executable that we know is bad, inet-manager.exe, right? The c6 is context. It's a context switch for grep. Shows six lines of context surrounding that search hit and it's ignoring case for this search. Not much really to it. It's too bad that it's cut off over here on this screen. This is the output of MFT, that particular search in the MFT there. And you can see file names highlighted here in blue. That's the file we were looking for. Inet-manager.exe and this is the standard info. Let's see if I can point it out over here. Get the fn, inet-manager.exe over there. So this one up here is the standard info and this one down here is the file name attribute. And you can see there's some definitive differences there, right? Standard info, which can be modified. You've got two timestamps that have been dumped back to November 16th, 2003. That same set of file timestamps from the file name attribute shows the actual time that this file was created and modified, which is July 21st, 2010. So I just told you everything that's on this slide, so I'm just gonna skip it. Except that you see there that there's definitive evidence of timestamp alteration, right? I mean, you've got a set of timestamps that are obviously right. They fit to your timeline and the other set just flat, doesn't. So this is definitive evidence of time alteration and we're actually seeing this a lot. The second set of timestamps just blows away the use of timestamp and it really kinda makes it look silly if you ask me. We're encountering this all the time. I would say almost weekly we're seeing different pieces of malware that are employing this technology, that are actually employing time stomping. So it is out there and in fact, there's a couple of keyloggers out there that do it by default when they install. They'll actually pull the date the system was built and stomp their own executables back to that or they'll move it back one year. So here we are back to log to timeline. So I'm gonna tell you guys how to make all of this stuff that I just told you completely obsolete. Again, thanks, Kristen, I really appreciate it. The latest version of log to timeline is added functionality that automates just about everything I just talked about and more. Here's a sample command. I'm not gonna read that out to you. You can go play with log to timeline by downloading it. Version 6.0 will run on Windows with some finagling. Look for a blog post in the very near future from Chris Pogue on exactly how to get it working if he doesn't already written it. It'll automatically parse registry hives, event logs, MFT, IIS logs, just about anything you can think of that actually logs with a timestamp. It'll do it automatically. You don't even have to really point it at a particular file. It actually does magic number searches. It'll automatically identify an EDT or an EVTX and parse it for you the way that it knows how. It's a pretty amazing tool. I'm actually looking forward to meeting Kristen and thanking him for writing. It's really awesome. So, it's demo time already. Wow, I'm way ahead. So we're gonna create a super timeline from a post-mortem image that I have loaded on my laptop. We use FLS, Regtime, and Mactime. We're gonna do a string search and look for some malicious files, and then we're gonna verify the timestamp of that. Probably only take a couple of minutes, and then while the one command is running, we'll do, I'll show you how to actually extract the MFT and the registry hives a really easy way. So, let me shrink this. Wrong button. I did cheat just a little bit. I already have my command prompt all open. Is that gonna be big enough for everybody to see? Yeah, it's cutting off a big chunk of it, isn't it? That'll be all right. So, I have an image on here that I've already scrubbed any data out of so that I'm not actually divulging anyone's private information, and I've actually already ripped out the hives and stuff because it's a little time consuming, and I don't wanna bore you with all the details, but I will show you how I did it here. So, the first step here, hey, wow, this is cool. I can actually move my stuff off-screen so you can't see it. All right, so the first step is to actually generate a body file, and that was the FLS command, right? FLS-M, you name it C colon, C colon, backsplash, whatever you wanna do, whatever makes sense to you. Name the file system, it's NTFS. Look at it recursively, and in this case, I already have my image right here in this C defcon folder so I can just say demo image, demo.io one. This is an end case image. It's the only thing I like about end case is their compression. So, there you go, end case users. Little something for you. So, this takes a couple of minutes to run while that's running. Oop, I forgot to direct it out to a body file. Mm-hmm, mm-hmm, mm-hmm, mm-hmm, mm-hmm, mm-hmm. Sorry about that. Demo fail. Anybody got a drink? I'll just redo it here, hang on. FLS-MC-FNTFS-R for recursive and point it at, at demo.io one, dump it out to a body file. FLS-Body, all right? Okay, so that's gonna take a couple of minutes to run. The way I usually extract all these files is with the FTK imager, which is another open source product. It's really, really easy. You just add the image file in here with FTK, and once that loads up, which doesn't take long, you can just browse right through it here. So, this is read-only, what's that? Oh, I need to scoot it over, thank you. The better. So, here you go, you've got your entire file system, and here's the root of the drive that'll show you the MFT right here, and you just right-click and export. So, it's insanely easy to get a hold of this stuff. And then obviously for your system hives and stuff, same place they are on every Windows machine, Windows, System32, config, voila, there you go, there's your SAM, your security, your software hives, all that. And then the NT user.dat files are in their user profile spaces in C documents and settings or in C users. So, that's really easy, and the body file is now done as well. So, the next step's gonna be to actually turn it into a super timeline, right? Is that what I said I was gonna do? Yeah, super timeline. So, like I said, I've already got these registry hives ripped out, and they're in this C DEF CON thing here. So, I've also modified my path so that this stuff runs natively, which is kind of cheating as well, but it makes it a lot easier to use. So, you're gonna run Regtime against the particular hive that you wanna see here. In this case, I'm just gonna do probably two of them here. We'll just do the SAM file, just for a demo here. Regtime.pl-m, name which hive you're gonna do, point it at the path that you're gonna, for the registry hive, dump it out to a super body, and notice I've got the two greater thans there, right? So, we're gonna append. So, there you go. Now you got a super body file right there. Once you've added everything that you want to add to the super body, you just run MAC timing against it again, just like you would regular timeline, and again, this runs very, very quickly. MACtime.pl-d-b-d is the outputted into CSV-b, pointed at a body file. In this case, we're gonna do the super body, and let that run for a second. Looks like, I suppose I gotta redirect it out, huh? Super timeline.csv, right? And there you go. Now, in our directory here, we're gonna have a super timeline, and I should probably look at that and make sure that it's actually got some content in it. It does. And then, again, we're gonna talk about how easily searchable a body file is, right? So, we're gonna do strings of the super timeline, just so you can take a look at it. And in this case, we're going to grep out something that I know is actually on here, called RDP service, which is another memory damper that I found on this case. Uh-oh. Did I blow up my demo? Mm-hmm, mm-hmm. Hang on. Oh, hang on. Let me take a look here. What have I got going on? Sorry, I kind of lost track of where I was. So, I've got my body file. Oh, that's what I did. I didn't append the registry stuff to, I didn't make a copy of the body file first. So, let's do that real quick. Come back. Right, so here's my FS body. I'm gonna copy it. I pasted it. I'm gonna rename it SuperBody. And then I'm gonna append that stuff to it. Sorry about that. It happens. Especially when you're on stage. All right, so now we've got the original body file there, renamed to SuperBody, and now we're gonna append that SAM stuff into SuperBody, and it moves very, very quickly. So now we're gonna take a look at that body file. And with strings and grep again, and look for that, I gotta turn it into a timeline. Okay, that'll take just a second to run through all that stuff. Anybody know any good jokes? Oh, this is one of them? Sure, better. Too far over now. There we go. How much does it need to be shrunk? It's kind of hard for me to see the screens. Better? Okay, that's the bottom of it. So this usually takes, I don't know, maybe two or three minutes. It really doesn't take very long. It's pretty fast. Again, if you were trying to sort this out with X ways or N case, you might have sorted it out and you'd have one set of timestamps by now. So this weighs a lot faster. And again, this can be done while you're sitting there at a customer site pulling these images if you're using fResponse, without affecting the image in any way. Because you're completely set read only. So it's really a great tool. I really like fResponse. It's one of the only ways that I know of to actually get a little bit more efficiency out of an onsite. I've actually seen forensic people pull up, set an image going and pull out a book instead of working. And I don't know about anybody else that's in here that does forensics for a living, but we bill a lot of money per hour. So I don't think clients like to see you sitting there reading a book. Oh, should be just about done. There we go. All right, so now let's take a look at what's in that body file. Again, you can pull this open with Excel if you want and search through it, but it's a heck of a lot faster to do it this way. So take a look at the supertimeline.csv. Again, we're gonna just use a simple grep command to look for a piece of known malware that I know is in here. And so here's RDP service. And there's one hit. And again, we're looking at a 2003 time stamp. And then, lo and behold, the very next hit is a prefetch hit. So that was the last time that this thing was run is actually in 2010, which is really odd. And then we've also got, down at the bottom, we've got an access and a create time in 2010, but the modified and birth time are both in 2003, which is pretty odd, to say the least. So again, we're gonna look at the MFT here. And I've already ripped the MFT, I think. I think I've already got it set. Nope, I don't. Good, I get to do it. Okay, so MFT.pl, really easy. This is probably the easiest one of the whole batch. Point it at the MFT and output it to a text file. And this takes like, I don't know, 60 seconds maybe. And then as soon as that's done, we'll be able to pull those two time stamps out of there and look at that RDP service. This is the RDP service was actually memory dumping malware that was just from a live case. And we actually see, when we see this malware, we see this same time stamping or time stomping just about every single time that we found it. And it's actually done with Pearl during the install. There's a couple of lines in the Pearl installer for this malware that turns around and screws up these time stamps pretty bad. But it's pretty slick. You know, your average run-of-the-mill CIS admin is gonna go looking for new stuff on a box, right? When they think they've got malware, they're gonna go looking for everything that just happened in the last six weeks, right? This will completely burn that down. They won't find it. So, all right, so now we've got a text file of the MFT. And we're gonna do the same thing. We're just going to use strings to look at that MFT.text. And grip-i, get some context there, C6. And we're looking for that, we're looking for RDP service again. And it's gonna run through that MFT file. And it'll pop up here in just a second, I hope, with some hits. And there we go. So, we've actually got two hits for RDP service, right? Remember that prefetch entry from earlier? Here's the prefetch entry. Pretty good idea, right? Those time stamps match, right? We've got June 14th, 2010, and June 14th, 2010. Well, here's the actual executable right here, rdpservice.exe. Here's the standard info attributes. And there's that February 12th, 2003, that's obviously wrong. Because here's your file name attribute. Remember, that one can't be altered. June 14th, 2010, right? This is time stomping. And like I said, the look and feel of this is pretty easy to do. You can pretty well blow this open within a couple of minutes. And it really makes time stomping feel sort of silly. So, there's our demo real quick. Uh-oh, lost my page. Are we there? There we go. So, here's some of the tools that we used here. Right, and where you can find them all. And this is all gonna be up on my blog as well, Ion Forensics. So, if you wanna go and download all this stuff, you can go, it's out there. So, tools used and credit to their creators. Regtime.pl and MFT, this is Harlan Carvey's stuff. He wrote Windows Forensic Analysis, Windows Registry Forensics, and he's got the supporting blog for Windows Incident Response. Great blog, Harlan's always got new stuff out there. And he's pretty opinionated, but he's a good guy. Everybody that, I hear people chuckling, they must know Harlan. FLS and MacTime, these were written by Brian Carrier, the author of File System Forensic Analysis, and the creator of the Sleuthkit, available for free out there. Logged to Timeline, this is Kristen Gunjensen. I'm pretty sure I'm torturing his name. GCFA Gold Paper is where this came from. Mastering Super Timelines with Logged to Timeline. And he's also got a blog, IR and Forensics Talk, blog.kittiland.net. The original MacDaddy was written by Rob Lee and was absorbed into MacTime by Brian Carrier. And it's really only fair to mention Rob since he is the original MacDaddy. Great tool, just a really slightly different output for MacDaddy. It's also good for, actually, for Macs, instead of just Windows machines. And a special thanks to Chris Pogue, CP Beefcake. He's right over here in the front row. For teaching me a Sniper Forensics methodology. I don't know if you guys have ever been on his blog or have looked at his methodology for this stuff. It's fantastic. It's really the way that I learned how to do computer forensics, and I just, I love it. I can't imagine sitting there and waiting while all this stuff is running, while sitting on my thumbs. So he's always got the time to mentor me, even when he doesn't have the time to mentor me. So thanks, man. I appreciate it. Real-world anti-forensics, right? This stuff is happening. We're seeing it at least once a month, and usually more frequently than that. In the course of real-world investigations, we regularly encounter malware and attackers that are using these techniques to try to obfuscate their trail. And as they start using these tools more regularly, if you're an investigator, you need to have the tools. You need to be better armed, and you need to be better prepared to recognize these things, and not just go, huh, that's an anomaly. This is easy enough to prove. Figure it out, use this stuff, and blow this stuff away. Instead of just going, oh, we had an anomaly. It's not right to do your homework there. Everything leaves trace evidence somewhere, right? This is Low Cards Exchange Principle, the father of modern forensics. Know how your tools work, not just what they do, make you a better investigator. And remember that the tools do not make the investigator. It's the investigator's use of the tools that make them effective, right? I have a miter saw, and a biscuit joiner, and a router at home. I am not a Finnish carpenter. I am a forensic analyst. So be aware that these tactics are in use. If you guys are doing forensics, and you suspect malware, and you're seeing stuff that just doesn't fit, give it a shot. It's not that tough, and get some pretty amazing results out of this stuff, all right? So anybody have any questions? Any questions? No, all right. Go ahead. A graphical view of the timeline, there is stuff out there. There's Excel templates and stuff that I've seen people dump it into, but it's kind of a pain to make it all fit. And if you actually look at a timeline as a CSV, it's not just a handful of entries. I mean, it's literally 450,000 entries for your standard hard drive. So, okay, and we'll do a Q&A later. So thank you guys very much for coming. I really appreciate it. Thanks guys.