Hello, everybody. Welcome to DEF CON. I'd like to introduce Michael Perklin with ACL
steganography. Take it away. Thank you. You're welcome. How's it going, guys? And girls.
I'm happy to be here at DEF CON again. I think this will be an interesting talk for those
of you who are interested in hiding things or finding hidden things, depending on if
you're a black hat or an investigator. My name is Michael Perklin. I'm a security professional.
I'm a corporate investigator as my day job. I specialize in cyber crime. And I'm a digital
forensic examiner. Basically I take the computer geek side and I take legal support, sort of
smash them together. That's what I do. In this talk I'll be talking about what steganography
is and I'll go over some examples that ‑‑ some classical examples, not digital examples,
on how steganography was used before computer.
Then we'll go through some digital examples to see how they work under the hood. And finally
I'll talk about ACL steganography, which is a new scheme that I came up. That will take
up the bulk of the presentation. So let's get started. What is steganography? It's
a Greek word ‑‑ sorry, the origins of the word are Greek and it means concealed
writing. There are two roots of the word. Steganos, which means covered or protected.
I apologize if I'm butchering the Greek. I may have Greek roots but I've never spoken
the language. Sorry, grandma. The term was first coined in 1499. But there are many earlier
examples of where steganographic techniques were used before the word even existed. Basically
it just means hiding something in plain sight. So let's go through some classical examples.
First example I want to show is a tattoo. Basically somebody would take one of their
slaves. And, again, this is basically a tattoo. So somebody would take one of their slaves.
Back in the day when people had slaves. They would shave the scalp. They would tattoo a
message on the scalp. And they would wait for the hair to regrow. They would send the
slave over to the recipient of the message with a package. And as they were delivering
the good, when they would find some private time, they would shave the head, they would
read the message, and the message was delivered. So it looks like the slave is going there
to deliver a package. But in reality there's a whole hidden message hidden under the hair.
A couple problems with it.
Mainly that the message has to be delayed. Because after you tattoo a message on someone's
scalp, you need the hair to regrow. There's also other problems with this scheme. Tattoos
are permanent. No regrets. Another example of classical steganography is using Morse code.
Some people would stitch some longer stitches and some shorter stitches on a jacket or sweater
or a shirt. And that would conceal a message.
On the person. The messenger would go. They would hand deliver one note. But as the recipient
would take the note, they would read the sweater and they would learn the second message, the
true intention of the visit. Here's an example of a tapestry that was stitched by a prisoner
of war in 1941. You can see there are two borders with some dots and dashes. And that
was Morse code. So this prisoner of war was hoping that, you know, by the time he was
delivering this tapestry, they would get a message out saying, I'm okay or whatever.
If you are interested in what the message says, you can grab the talk online and you
can decode it yourself. The next classical example is invisible ink. This is a very simple
technique but it's quite effective. Basically you would use lemon juice or something acidic
and you would write on top of a piece of paper with this liquid. Allow it to dry and
then you would deliver the paper.
paper to your recipient. The paper would have other writing on it so it would look like
it says one thing. But what happens is the acid in the lemon juice or the acidic liquid
that you use breaks down parts of the paper. So when you put that piece of paper over heat,
it would start to burn. But the parts that were broken down a little bit more by the
acid that you added, they would burn first. The result would be ‑‑ it would turn
darker and you could read the message that was written with the liquid. This is a lot
of fun to do if you've got young kids. I've done it with my nephews and they've really
enjoyed it. Now let's take a look at some digital steganographic methods. First example
I'll talk about is photographs. This is one of the most common types of digital steganography.
You can encode one file as color information inside a photo. This uses the fact that only
superhuman
humans can tell the difference between lemon and chartreuse. And by superhuman I mean the
fair sex in the audience. Each pixel is assigned a color with an RGB color code. And the very
last bit of this color code will always be part of the secret message that you're encoding.
So the example I have on screen here is DFFF00. That's chartreuse. That very last zero is
part of the message that you're encoding. Another example is DFFF01. That's not the
chartreuse. It's something similar. So the difference between the two colors is imperceptible
to most of us. But if you look at the very last digit for all the adjacent pixels, you
can rebuild a whole other file there. Eight adjacent pixels yields one byte of encoded
information. Audio steganography is a similar concept to the photographs. But it uses sound.
And again, it's based on the photographs. So, you're basically creating a single work.
fact that humans can't tell the difference between 400 hertz and 401 hertz, especially
if the note isn't sustained for a long time. After each frame of audio, one bit is encoded
in that frame. If you get a bunch of audio frames, you can encode a bunch of bits, you
get your bytes and now you've got your message. If you're interested in this kind of stuff,
I urge you to take a look at John Ortiz's work. He's a presenter at Black Hat. Some
of his presentations are really interesting. They go a lot further into both photographs
and audio steganography, more than just using one bit. Some really neat math tricks you
can do to encode a lot more information. So look up John Ortiz if you're interested.
Another digital example I'm going to talk about is x86 ops. If you take a ‑‑ if
you have a portable executable file or an EXE file, you can encode information inside
of it using operations that don't really have an impact on the program as it's running,
such as the NOP or the NOP code. This is an operation that does nothing. So if you have
three NOPs, that could mean one thing. If you have five NOPs, it means something else.
You can also use complementary operations like add one and then subtract one. The result
is nothing, but by having an add one and a sub one, that could mean something. Maybe
add five, subtract one. That could mean something. You can also use complementary operations like
sub five, it means something else. Any complementary operations would work, like multiplication
and division. As long as you have some kind of a scheme to write this, it works. PE files
or EXE files, they have a lot of other areas where you can encode information. This is
looking at some of the raw bytes and hex form of a PE file, and you can see that there's
a lot of space there. You can jam data that isn't expected by the user, but it wouldn't
impact the running of the program.
But it would hide data. So if you send this EXE to someone, they can decode it on their
side. The last digital example we'll be talking about is chafing and winnowing. This is probably
the most interesting one for me, at least. It was conceived by Ron Rivest in 1998. He's
the R in RSA. He also made the RC4 algorithm that a lot of the WP stuff was based off of.
Chafing and winnowing isn't exactly encryption, and it isn't exactly steganography. It's sort
of a hybrid of both, but it isn't really either. It's sort of a hybrid of both, but it isn't
really either. It has properties of both. What happens is the sender doesn't only send
his message. He also sends a bunch of gibberish as well. So anybody who's listening sees the
message and they see the gibberish all at once, and they don't really know which one
is which. But the sender is very careful that whenever he sends a piece of the message that
is truly part of the message, if you were to run a calculation on it, like a parity
check or some other calculation on the contents of the message, it will always come out to
a certain value. And if you were to run this in a different way, it will always come out
to the same calculation on one of the chaff packets or the non-message packets. It would
not yield the same result. So the receiver, whenever they receive a packet, they would
run the same calculation on it. Anything that matches the expected value must be part
of the original message. And if they run the calculation and they get a different result,
it must be part of the chaff, and then they can discard it. Here's a visual example.
You can see on the left, there are four pieces of this message. And the contents of the message
are the bits. One, two, three, four, five, six, seven, eight, nine, 10, 11, 12, 12, 13,
14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24. And a lot of these are from Alice. And the
right side, this is what Bob receives from Alice. And some of the packets have an even
Mac code, so those are the legit pieces of the message. The rest of the packets all have
a odd Mac code. So Bob knows to discard these and only use the ones that have an even Mac
code, and that must be the message.
You can reassemble those together and get the original message.
All right.
So we talked about a couple of different types of steganography.
They all have something in common.
They have three things in common.
Number one, you need a medium of arbitrary information.
The medium could be your scalp.
It could be a tapestry.
It could be a photograph.
You need to have a key or a legend, a way to encode data.
If you encode this way, it means that.
If you write that, it means something else.
And finally, you need a way to differentiate between this encoded information and the rest
of the medium information that is expected to be there.
So these three things make up steganography.
And with that, let's talk about ACL steganography, the scheme that I developed.
It's a way to encode files as access control entries within an access control list on a
file on an NTFS file system.
That was a mouthful.
The medium is any file that's on an NTFS file.
The key is security identifiers within the access control entries.
And the differentiator between the message and regular stuff is access control entries
with an unlikely combination of permissions.
Before we get into more of how the scheme works, I want to backtrack a bit and talk
a bit about how NTFS security works under the hood just so that we can understand how
the scheme works.
So on screen here are two images.
The one on the left is NTFS.
The security tab of the properties window for a file.
This shows that there's a user, Michael, who has read and execute permissions on the file
that has been right clicked.
On the right side, we see the computer management window.
This is where Windows adds users and you can manage the users.
And there is a user, Michael, there.
When I'm pulling up the properties for this file on the left here, Windows doesn't store
the permission entries by name.
They don't say that Michael has read, write and execute permissions.
They say that security identifier 12345 has the permissions.
As I'm pulling up this property window, Windows will take a look at the users, will see that
security identifier 12345 matches with user Michael, so it displays Michael nicely for
me so that I'm not really confused.
I know that Michael has read and execute permissions.
There's a lot of permissions that you can set for a user, a lot more than just the five
or six that you see on the left screen.
There are 22 unique permissions in all.
However, they are stored in only 14 bits of information.
This is because a lot of these bits are reused depending on what you're setting a permission
on.
For example, for directories or folders, if you have the ability to traverse that directory
to open it up, that's one permission you need to track.
But you don't traverse a file or list the contents of a file the same way you do with
a directory.
So some of these bits are reused depending on if you're looking at a folder or if you're
looking at a file.
There are a bunch of unused values which I assume are left there for future expansion
of NTFS.
But as you can see on screen, there's a lot more granular permissions than just read,
write and execute.
This slide here shows the difference between the simple and advanced view of the permissions.
On the left is the file that I was showing earlier.
And on the right.
You see quite a lot of permissions.
And I'm not sure how well you can see all the entries on the right.
But there's a slash there that shows that one bit would be used for either traverse
folder or for execute file.
It's the same bit.
But depending on if it's a folder or a file, it has a different meaning.
So I mentioned security identifiers.
Permission entries are stored using security identifiers.
If a user is removed, the operating system can't look up the friendly name to show in
that dialogue.
This is the same file with the same Michael user who had read and execute permissions.
But I've deleted the Michael user from the operating system.
And you can see here that the top entry in the list, it says S1 yadda, yadda, yadda.
That is the security identifier for the user Michael.
And because Windows can't look it up, it can't display Michael.
So this shows that NTFS stores all these permissions by identifier and not by user.
Let's talk a little bit more about the identifiers.
They have a maximum size of 68 bytes.
The first few bytes are pretty much static.
The first byte will always be one.
That's the revision number.
Microsoft hasn't released a second revision of these security identifiers.
The second byte is the count of the number of sub authorities that will be in the rest
of the SID.
The maximum number here is 15.
That's the most ‑‑ the highest amount of sub authorities you can fit into a security
identifier.
Six bytes are used for an identifier authority.
There's too much about that to go into great depth in this talk.
But for our purposes, we can just say that the value will always be four.
And finally, the last 60 bytes store the contents of all the sub authorities.
All right.
We've gone through a lot of acronyms.
Let's do some acronym review or some AR, as I like to call it.
There's an access control list or an ACL.
That is a list of access control entries.
There's an access control entry, an ACE, which is a permission rule which says allow these
permissions for this SID or deny these permissions to this SID.
And finally, there's the security identifier, the SID.
That is a unique identifier for that user or group of a Windows system.
All right.
Enough slides.
Let's do a quick demo.
All right.
This is the part of the presentation that I was most worried about everything breaking.
But everything looks okay.
Nothing crashed yet.
Okay.
So this is a Windows VM.
Let's put it in full screen so we can see a little bit better.
All right.
So I have prepared a file that I'm going to include.
I'm going to encode using this ACL steganography scheme.
I'm going to encode a true CRIP volume.
So I've created a true CRIP volume.
And that's this here, the local disk T. Inside I have a bitcoin wallet.
It's just a simple file that holds all my bitcoin keys for this example.
I'm going to encode this bitcoin wallet and hide it in my file system in a way that cannot
be easily found by a forensic investigator.
So let's dismount this true CRIP volume.
We want to make sure it's not in use.
Before we encode it.
All right.
Now that that's done, I have also prepared ‑‑ okay.
So here's the true CRIP volume that I will be encoding.
I need to put this file into ACL entries on a set of files.
So I've prepared 16 text files that I will be using to hold this true CRIP volume.
Let's take a look at the permissions of some of the files in here.
I'll just choose number one.
Right‑click properties.
I'll go to the security tab.
And you can see there's default permissions here.
Authenticated users, the system, nothing fancy here.
So now that we know what the permissions look like already on this file, let's encode
some data into it.
So I'm going to launch the ACL encode utility that I've created.
We'll choose the file that I want to encode.
In this case it is the true CRIP volume.
This is what I'll be placing into the ACL entries.
Next I have to choose a file list.
It's a simple text file that says which files should I use to encode this data.
So I'm going to create a file list real quick.
I will go to the test folder.
Take all 16 of these files that will be in our list.
And I will save the file list.text right here.
Okay.
So just so you can see what that did.
It created a simple text file.
With one entry for each of the files that I selected in that dialogue.
So I'm now going to encode the true CRIP volume into all of these 16 files.
And it's as easy as clicking encode.
It takes a little bit of time because as you can imagine it has to split up the file into
a lot of different pieces and convert these pieces into ACL entries and put each of these
entries on all the 16 files that I've chosen.
For this example it takes about 27 seconds.
I've timed it.
In addition to splitting up the file, it also needs to do a couple of other things
like add the security identifiers to a special part of the volume called the secure file.
I'll go into more depth about that a little bit later in the presentation.
And there we go.
The file has been encoded.
So now if we take a look at the test files, they look like they're regular files.
But if we take a closer look at the security permissions, we'll notice that there's a lot
more entries here than there were before.
Each of these entries don't have an associated user account within Windows.
So Windows can't look up a friendly name like Michael to display.
So all these values here are the ‑‑ is the bitcoin wallet that has been put in the
true curve volume.
Now that we've written it, let's take it out.
And it's the exact opposite.
In this case I'm going to change the target.
Let's say out.
So it will make a true curve volume.
And we'll hit decode.
Decoding is a lot faster than encoding.
It started to create the file.
It's chunking out.
And shortly we should see that the file has been decoded.
And it has.
So this is it here.
You can see that the file size is the same, 292 kilobytes.
Let's test if it works.
We will mount this using my super secret password.
And there it is.
Open it up.
And there's the wallet.dat file.
So we've successfully encoded it and decoded it.
It worked.
Come on.
I'm having a hard time getting out of this VM.
Yeah, drink.
.
.
.
.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Key shortcut is not working.
I'm trying command F. There it is.
Okay.
Yeah, drink harder than the audience.
Yeah, I think that deserves it.
All right.
Let's put empty empty back together.
together again. Get back to here. Okay. So we just went through the demonstration. Let's
take a closer look at how this worked under the hood. What was the program doing behind
the scenes? So the file that I encoded, it was a Truekit volume. When I hit the encode
button, it chunked the file up into 60‑byte chunks. You can see on the screen behind me
there are yellow chunks and blue chunks. In this example, I'm only using a file list
of two files just for simplicity. In the demonstration, I chunked it up into 16 files. So there would
be 16 different colors instead of the two you see. But each chunk becomes an SID. There
are two files in the diagram, file one and file two. File one is on the left. The first
chunk will be written as an SID and it will be encoded there. The second chunk will go
to file number two. Third chunk will go to file number one again. Fourth chunk will go
to file number two again and back and forth until the entire file has been encoded.
All the ACEs are created with an allow permission and it allows that SID to do certain things.
Each of these ACEs are added to the ACLs for all the files listed in the file list.
When it's doing this, the order is important because we need to know where chunk one goes,
where chunk two goes. So when we decode it, we reassemble all these chunks in the right
order. Also, just like the chafing and winnowing example that we went over earlier, the order
is important because we need to know which ACEs are legitimate and which ACEs belong
to my encoding scheme. So there's a way that I do this. There are two bits set in every
single permission for an ACL encoded entry. It's the synchronized bit and the read permissions
bit. The reason why I chose these is mainly because the synchronized bit cannot be set
within the Windows UI. If you go to the security tab of a file within Windows and you go to
look through that long list of all the advanced permissions, you will not find synchronized
there. It's a sort of a hidden piece of Windows that's used for thread synchronization. It's
used under the hood for parts of the Windows operating system and it's not typically available
to a user, although you can set it programmatically, which is what I've done. And those two bits
are red in the diagram you see here. The green bits are what I use for encoding their position
within the overall file.
So the last nine bits are used as a counter with values of zero through 512. The first
bit is ‑‑ sorry, the first chunk will be encoded with a value of zero. The next
chunk will be encoded with a value of one, two, et cetera. So it can hold all these.
The file list that we're using, the list of all the 16 files that I chose, that becomes
kind of like a symmetric key between the encoder and the decoder.
Because without that file list, you don't know what order all your entries belong in
and you don't know how to reassemble them. So the list identifies which files on the
NTFS volume have ACL encoded entries and the list also identifies the order in which
those entries are encoded. Now, as you can imagine, there are some limitations. An access
control list can be no larger than 64 kilobytes per file. This is a limitation of the Windows
operating system.
Now, each access control entry in the list has a maximum size of 76 bytes. That's 68
bytes to encode the SID plus an 8 byte for a header which says allow or deny and some
other details of that access control entry. This produces a theoretical maximum of 862
access control entries per file. Even though we can cram 862 entries per file, I've imposed
a limit of 512 per file. And this is mostly because you need room for legitimate entries.
If you remove the ability for everyone to read a file or for the administrator to write
to a file, you can't use that file at all. So there has to be some room for real permissions.
That's why I've imposed the limit of 512.
So using these numbers, excuse me, that means that the largest possible file that you can
encode is by this calculation here. The number of files in the list times 512 times 60 bytes
or about 30 kilobytes per file. That's the number of files in the list times 512 times 60 bytes.
file. So the larger file that you try to encode, you need to have more and more files in your
file list to accommodate this. Each file in the list allows you to encode 30 kilobytes
more data. So if you need a larger file, use a longer list. There's another limitation,
the secure file limitation. Now the dollar sign secure file, that is a hidden file that's
on all NTFS volumes. This file is like a mini database that stores all of the security information
for every file. It doesn't matter if it's in C Windows or C users, any file anywhere on the
volume, all of the permissions for every file are all crammed into this one file called the
secure file. Now every time a new security identifier is encountered, Windows adds that
SID to the secure file. It does this so that in the future if you're trying to read or write
permissions of that file, Windows will be slightly optimized and it will know that
there's a security identifier in the secure file. So if you're trying to read or write
permissions of that file, it will know that it's there. It sort of caches it. Now, NTFS
does not remove old or unused SIDs from the secure file, even if all the files ‑‑ all
the files that user used to be able to read or write have been deleted. So you can delete
the Michael user. You can remove every single file that Michael ever had permissions on,
but the SID for Michael will always still be there.
It's designed to grow in size and never shrink. This imposes kind of a severe limitation.
Every single chunk of an ACL encoded file will always persist in the secure file forever.
So the more you try to encode data, the more data will be eaten up by your file system
and you won't be able to recover this, even if you try to clean it up. Now, if you do
some manual hacking, you might be able to remove them manually.
But that's beyond the scope of this talk. Let's take a look at how this works or how
this looks to a forensic examiner. I mentioned that I'm a forensic examiner and I have access
to a lot of forensic tools, so I figured what better way to test this than to turn
my tools on to it. So I took a 2 gigabyte USB key and I formatted it as NTFS and then
I used two of the most common forensic tools in the industry, access data's FTK and guidance's
N case forensic. I used slightly older versions of these tools because they're more widely
known and more supported, but even the newest versions of the tools have the same results.
So in order to do the test, I prepared a couple of test files. Again, I created a
folder with a bunch of text files as my list of files that I'll be using. And I created
a file list.txt which lists all those files.
Then I created an imposter.
I wanted an input file that had contents that were nowhere else on the volume so I'd be
able to search for it easily to see where it came up on the volume. So I created a 4
kilobyte text file with just DEFCON XXI repeated over and over and over again. This would allow
me to search for it later to find it. Let's see how access data's FTK4 held up on this.
This is FTK4. We're taking a look at the list of all 16 files. You can see on the bottom
half of the screen.
File number one is selected. And FTK is showing us the owner of the file. And it's showing
us all the other properties of the file like the size and the date that it was created,
the date it was last modified, et cetera, et cetera. But it does not show the access
control lists. So I started hunting and pecking all throughout the program looking for where
I can see the security permissions on the files that are listed in FTK.
FTK lists a lot of different fields within NTFS that you're able to view. None of these are
the access control lists.
So I found that FTK4 has no way to show what permissions were set on a file. I contacted
their tech support and I discussed the issue with them. They assured me that there was
no way. I discussed it on their user forum asking if anybody knew of a way to see which
which users had permissions on the files that are being analyzed in FTK4 and the consensus
was use another tool. So FTK4 cannot do it. However, FTK4 can still analyze the dollar
sign secure file and sure enough if you manually search through that secure file, you can see
some of the contents. This is 60 bytes of DEF CON XXI repeated. This 60 bytes is one
of the SIDs for one of the files that was encoded. So you can still see the data buried
in the secure file, but it's not in an easily presentable list. And of course in this case
I'm searching for a file that ‑‑ for values that I knew was in the input file because
I put them there. If TrueCrypt was used or something was used that would encrypt the
data in a way that I couldn't search for it easily, this would just be more gibberish
and I would have no idea that this was part of an ACL encoded entry or something like
that if it was just a random SID. Let's take a look at NK forensic 6. There are a couple
of different view modes you can have when you're looking at a file. Right now we're
looking at the home view of the entries list and you can see all 16 of the files listed
there. File number one is selected on the right. So that's the file that we're looking
at. Now the second arrow is the permissions tab. When you click on the permissions tab,
you can see the permissions of that file. You can see the permissions of that file.
And here you can see there's an access control list for that file. The very first one, S14,
yada, yada, yada, that is the permission list for that one file. Now if I want to take
a look at the permission list for another file, I have to go back to the home folder,
choose file number two, then click back on the permissions tab so I can view the permissions
for file number two. I want to look at file number three, click home, click file three,
click permissions.
It's a very manual process and no investigator has the time to manually inspect all the permissions
for all the files on an NTFS volume. And again, if we take a look at the dollar sign secure
file with an N case six, you can see the contents of some of the SIDs. Defcon XXI is
shown there in the bottom left of the photo. And in addition to the one SID that's highlighted,
there are two other SIDs that occur later in the secure file. The first one is the
SID, again, 60‑byte chunks. Each of them have Defcon XXI repeated.
So the forensic detection of ACL encoding, it's a very manual process using the most
common tools in a Forensic Investigator's Tool Kit. Sure there are other tools that
may be able to view access control lists more readily, but they aren't the standard go‑to
tools for Forensic Investigators. Now, you can detect some of these, and you can also
using an automated way. NKS forensic has a scripting language called N script. You can
write some N scripts to automatically go through every single file, look at the access control
entries, compare each of the entries with the SIDs that appear in the Windows operating
system you're analyzing. If there are differences, so there are entries on a file that don't
match anything on the operating system, well, maybe this should be looked at. So you can
automate a script to show everything to you in a nice way, but that's over and above this
talk. And it looks like I'm out of time, so I can't even tell you about that. If there
are questions and answers, you can come see me in the speaker Q&A room. I want to thank
Josh, Nick, Joel, Rish and Kyle for their help in testing this scheme. Thanks to my family,
my friends, my colleagues, and special thanks to Eugene Philippowitz for seeding the thought
in my mind. How can I hide data on a drive without
detection? Thank you.
It seems that I wasn't actually out of time. So if there are questions, I have ten minutes.
So if someone wants to ask a question, you can. Come here, see this goon if you have
a question, and I can answer it. But in ten minutes, I will be in the speaker Q&A room
for better questions. Yeah.
Let's see. Yes, sir. Can we have the mic turned on, please, for the audience?
There we go. All right. Would there be any way to implement
this, say, into Mac OS's ACLs? Yes. There would be a way to add this to
Mac OS. The scheme that I created was for NTFS entries using SID's. The way that it's
that macOS, they use an HFS file system. You would have to encode it in a different way.
But this scheme could definitely be adapted for that. It's just a matter of writing the
tool to get it done. Cool. Thanks.
Thank you. Nice job, by the way.
I'm sorry? Nice job. Nice job.
Oh, thank you. All right. So I got here a little late and
I missed the entry point apparently in the beginning of the presentation.
I'm sorry. I'm having a very hard time hearing that mic.
He can't hear the mic. Have it right now.
No? I just hear echoes. I'm sorry.
Here, come on the stage. Tell me your question.
Just ask me your question and you can repeat it.
.
So the question was for streaming media. If you were to take a file and stream it, let's
say from a cloud, can you use this encoded information and distribute it through a stream?
I would say no to that because this scheme doesn't store anything in the file itself.
It stores it in the metadata about the file that the hard drive is holding. So all the
access control lists, this is within Windows. It's for the file. Once you start distributing
the contents of a file, you're not even touching the metadata, so that's not going to be distributed.
Hi, there. So I guess my main question here is how could I avoid detection with this method
when we're modulating communication?
Why can't I just write something that computes entropy and automatically detect if someone's
doing this? Because it's a deterministic place to drop in subchannel or covert channel communication.
So how would you compare this to then using TrueCrypt with a random offset deep in the
file system where I've already randomized the free blocks? This to me looks like it's
immediately detectable.
By using statistical and standard communication entropy calculations. And maybe
that's beyond the scope of this meeting, but it's a curious question I have.
It is a little bit beyond the scope. As far as detection goes, as long as you're able
to see the entries, you'll know that there's something there. You won't know what is there,
but you'll be able to tell that there is something. Now, as far as encoding the entries in a way
that would not be detectable, so it's a little bit more of a covert subchannel, you can always
adjust the scheme in a way so that each of the SIDs you create are valid SIDs that are
in the operating system. But I would imagine that by doing that, you would have to store
much less than 60 bytes per chunk, which would mean you would need far more values
to store a much smaller file.
Yeah, but someone in your position that wants to detect someone doing this, a traditional
NTFS file system just has blank data in these areas. Now someone is jacking in a modulation.
Into some bits that are unused ACL bits. To me it seems it would be immediately detectable.
Because you're not bearing it in with the normal randomness pattern in the drive somehow.
True. It would definitely be detectable if you're looking for it. But in most cases,
you're not looking at the access control list for the data that you're analyzing. If I'm
doing, let's say, an intellectual property case as an examiner to see did somebody exfiltrate
data from their company, I would look for common things. Did they use a USB cable or something.
key to get data out, did they email themselves, did they do all these things. I'm not about
to start looking at all the access control lists on every file on their desktop computer
or on their laptop to see if they have encoded that information. But of course you can have
a script that would automate checking for these now that we know that this scheme exists.
But again, it's a cat and mouse game. You come up with a better way of getting around
the controls. Well, now you get controls to detect that. It's a cat and mouse game.
All right. Thanks. Thank you. Anyone else? Do we have time for one more?
Time for probably two more. Okay. Two more. These are the last two questions
here. I was wondering if you were familiar with
NTFS alternate data streams and if the scheme can work for files hidden through ADS.
Sorry, did you say NTFS alternate data streams?
Yes. Yes. I am very familiar with it. Both FTK and NCASE support detecting alternate
data in these alternate data streams. For those who aren't aware of it, if you have
a file name, like let's say file list.txt and you double click the file, you're looking
at the first stream of that data. It's possible under the hood, using some command line tools,
you can have two separate files that are both assigned the same file name, file list.txt,
so you can take a look at the second one. Do you know if those files hidden through
ADS follow the same permissions? Sorry.
Do the files hidden through ADS follow the same permissions?
The question was do these alternate data streams use the same permissions, and they do. It's
because the permissions, the access control lists are assigned to that file by file name.
Whether there's one, two, or ten different alternate data streams within that file, it's
all the same permissions as a master file. Thank you. That was a good question.
All right, last question. Can you hear me?
Yes. Here.
Okay. So the dollars secure file ends up having all this extra junk. Have you considered
using that to place stegotext since you can directly manipulate it, I mean indirectly
manipulate instead of directly manipulating the files?
The question was about the dollar sign secure file and if you could use that to place the
can embed stuff within the dollar sign secure file as a method of stego. That's actually
exactly what ACL encode does. It chunks it up and throws it in the dollar sign secure
file. By adding an entry to a file on a hard drive, that SID gets put into the dollar sign
secure file by Windows automatically. You don't need to manually put it in dollar sign
secure. You just add an ACL entry and it will go in there because of Windows.
Even if the files are deleted, the ACLs disappear, but the dollar sign secure file is
still there with data that could be decoded if it were decoded in a decodable way instead of
reading the ACLs out of the files. That is the junk that normally accumulates there, that's
entropy that you can manipulate to store data to and you don't even need the files anymore.
You create the files and then delete them. That's a good point. That sounds like a
different application of this type of scheme. That's a good point. That sounds like a
different application of this type of scheme. I would be curious if you could write something
like that. That would just be a different way. Repeat it? Sorry. He was saying within
the dollar sign secure file, if you know that the data is in a certain way, you can
manipulate the data into a slightly different way to have a different message. Did I get
your question? Yes. You brought it up as a way that the system leaks data. Why not
exploit that and then you don't even need the files. You don't even need the files. You
can create files with ACLs that puts data in the dollar secure and then you just delete the files
because the data isn't there anymore. It's in dollar secure. So now it's just this junk that
accumulates and it just looks like the random stuff that normally accumulates there over the
lifetime of the file system. That's right. It's just a different way of doing it. But
yeah, it would definitely work. And then you don't even need the files, just delete them.
That's right. You can get rid of them. Yeah, if we have time. Yeah. So I'm just going to
ask a question. So I think the technique by which you distribute it amongst multiple files is
pretty similar to open puff, right? But in a way, you know, you're using a different technique in
terms of, you know, how you're hiding that data, let's say. I think to dovetail on a couple of
the other questions, you know, around alternate data streams, certainly you could maybe use
something like stealth ADS, you know, to circumvent any kind of forensic, you know, detection
of that. And I think in addition to that, you could maybe use kind of the volume shadow copy
to hide data in the volume shadows, too. Just as, you know, as another way to circumvent any kind
of forensic detection. Interesting. I wonder if volume shadow copies, if they make snapshots of
the access control list at that point in time as well as the data at that point in time. It's a
great question. I don't know the answer. But yeah, certainly worth investigating. Yeah, no, for
sure. I think what's clear here, and this goes back to the summary slide of all steganographic
techniques. As long as you've got the data, you're going to be able to do a lot of things. So if you
have those three things, a medium to store information and a way to differentiate between
encoded information and legitimate information and a key or a legend, you can encode information in
anything. For example, how do you know that this pin on my left side means one thing instead of
this pin on the right side? It could mean anything as long as both sender and receiver agree that
this will have one meaning and that will have another meaning. Cool. Thanks. Thank you. I think
that's all the time we have for questions now. I'm going to be in the
speaker Q&A room if there are any additional questions. Thanks for coming.