Welcome, DEF CON, to Offensive Forensics, CSI for Bad Guys.
I am, if you can read, Benjamin Caudill, Principal Consultant of Rhino Security Labs.
And I kind of want to get this talk started off with a story as 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.
So naturally this was kind of the target for social engineering and spear phishing
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 lying 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.
And 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 these systems 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 Rhino 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 laughing.
Okay.
All right.
I'm going to start 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.
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.
Okay.
So this kind of is applicable or useful to us, not only in explicitly useful information
or explicitly sensitive information, so 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 technique
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.
They're inefficient for getting to the next level, moving laterally or getting passwords
or things like that.
And frankly, pen testing has 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
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 process is essentially grab the memory, pull the plug, do disk 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 hyperfill.sys, page sys, things like that, and of course
the Linux complements 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.
We don't have to worry about the legal side of things.
We don't have to worry about chain of custody, 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 data 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 kind of 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.
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 ‑‑ this is a technical thing.
It's not a forensic lesson, but more of an application lesson.
This ranges kind of from the simple, again, Windows clipboard, I use it 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 user information.
Add 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't
actually grab clear text passwords.
Another one I wanted to mention was kind of 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, 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 through 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 I have a question.
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 form history.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 bunny hole, this particular example was from a pen test I did
a while back of that same form history.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 MRU list, most recently used, what has the user been looking at?
Prefetch files, what has the user been running?
I use the example of truecryptformat.exe, a file that is only accessed or 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 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 of really good Metasploit
modules kind of specific to this subject, won't dive too much into that.
But backups and volume shadow copy service, another huge area you can get a lot of good
information on.
Kind of a quick horror story on this.
I was doing another pen test where 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 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 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 smart phone 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 phishing,
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 of these apply to every OS, every version of Windows, application version
and so forth.
So again, this is kind of where a interpretive script was born out of this.
Forensic Scraper, which using OS identification grabs and downloads all this awesome stuff.
Browser files, most recently used files, prefetch 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, 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 are sending that to DEF CON, I don't know if they have a place
for that.
It will be out there anyway.
Contact, there is my e‑mail address or you can find us on Twitter if you have something
else.
And that is all I got.