ACL Steganography: Permissions to Hide Your Porn
Perklin, Michael
Everyone's heard the claim: Security through obscurity is no security at all. Challenging this claim is the entire field of steganography itself - the art of hiding things in plain sight. Most people know you can hide a text file inside a photograph, or embed a photograph inside an MP3. But how does this work under the hood? What's new in the stego field? This talk will explore how various techniques employed by older steganographic tools work and will discuss a new technique developed by the speaker which embodies both data hiding and data enciphering properties by encoding data inside NTFS volumes. A new tool will be released during this talk that will allow attendees to both encode and decode data with this new scheme. Michael Perklin is currently employed as a Senior Investigator within the Corporate Investigations department of an Enterprise class telecommunications firm. Throughout his career he has performed digital-forensic examinations on over a thousand devices and has processed petabytes of information for electronic discovery. Michael has spoken at security conferences internationally about a variety of topics including digital forensics, computer security, data hiding, and anti-forensics. Michael holds numerous security-related degrees, diplomas and certifications, is a member of the High Technology Crime Investigations Association, and is an avid information security nut who loves learning about new ways to break things.
 Hello, everybody. Welcome to DEF CON. I'd like to introduce Michael Perklin with ACL Stegodronography. And take it away. Thank you. 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 if you're 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 Stegodronography is. And I'll go over some examples that, some classical examples, not digital examples on how Stegodronography was used before computers even existed. Then we'll go through some digital examples to see how they work under the hood. And finally, I'll talk about ACL Stegodronography, 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 Stegodronography? It's a Greek word. The origins of the word are Greek and it means concealed writing. There are two roots of the word. Stegonos, which means covered or protected. And Grafe, which means writing. 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 Stegonographic 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 back in the day when people had slaves. They would shave the scalp. They would tattoo a message on the scalp. They would wait for the hair to regrow. They'd 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. So a couple problems with this, mainly that the message has to be delayed because after you tattoo a message in 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 Stegonography is using Morse code. Some people would stitch some longer stitches and some shorter stitches on a jacket or a 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, dots and dashes, and that was Morse code. So this prisoner of war was hoping that by delivering this tapestry, they would get a message out saying I'm okay or whatever. If you're 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 to your recipient. The paper would have other writing on it, so it looked 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 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 secondographic 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 super humans can tell the difference between lemon and chartreuse. By super humans, I mean the fair sex in the audience. Each pixel is assigned a color with an RGB color code. The very last bit of this color code will always be part of the secret message that you're encoding. The example I have on screen here is DFF00. That's chartreuse. That very last zero is part of the message that you're encoding. Another example is DFF01. That's not chartreuse but 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 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've got a bunch of audio frames, you can encode a bunch of bits. You've got 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 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, 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. You can see that there's a lot of space there where you can jam data that isn't expected by the user. 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're 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 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 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, 1, 0, 0, and 1. And the MAC codes, if you look at the MAC codes, all of them are even. This is the encoding scheme for this example. On 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, 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 system. 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 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's 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 and execute permissions. They say that security identifier 1, 2, 3, 4, 5 has the permissions. As I'm pulling up this property window, Windows will take a look at the users. We'll see that security identifier 1, 2, 3, 4, 5 matches with user Michael. So it displays Michael nicely for me so 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're stored in only 14 bits of information. This is because a lot of these bits are reused depending on what you're sending 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 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 at the top entry in the list, it says S1, yada, yada, yada. 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 the 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 you can ‑‑ the highest amount of sub-authorities you can into a secure identifier. The next six bytes are used for an identifier authority. There's too much about that to go into a 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 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. 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 encode using this ACL steganography scheme. I'm going to encode a trueCrip volume. So I've created a trueCrip 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 trueCrip volume because 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 ‑‑ here's the trueCrip 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 trueCrip 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 will 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 trueCrip volume. This is what I'll be placing into the ACL entries. Next I have to choose a file list. This is just 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. Let's take all 16 of these files. We'll be in our list. And I will save the file list.txt. 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 dialog. So I'm now going to encode the trueCrip 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 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 their 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 grid 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 grid volume underscore out. 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 a wallet.dot file. So we've successfully encoded it and decoded it. It worked. Come on. I'm in a hard time getting out of this DM. Yeah, drink. What? I'm going to get out of this. Key shortcut is not working. I'm trying command F. There it is. Okay. Drink harder than the audience. Yeah, I think that deserves it. All right. Let's put empty dump 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 true grid volume. When I hit the encode button, it chunked the file up into 60 byte chunks. You can see there 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 ASEs are created with an allow permission and it allows that SID to do certain things. Each of these ASEs 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 win-win example that we went over earlier, we need to know which ASEs are legitimate and which ASEs 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 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 read 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 value of zero, the next chunk will be encoded with 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. 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 or 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, your windows will be slightly optimized and 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 in 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. If you do some manual hacking, you might be able to remove them manually from the secure file, 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 onto 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 is FTK and guidance is NCASE 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 input file. 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 DEF CON X X I 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 is FTK 4 held up on this. This is FTK 4. We're taking a look at the list of all 16 files you can see on the bottom half of the image. 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 and it was created, the data was last modified, et cetera, et cetera, but it does not show the access control list. 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 FTK 4 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 users had permissions on the files that are being analyzed in FTK 4 and the consensus was use another tool. So FTK 4 cannot do it. However, FTK 4 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 true crypt 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 is part of an ACL encoded entry or if it was just a random SID. Let's take a look at guidance NKS Forensic 6. Now, in NKS 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. And here you can see there is an ‑‑ there are access control lists for that file. The very first one, S1 for 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 the 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. Again, 60‑bite 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 toolkit. 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 using an automated way. N case 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, Rich 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. But in ten minutes, I will be in the speaker Q&A room for better questions. Yes, sir? Can we have the mic turned on please for the audience? So 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 SIDs. The way that Mac OS, they use the in 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. Thanks. Thank you. Nice job, by the way. I'm sorry. Nice job. Nice job. Oh, thank you. 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. Can you hear? 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 asking your question and you can repeat it. So the question was for streaming media, I think it's a good question. I think it's a good question. So the question is for streaming media, if you were to take a file and stream it 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 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 in a well-known place in the file system? Why can't I just write something that computes entropy and automatically detect if someone is doing this? Because it's a deterministic place to drop in sub-channel 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. 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 successful, so it's a little bit more of a covert sub-channel, 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 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 lists for the data that you're analyzing. If I'm doing 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 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 game 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? 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. So you do say NTFS alternate data streams? Yes. I am very familiar with it. Both FDK and case 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 dot text, 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 dot text. 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? Hidden in, oh. 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, they all have the same permissions as the master file. Thank you. That's a good question. Last question. Can you hear me? Here. So the dollar secure file ends up having this extra junk. Have you considered using that as a place to put stego text? Since you can directly manipulate it? Indirectly manipulate it instead of manipulating the file? The question was about the dollar secure file and if you can embed stuff within the dollar secure file as a method of stego, that's exactly what ACL code does. It chunks it up and throws it in the dollar secure file. By adding an entry to a file on a hard drive, that SID gets put into the dollar secure file by windows automatically. You don't need to manually put it in dollar secure. You just add an ACL entry and it will go in there because of windows. But I mean that even if the files are deleted, the ACLs disappear but the dollar 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 too 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. I would be curious if you could write something like that. That would just be a different way. Oh, repeat it. Sorry. He was saying within the dollar secure file, if you know that the data is in a certain way and you can manipulate the data into a slightly different way to have a different message. Did I get your question? Yes. You would be brought up as a way that the system leaks data. Why not exploit that and then you don't even need the files? You can create files with ACLs that put data into that 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 only 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. You would even need the files just to leak them. That's right. You can get rid of them. Yeah, if we have time. Yeah. So I think the technique by which you distributed 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 frames, 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 copies, you know, 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? That's a good 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 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 and A room if there are any additional questions. Thanks for coming. Thank you.
 Hello, everybody. Welcome to DEF CON. I'd like to introduce Michael  Perklin with ACL Stegodronography. And take it away. Thank you. 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 if you're 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 Stegodronography is. And I'll  go over some examples that, some classical examples, not digital examples on how Stegodronography was  used before computers even existed. Then we'll go through some digital examples to see how they work  under the hood. And finally, I'll talk about ACL Stegodronography, 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  Stegodronography? It's a Greek word. The origins of the word are Greek and it means concealed  writing. There are two roots of the word. Stegonos, which means covered or protected. And  Grafe, which means writing. 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 Stegonographic 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 back in the day when people had slaves. They would shave the  scalp. They would tattoo a message on the scalp. They would wait for the hair to regrow. They'd  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. So a couple problems  with this, mainly that the message has to be delayed because after you tattoo a message in  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 Stegonography is using  Morse code. Some people would stitch some longer stitches and some shorter stitches on a jacket  or a 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, dots and dashes, and that was Morse code. So this prisoner of war was  hoping that by delivering this tapestry, they would get a message out saying I'm okay or  whatever. If you're 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 to your recipient. The paper would have other writing on it, so it  looked 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 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 secondographic 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 super humans can tell the difference  between lemon and chartreuse. By super humans, I mean the fair sex in the audience. Each pixel  is assigned a color with an RGB color code. The very last bit of this color code will always be  part of the secret message that you're encoding. The example I have on screen here is DFF00.  That's chartreuse. That very last zero is part of the message that you're encoding. Another  example is DFF01. That's not chartreuse but 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 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've got a bunch of audio frames, you can encode a  bunch of bits. You've got 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 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, 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. You can see that there's a lot of space there  where you can jam data that isn't expected by the user. 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're 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 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 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, 1, 0, 0, and 1. And the  MAC codes, if you look at the MAC codes, all of them are even. This is the encoding scheme for  this example. On 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, 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 system. 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 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's 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 and execute permissions. They say that security identifier  1, 2, 3, 4, 5 has the permissions. As I'm pulling up this property window, Windows will take a  look at the users. We'll see that security identifier 1, 2, 3, 4, 5 matches with user Michael. So  it displays Michael nicely for me so 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're stored in only 14 bits of information. This is because a lot of these bits are reused  depending on what you're sending 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 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 at the top entry in the list, it says S1, yada, yada, yada. 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 the 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 you can ‑‑ the highest amount of sub-authorities you can  into a secure identifier. The next six bytes are used for an identifier authority. There's too  much about that to go into a 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  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. 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 encode using this ACL  steganography scheme. I'm going to encode a trueCrip volume. So I've created a trueCrip  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 trueCrip volume because 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 ‑‑  here's the trueCrip 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 trueCrip 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 will 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 trueCrip volume. This is what I'll  be placing into the ACL entries. Next I have to choose a file list. This is just 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. Let's take all 16 of these files.  We'll be in our list. And I will save the file list.txt. 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 dialog. So I'm now going to encode the trueCrip 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 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 their 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 grid 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 grid volume underscore out. 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 a  wallet.dot file. So we've successfully encoded it and decoded it. It worked.  Come on. I'm in a hard time getting out of this DM. Yeah, drink. What? I'm going to  get out of this. Key shortcut is not working. I'm trying command F. There it is. Okay.  Drink harder than the audience. Yeah, I think that deserves it. All right. Let's put  empty dump 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 true grid volume. When I hit the  encode button, it chunked the file up into 60 byte chunks. You can see there 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 ASEs are created with an allow permission and it allows that SID to do  certain things. Each of these ASEs 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 win-win example that we went over earlier,  we need to know which ASEs are legitimate and which ASEs 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 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 read 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  value of zero, the next chunk will be encoded with 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. 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 or 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, your windows will be slightly optimized and 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 in 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. If you do some manual hacking,  you might be able to remove them manually from the secure file, 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 onto 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 is FTK and guidance is NCASE 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 input file. 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 DEF CON X X I 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 is FTK 4 held up on this. This is FTK 4. We're taking a look at the list of all 16  files you can see on the bottom half of the image. 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 and it was created, the data was last modified, et cetera, et cetera, but it  does not show the access control list. 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 FTK 4 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 users had permissions on the files that are being analyzed in FTK 4 and the  consensus was use another tool. So FTK 4 cannot do it. However, FTK 4 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 true crypt 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 is part of an ACL encoded entry or if it was just a random SID. Let's take a look at  guidance NKS Forensic 6. Now, in NKS 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. And here you can see  there is an ‑‑ there are access control lists for that file. The very first one, S1 for 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 the 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. Again, 60‑bite 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 toolkit. 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 using an automated way. N case 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, Rich 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. But in ten minutes, I  will be in the speaker Q&A room for better questions. Yes, sir? Can we have the mic  turned on please for the audience? So 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 SIDs. The way that Mac OS, they use the in 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. Thanks. Thank you. Nice job, by the way. I'm sorry.  Nice job. Nice job. Oh, thank you. 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. Can you hear? 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 asking your question and you can  repeat it. So the question was for streaming media, I think it's a good question. I think it's a  good question. So the question is for streaming media, if you were to take a file and stream it  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 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 in a well-known  place in the file system? Why can't I just write something that computes entropy and automatically  detect if someone is doing this? Because it's a deterministic place to drop in sub-channel  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. 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  successful, so it's a little bit more of a covert sub-channel, 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 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 lists for the data that you're analyzing. If I'm doing 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 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 game 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?  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.  So you do say NTFS alternate data streams?  Yes. I am very familiar with it. Both FDK and case 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 dot text, 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 dot  text. 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?  Hidden in, oh.  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, they  all have the same permissions as the master file. Thank you.  That's a good question. Last question.  Can you hear me?  Here.  So the dollar secure file ends up having this extra junk. Have you considered using that as a  place to put stego text? Since you can directly manipulate it? Indirectly manipulate it instead of  manipulating the file? The question was about the dollar secure file and if you can embed stuff  within the dollar secure file as a method of stego, that's exactly what ACL code does. It  chunks it up and throws it in the dollar secure file. By adding an entry to a file on a hard  drive, that SID gets put into the dollar secure file by windows automatically. You don't need to  manually put it in dollar secure. You just add an ACL entry and it will go in there because of  windows. But I mean that even if the files are deleted, the ACLs disappear but the dollar 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 too 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. I would be curious if you could write something like that.  That would just be a different way. Oh, repeat it. Sorry. He was saying within the dollar  secure file, if you know that the data is in a certain way and you can manipulate the data  into a slightly different way to have a different message. Did I get your question?  Yes. You would be brought up as a way that the system leaks data. Why not exploit that and  then you don't even need the files? You can create files with ACLs that put data into  that 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 only 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.  You would even need the files just to leak them. That's right. You can get rid of them.  Yeah, if we have time. Yeah. So I think the technique by which you distributed  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  frames, 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 copies, you know, 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?  That's a good 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 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 and A room if there are any additional  questions. Thanks for coming.  Thank you.
DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_0_791.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_792_1223.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_1224_1859.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_1860_2735.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_2736_2819.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_2820_3983.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_3984_4151.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_4152_4871.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_4872_5579.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_5580_6611.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_6612_6935.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_6936_7067.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_7068_7595.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_7596_8711.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_8712_10103.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_10104_11399.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_11400_11975.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_11976_12647.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_12648_13847.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_13848_14915.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_14916_15839.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_15840_16883.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_16884_18527.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_18528_19787.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_19788_20459.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_20460_21395.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_21396_22631.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_22632_23543.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_23544_23687.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_23688_23735.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_23736_23783.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_23784_23903.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_23904_23951.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_23952_24239.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_24240_24323.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_24324_25055.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_25056_25319.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_25320_25619.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_25620_26315.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_26316_26363.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_26364_27071.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_27072_27323.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_27324_28655.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_28656_31559.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_31560_31895.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_31896_31979.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_31980_32027.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_32028_32147.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_32148_34343.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_34344_36083.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_36084_36863.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_36864_38171.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_38172_38963.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_38964_40139.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_40140_40907.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_40908_41567.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_41568_42575.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_42576_42911.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_42912_43463.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_43464_43535.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_43536_44471.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_44472_44771.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_44772_45479.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_45480_46703.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_46704_46799.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_46800_49019.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_49020_50603.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_50604_51023.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_51024_51767.png DEF_CON_21_-_Michael_Perklin_-_ACL_Steganography_Permissions_to_Hide_Your_Porn_J4x8Hz6_hq0_51768_67197.png
Hello, everybody. Welcome to DEF CON. I'd like to introduce Michael Perklin with ACL Stegodronography. And take it away. Thank you. 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 if you're 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 Stegodronography is. And I'll go over some examples that, some classical examples, not digital examples on how Stegodronography was used before computers even existed. Then we'll go through some digital examples to see how they work under the hood. And finally, I'll talk about ACL Stegodronography, 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 Stegodronography? It's a Greek word. The origins of the word are Greek and it means concealed writing. There are two roots of the word. Stegonos, which means covered or protected. And Grafe, which means writing. 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 Stegonographic 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 back in the day when people had slaves. They would shave the scalp. They would tattoo a message on the scalp. They would wait for the hair to regrow. They'd 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. So a couple problems with this, mainly that the message has to be delayed because after you tattoo a message in 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 Stegonography is using Morse code. Some people would stitch some longer stitches and some shorter stitches on a jacket or a 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, dots and dashes, and that was Morse code. So this prisoner of war was hoping that by delivering this tapestry, they would get a message out saying I'm okay or whatever. If you're 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 to your recipient. The paper would have other writing on it, so it looked 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 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 secondographic 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 super humans can tell the difference between lemon and chartreuse. By super humans, I mean the fair sex in the audience. Each pixel is assigned a color with an RGB color code. The very last bit of this color code will always be part of the secret message that you're encoding. The example I have on screen here is DFF00. That's chartreuse. That very last zero is part of the message that you're encoding. Another example is DFF01. That's not chartreuse but 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 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've got a bunch of audio frames, you can encode a bunch of bits. You've got 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 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, 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. You can see that there's a lot of space there where you can jam data that isn't expected by the user. 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're 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 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 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, 1, 0, 0, and 1. And the MAC codes, if you look at the MAC codes, all of them are even. This is the encoding scheme for this example. On 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, 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 system. 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 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's 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 and execute permissions. They say that security identifier 1, 2, 3, 4, 5 has the permissions. As I'm pulling up this property window, Windows will take a look at the users. We'll see that security identifier 1, 2, 3, 4, 5 matches with user Michael. So it displays Michael nicely for me so 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're stored in only 14 bits of information. This is because a lot of these bits are reused depending on what you're sending 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 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 at the top entry in the list, it says S1, yada, yada, yada. 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 the 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 you can ‑‑ the highest amount of sub-authorities you can into a secure identifier. The next six bytes are used for an identifier authority. There's too much about that to go into a 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 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. 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 encode using this ACL steganography scheme. I'm going to encode a trueCrip volume. So I've created a trueCrip 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 trueCrip volume because 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 ‑‑ here's the trueCrip 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 trueCrip 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 will 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 trueCrip volume. This is what I'll be placing into the ACL entries. Next I have to choose a file list. This is just 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. Let's take all 16 of these files. We'll be in our list. And I will save the file list.txt. 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 dialog. So I'm now going to encode the trueCrip 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 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 their 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 grid 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 grid volume underscore out. 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 a wallet.dot file. So we've successfully encoded it and decoded it. It worked. Come on. I'm in a hard time getting out of this DM. Yeah, drink. What? I'm going to get out of this. Key shortcut is not working. I'm trying command F. There it is. Okay. Drink harder than the audience. Yeah, I think that deserves it. All right. Let's put empty dump 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 true grid volume. When I hit the encode button, it chunked the file up into 60 byte chunks. You can see there 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 ASEs are created with an allow permission and it allows that SID to do certain things. Each of these ASEs 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 win-win example that we went over earlier, we need to know which ASEs are legitimate and which ASEs 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 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 read 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 value of zero, the next chunk will be encoded with 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. 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 or 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, your windows will be slightly optimized and 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 in 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. If you do some manual hacking, you might be able to remove them manually from the secure file, 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 onto 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 is FTK and guidance is NCASE 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 input file. 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 DEF CON X X I 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 is FTK 4 held up on this. This is FTK 4. We're taking a look at the list of all 16 files you can see on the bottom half of the image. 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 and it was created, the data was last modified, et cetera, et cetera, but it does not show the access control list. 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 FTK 4 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 users had permissions on the files that are being analyzed in FTK 4 and the consensus was use another tool. So FTK 4 cannot do it. However, FTK 4 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 true crypt 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 is part of an ACL encoded entry or if it was just a random SID. Let's take a look at guidance NKS Forensic 6. Now, in NKS 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. And here you can see there is an ‑‑ there are access control lists for that file. The very first one, S1 for 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 the 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. Again, 60‑bite 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 toolkit. 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 using an automated way. N case 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, Rich 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. But in ten minutes, I will be in the speaker Q&A room for better questions. Yes, sir? Can we have the mic turned on please for the audience? So 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 SIDs. The way that Mac OS, they use the in 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. Thanks. Thank you. Nice job, by the way. I'm sorry. Nice job. Nice job. Oh, thank you. 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. Can you hear? 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 asking your question and you can repeat it. So the question was for streaming media, I think it's a good question. I think it's a good question. So the question is for streaming media, if you were to take a file and stream it 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 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 in a well-known place in the file system? Why can't I just write something that computes entropy and automatically detect if someone is doing this? Because it's a deterministic place to drop in sub-channel 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. 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 successful, so it's a little bit more of a covert sub-channel, 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 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 lists for the data that you're analyzing. If I'm doing 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 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 game 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? 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. So you do say NTFS alternate data streams? Yes. I am very familiar with it. Both FDK and case 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 dot text, 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 dot text. 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? Hidden in, oh. 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, they all have the same permissions as the master file. Thank you. That's a good question. Last question. Can you hear me? Here. So the dollar secure file ends up having this extra junk. Have you considered using that as a place to put stego text? Since you can directly manipulate it? Indirectly manipulate it instead of manipulating the file? The question was about the dollar secure file and if you can embed stuff within the dollar secure file as a method of stego, that's exactly what ACL code does. It chunks it up and throws it in the dollar secure file. By adding an entry to a file on a hard drive, that SID gets put into the dollar secure file by windows automatically. You don't need to manually put it in dollar secure. You just add an ACL entry and it will go in there because of windows. But I mean that even if the files are deleted, the ACLs disappear but the dollar 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 too 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. I would be curious if you could write something like that. That would just be a different way. Oh, repeat it. Sorry. He was saying within the dollar secure file, if you know that the data is in a certain way and you can manipulate the data into a slightly different way to have a different message. Did I get your question? Yes. You would be brought up as a way that the system leaks data. Why not exploit that and then you don't even need the files? You can create files with ACLs that put data into that 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 only 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. You would even need the files just to leak them. That's right. You can get rid of them. Yeah, if we have time. Yeah. So I think the technique by which you distributed 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 frames, 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 copies, you know, 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? That's a good 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 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 and A room if there are any additional questions. Thanks for coming. Thank you.
introduce Michael Perklin with ACL interested in hiding things or finding hidden existed. Then we'll go through some digital examples to see how they work under the hood. And which is a new scheme that I came up. That will hiding something in plain sight. So let's go paper with this liquid, allow it to dry, and then encode one file as color information inside a This is an operation that does nothing. So if you them are even. This is the encoding scheme for could be a tapestry, it could be a photograph. ACL steganography, the scheme that I developed. I'm not really confused. I know that Michael has for future expansion of NTFS. But as you can see released a second revision of the security number of sub-authorities that will be in the again. And back and forth until the entire file that's on all NTFS volumes. This file is like a but that's over and above this talk. And it looks you can come see me in the speaker Q&A room. I I'm not about to start looking at all the access as a place to put stego text? Since you can embed stuff within the dollar secure file as a I think the technique by which you distributed shadow copies, you know, to hide data in the