 Welcome to this presentation on time-stopping which is going to be dubbed Whose Time Is It Anyway. For those of us who are visiting from across the pond please allow me to translate this is the presentation on time-stopping called Whose Time Is It Anyway. It doesn't make the presentation any better to speak like this. It just makes you want to drink warm amounts of beer and do funny things to Kate Middleton. So let's talk about time-stopping for a few minutes. Time-stopping is a critical thing for forensic analysts because forensic analysts love building timelines. It's great. They can figure out what happened on a computer and they can reconstruct the events with a certain degree of accuracy and that's nice. And in order to hide that some unscrupulous people as they could be called used to change the certain time values and they would go in and they'd change the clock on the system. But doing that has a certain amount of problems. First you need to have access to the system clock where you have to have rights and the second thing is newer versions of the operating systems are now recording these events in the system lock files. So Windows 7 and Windows Vista now record event ID number one at level four to show the times change and you'll notice at the bottom of the screen there it has old time and new time. So that's not really the best way that we're going to hide our activities, our fun things. So what happened in 2005? There was a wonderful demonstration and exhibit of time-stopped at AXE and that was since pulled into Metasploit and that was great. People loved it. And now there's a GUI available that you can download from Sourceforge where you can change the four time stamps that are part of NTFS or three time stamps that are used in FAT file systems. There are a number of other tools that are also about out there free for download under trial versions such as Attribute Magic. They go through and they change time stamps as well. A little problem with Attribute Magic though, it only changes three of the four NTFS time stamps. It doesn't do the MFT time stamp, which is interesting. So all these wonderful tools are out there to go time-stopped and it's fairly efficient. And if you're not paying attention or if you're an unscrupulous or a poor sap of a user, well, you're going to miss what happened there. But here's the rub. They don't work real well. They don't do a good job. And the other thing is they usually only hit one file at a time. Now if you think back five or six slides, what did I say forensic analysts like to do? They like to reconstruct a timeline. And when they build their timelines, they are built in context. They don't look at individual files. They look at what's happening on an entire machine. For example, there aren't four time stamps on NTFS systems. There are eight time stamps on NTFS systems. There are four time stamps under the standard information attribute, which we'll take a look at in just a second. It's identified by hex number 10. Those are the ones that are picked up by forensic tools and those are the ones that time stamp hits and magic attribute hits. There's another set of time stamps under attribute number 30, under file name, and those four match exactly what's in standard information. The problem is when you stamp something or time stamp something, it doesn't modify these as well. So, oops, there's a seam in the story here. Now what's supposed to happen on a Windows based system is you modify files and standard information and when you make another change, all of those records, those four data values are supposed to swing over and change the file name attributes. That's if you've modified the system correctly and sometimes when you use time stomping tools, you're not going through the Windows API, so therefore Windows doesn't always update, so therefore we have things that aren't in sync. Let's take a look. Hi, the hex editor here opened up in front of you. You'll see a nice blue box right up here. Attribute ID number 10, attribute ID number 30, count specific number of bytes later and you'll see four time stamps, right? You'll see create it, which is the first one. What's after create it, we have less modified. We have MFT entry and then the last one is the last accessed. Don't forget on Windows seven based systems and on Vista, the last accessed time stamp is no longer forcibly updated. It is only updated when the file is modified or created, right? But we have these and these four time stamps here match. This is great. This is the way it's supposed to work. But if an examiner sees something that looks kind of funny, they're going to start digging. They're tenacious that way. And when they see obvious signs of time stomping, they start sniffing around. Take a look at this time stomping that showed up right here. Anyone here see a problem with the time stomping that was done? I mean, oh yeah, there are no dates. That could be a problem. All right, the moment that starts happening, you have an examiner starting to sniff pretty curiously in that area. All right. But what about things that aren't as obvious? Let's take a look. This is a screen capture from NCASE. It grabbed four time stamps for this unknown EXE. You'll see it created and accessed a last written in the entry modified. And you'll notice that the entry modified is off, not by a lot, but by a few minutes and a few seconds. If I take a look at that, those values directly in the MFT with a hex editor, I get the eight stamps that are shown on your screen right now. You'll notice they both have the created dates. They both have the last access, the last modified in the MFT entry. And the one that's pictured in gold is the one that was off. So as an examiner, someone might go in and say, well, wait a second, that's off. Let me look a little closer. And when you look a little closer, what do you notice about the leftmost bits? They're not off by a little. They're off by a lot. So I hate to do this to you. I'm going to back up in a presentation. What do you notice here? The creation date, the last access date and the last written date, are they all the same? They look the same to me. The problem is, NCASE only goes down to the second. Time stamps, well, they go down to the nanosecond. So there are changes here. So clearly there's evidence of time stomping that's been done here. And through the Windows API, Windows Explorer, NCASE, FTK, you wouldn't notice it. You'd actually have to go down and look at the hex level. Now some really good time stomping has been done recently where people wind up grabbing the date of the Windows install files. And they apply them and they copy them. The problem is, it's pretty easy to identify what files are part of the standard Windows installation and which ones aren't. This situation that you see on the screen, too good to be true. Unknown.exe, the file creation date, the last written date and the last modified date match exactly what happened on this Windows installation. Hmm. Funny that last access date's the only one that's off. So we've got to remember that the files when they're analyzed or time stamps they are done in context. Which means if we're going to be running executables on someone's system, well, they're going to start leaving a trail. Time stomping doesn't fix the trail. We have problems with things like the MRU and we have problems with the Windows pre-fetch. So let's talk about the Windows pre-fetch for just a second. Every time you launch an executable on a Windows based system starting with XP or Vista or 7, you have the Windows pre-fetch or Super Boost or Super Pre-fetch and that's great. But all of a sudden we notice that there's an extra file there. That file is going to have eight time stamps as well, right? So if we're going to run an executable on a system and we don't want someone to know about it, not only do we have to time stamp the executable itself and fix those eight time stamps, we got to go time stamp the pre-fetch. Inside the pre-fetch at offset hex 78, there is an embedded time stamp as well. Time stamp doesn't fix that. So if I'm going to go check or an examiner is going to go check or you're going to go check to find out whether or not an executable has been run on a system, crack open a pre-fetch file with a hex editor, go down to offset 78 and take a look at the time date stamp. Does that match the same time date stamp that shows up for the file itself? Probably not. All right. So a wise person told me when they were reviewing the presentation, I believe his comment was, quote, screw that. I'm just going to delete the pre-fetch file completely. So you have an option if you're going to run an executable, you can either delete the pre-fetch or you can go time stamp it and then go worry about the stuff inside it. All right. The Windows registry, that wonderful collection of files. Anyway, there are embedded time stamps in there as well. So most recently opened files. Hey, they're all sitting in the Windows registry. So if you've opened a file, if you decide to snoop on someone and you didn't mean to or you wanted to and you're trying to cover your tracks, don't forget you got to worry about what's inside the registry. Not fixed by time stamp. All right. The Windows registry also records whether or not applications were run. And sometimes there are time stamps there as well. Also not fixed by time stamp. All right. Now a lot of the registry entries are stored in Rop 13 which obscures what happens which means reading them as a problem. Data files, now they have time stamps as well. All right. So we've got a problem. We've been running into a system. We're taking a look at it. We pulled out our utility time stamp and we broke out Metasploit. We're time stamping it all over the place and now we've got to worry about what's inside the file. So what happens when we create or open a file? Well, there aren't four time stamps. There aren't eight time stamps. There are 33 time stamps. Holy Hannah. That's a lot to go fix. So whenever we open a creative file on a Windows based system, the file itself is going to have eight stamps, right? Four in standard information, four in file name. The shortcut that gets caught in my recent documents, well that's going to have eight time stamps. If it's an office file you've decided to snoop and go open, something that belongs to your boss, your co-worker, your friend, your spouse, your neighbor, your pets, whatever. If that's an office file, that's going to have eight time stamps. Oh yeah, then there's going to be registry entries and yeah, don't forget about the prefetch. That's going to have nine time stamps. So now we have to worry about 33 time stamps. Wow. Adobe Acrobat. Oh yeah, that stores its most recent documents and files that are opened inside the registry as well. So you'll have to fix what's happening with the registry and being read. All right, so let's take a quick look at something. We have an Excel spreadsheet. It was created on July 31st, 2011, at about 8.52 in the evening. All right, working late, working on spreadsheet, accounting files. I time-stop it because I don't want someone to know I was looking at it. Once the last time you opened up an office file using an XML editor. Oops. Hey wait a second, look at that right there. Create it. 2011, 7, 30. Does that time stamp match the one that's in the MFT? No, probably not. So right now I got to go fix something else. All right. And this is something we talked about previously. There's a certain degree of granularity. Time stamps on Windows based systems are stored in 64 bit values. All right. Those 64 bit values cover time that's elapsed since January 1, 1601 in 100 nanosecond increments. Time stamp EXE, magic attribute, and the other tools that you can download from the net only go down to the nearest second. Well, if they only go down to the nearest second and I break open the hex editor, I'm going to notice that someone did time stomping. So what would be better than actually time stomping it? It would be copying the value, the whole 64 bit value from another file. Take a look at the file right here. What do you notice about the stuff that's highlighted in red? Do they all match like they're supposed to? No, what happened to the leftmost bits? They're off. Someone time stomped. You wouldn't notice this looking at it through a forensic tool. You'd only notice it through a hex editor. You can compare it. The values that you see here on the screen for the created stamp, round it to the nearest second. Don't forget we're going to be reading from right to left. What about malware that shows up on a machine? You know those unscrupulous malware developers pushing out their code, trying to steal your data. How dare they? And they drop an executable on your box. So what happens if you crack that open? Well, here's the same unknown .exe that I showed you earlier and you'll notice that the signature at the top has that trusty 4D5A, the MZ. And I can move over to the start of the PE header, points all the way down the EO and I can jump all the way down the EO and then I get my file signature for my PE header and then I move over a certain number of bytes and hey look, there's another timestamp. The date .exe was compiled, embedded right there in the executable. Now, that's not the date that it was run. However, what happens if the compiled date is later than the timestamp date? Something's going to be up and someone's going to start looking. That's great. And then there's the issue of external media. God, I have a bunch of wonderful people in my office. They always secure their machine with their name and their password whenever they get up and they walk away. And I worked for a place, you know, a few jobs back where they never did that. So, you know, it's amazing what people would run around doing and take flash drives and put them everywhere. But what about the timestamping on external media? Flash drives, you know, by default use FAT32 because they're compatible and they can move across different file systems. Well, they don't store time in the same way that NTFS does. Here, there's a certain number of bits in the root directory, only stored in one location, not two, where it breaks down time. You'll notice that the first set of bits only handle stuff in 10 millisecond increments. We don't have to worry about nanoseconds. We'll notice that the next two bytes handle what creation time down to the hour minute second. Then we have a creation date and we have a last access date. We'll skip two bytes. We'll go all the way up to the last modified time. So, we can time-snomp that with any of our tools. But is it worth it? If I take a file, run over to someone's computer, plug my thumb drive in and I copy the file over directly from mine to theirs, what happens with the time stamps? Well, the moment I copy the file over, that new instance of the file, whether I've copied it or moved it, is going to give me a new creation date. The date on which I copied the file. The last access date will be the date I copied the file over. The MFT entry will be the last, you know, the date I moved the file over. But what happens with the last modified time stamp? Oops. Now don't forget, some people might sit there and say, well, yeah, it's not really worth it. No one's going to really know. Hey, the last modified time stamp is kind of like a fingerprint. Remember, it goes all the way down to the 100 nanosecond level? And what are the odds of two files having the exact same last modified date? Pretty thin, right? So you'll want to stomp that too. All right? So what's the bottom line to all this? It's damn near impossible to time stamp things effectively with the tools that are out there. It just doesn't work. All right? And since it doesn't work, you know, if you, if someone is going to do something that they shouldn't, not that I would ever advocate that, the idea is to time stop enough to get rid of enough data to get rid of the prefetch to hide enough keys. So someone doesn't go looking at things with the hex editor because, you know, it's a trade off. The forensic examiner, that's work for them. That's extra effort. They're not going to go down that path unless they have a reason to do that. If you want to copy of this presentation, send me an email to that address. Give me the presentation at gmail.com. I have lots of time left for questions. Any questions from you? No? That's it. Yeah, HFS plus, you know, I'm not the greatest Mac expert and I'll be the first to admit it. So how's this work on Mac? Most of it is stored in iNodes. Is that right? Time stamps? iNodes? Trees? People looking they're not telling me yeah. It doesn't get easier because it's not stored in the same spot. It stores it in different iNodes. He wants to know how well this same process works on EXT. The question before was how well does it work on HFS plus? And the idea is not as well and it's pretty hard to go in to manually manipulate the iNode files. The tools that are out there to go analyze, the question was how well can someone efficiently analyze time stamps to see if something's been rounded to the second or not. There are some end scripts out there to go out and compare the time stamps that will go down and check to determine whether or not something's been modified. So there you have it. Thanks very much. Have a great time. Enjoy the content.