Julie: Hi, everyone. Thanks for joining today’s webinar Trust But Verify: Digital Artifact Edition. My name is Julie O’Shea, and I’m the global marketing manager here at BlackBag. Before we get started today, there are some things that I’d like to review. We’re recording this webinar and we will make sure to share an on demand version when the webinar is complete. If you have any questions for us, please submit them in the questions window, and we will answer them in our Q&A at the end of the webinar.
I’m excited to introduce our speakers today. We have Matt McFadden and Lexi Michaels. Matt is the director of training here at BlackBag. After 17 years in law enforcement, Matt honorably retired as a police Sergeant from the Clovis police department in California. For 13 years, Matt conducted digital forensic investigations and supervised the department’s high-tech crime team.
He has provided expert testimony in state and federal courts for digital evidence examined in child exploitation, murder cases, fraud, and many other crimes. Matt holds several industry recognized certifications in digital forensics and incident response. Lexi is a forensic engineer here at BlackBag. Prior to BlackBag, she worked for years seizing, imaging and analyzing digital evidence in internal investigations, intellectual property theft, employment litigation, and hacking cases at a consulting company in Philadelphia. As she developed her field experience, it built her desire to teach in the digital forensic community to serve examiners by increasing their case analysis expertise.
Thanks for joining us, Matt and Lexi, and Matt, if you are ready, I will hand it over to you to get started.
Matt: Yeah. Thank you, Julie. And thank you everybody for joining. We’ve put together a presentation here covering a case scenario that we’re going to examine looking at digital evidence and we’ve chosen to focus on trust but verify. Can you trust what you’re seeing? Do you need to look deeper? And how does that apply to your case? We’re hoping that we’ll convey some methodologies and techniques to consider and to apply to your cases when you immediately go back to that fun case log and backlog that’s waiting for you.
So to jump right in, we’re going to go over a case scenario analysis here, we have an intelligence breach investigation. We have a subject who is under a suspicion of taking some intelligence documents out of a secure site. We have their laptop and we do have a witness that is reporting that our subject of interest, or suspect, is involved in a deletion action between 15:40 and 15:45 hours.
This is a hard lock around these dates and times. This is EDT time zone. And we are really locked between this time due to our witness statement. I’m going to switch over to Black:ight here, but we believe that we’ve narrowed it down… we’re going to be looking at the recycle bin, but in narrowing down, our intelligence is pointing to this list.txt entry.
Now we want to rule the [indecipherable] out, and that’s kind of upon us. And the entry here that we’re seeing is our item that’s been parsed out of the trash. So we see it as list.txt. We see the path from which it used to be, the original path, and then we have a deleted data entry in here. So we’ve got a little bit of an issue here because looking at our deleted date and time, remember it was a 15:40 to 15:45 was our hard date and time lock that we’re looking at, and this is out of scope.
So we’ve got an issue at hand here that we need to resolve. Do we just discontinue with the investigation at this point? Or do we dive a little bit deeper?
So going back here and talking about the learning objective, we’re going to cover in this and focus on is, you’ve got to know your evidence, you have to know what you’re looking at and what it means. We should be able to trust her tools, but it’s upon us to validate them and verify the actions of what’s going on. And then there’s an old movie that I kind of grew up seeing all the time. It tends to broadcast during the summer, it’s kind of a nineties kind of flick, and they basically would have this commercial play and the bottom it would flash and say, would you like to know more? Suggesting you click on that button.
And I kind of put that up here because, you know, do you want to know more about this? Do you want to know more about what you’re investigating? And as we season ourselves as forensic examiners, that is more and more the case of, I do want to know more. A lot of our cases just beg for us to dive a bit deeper and to pull back the curtain a bit and start looking around to what is really going on here. So back to our case here, we’re out of scope now. We have our 15:40 to 15:45 timeframe that our witness is saying a deletion action occurred. We’ve got this going on, you know, what does all this mean? And we need to look a little deeper at this.
So one thing is, what does deleted mean? What does deleted mean when it relates to parsed trash items? Well, BlackLight makes it easy. You can look to the source here, and I see $ITLS12N.txt. And that is indicating to me, okay, this is the buddy file. Knowing my evidence from Windows Vista and on, this is Windows 10. This is the buddy file that goes with the $R. So that’s where we’re getting our information to validate it.
Just looking through these as we do in our class, we see our eight byte header that identifies what operating system type this is. We get the eight byte file size. And then in here, we get the eight bite date and time. So doing a little validation, just as BlackLight allows us to usually through the data interpreter, we see January 24th at 15:26:15. That’s the date structure that’s being parsed here. We’ve just trusted, but verified it. Okay. We validated that date and time.
But still it doesn’t help us. We are no closer to our scope. The rest of the file, yhis is just the entry original path and Unicode. And then the path is there. So we haven’t got a whole lot else to go on. So within BlackLight, we can go over here and do a right click reveal. And I’m going to reveal and file browser. Meaning I want to see this in the file system browser. What does this look like on disc?
And here I have the $I, and just focusing here, it’s not helping me much more. These are all still 15:26:15, like, well, thank you. You know, that doesn’t help me a whole lot. I could look down here in the metadata and I’m kind of focusing here, and I’m looking at my dates and times. Some of these are from above, but I get the extra date changed, but that’d be some administrative information, but still I’m out of luck. I’m no closer to revealing any evidence of my 15:40 to 15:45 timeline, and my hours for my scope.
So do I give up? Do I say, Oh, this isn’t the file or do I dig deeper? Do I ask, would you like to know more? You know, do I dive deeper into this?
So what we need to do is, we need to look around and dive into some things. Now, one quick thing is, my source path is showing the security identifier and the last red or relative identifier, 1001. I can quickly validate this to be within the actual intel. I could go over within BlackLight to my accounts, and there’s 1001 red, resolved as James, through looking at the Sam registry hive. So, okay, I’ve got James here, but I want to dive deeper. I want to know my evidence, and knowing my evidence and looking at it, I can quickly go to the root and look and go, Hmm, it looks like I’m dealing with NTFS.
So knowing that NTFS is at play here, what I could do is go over into system and I can load up all of the parsed items in here. It’s loading the registry, but I want to go into system logs. And I want to go to my old buddy USN journal, update sequence number journal. I want to go look for the file that would be related to our entry. Remember that it was named a $ITLS12N.txt. Let me go back to my actual intel here, and my trash items reminder short term memory, but here it is $ITLS12N.txt. Knowing my evidence, this is going to resolve to the file would have been $RTLS12N.txt.
And if I were to go back to the file system and poke around and look at it here, I’m not going to see it. It’s not going to be present. By looking through the recycle bin, I don’t see my $RTLS12N, it’s gone. So the actual file is not really helping me here.
I’m going to go over and let’s go ahead and look for that guy inside of the [indecipherable]. I’m going to say, Hey, file name. I’m going to look for the $RTLS12N.txt and say, Hey, do you see that within your journal logging here? This is the update sequence number journal. Let’s kind of log what’s going on on the system.
So now I do see it. There’s an entry. This is cool. I’d have the MFT record 195391, I want to take a note of that, and then sequence 11. But remember, I have filtered based on a name. I kind of want to go filter based on the MFT record. I want to go look at what’s going on with that. So I’m going to go switch my filter view to say, show me MFT record 195391, sequence 11. So MFT record, I’m going to add in sequence 11 to match up exactly to that MFT record. And then I’m going to say apply, once I type it in, 195391. Okay. So I’m going to change MFT record to match, sequence number to match, and I’m going to hit apply. I’m going to sort by my USN date. And now what I’m looking at is the update sequence number log entries are the journal entries for the history of this file on the system.
And let’s walk through and see what’s going on here. So I have list.txt. It’s on the file system. It’s looking like I don’t have the earlier entries. They may have been purged. But I see renamed old name and then renamed new name. If I scroll over here, I see a parent MFT record in sequence ID that tell me where this was, what folder it was in. So I can go look these up. Like, what is 110440, sequence six. And what is 111592, sequence eight? Where it was, let’s stop text. So I can easily go over to the file filter 110440. And then I’m going to go into my sequence six, a 110440, 6. And I’m going to say file system ID, my 110440. And I’m going to go look at that and see what that is.
And that is pictures. Users/James/Pictures. That’s where we saw this guy. So my file system ID matches and my sequence. It’s important to know what instance of this is sequence six. It’s actually out there in User/James/Pictures, according to the USN journal log at this date and time.
And then it moves over to another one. It moves over to 111592. We have an old name renamed. So my entry of list.txt goes from this User/James/Pictures over to another place. And we can go see what 111592 sequence eight is. So I can easily go to the file filter and go 111592. And that should look familiar.
That’s where we found it at. That’s the recycle bin. So what we’re looking at is the USN journal entry logs for it being renamed to the $R, and moving over to the recycle bin. And if we look at our time on here, this is matching that time that we were still at a scope of 15:26:15. But here’s where the story continues on. Okay. We have more entries here in the file system that are going to help us to tell our story.
We see it sits over there. A couple of things happen to it, but look what happens right in this area here. 15:31:17, we got a rename old name to a rename new name, and it hops out — if we look at the parent — it hops back out of the recycle bin and goes back to User/James/Pictures right here, where it was before.
So what does that indicate? It’s indicating knowing our evidence, going back to this stuff, it’s indicating that this was restored from the recycle bin and has been placed back to the User/James/Pictures, according to our journal entry. And we can go over here. We see the name changing back to its normal name. And then look what happens here. This is where the red flags are going up going, wait a second, it’s getting renamed again. And that rename action is occurring at 15:31:17, right there. Okay.
And we look again, it’s been moved back to the recycler, and if we look down to the end here, look at the action that we see. File closed delete at 15:43. And it has got a new name from the second recycle action. And now we’re within scope.
So the reason I bring this up is it’s showing the volatility of evidence, and how that evidence not being there may lead us to believe, based on a single parsed trashed entry in here, of just relying on a single date of a parsed item. But diving deeper inside of our evidence by knowing it and knowing what we can look at, we see these items here. Now this file eventually gets deleted, and this is the file that we no longer see on the file system. Okay. If I were to go chase the $I buddy of this, just to show you the volatile nature of data, I could look for a $IEC55R2.txt. Yeah, I’m going to kill the sequence number there. I could go look for that guy, and — let me switch over. And this is the MFT record. I want to show you take note of record 32192 sequence 56, and to go over here to my MFT record, and I’m going to go 32192, and this is number 56. So this is the 56 version or whatever of the MFT record we’re going to see for our $I buddy, related to our file.
So if I scroll down and — let me just sort by MFT sequence — and I go down to 56, where our entry was, this is the short life it had in the recycler. And right here is when the MFT record gets handed off to the new sequence number, to a new item. And we see that happens within six seconds on the file system. So our data is volatile within six seconds, NTFS said, hup! You’re done, reassigned. And this record got purged, which was our evidence showing us the second recycle bin action. Okay. And that’s what made us think we are out of scope with that 15:26 hour, but we’ve been brought back in scope by actually looking at the evidence. And I’m sharing this because this is evidence we really don’t want to miss. This is where we want to know our evidence and we want to know more, so we’re diving in.
So in cases that we deal with this can surface and, you know, to bring Lexi in just… cases that you’ve worked or you’ve seen on the corporate side. Have you seen things like this or work with recycle bin examinations and seen things where it may lead you one way and you know, you look another, and it means something else or, or just, how did it tie into your cases?
Lexi: Sure. So in the private sector, we do get a lot of employment cases. And these cases typically involve an employee being terminated from a position, or an employee leaving to go to a competitor. And, you know, on their way out, they’ll start deleting data that they weren’t supposed to have, or they’ll even start copying data to external drives, to take with them.
And the recycle bin is a great artifact to start with because we’re going to see what has moved into the recycle bin or gone through the recycle bin. And BlackLight does a great job at parsing this data for us, but we want to verify this data so we can be more confident in our findings. And not only will verifying this allow us to be more confident, but we’ll get a clearer picture of what has happened with the data along the way, because the tool doesn’t always connect the dots for us. That’s your job as a forensic examiner. So digging into the data and verifying is just only going to make your case stronger.
Matt: Yeah, it’s a good point. As much as we want to push one button and have it all magically come together, you know, and that’s on us, we’re software manufacturers here at BlackBag, now part of Cellebrite, we’re doing our best to connect these things and bring them all together for you. But you know, it is our job as digital forensic examiners to the ones that piece it together to tell that story and reveal that truth. Anything further here, Lexi, let me know, and we’re about ready to move onto the second example.
Lexi: I’m good on my end.
Matt: Okay, cool. So we’re going to look at another one here and then we’ll come back and talk about and open up the questions afterwards. This one is going to be just a little bit longer, but our intelligence breach investigation has led us to an application called 010Editor.exe.
We have stumbled across this, and I’ll lead you to the first evidence item that is indicating that 010Editor has been used within our timeline here to edit stuff. And we want to know what has it edited, if anything, and what did it do? Because this intelligence investigation is pretty sensitive and our bosses are saying, Hey, you need to figure this out. Cause you’re the forensic folks and you do all that magic. So tell me all the answers, right?
So we’ve got to dive into this and we want to figure out what we’re dealing with here. So I’m going to go ahead and close up the laptop case, and I’m going to open up… this is the desktop investigation that we’re looking at. And what I want to do is dive into this, and I want to look at the evidence at hand here.
So our first indication of this is that our actual intel, we did a lot of parsed artifacts here. A lot of new Windows support that we’d brought in. And the one that is drawing our attention is communication dialogue entry. I’m going to go ahead and turn off a couple of the volume shadow copies here, and memory files that have been brought in, but inside the communication dialogue I get these last visited. These are basically parsed entries from NTuser.dat, and you can see the entry right down here coming from, NTuser. And I have 010Editor.exe, and I have a path being accessed of documents, logs, and log files.
So looking at this, I get some information out of here. I get the name, I get that it’s accessing inside of a user. The user can be identified as USSF-JJKreese — this just happens to be the United States Space Force, right?
I created this before the entity actual became real. And we’ve got the user. And then we’ve got this NTuser.dat entry showing us USSF-JJKreese documents, log, log files, and we’ve got 010Editor accessing something. So can we say what this is accessing, can we look further? And that’s where we want to dive in here.
So this is item one of a six step analysis we’re going to do. We’re going to start grabbing information. So I’m going to get the last write date and time here, and this information about this communication dialogue, but I also want to go over and pull some file system information about log files. OK, so I can go over to the browser. I can go into the active volume and I want to go down under the users and we’re going to go chase J-JKreese/Documents, logs, and log files.
So Users/JJKreese/Documents/Logs, and I’m going to highlight log files. And I’m going to look at some of the metadata here. I can get some dates and times about this folder. I get the file system ID and sequence number. But I’m going to kind of want to look further here.
So what I’ve done here is I’ve started to make some notes. There’s our communication dialogue showing us, 010Editor logged by the communication dialogue, we have January 25th, and we’ve got 12:04:14 EST time as marked, and then accessing this folder.
So the question is, can we show what was accessed? So that begs the question of what artifact, what’s our go-to evidence? Where do we go to find out what 010 is accessing here? And there’s multiple answers. So the next step we’re going to take is a fun one, over to the activities cache.
This is Windows Timeline, and it is supported by a SQLite database. And I get a bunch of parsed entries that BlackLight parses out. I can go out and look at the SQLite database wall if I want to in BlackLight, but I want to look in here for a couple of things. We’ve got a lot of entries, so I’m going to be a little bit lazy here and use a filter. And I’m basically going to say, Hey, anything, do you have 010Editor.exe in entries? And I’ve narrowed it down pretty good, but I’m a little lazier than that. So I’m going to go down and say, Hey, do you have any that also have the word log files? Nice. I got down to one. Now, always be careful of over filtering. Make sure I’ve not filtered anything out, but looking in here, in this Windows Timeline, these parsed entries, I see activity type five, which is indicative of an application starting, and inside the payload, I get a lot of data that I can use that’s parsed from this database entry, supporting the Windows Timeline or activities cache.
And if I look in here, look what I see. 010Editor from my filter, and look at this nice one right here. Zoom in on that. I get 010Editor accessing C:Users/JKreese/Documents/Logs/LogFiles. Nice. And a file. It’s accessing you. USSF Crypt.torrent. Nice entry. Okay.
So what I want to do is I want to grab some dates and times: my start application time, I have a [indecipherable] time here, but I’m going to take this data and I want to make a note of it over here. Okay. That’s step two. Remember there’s six steps here. So we’re going to walk through a few more. And as we collect this data, you’ll feel maybe a little bit overwhelming. Like, man, I got a lot of data to work with. We’re going to come back in and work it out and lay and sort out this evidence so it makes sense.
Now the question is, what else? What’s another piece of evidence we can look at that’s going to help applications accessing items? Jump lists, right? There it is, right there. Parsed out 010Editor, and look at that, USSF Crypt.torrent. Nice. Okay.
So first what I want to do is inside of this item, I kind of want to go out and look at the source file times for my jump list entry. Me, it’s just a step. I like to know what the file system says about it. So I’m going to right click and reveal in file browser. It’s asking, Hey, I’m going to change the selection here for you.
I’m like, thank you, BlackLight for asking, but we’re good. Okay. And I’m focusing on these dates and times. I want to look and log these. Now, again, going back to the items of know your evidence, we di want to know more and trusting, but verifying. I want to grab when this was created. Cause that’s indicating when this jump list file was first created for the application accessing the entry. When was it modified? Has it been modified and updated? Has there been any access dates? What has changed with this? I want to log these, and we’re going to come back and look at those. And then getting over to the jump list, this is the jump list ID that’s parsed out and converted over by BlackLight to verify it’s 010Editor. I get the intro here and inside of this entry, I get a fair amount of data.
If I were to go over here and click preview, I get a bunch of entry information. This is what’s called link target information. This is the link targeting. Jump lists are basically… they can be a collection of link files, but more data. This is about the source files. So I want to log all this stuff.
Look here. I actually get the target file size that was logged when this was last accessed or updated on here, it gets logged in at 22,942 bytes. That’s important. We want to log that. Okay. A couple items in addition that we get, to show you that these are link files embedded in here — we covered this in our Windows course — these are link entry streams. Okay. Big capital L there. And just going through and looking at these, we can get the data and actually parse the data raw, remember trust, but verify.
And I’m seeing these dates and times right here that are being pulled, remember 9:56:13 is one of the dates and times. And if I go out here, the preview 9:56:13. Just validating the data as it’s parsed by BlackLight.
Now, two other really valuable things I get out of here are what’s called DestList. DestList is really good information about when this application accessed this item. Again, we want to validate it. I personally validated this, but I get a timestamp of when it was last accessed. Okay, I get here and again, that’s another value. The 12:04:14 that we can pull out of the DestList application. We see a pin indicator flag. And basically right before that for eight bytes of that pin indicator flag, that is our date and time right there, 12:04:14 converted nicely over for us by BlackLight.
Another valuable artifact that we get, that isn’t fully brought to light, is this value right after the pin indicator flag, this is the access count. This is meaning twice. It’s been accessed twice. So I’m going to make a big note of all this information. Grab one more. I want the last access date and time; I want that It’s been accessed twice; I want to get the link target information here; the size. And one more thing of big value here. I want to get an object ID. Can I get a volume ID? And then right here that 2480734B [indecipherable]. And so on. That’s my object ID. This is engaged and applied with Microsoft’s link tracking service, and it helps to track objects across volumes or within volumes when they’re being accessed. We’re going to take note of that, cause that’s going to come up and help us as we take our six steps through this. And it’ll surface why here in just a second.
So a lot of notes on this one, that’s probably the biggest one we’re going to look at. We have our source file information for the jump list. We’ve got our size of the jump list that’s logged from the link target or the actual USSF Crypt.torrent. We have the created dates and times, the latest access count, and object ID. So let’s take another step here. Now we want to go look for this file.
We know we started off with, 010Editor. What did it do? Now? We know it’s accessing USSF Crypt.torrent, but where is this file? Where is USSF Crypt.torrent? Is it still on our volume? Is it even around? Okay. I might go look for USSF Crypt.torrent and filter. And this is common in investigations. You found it, but now which one is it?
Okay. We can probably rule out that one. Right? Oops. The link one. But these three, which one is it? A couple of them are different sizes. So I can try to look at free dates and times, but that’s not conclusive. The name isn’t even conclusive. Cause we all know we can name entries the same thing, you know, on most file system volumes. So which one is it? You know, I hope we’re not relying on just name. If I were to go over to trash, there’s another one. This is a whole nother one. So I’ve got like four or five to choose from here. So it’s like, ah, which one is it? Okay. And here I want to get back to getting into knowing your evidence. Okay. And knowing more about it.
So let’s start here. Let’s start on this trash item. We see it’s RCUHWAQ.torrent. We have the original path and we’re going to grab our delete date and time 12:18:36. We notice a size of zero. Okay. So looking at all this we want to know what is this entry? If I were to go over to the metadata for this file and scroll down, the NTFS object ID is automatically parsed for me. Okay. Now, if you remember, we grabbed this one here. We have the 2480734B, right. 2480734B 28F1189. Well, this is just a little endian integer conversion stuff where we see 2480734B. Right. That matches up 28F1189. It’s matching. Okay. So this object ID saves us and is correctly identifying that as our entry of note related to 010Editor.
Okay. So we want to make a note of that. We want to get that information down, but also what we want to do is, we want to get the file system information, get the file system, so we have the MFT record of 95652. And I’m going to pull the sequence of five. We’re going to use this to track it later. Okay. Get some file system information.
And also what about the dates and times? Because we want to tell the whole story here. We’re just, right now we’re data collection mode, we’re collecting data about this. And you know, this whole walkthrough, we’re spending like 15 minutes doing this. It’s not a lot of time, but knowing our evidence, we’re able to get this.
So, when was it created? When was it changed? This change date in as an administrative logging of something on the file system changing at 12:18:36.
What happened there? What happened at 12:03:51? Because the file was modified during that time. Okay. So what we’re going to do is, we’re going to go over here, and we’re going to make a note of our recycle bin findings. We found the file, we identified it by object ID, got the file system information, related dates. And now we have the recycle bin information showing something happened at 12:18:36. Okay. We want to log that.
All right. Two more. Real quick. Two more things and then we’re going to wrap this all up. So we have gone from finding 010Editor, wondering what it was accessing; identifying that it accessed a file; finding out when it accessed the file; identifying that file specifically. And now we found the file and matched it up by its identifier and grabbed a bunch of information about it.
Now what happened with this file? What would tell us what’s happened with it? And what we want to do is go look at another evidence item. There’s a lot here to choose from, but what about link files? Okay. Link files can show what’s happening to an entry as we access it on the file system. As things end up getting manipulated and worked on by the computer user. So I’m going to scroll down and see, do we have any entries for USSF Crypt.torrent? And there we go. We’ve got a link file entry. This is good. Okay.
So we know link files show that the file has been accessed. So the first thing I might want to do is rely on the file system. The file system is hugely important. So I’m going to right click and review in file browser. I want to go look at the actual link file data. And I want to collect this information because this is when it’s created, likely when it was first accessed, when it was modified 12:03:55, and date access. I want to get this information about the file. And then going back to the link file information, I can click preview and look at the link target dates and times — we did this in the jump list, cause it had linked target information — but look at what we see here.
Target size zero. Our file size is zero now. It’s empty. Okay. We can go back and look at the original file inside of the trash items, but it’s empty. There’s nothing there anymore. If we want to know that this pertains to the correct entry, we can go down and rely on our old buddy, that object ID and look, object ID matches. That is our entry.
So something happened in these dates and times, and now our target file size is zero. And look, date written 12:03:51 that is surfacing again. And we look across 12:03:51. We’ve got a modification. It’s all starting to come together here a little bit. So there’s our link file information that we want to craft.
Okay. One more. And then we’re going to tie this all together. Okay. The last thing we’re going to chase here is the file system ID for our actual entry that the application accessed 95652 sequence five. 95652 sequence five.
So I’m going to go over here to our buddy that we used before and it’s a USN journal. Okay. This is our last step. I’m going to go look at MFT record 95652. You’re relying on my short term memory there. Okay. And we had sequence… I think it was five. I’m going to validate that, MFT sequence five. 95652 sequence five, to go look at this file inside the USN journal.
Now let’s walk through — I’m going to sort by USN date — and let’s walk through like we did in the last example, what happened to this guy? So here we have the entry that 010Editor is accessing. We see it’s created at 9:56:19. If we go back and look at the creation dates, we actually see it was created on 9:56:13.
So is this the object or the actual data being written at 9:56:19? We’ll take note of that. We’ll find out where it’s stored. Can we see it hopping over likely to recycle bin? We can check the file system IDs like we did before. But tracking down, we see some object ID change actions by looking at the recents here in the USN journal. Okay. And then as we get to 12:03:51, remember 12:03:51 was a marked date and time that we are wondering what’s going on. Look at what’s happened here. Okay. Inside here, we get a data truncation that has occurred. So to zoom in on there. Okay. Right during that time at 12:03:51, we see the USN journal is logging at data truncation. So knowing the USN journal, how it works, the file system stuff, we have 010Editor accessing USSF Crypt.torrent.
And at 12:03:51, our data is dropping and we can piece together the rest of the stuff here. And then remember 12:18:36. We had an admin change and ends up going over to the recycle bin. All right. So let’s make some notes there for the dates and times out of the USN journal, and let’s piece this all together. Okay. And we’ve walked through a six step about a 10, 15 minute venture into this. Okay. And we need to know our evidence and how it all correlates. We need to trust it, but verify it. We’ve gone through and parse some of these entries and validate what they indicated sometimes even looking at the hacks, but the big flashing question: do we want to know more? Do we want to just look at what the tool says and say, okay, that’s it? Or do we want to really dig in, do our job and piece this together, and really tell the story and reveal the truth in this matter?
So here we go. All this is, is taking these items here and just laying them out, and knowing what we know about the evidence, piecing it together. So we have from the file system data jump list, link file, target data. We collected 9:56:13, our USSF Crypt lands on the volume. Okay. We have an access during the same time. And then according to USN journal and jump list data, showing our application of interest in this intelligence investigation, accessed that entry. And we have the link target data written from the jump list. We have a link target data being written at 9:56:13. Okay. So the birth of our file, basically.
Then we go down, and we found some torrent file activity that we want to look at a little bit. This is per the USN journal and jump list link target, access data, 10:14 and 11:04.
Curiously enough, I actually went out on the file system on this date and time and found out BitComet was launching. And BitComet was active. This is not good. This is an intelligence breach investigation. I’ve got BitComet launching with torrent files on a system. This is not looking good for our subject right now. Okay.
Then looking a little further. What happened to our file? We have 010Editor accessing an altering USSF Crypt.torrent. We have a jump list source file gets created at 12:02:26, indicating that 010Editor gets launched. Okay. We have it capturing the file size of 22,000 plus bytes. This is likely our first access per that DestList we parsed. Remember that list of the activities, cached windows, timeline. It showed an application started one second later, that’s corroborating 010E launching and accessing USSF Crypt.torrent. Now look within — what is this, like a minute and a half? — USN journal is showing data truncation. Okay. Is that, is that our actual file getting shrunk down? And then we see the changed file size and the link while within that same few seconds indicating the logical size is now zero. And we have Comdlg showing that it accesses the path. We have the DestList showing another access at 12:04:14, likely our access count by the program. You know, we have to figure out what this is, but did the subject open up the file again and look at it to verify the data was gone? Okay.
The actual file gets changed at that 12:18:36, because it gets moved over to the recycler. And then we get a quote deleted date and time, but date time has been moved to the recycler. So the goal here is to show that we can take an application, 010Editor, and go, Hmm. I wonder what this has done on the volume. And look at how far we’ve come down the road in 15 minutes. Just looking at it and knowing our file system, knowing our evidence, trusting but validating it further and asking ourselves: Do we want to know more? And applying that, we could tell a really good story about what’s happened.
We’ve got a subject who has a hex editor who accesses a torrent program, basically clears all the data out, and we’re actually finding that some torrent activity on the system related to this file before the data is purged. Okay. We see this in cases, we see suspects getting rid of data, and this is revealing a lot of that.
So coming back to our three points, if we haven’t stressed it enough: know your evidence; trust but verify. And would you like to know more about it?
And bringing in Lexi back in, I don’t know if you have a story about cases that you’ve worked related to this, where you find something and then you start scratching at that surface and it’s like, Whoa, you ended up finding more to the story.
Lexi: Yes. So there have been a few cases that I have in mind where the evidence isn’t always what it may seem to be, but as you dig a little bit deeper, you really see the bigger picture and the story of what happened. And one case that comes to mind for me is an employment case where the employer found inappropriate images on their employee’s work machine. And when this case started, the employer handed us over about six hard drives that the employee used over last 10 years. And after we imaged and processed the evidence, it was an overwhelming amount of data. As you can imagine, it was literally 10 years of data. So the first thing we did was mount the images in BlackLight, and we went straight to media view and this allowed us to easily identify the photos and then the source of the photos.
But of course it wasn’t that easy. And the data wasn’t pointing to your typical internet downloads, torrent downloads, or even a copy from an external drive, which is pretty common in these types of cases. So we did a further analysis, and it showed that the inappropriate files were copied over to every drive this employee had. And we were able to identify this by backtracking the photos by the volume ID of each drive. And by this, I mean, we started with the most current drive that the employee was using. We identified the photos and saw that the volume ID for those photos was linked to the previous hard drive that he used. So we were able to backtrack this for all six hard drives.
After that we saw that the files were not accessed after they were copied onto the hard drive. So there wasn’t a lot of activity going on with these photos, but we still were facing the question, where did these files come from originally? They had to come from somewhere. And a deeper look showed that the metadata for these inappropriate files were linked to a second person who was not initially involved in this case. And a quick search of this person’s name showed that he was a former employee of the company and worked with the employee in question 10 years ago.
So to reel this in, in the end, the evidence did not suggest that the employee of interest was the owner of these photos. It seemed likely that he just simply copied a folder over from this former employee, which he thought to be hundreds of work files, but in the end, unfortunately, he was gifted a handful of inappropriate files, which would later on get him in trouble.
Now, the photos were on all six drives, but they were never accessed. And at first glimpse of this evidence, we would be quick to say that the employee in question was guilty, but as we verified the data along the way and connected the dots that turned out to be false, and you as the examiner need to dig a little bit deeper than the tool and verify your data, because the evidence is not always what it seems to be. And doing your job as a forensic examiner, typically someone’s reputation, job, or even life is on the line. So you need to make sure you have the full story and not really just rely on what you’re seeing on the tool.
MattL Yeah. Some good points there, Lexi, it’s an interesting case example of… you know, on the law enforcement side I’ve worked a lot of cases, and the one I relate to are the child exploitation cases where you find people in possession, but you know, where is it sourced from? When was it used? Is there evidence of use? Is there more to the story? Would we like to know more? And yeah, we should, to find out what exactly is occurring. And you’re right. You know, we may think, well, I’m a digital forensic examiner and, you know, at least the lab I had back then, it was like, there was no windows, they called it the cave, you know, “I’m going to go to my cave and examine.”
But we tend to forget that we are people that will find truth in these matters, and this truth, you know, it sometimes just corroborates information in our case. Sometimes it is the only information in the case that really brings light to something. You know, I’ve had some very serious personal crimes, including homicides, where they were really going, what is the digital evidence telling you? You know, and it’s our job to get in there and examine, to find evidence, to reveal the truth. We’re looking, you know, is there guilt? Is there innocence? What is going to be revealed here? And it’s coming down to, we’ve got to know our evidence, we’ve got to verify it, and we want to dive deeper in these cases.
So let’s see, anything more to add?
Lexi: Now, I think you said it spot on.
Matt: All right, Julie, we’ll bring you back in and kind of open up… if we got questions out there or things that we can help answer or clarify more.
Julie: Yeah. Sounds great. Thank you both. Those are really good examples. So we had a few questions come in. Let’s see here.
How about: let’s say you have a lot of data, where would the best place to start the investigation be from both LE and the private sides?
Matt: Lexi, do you want to maybe start with that one and I’ll close it up?
Lexi: Yeah, sure. So in my experience doing a lot of employment cases, we’re typically looking to see if maybe an employee took data. And external drives are huge evidence in cases like this. And I like to start with the link files, because you’ll be able to see if an external drive was plugged in and used, but not only that, but sometimes you can see what files were located on those external drives. So link files for me is something I like to start with in those types of cases.
Matt: Yeah. And you know, to talk on that. And it’s funny, cause you know, we’re obviously talking about the Windows based side of it here. We’ve got the MacOS side and other things and you know, in law enforcement and… as with, you know, a lot of cases, we’re going to take what we know about the case now. We’ve all had those cases where, you know, they give you the evidence. You’re like, what are you looking for? And I’ve got a “Just look, see if you can find something.” And I know we all love those cases. So we have those to contend with, but hopefully in our cases we have some lead, we’ve got a statement, we’ve got something pointing us towards a direction. And that’s where item one here, of knowing your evidence, as someone is telling you a case, you start thinking through, okay, what kind of evidence, what file system, what operating system? And then we start going, okay, Oh, I might want to look here. I might want to look in there.
And it’s funny what Lexi is saying is on our search warrants, we’d go out and, you know, kick in doors and be doing a child exploitation investigation on, you know, distribution or production case. And we would be okay, you know, time is of the essence because we’re onsite and we may have somebody on scene being interviewed and link files os a good one. Link files is a good one to go to, to try to find stuff. Recycled bin, my buddy USN journal, update sequence number journal is another one, but you’re going to go to your go-to evidence buddies, right? Where that may reveal something. But it’s good to have a good collection of them, because we’ve all had those cases where we’re looking and we go to our go-to buddies for evidence. We’re like, Oh, you got nothing? Nope. You got nothing? Nope. And you’re going, huh. I wonder if I have any evidence here.
And then that’s the challenge of digging around. Because I’ve had those cases where you’re going, man, I’m not finding anything. And then you dig into one more place and all of a sudden the whole case just pops out and jumps out at you. And you’re like, man, woo. Look at that. So, you know, it’s good just building up. And you know, it’s a plug for training. Definitely getting to train and expand our knowledge there. It’s a good plug for networking and having buddies that are other forensic examiners. I network daily with forensic examiners and you know, like what are you finding and where are you finding stuff? And what’s your go to, because you can call them up and, or message them, be like, Hey, I got this case, where should I go? And a seasoned examiner can help guide you as well.
Julie: Thank you. Okay. How about: how important is it to understand manually parsing data? How often do you do it and how does that technique play into everyday case investigations?
Matt: Okay. That’s a good one. I think the importance of understanding manually parsing data, to me, it’s vital. You know, when I first started, it’s a challenge, but this is a hill we’ve got to climb and learn these things. And you know, how does that apply to cases? How often do we do it? You’re probably not manually parsing data regularly in every case, but I can tell you almost daily through these listservs and networking that I’m involved in, I see those cases. I just saw one recently where it related to a master file table entry. And they were like, I’m not seeing something that should be here. Where is it? And without manually looking at it, you can’t answer it.
So basically when I do training, when I talk to people in the cases that I’ve worked, it’s nice when the tool gives you that data, you look at it and you hit the internet, you hit the USN journal. You hit things, and whether it’s MacOS or Windows or other file systems or whatever we’re dealing with, that data is there. That’s great and trust, but verify it.
But what happens when you click that button and nothing shows up? What do you do? Where do you look? And that’s where I’ve seen that in cases, where Firefox gave an update. We know Firefox updates like every five minutes, it seems. And maybe they changed their database structure and the tool, not to its fault, hasn’t kept up to the exact iteration of the Firefox, and it’s not parsing that data for you. And so you can manually go down and manually go in and parse this data out. So that that’s where it can really help you.
And the importance of it is, when I see that when you go to court, you’re not asked, Hey, you know, this tool parsed all the data for you. We trust this tool. So we’ll just rely on that. That doesn’t happen in court. You know, usually you’re going to court and you’re having — at least the times I’ve been in front of jury trials and court trials and hearings and stuff — it’s on you. Like Lexi said, it’s, it’s our job to be the ones that testify. The tool helps us for efficiency. It helps us to be thorough, but it’s on us to know this data and how it is stored, what it means and to be able to analyze it.
Julie: Thanks, Matt. Alright. How about this question: Can you find the same information in the trash on a Mac, as you would in the recycle bin on Windows?
Matt: I’m jumping on that one real quick. It’s a bit different. Not fully, but yeah.
I mean, we’re dealing with two different… well, MacOS would technically be the operating system. You know, we have the file systems of HFS+ or APFS, you know, that it works on, and then we’ve got on the Windows side, we have the different Windows operating systems and then, you know, FAT, exFAT and NTFS file systems upon which it was stored. So those recycle bins that function typically with the operating systems, they work a bit different. Now we have security identifiers versus on the Mac side, you have a UID or unique identifier. You know, you have the $recycle. bin versus the .trash or the .trashes for the users, in the root of the volume. So you’ll find them in different areas. And, and that’s where, you know, I think our strength at BlackBag we’ve been known for is on the Mac side. But you know, one of my colleagues, Bruce Hunter is phenomenal at Mac analysis and I’ve had to step up my game with my history. I’ve been analyzing Windows for 20 years, and there’s definitely some differences, you can’t transition over easily. So it’s good to know both.
Julie: Thanks, Matt. Well, we are getting close to the top of the hour here, so I want to just wrap up and say thank you to Matt and Lexi for showing us how to make sure you’re telling the whole truth using supporting evidence in investigations. And as a reminder, we will be sending this out as a recording afterwards. So please stay tuned and check your email for that.
If you’re interested in learning more about any of our products or services, please email sales@blackbagtech.com. And of course, be sure to follow us on Twitter, Facebook, YouTube, LinkedIn @blackbagtech, and subscribe to our blog on blackbagtech.com. Thanks everyone for joining us today and make sure you have a great rest of your day and stay safe. Thank you.
