 Hello, everybody. Welcome to DEF CON. I'd like to introduce Michael Perklin with ACL Stechidontography. 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 stegonography is. And I'll go over some examples that, some classical examples, not digital examples, on how stegonography 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 Stegonography, which is a new scheme that I came up. That'll take up the bulk of the presentation. So let's get started. What is stegonography? It's a Greek word. Sorry, the origins of the word are Greek and it means concealed writing. There are two roots of the word. Stegonos, which means covered or protected. And graphé, 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 and they'd 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. There's 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 with 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 would look like it says one thing, but what happens is the acid in the lemon juice or the acidic liquid that you use breaks down parts of the paper. So when you put that piece of paper over heat, it would start to burn, but the parts that were broken down a little bit more by the acid that you added, they would burn first. The result would be, it would turn darker and you could read the message that was written with a liquid. This is a lot of fun to do if you've got young kids, I've done it with my nephews and they've really enjoyed it. Now let's take a look at some digital 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 and by super humans I mean the fair sex in the audience. Each pixel is assigned a color with an RGB color code and the very last bit of this color code will always be part of the secret message that you're encoding. The example I have on the screen here is DFFF00. That's chartreuse. That very last zero is part of the message that you're encoding. Another example is DFFF01. That's not chartreuse, but it's something similar. 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 complimentary 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 complimentary operations would work, like multiplication and division. As long as you have some kind of a scheme to write this, it works. PE files or EXE files, they have a lot of other areas where you can encode information. This is looking at some of the raw bytes and hex form of a PE file. And you can see that there's a lot of space there where you can jam data that isn't expected by the user, but it wouldn't impact the running of the program, but it would hide data. So if you send this EXE to someone, they can decode it on their side. The last digital example I'll be talking about is chafing and winnowing. This is probably the most interesting one for me at least. It was conceived by Ron Rivest in 1998. He's the R in RSA. He also made the RC4 algorithm that a lot of the WP stuff was based off of. Chafing and winnowing isn't exactly encryption and it isn't exactly steganography. It's sort of a hybrid of both, but it isn't really either, 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 parody 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 chaf 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 chaf 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 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 the 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 is a user, Michael, there. When I'm pulling up the properties for this file on the left here, Windows doesn't store the permission entries by name. They don't say that Michael has read and execute permissions. They say that security identifier one, two, three, four, five 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 one, two, three, four, five matches with user Michael so it displays Michael nicely for me so that I'm not really confused. I know that Michael has read and execute permissions. There's a lot of permissions that you can set for a user. A lot more than just the five or six that you see on the left screen. There are 22 unique permissions in all. However, they are stored in only 14 bits of information. This is because a lot of these bits are reused depending on what you're 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 that 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 permission than just read, write and execute. This slide here shows the difference between the simple and advanced view of the permissions. On the left is the file that I was showing earlier. And on the right, you see quite a lot of permissions. And I'm not sure how well you can see all the entries on the right. But there's a slash there that shows that one bit would be used for either traverse folder or for execute file. It's the same bit. But depending on if it's a folder or a file, it has a different meaning. So I mentioned security identifiers. Permission entries are stored using security identifiers. If a user is removed, the operating system can't look up the friendly name to show in that dialogue. This is the same file with the same Michael user who had read and execute permissions. But I've deleted the Michael user from the operating system. And you can see here that 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 these security identifiers. The second byte is the count of the number of sub-authorities that will be in the rest of the SID. The maximum number here is 15. That's the most you can, the most amount, sorry, the highest amount of sub-authorities you can fit 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, so let's do some acronym review or some AR, as I like to call it. There's an access control list, or an ACL. That is a list of access control entries. There's an access control entry, an ACE, which is a permission rule, which says, allow these permissions for this SID, or deny these permissions to this SID. And finally, there's the security identifier, the SID, that is a unique identifier for that user or group of a Windows system. All right, enough slides. Let's do a quick demo. 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 true-crypt volume. So I've created a true-crypt volume, and that's this here, the local disk T. Inside I have a Bitcoin wallet. It's just a simple file that holds all my Bitcoin keys for this example. I'm going to encode this Bitcoin wallet and hide it in my file system in a way that cannot be easily found by a forensic investigator. So let's dismount this true-crypt 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. Okay, so here's the true-crypt volume that I will be encoding. I need to put this file into ACL entries on a set of files. So I've prepared 16 text files that I will be using to hold this true-crypt volume. Let's take a look at the permissions of some of the files in here. I'll just choose number one. Right click properties. I'll go to the security tab. And you can see there's default permissions here. Authenticated users, the system, nothing fancy here. So now that we know what the permissions look like already on this file, let's encode some data into it. So I'm going to launch the ACL encode utility that I've created. We'll choose the file that I want to encode. In this case, it is the true-crypt 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.text right here. Okay. So just so you can see what that did, it created a simple text file with one entry for each of the files that I selected in that dialogue. So I'm now going to encode the true-crypt volume into all 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 of timed it. In addition to splitting up the file, it also needs to do a couple of other things like add the security identifiers to a special part of the volume called the secure file. I'll go into more depth about that a little bit later in the presentation. And there we go. The file has been encoded. So now, if we take a look at the test files, they look like they're regular files. But if we take a closer look at the security permissions, we'll notice that there's a lot more entries here than there were before. Each of these entries don't have an associated user account within Windows. So Windows can't look up a friendly name like Michael to display. So all these values here are the, is the Bitcoin wallet that has been put in the true 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'll make a true grid volume underscore out. And we'll hit decode. Decoding is a lot faster than encoding. See, 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 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? The key shortcut is not working. I'm trying command F. There it is. Okay. Yeah, drink harder, I heard in the audience. Yeah, I think that deserves it. Let's put Dumpty Dumpty back 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 red in the diagram you see here. The green bits are what I use for encoding their position within the overall file. So the last nine bits are used as a counter with values of zero through 512. The first bit is, sorry, the first chunk will be encoded with a value of zero, the next chunk will be encoded with a value of one, two, et cetera. So it can hold all of these. The file list that we're using, the list of all the 16 files that it shows, 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 large 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. Every time a new security identifier is encountered, windows adds that SID to the secure file. It does this so that in the future, if you're trying to read or write permissions of that file, windows will be slightly optimized and it will know that 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. Now 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 encased forensic. I use 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 Defcon XXI repeated over and over and over again. This would allow me to search for it later to find it. Let's see how access data is FTK4 held up on this. This is FTK4. We're taking a look at the list of all 16 files. You can see on the bottom half of the image. File number one is selected and FTK4 is showing us the owner of the file and it's showing us all the other properties of the file like the size and the date that was created, the date that was last modified, et cetera, et cetera. But it does not show the access control lists. So I started hunting and pecking all throughout the program looking for where I can see the security permissions on the files that are listed in FTK. FTK lists a lot of different fields within NTFS that you're able to view. None of these are the access control lists. So I found that FTK4 has no way to show what permissions were set on a file. I contacted their tech support and I discussed the issue with them. They assured me that there was no way. I discussed it on their user forum asking if anybody knew of a way to see which users had permissions on the files that are being analyzed in FTK4 and the consensus was use another tool. So FTK4 cannot do it. However, FTK4 can still analyze the dollar sign secure file and sure enough, if you manually search through that secure file, you can see some of the contents. This is 60 bytes of Defcon XXI repeated. This 60 bytes is one of the SIDs for one of the files that was encoded. So you can still see the data buried in the secure file, but it's not in an easily presentable list. And of course, in this case, I'm searching for a file that, for values that I knew was in the input file because I put them there. If TrueCrypt was used or something was used that would encrypt the data in a way that I couldn't search for it easily, this would just be more gibberish and I would have no idea that this is part of an ICL encoded entry or if it was just a random SID. Let's take a look at guidance's Ncase Forensics 6. Now, in Ncase Forensics 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 are access control lists for that file, the very first one, S14, yada, yada, yada. That is the permission list for that one file. Now, if I want to take a look at the permission list for another file, I have to go back to the home folder, choose file number two, then click back on the permissions tab so I can view the permissions for file number two. I want to look at 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 NK6, 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-byte chunks, each of them have Defcon XXI repeated. So the forensic detection of ACL encoding, it's a very manual process using the most common tools in a forensic investigator's 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. NK's 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. 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 10 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 10 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? There we go. So would there be any way to implement this, say, into macOS's ACLs? Yes, there would be a way to add this to macOS. Now, the scheme that I created was for NTFS entries using SIDs. The way that macOS, they use an HFS file system, you would have to encode it in a different way, but this scheme could definitely be adapted for that. It's just a matter of writing the tool to get it done. Cool. Thanks. Thank you. Nice job, by the way. I'm sorry? Nice job. Nice job. Oh, thank you. All right, so I got here a little late, and I missed the pouring 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 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. If you were to take a file and stream it, let's say from a cloud, can you use this encoded information and distribute it through a stream? I would say no to that because this scheme doesn't store anything in the file itself. It stores it in the metadata about the file that the hard drive is holding. So all the access control lists, this is within Windows. It's for the file. Once you start distributing the contents of a file, you're not even touching the metadata, so that's not going to be distributed. Hi there. 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's 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 block? So this to me looks like it's immediately detectable by using statistical and standard communication entropy calculations. And maybe that's beyond the scope of this meeting, but I just, it's a curious question I have. It is a little bit beyond the scope. As far as detection goes, as long as you're able to see the entries, you'll know that there's something there. You won't know what is there, but you'll be able to tell that there is something. Now, as far as encoding the entries in a way that would not be detectable, so it's a little bit more of a covert 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'd need far more values to store a much smaller file. Yeah, but I mean 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's 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. I mean if I'm doing, let's say, an intellectual property case as an examiner to see, did somebody exfiltrate data from their company? I would look for common things, did they use a USB key to get data out? Did they email themselves? Did they do all these things? I'm not about to start looking at all the access control lists on every file on their desktop computer or on their laptop to see if they have encoded that information. But of course you can have a script that would automate checking for these now that we know that this scheme exists, but again it's a cat and mouse game. You come up with a better way of getting around the controls, now you get controls to detect that. It's a cat and mouse game. All right, thanks. Thank you. 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. Sorry, do you say NTFS alternate data streams? Yes. I am very familiar with it. Both FDK and NCASE support detecting alternate data in these alternate data streams. For those who aren't aware of it, if you have a file name, like let's say FileList.txt, and you double click the file, you're looking at the first stream of that data. It's possible under the hood, using some command line tools, you can have two separate files that are both assigned the same file name, FileList.txt. So you can take a look at the second one. Do you know if those files hidden through ADS follow the same permissions? Sorry. Do the files hidden through ADS follow the same permissions? The question was do these alternate data streams use the same permissions and they do. It's because the permissions, the access control lists are assigned to that file by file name. Whether there's one, two, or ten different alternate data streams within that file, they all have the same permissions as the master file. Thank you. That's a good question. All right, last question. Can you hear me? Okay. So the dollar secure file ends up having all 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 directly manipulating the file? The question was about the dollar sign secure file and if you can embed stuff within the dollar sign secure file as a method of stego, that's actually exactly what ACLN code does. It chunks it up and it throws it in the dollar sign secure file. By adding an entry to a file on a hard drive, that SID gets put into the dollar sign secure file by windows automatically. You don't need to manually put it in dollar sign secure. You just add an ACLN entry and it will go in there because of windows. Oh, 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 encoded 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. You know, that's a good point. That sounds like a different application of this type of scheme. You know, I'd be curious if you could write something like that. That would just be a different way. Overpeat it, sorry. He was saying within the dollar sign secure file, if you know that the data is in a certain way, you can manipulate the data into a slightly different way to have a different message. Did I get your question? Yes, since that is, you brought it up as a way that the system leaks data, why not exploit that and then you don't even need the files. You can create files with ACLs that puts 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 junk that accumulates and it just looks like the random stuff that normally accumulates there over the lifetime of the file system. That's right. It's just a different way of doing it. But yeah, it would definitely work. And then you don't even need the files just to delete them. That's right. You can get rid of them. Yeah, if we have time. Yeah. So I think the technique by which you distribute it amongst multiple files pretty similar to Open Puff, right? But in a way, you're using a different technique in terms of how you're hiding that data, let's say. I think to dovetail on a couple of the other questions around alternate data streams, certainly you could maybe use something like Stealth ADS to circumvent any kind of forensic detection of that. And I think in addition to that, you could maybe use kind of the volume shadow copies to hide data in the volume shadows too. Just as another way to circumvent any kind of forensic detection. Interesting. I wonder if volume shadow copies, if they make snapshots of the access control list at that point in time, as well as the data at that point in time. It's a great question. I don't know the answer, but yeah. Certainly worth investigating. Yeah, no, for sure. I think what's clear here, and this goes back to the summary slide of all steganographic techniques. As long as you 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. Thanks for coming.