 Welcome DEF CON to offensive forensics, CSI for bad guys. I am, if you can read, Benjamin Caudill, principal consultant of Rhinosecurity Labs. And I kind of want to get this talk started off with stories to kind of how this concept came about. I was doing a pen test several years ago with actually when I was kind of a junior assessor for a financial institution in a case a while back where during the information gathering phase we had determined that the company had gone from kind of a decentralized infrastructure to a centralized one, which really just means that they have database servers now. So kind of during this phase we had discovered, enumerated a lot of information about the company, found out that a lot of their data assessors or data analysts had local copies of the entire PII database on their local system, which what can go wrong, right? So naturally this was kind of the target for social engineering and spear fishing and all these sort of things and managed to get access to several of these systems and we really only needed one of these PII databases to be golden. That was the whole objective here. Went after one system after another after another. Hours and hours of searching, days and weeks even and couldn't find anything, not a single social number on any of these systems. So we kind of wrapped things up, had the kind of post-talk discussion with the manager there where it came out that he had previously sent an e-mail out to the department saying, hey, if you have any of these databases still laying around, make sure you one delete them and two empty the recycle bin. Yeah, nice. So kind of just having finished up the pen test and so forth between my partner and I, we kind of became this guy as we realized that if we would have just looked at the MFT, grabbed a disk image of the system and really kind of done a, almost a forensic analysis of the system that we would have compromised, we would have had millions of social security numbers on any one of these given systems. So close. So this kind of concept really led to the concept I'm kind of talking about today, offensive forensics and this is really where I realized that if I would have taken a more forensics based approach to the post-exploitation phase and information gathering and so forth, we would have had a lot much more success. So again, this is not really a talk so much about the forensics side of things. It's more about forensics applied in a new and unconventional way. So again, I am Benjamin Caudill, principal consultant with Ronos security labs, have some experience in pen testing, social engineering, web applications, that sort of thing. About four years in security now, been with aerospace and defense industry. I mentioned finance a little bit, been doing consulting recently, kind of the normal stuff. About eight years in IT, so I'm a well versed nerd. And a number of certifications, but again, we're at DEF CON, so who really cares about that? Someone started drinking early. So the overview of the talk. So we're going to start with kind of the traditional forensics, a little bit about the background on that and what that means and kind of how this ties into everything. I'm going to jump into kind of the offensive side and offensive forensics, introduction of that, the basics and everything. And then I'm going to kind of do a deep dive into really the technical details here. Looking at the memory forensics, the potential and problems we have with that. Disk and registry, again, a lot of these examples are Windows based and kind of the potential and problems with the disk and registry side. And then towards the end, releasing a new Metasploit module to kind of cover all the things that I have previously discussed, some quick usage and hopefully a demo. So the traditional kind of digital forensics is essentially the recovery and investigation of material found in digital devices. Pretty simple concept, but this is a really useful idea for us as pen testers as we are essentially trying to get digital information from these systems. This kind of is applicable or useful to us, not only in explicitly useful information or explicitly sensitive information, social security numbers, passwords, things like that, but also implicitly sensitive. Things like a calendar, a contact list of the entire company. These are things that we can utilize towards social engineering, towards password cracking, a lot of other attack avenues that wouldn't be necessarily on a technical front, but can still certainly be very useful. So again, kind of a lot of the traditional forensics tools and really concepts are essentially for investigations, whether that's civil corporate, criminal, whatever the case may be. The objective for forensics essentially is to solve a crime, loosely speaking. So again, as a result of this, there's very few forensic tools that are very applicable to pen testers directly. So kind of on a more direct front then, offensive forensics is the use of forensics techniques for offensive purposes. And I kind of have the subtext here of again, improved social engineering, more efficient password cracking, being able to get a better dictionary list, for example, by again grabbing something like a contact list is very useful. And again, kind of going back to what I said earlier, this is really useful in a traditional post exploitation situation, where those kind of typical steps, post exploitation steps are really insufficient for getting to the next level, moving laterally or getting passwords or things like that. And frankly, pen testing is a time limit. You can't spend all day key logging a particular system, even if you do have access, and waiting for the user or the multiple users to go to a particular form, web page, whatever the case may be, it's much more easy, much more efficient to kind of do some of this forensic analysis and grab previous files like browser files, for example, and grab those and use those as a basis for your next steps rather than the key logging out route. So again, kind of comparing the offensive with the traditional forensics, the objective here is really to gain access to additional sensitive information, again, whether that's explicit or implicit. So again, the forensic comparison here, traditional forensics and offensive forensics have very different processes. Traditional forensics, again, even with a live analysis, the processes essentially grab the memory, pull the plug, do disc forensics and get a lot of those files that you couldn't access when it was live because they were being used by the OS. I use the example here of hybrid fill dot sys, page sys, things like that, and of course, the Linux compliments there. A live analysis for offensive forensics is very different because you don't have physical access or it's assumed that you don't. We can still grab memory. We have the benefit of not having to worry about the legal side of things. We don't have to worry about chain of custody, loss of potential loss or modification of evidence and really the legal analysis. But we also have the disadvantage, again, of a lot of the permissions issues in Windows or whatever your OS is, prevents you from accessing a lot of those core OS files that we would want to access. So, again, there's a little bit of a difference. Some of those files are less useful than they would be otherwise. On the dead analysis, again, it's assumed that you have physical access to the box when you're doing a traditional forensic analysis of things, which we can also kind of presume is the case with offensive forensics, but is not as common. In addition to that, also, we lose the potential user interaction or live memory exploitation of having the user actually be on the system at that time. If you happen to be typing in your password at the same time that I'm grabbing a memory dump, I win. So, again, for the offensive forensic side, when we're actually doing a pen test, more often than not, this is going to be a remote attack or a remote or a live analysis scenario. So I'm going to kind of focus on the live analysis situation from here on out. So kind of diving more into the technical details here. On the memory side, we have a wide range of things that we can look at. And, again, memory forensics is in itself its own science. So this isn't, again, not a forensic lesson, but more of an application lesson. This range is kind of from the simple, again, Windows clipboard I use as an example, applicable when you're talking about password managers, copy, paste, if I grab it at the right time, again, clear text passwords. To kind of the niche command line history, I've never actually seen this myself, but DOS key slash history will give you a full list of everything the user has typed in that given session. Again, theoretically, this could bring up anything from added users for like a sysadmin case to FTP, telnet sessions, and any number of other things. As well as kind of a more fragmented subject, things like passwords, key files, encryption keys. At the very least, you can grab encryption keys and things like that. There's numerous papers on TrueCrypt, for example, being able to grab the encryption key and open containers. But, again, as I mentioned with the Windows clipboard example, in certain cases, you can actually grab clear text passwords from any given process. Another one I wanted to mention was kind of on the, almost on the privacy side, is private browsing and sandboxing. There's a lot of, kind of despite the moniker of porn mode, a lot of these private browsers are actually used by users because of the implied sensitive nature of the browser. You can't, there's no records kept and so forth and so it would be theoretically more secure to go to your bank or go to a sensitive site, things like that. And, again, there's multiple papers on the flaws with a lot of this logic. The one that comes to mind is IE's in private, which actually writes files to disk during that private session. It deletes the files at the end, but, again, going back a slide or two, being able to recover those files to the MFT and grab those deleted files essentially allows me to replicate or look into your private session, which who knows why you're doing that. Along the same line, another kind of example of this is when you're actually catching this in memory, there's a lot more kind of unique identifiers for nearly every one of these private browsers that if you were to catch it in memory, do a memory dump or so forth, you could actually identify that this is running as a private session, which, again, could highlight kind of to the pen tester why the user is doing that and might be something to look at specifically. And actually, we are working on a volatility plug-in to do exactly this, but I wasn't able to get it done today, so look for it. On the disk and registry side, there's a number of files here that I'm going to list and kind of areas really to look at. The first one that really comes to mind here, kind of through my own research, was browser files. Every one of the four or five major browsers has some sort of browser leakage to one extreme or the other. But all of them are useful. I use the example here of Firefox, really just to pick on them, but all of them are kind of the same case. I list a number of Firefox files here, key3.db, kind of from the obvious or the simple password files, bookmarks and history, again, in the right context, certainly useful to things that are a little bit more subtle but certainly interesting, like the formhistory.sqlite file is something I'm going to look a little bit more into, which provides all the saved form data for the particular browser. So kind of following that bunnyhole, this particular example was from a pen test I did a while back of that same formhistory.sqlite where we got essentially full credit card data of the particular victim. Pretty crazy stuff. But in this case, obviously didn't help with the actual pen test. Moving forward, though, we actually did a little bit more analysis here and found that there was both a clear text account or a user name, essentially, as well as clear text recovery questions to actually reset that account. So kind of using some of those previous things I had mentioned, this particular database, the HR database, actually, was being used and this in conjunction with the saved password or the saved history, I was able to actually reset the password on this account and get access to the system. So some more examples here of kind of things to look at. The MRE list, most recently used, what has the user been looking at? Prefetch files, what has the user been running? I used the example of truecryptformat.exe, a file that is only accessed, specifically the prefetch file, a file that's only created really, when the user has actually created a truecrypt container on that system. So this is really the difference between finding truecrypt on the system and believing they may have a truecrypt container on there and actually knowing for sure that there is a truecrypt container out there and where to actually find that. Another big one, kind of as I mentioned at the very beginning, was deleted file, slack space, again, a huge subject in and of itself, but there's a couple good, really good menace wave modules, kind of specific to this subject, won't dive too much into that. But backups and volume tele copy service, another huge area, you can get a lot of good information on, kind of a quick horror story on this, is I was doing another pen test where the, I was able to get on the system of a sys admin who regularly did the password resets for users and found out very quickly that after every single one of these password resets, he would clear the entire log of his chat history, which is where he gave the passwords out to prevent exploitation or data leakage or whatever the case may be. But he never actually deleted the file, so I couldn't, you know, grab it through the MFT or delete files or so forth, but he did have the volume shadow copy service running and when I accessed that, I could see all the previous conversations from previous backups of this and actually access all those previous passwords he had given out. A couple more examples, crash dumps, again, theoretically this is something that's useful, typically this is really only kernel memory that's being dumped on a Windows system anyway. This is also really useful though as these, this can be changed. This is a setting in Windows, again, it's something to look at if you find it. And the last one here is kind of a list of miscellaneous things, calendars, address books, other smartphone backups, again, you can get contacts, pictures, GPS data off of iTunes backups, things like that, print spools, you know, what has the user been printing and a ton more. And again, this is a lot of implicitly sensitive information you can use for spear fishing watering holes, again, more efficient password cracking using tools like cup and so on and so forth. But really, we have the issue of as we get more files to look for, more potential, we also have the problem of practicality. Looking through these, let's say, 500 files, it's going to be very difficult and very time consuming to actually do this all by hand. Again, not all these applied every OS, every version of Windows, application version and so forth. So, again, this is kind of where a meterpreter script was born out of this. Forensic scraper, which, using the OS identification, grabs and downloads all this awesome stuff, browser files, most recently used files, prefetched data, Windows crash dumps, print spools and a ton more that I can't even list here. So kind of a very quick demo, because I'm running out of time here. It's a very simple Metasploit application or Metasploit module here. It's pretty much a point and shoot. I threw up a couple of quick snapshots here. The first is some IE cookies. You can see in the Windows directory there. And very shortly thereafter is network shortcuts, which is all the network shortcuts that are saved under my computer. Again, useful stuff. This is another example where they had two browsers on one system and you can actually see all the stuff in yellow is all the Chrome files that were grabbed, including cookies, history, login data, passwords and things like that. And the Firefox is all the information that I had mentioned previously, again, that form data, downloads, login data and so on and so forth. So for QA, for QA, there is a QA room actually afterwards. You can find me there. I will be there for a little bit on this actual forensic scraper module. We will be releasing this within the next couple days or so. So look for that either on the website or we're sending that to DEF CON. I don't know if they have a place for that. It'll be out there anyway. Contact, there's my email address or you can find us on Twitter if you have something else. That is all I got.