Use Their Machines Against Them: Loading Code with a Copier
Rich, Michael
We’ve all worked on ‘closed systems’ with little to no direct Internet access. And we’ve all struggled with the limitations those systems put on us in the form of available tools or software we want to use. I didn’t like struggling, so I came up with a method to load whatever I wanted on to a closed system without triggering any common security alerts. To do this I had to avoid accessing the Internet or using mag media. In the end all I needed was an office multi-function machine and Excel. It’s all any insider needs. For my presentation and demo, I’ll show you how I delivered a select group of PowerSploit tools to a clean, isolated machine. Of course, Excel has been known as vector for macro viruses for quite some time and some of the techniques—such as hex-encoding binary data and re-encoding it on a target machine—are known binary insertion vectors but I have not found any prior work on an insider using these techniques to deliver payloads to closed systems. You’ll leave my presentation knowing why Excel, umm, excels as an insider attack tool, how to leverage Excel features to load and extract arbitrary binary data from a closed network, and what to do if this really frightens you. BioL Mike has over 20 years experience in the military. He has been part of everything from systems acquisition, to tactical intelligence collection, to staff work, to leading a unit dedicated to data loss prevention. He recently retired from active military service and is now working as a systems security engineer. This is Mike’s first security conference presentation and will also be the first public release of a tool he has written. Mike has previously published twice in 2600 magazine. Mike is super proud of his OSCP certification. He’s also a CISSP.
 Alright. So, my name's Mike, thank you for coming to the talk. Sorry for the long delay there. They make us test our VGA to HDMI converters in the green room, but it turns out that the green room equipment is not the same as the equipment in this room. So, it didn't work. Anyway, I'm going to talk about loading code from a copier. And now, I've mentioned this title several times during the weekend, you know, with the blue badge. People ask me all the time when I'm talking about. So, I have to disabuse some notions right away. I'm not infecting the printers I'm talking about here, the scanners, by doing the firmware. I'm using them as designed as a scanner and moving documents from the scanner to a target workstation on a closed network and interpreting those documents in a way to drop binary files onto the target machine. So, I just wanted to show you understood that right away. This is definitely an insider attack. This is for something I worked on to do work on a closed network to load arbitrary tools. Here's what I'm going to go over. It's a phase attack. And each step of the phase kind of changes the amount of data I get per page on the scanner into the machine until I go from basic just text analysis down all the way to getting about 80 kilobytes of data per page onto a target machine. So, that's the different phases. We're going to go through that all with you. So, the way this all started is I was at work on a closed network and they had a collaboration portal on the network. It was kind of a share point based kind of thing. And it had these text entry boxes like you can see here. And it didn't take me long to discover that they are being, the data was being validated client side with some JavaScript. And I was like, oh, well, I bet I can beat that and put some cross-site scripting attacks on my collaboration portal at work. But that's easy to do when you're at home, right? When you're using your machine, you would use something like tamper data or burp suite to intercept the call and modify it after it's been through the JavaScript modification. But I didn't have any of those tools available to me. So, I kept trying to think through what would I do to make this happen. I was like, well, like I said, tamper data, burp suite to intercept the post call, don't have those. I could forge the post call, but I didn't have curl or W get available to me. And eventually I came to the conclusion that what I really wanted to know how to do was put whatever tool I wanted on this machine without making anybody mad. Without getting caught, really. So, that's kind of where I ended up working on this particular problem. So these are the conditions I had to work with. I had a closed network, sort of, right? There are no really truly closed networks anywhere because they're basically not useful. But this is, for all sense of purpose, is a closed secure network. In this network, the USB ports are secured and monitored, sometimes they're physically locked. CDUs are secured and monitored, typically from a writing standpoint, not so much a reading standpoint, but nonetheless, it is monitored. There is an endpoint security system on this, on my workstation. And, you know, it's generating logs for everything I do down in the mouse click, I guess, I don't know. But only certain things, it logs, they're going to draw attention from any kind of security people, right? So I wanted to avoid those things. There does exist a data transfer point between a less secure network that's closer to the Internet and this secure network. But I didn't know how it worked. I didn't know what it logged. I didn't know what rules it had for scanning. I didn't know who it alerted. And I wasn't really in the mood to try and keep poking out of it to see what I could figure out and raise my noise level until I got through what I wanted to. Because I didn't want to get fired. So I didn't want to use that. And basically it's a Windows at Microsoft Office environment. These are the tools I had available when I got right down to it. I had Microsoft Office, which provides access to visual basic for applications. I had professional level printers and scanners that can print and scan to a very fine level, which is really useful for what I was doing. And Adobe Acrobat with Optical Character Recognition is what I used. Alright, so first is getting Excel into attack mode. And this is just turning on developer mode in Excel. Now, you know, we all get those little pop-ups that say, hey, don't run the macros, that kind of stuff, or you want to prove these macros. But if you're the insider writing the macros, that kind of is pointless, right? So, and I call Excel attack mode because inside of Excel, you can write arbitrary script. And Excel with visual basic applications can modify files at the byte level. And not only that, you can call arbitrary DLLs with arbitrary functions, with arbitrary inputs to those functions. And that's an awful lot of arbitrary for any insider to have available to them as an attack surface. So I call it putting Excel into attack mode. And it's not hard to do, and I'm sure you guys all know how to do it. But you just go to the file options, you turn on Customize Ribbon, you turn on the developer checkbox, and you get a new ribbon on your Microsoft Excel page, and you click the ribbon there, you click Visual Basic, and then you now have access to a fully functional integrated development environment on your workstation. Now, I think the important point here is you're an unprivileged user, and you now have integrated development environment. And I know in many places, the users who are developers, who are the ability to write binaries, they get extra monitoring, they get extra scrutiny. But the point is every user on a Microsoft Office-based network can do this, and it's probably not being watched. So this is called, I call it putting phase zero, getting it set up. Now, the next thing you want to do is you want to get an arbitrary script into your Microsoft Excel. And the way I do that is by printing it and scanning it, basically. There's some tricks to it. Let me show you here. This is a Mac, so I'm going to mess this up, but that's all right. So this is the script that I'm going to talk about a little bit later. This is a script that is the phase one of the attack. And you can see some things you need to do is you don't have any indentation, because the indentation on the OCR messes up the order of execution in the script. So that's not super useful. And a lot of other things will kind of go wrong here when you do this. Now, let's see. Mac me. All right. Now, I would show you if my Windows machine were here that I would do this live here. I would just cut and paste this whole thing. So basically you scan this on your work computer, your work scanner. You have an email to you. That's how typically the documents get to you. You just OCR it. You highlight all. And then cut and paste it into Visual Basic. Let's see what happens if I do that here. Of course, Visual Basic isn't turned on here, because this is not my machine. And I don't know how to do it on a Mac. All right. So we're not going to do the scripts. Okay. So I have some samples in my presentation, though. So let's go back to my presentation. Nope. So we're not going to drop out of that anymore. Okay. All right. So I talked about how you do it. You can print down to about 8.0 font. You scan it. No demo time. So let's skip it. All right. So these are the screenshots from previous briefing I did on this. So when you drop it into Microsoft Excel Visual Basic, it doesn't work exactly right. You can see here that these lines here, these are all comment lines. And the comment delimiter has fallen off. So that's one kind of error. Let's see. Another common one right here, it gets rid of an equal sign. That happens quite a lot. And let's see if I can find any of the function flow ones. Nope. I don't see it. Other kind of weird errors that happen. Sometimes it interprets ones as Ls. So I have a function called a calculate checksum one byte exclusive or. It changed it to L byte exclusive or. But it did that for every instance of that word. So it basically still worked even though it changed the name of the function. So that was kind of a happy failure. But you have to watch out for all the change in the program flow. And then once you go through and re-edit your stuff, you still find more errors. When you go ahead and click F5 to run it, you can see there's one highlighted right there. The value is kind of in the middle of nowhere there. And I'm not exactly sure where that came from on this one. But it'll help you fix it. And the bottom line is you can do this. You can get an arbitrary script into place using a scanner without too much of a problem. Now, you could also type them. If you took out the comment lines, the hex magic stuff I'm going to talk about in a second isn't that long. It's only a few pages. But if you had a really long, complicated script, you could get it in this way. All right. So the goal is to use those methods I just talked about to make a script that will take an arbitrary file and encode it in binary, sorry, encode it in hex, and make it so you can print it out really nicely, and then take those to work and scan them. And why did I go with hex? Well, I did a bunch of experiments. I found that I could get down to a much smaller size font from a 12 point to 8 point to get more data on there between hex encoding and base 64. I didn't have any word length errors, meaning when the OCR ran through the document, it interpreted the length of the words as it was supposed to be. Whereas base 64 about, you know, over 10% of my words got messed up with length. So like missing symbols or added symbols. Transcription errors. I didn't have any transcription errors in my initial experiments. It decoded every word correctly, every hex code correctly. Whereas base 64, there was a ton of errors. Now, other experiments showed me that there are errors in hex encoding, but they're usually one for one, and they're usually really easy. So it means it's like an 8 goes to an S, and it always does that. It always interprets 8s as Ss. So it's easy to fix that, and it's also easy to realize that an S is not a valid hex code. So if it's an S, it's actually supposed to be an 8. Base 64, that won't work, because almost every type of a character is included in the base 64 encoding. And so you can't tell where your errors are. You don't know what's going wrong. So I didn't like base 64 encoding, even though it gave me a lot more data per page. So this is what it looks like when you encode a file. The script, the hex attack script, which I would have loved to have shown you running in real time. We'll create this, and it generates two columns. This is the data column, the information in the file there. And this is the 2 byte exclusive or check sum, which I'll talk about here in a little bit. And then you just export those as a CSV file and print them, and you can take these pages and scan them and transfer your data into your closed network, as long as the secretary is not watching you scan. All right. So I realized that the hex encoding wasn't going to be perfect. I was going to have errors, so I built this kind of compact exclusive or check sum in there. Now, the reason why I use it really, it needed to be really small, because every byte I give over to my parity, my check sums, is another byte that I lose in data, and I needed to get as much on a page as possible. So along with this 2 byte exclusive or taking a gamble that I wouldn't have that many collisions between failure modes to show that the data would work. And it did work. And when you run the code, if it can't match the check sums, it'll give you this little data's corrupt cannot decode the data. And then it'll highlight the offending line in red. And I'm going to have a hard time showing you what I usually show. Now, what you typically have to do here is, let's see, I'll do this in a second, but you'd think of it painting the butt to find these broken lines in your printout, but it really isn't. You would just take this exclusive or, and you would find it in your Adobe document and find that line. And after you do this a few times, you realize there's a pattern to the failures. There's certain symbols that show up like till does and stuff like that. And any dots that happen to be between the lines of your actual printout will cause errors. And so you learn to find them very fast. It doesn't take very long to fix even a large amount of dot hex data using this method. And now, since I'm briefing at Defcon, and I was warned that I have to have pictures of cats, if you were to decode this hex code, it generates this picture of an osloot. This is something I was working on at work. I actually dropped a binary file, but I figured a formatted file would work. So that's what that one does. Now, when I really took this, took this to the next step, and I was going to use it to drop my DLL in place, I discovered really quickly that it didn't work as well as I thought. I had quite a bit of error, although it's only about 1% error. It's still a lot of problems to fix. And so I discovered all these kind of errors that you see here. You know, B hat turns to 8 a lot, 1 to L, 5 to S, these kinds of things here. And some of these are pretty bad, right? A B to 8, that's bad, because both B's and 8's are valid hex code. 1 to L's, not a problem. 5 to S is not a problem. D to 0 or O, that can be a problem. And 6's get changed. So I came up with some alternative characters that actually show up in the printouts. I used a hash mark for a B and a question mark for a D. I just chose them because it didn't look like anything else. So I thought that they would OCR pretty well. And I was right. They did work really good. And I auto-replaced the other major errors, and then I put strong visual indicators in the decoding to show you where your problems are. The only thing I can show you about that right now is the one you already saw, the red one. But when I did this with my actual DLL, I only had one manual correction and 1,210 lines of text. That's about 19 pages of decoded text. And so it worked out really well. I don't think I can show you. Maybe I can try to show you. Let's see. I did open it. Where'd it go? Yeah. So here is... There we go. Okay. All right. So you can see here, here's the 2-byte Fusivore. And here's the data line with the questions for the Ds and the hash marks for the Bs. I don't think I can find any easy to see errors real quick. But... No. Not going to do it fast enough. So it'll scan pretty well. All right. Does anyone know how to make PowerPoint come back to the slide you just left? Say again? I'm on it. All right. There you go. Thank you. All right. Okay. So the hex attack is really super reliable. You really can get data very easily onto a machine, and it's not going to fail pretty much at all. And if you really had to, you could enter it by hand. You could type in those hex lines if you really wanted to. And now that gets kind of tedious after 19 pages. But if you didn't have a scanner available, you could do this and still get arbitrary binaries on your system. The bad part is it doesn't allow data density, about 3.6 kilobytes of data per page. And I put some common tools here. No. Go back. Put some common tools here between PowerScold and MemeCats. That would be like 200 pages of data you would be trying to scan at work. So that would probably raise some flags. So that's a little too much. And there's no exfiltration compression advantage. If you wanted to remove a binary file from this closed network and print it out in hex code and take it home and recreate it, you wouldn't really be able to do it with any kind of real compression. If that file was 3.6 kilobytes long and you printed it, it'd probably be a page long and you're not getting any real benefit unless it's an unprintable document. So I needed to do better. And so I got the thinking. How could I possibly put more data on a page? How could it, if there was just some technology somewhere that would allow me to encode data, black and white, two-dimensionally on a piece of paper at the pixel level, what could I possibly use? Well, yeah, so it didn't take me too long to figure out that there's an awful lot of 2D barcode stuff out there. And so I went with some barcode experiments. First I practiced with data matrices. I wanted to see how close I could get them down. And I just took this big one you see here and I kept shrinking it using PowerPoint and saving it as an image until it got to the point where the lines between the data bits started to blur and it wouldn't work anymore. And I'm just trying to see how small I could get onto a page that way. But I kept thinking about it. And with the amount of error correction built into most two-dimensional barcodes, I was only going to get about 25 kilobytes of data per page. They have about 60% error correction that depends on the barcode. But it's because they're designed for machine purposes. They're designed for low light. They're designed for weird orientations for people using cell phones. And that's a different design problem than I've got, where I'm basically taking the sheet, putting it on a scanner that scans very well in a perfect environment, and I control the orientation from the get-go. So I thought about, well, maybe I can make it better. I took some features from these barcodes, timing lines, in order to help locate the data and read Solomon Ford error correction. But I was like, I can make it better for my purposes. And so lo and behold, I generated the 8.5 by 11 inch big barcode. And that's what it looks like. And with that, I can get about 85 kilobytes of data per page. And this is what it looks like up close when you zoom in. It has a timing line on all four sides. And it has the data, I call it the data meat in the middle. And if I print that image at about 72 dots per inch, I can get about 88 bytes of information across a single pixel line. And each of these is a bit, right? I mean, that's an off bit. Those are on bits. And I get about 85 kilobytes of data on a page. So I was pretty happy with that. And so interpreting it, I basically, I start with a raster scan going across the image until I find the top leftmost timing mark. And then I kind of stop. And from there, I do a thing which I technically call wiggle fit, where I've got my mask and I put it over the timing mark that I found. And I just keep moving it around until I find the most black part of it. Because you can see when they scan, the edges get pretty fuzzed out. Man, that was cool. The thing got all big. Anyway, and so I wanted to find the most black part. So that's what it does. It moves the mask around. It finds the mask that has the most dark, picks the center point and moves across to the next timing line, timing mark, and it just finds the center of the next timing mark. And it works very well. And I do this on all four sides. And then the end, I end up with this, where each of the centers are indicated. And then you end up with just a bunch of grid of intersections for each of these lines, you know, matching this mark with the one all the way at the bottom, makes a straight line. This guy here, matched all the way to the right, makes a straight line. And I just calculate the intersections and at the intersection of each one is a data pixel. And I picked the data off that pixel and I decide whether it's an on-bit or an off-bit. And it works fairly well. I do get some errors. I didn't expect it to be perfect. My first test runs, I ended up with something like this. This is a heat map. All the black is bits that were read correctly in my scan. Now, these red ones here are bad bits. And there's a couple of little outliers. There's one here. There's a couple over here. This is what I really expected it to look like. Since I started in the upper left, I figured it would start getting bad by the bottom right. It turns out I wasn't really correct. When I took the 8.5, 11 document, I get this big heat problem in the middle here. And stop that. So the big problem here is this is a lot of error. Can't see the error. The red marks? Yeah. Okay. So imagine red marks where I'm circling. I was afraid you weren't going to be able to see it when I was thinking of doing this brief. Sorry. So there's a bunch of red marks and they're kind of clustered. Now, the problem is I have to adjust my error encoding on the big barcode to handle the worst error, not the best error. So if you were able to see it, you would be amazed at how clean it is up here. You would be astounded at how nice it is around here. But you see this giant red stuff in the middle and that's what I have to base my error correction on, which causes a lot of data loss for parity bytes. So I knew I needed error correction. I knew it wasn't going to work, so I want to read Solomon Ford error correction. And it turns out I don't understand read Solomon Ford error correction at all. I don't understand the math behind Galois finite field either. So I was like, well, I don't want to do this stuff from scratch. I'm just going to find a library. There's lots of libraries out there for forward eraser correction and forward error correction, except the pond test I discovered that the majority of the forward error correction ones I found out there just don't work. I don't know who's writing these opaque API libraries that I can't figure out and actually contact university professors and they couldn't figure out. But stop it. If you're going to put something out there, make sure it works. So, but there's a lot of forward eraser correction libraries out there. So I decided to go with forward eraser correction and see if I could use it. Now the problem is forward eraser correction is for a data stream where the, you're missing data. That doesn't make it to the receiver. That's what it's really for. And it works a bit like this. You have a, you have some data and you separate in the blocks. You assign a parity byte to each block, parity bytes to each block. And then if one of those blocks turns up missing, you use the parity bytes and the remaining blocks to recreate the missing block. And that's how forward eraser correction works. Now my problem is not missing data. My problem is corrupted data. So I decided, well, what if I did a checksum and if the checksum didn't match, I consider that block dead and I just take it out. So that's what I did. I got my block of data, my parity data, and then I've got my checksum for the whole thing. And if one of the parity bytes turns back, or one of the checksums is bad, then I ignore that block and try and recreate it. But it didn't work. I had too many collisions and so I was actually trying to recreate the missing data with corrupt data and the math will still work and it'll generally generate a corrupted response, generate a corrupted file. So it just didn't work. So I knew I had to go do forward error correction. Forward error correction is for corrupted data. So you have a word of data. You separate it into bytes. You add parity bytes to that data. If two of your bytes go bad, you can use two parity bytes to find the bad data and then two parity bytes to correct it and it works very well. And this is what I needed. But like I said, the problem was there weren't any working libraries out there for me to use. So I had to write one, much against my will. But I found this really good Python-based library at Wiciversity. And a line for line, I just recreated it in C basically, C++, until I got the thing working. There was a lot of debugging and pain and suffering involved in there. But I finally got it working. And this is what I had to do to get re-sum and forward error correction working for my big barcode. All right. So because of the big heat map of error in the middle that I told you about that you couldn't see, but you're just going to have to trust me, I needed about 45% error correction for it to work. Which means I only got about 47 kilobytes of data per page, which resulted in, you know, it's still order of magnitude better. So if you have PowerSplit, you can get it in 18 pages versus 232. So you can really start moving some data now. You have a good kind of compression advantage over the previous methods. And the demo is awesome. It really is. So I'll show you how it all works. I'll show you how you use the script and the DLL to open the, to create the barcodes and to interpret them. And I do live drops of everything. So yeah, it was really good in my room. You guys should have been there last night. All right. So I decided to give myself a grade on how this went for me. So my goal was to install PowerSplit on a machine that didn't have it on it using these methods and not using magnetic media. So just some grades. Interpret a page size barcode. Yeah, I could do it. The read solemn and encoder decoder. I was able to make it work eventually. There's a yellow mark there. I'm going to talk about that in a second. I built the library. I call it side loading. I was able to get the payload decoded onto my target machine, except because it was like 18 pages of data, I just made a portion of PowerSplit. So it was only three pages long. So I only gave myself a yellow on that. The hex encoder works. I was able to replace the library using the OCR method. And I was able to write my DLL, hex encode it and drop it on my target machine so I could read my big barcodes. It all worked after much effort. It has taken my word for it. So the POC was a success. The kind of stuff I learned from this was that standard offers tools provide a lot of power to the user that you know, maybe you're not fully aware of. We basically have a user-concode. The system is not secure. But the bottom line is any user on a Microsoft-based machine can code. And that is a big attack surface to pay attention to. And a termed insider can do it. And you can use innocuous input-output systems for creative purposes that weren't intended and that no one's really monitoring. No one's really monitoring the printing and scan load, even on the secure network that I was using. And they're not watching for information to come in this way. So it just provides a kind of a hole there to try and squeeze through. All right, some future branch research. I like to reduce the size of the big barcode DLL, the side load DLL. It was 19 pages of hex code. I like to make that a lot smaller. Size optimization is not really my thing, but that's something that I could work on. The error rates. I made an experiment to add more timing lines into my big barcode thinking it would help with the error rates for reading the big barcode. And I was 100% incorrect. It actually messed it up. And I still don't know why. It doesn't make any sense. But I like to improve the error rate so I can use less parity bytes. But this next line is the real key. If I can use, pardon me, if I can use 2 to the 16th read-solving encoding, I can do a lot better. So read-solving encoding at the 2 to the 8th means that your code words are 255 bytes long and it has to include your parity bytes. So you have to base your error on the amount of error you're expecting at 255 bytes. And because of the invisible heat map, I have to plan that for the high error areas, not the really nice areas. 2 to the 16th read-solving encoding means I can have a code word 135 kilobytes long, which is longer than my page. And I only get about 1% of error across that page as a whole. So I wouldn't need very many parity bytes at all if I could use 2 to the 16th read-solving encoding. But I couldn't get that math to work. And it also runs much, much slower. And so running experiments to debug it was taking me too long. So I didn't keep pursuing that. But if I get that working, it would improve the amount of data I could put on each page by quite a bit. If I could add colors to the big barcode, instead of just black and white, I did a four-color experiment to see that way I'm only using four blips instead of eight to define my bytes. I was able to get at the work, but there's a lot of error in decoding a color from a scan, quite frankly. But I think it's an area for future research. And also, I got really excited about using Excel to mess with things. Though visual basic for applications is kind of a pain, it is powerful. The ability to write at the right level means you can do anything with it you want. Making a hex editor at a visual basic for applications would be super easy. I started that a little bit, a steganographic encoder, decoder. I did that already so I could send myself stuff to work. That's easy to do. Restoring the command prompt. If you're on a machine with a command prompt locked down by security policy, it's just a matter of flipping a byte to make that work again. And you can do that with Excel. And I don't know for sure, but I think you can get away with some direct reflexive DLL injection as well, messing with the way Excel calls DLLs. I don't think any of this stuff is earth-shattering new. People have been running it macroviruses forever. They're all back in vogue now. But this is from the perspective of an insider being able to just do these things to your machine. And it's something I think you should need to watch out for. I don't think I can show you much more, unfortunately. Let's see. I really wish I could show you the demo. So here's some stuff that looks like it's left over from when I was practicing. Let's see if I can open this here real quick. I don't know what to do with that. Yep, you guys are watching me mess up this guy's computer right here. There you go. What the heck's the... Texted it. There you go. All right. This thing here, I don't know if you guys can read it. I don't know if I can zoom in. Nope. Let's say again. It's amazingly hard to hear people down there. I don't know if you can read it or not. A little bit. So this.dat file gets dropped when you do a encoding with big barcode. These are the important parts here. You have to have this encoded data length and you have to have the md5 sum in order to decode it with the big barcode on the backside. You have to provide those as inputs to your script. So that's important there. When you decode the DLL, it also drops this file here, which is a prototype for using the DLL. Because visual basic is very, very picky about how DLLs are called and used. So this gives you the prototype for it. And this is all in the... It's supposed to be in the materials that are delivered with the brief. So that's really about it. I'm sorry that my machine was too old in order to use super fancy screens. That's kind of all I've got. Any questions? Alright, thank you guys very much.
 Alright. So, my name's Mike, thank you for coming to the talk. Sorry for the long delay there.  They make us test our VGA to HDMI converters in the green room, but it turns out that the green room equipment is not the same as the equipment in this room.  So, it didn't work. Anyway, I'm going to talk about loading code from a copier.  And now, I've mentioned this title several times during the weekend, you know, with the blue badge. People ask me all the time when I'm talking about.  So, I have to disabuse some notions right away. I'm not infecting the printers I'm talking about here, the scanners, by doing the firmware.  I'm using them as designed as a scanner and moving documents from the scanner to a target workstation on a closed network and interpreting those documents in a way to drop binary files onto the target machine.  So, I just wanted to show you understood that right away.  This is definitely an insider attack. This is for something I worked on to do work on a closed network to load arbitrary tools.  Here's what I'm going to go over. It's a phase attack. And each step of the phase kind of changes the amount of data I get per page on the scanner into the machine until I go from basic just text analysis down all the way to getting about 80 kilobytes of data per page onto a target machine.  So, that's the different phases. We're going to go through that all with you.  So, the way this all started is I was at work on a closed network and they had a collaboration portal on the network.  It was kind of a share point based kind of thing. And it had these text entry boxes like you can see here.  And it didn't take me long to discover that they are being, the data was being validated client side with some JavaScript.  And I was like, oh, well, I bet I can beat that and put some cross-site scripting attacks on my collaboration portal at work.  But that's easy to do when you're at home, right? When you're using your machine, you would use something like tamper data or burp suite to intercept the call and modify it after it's been through the JavaScript modification.  But I didn't have any of those tools available to me. So, I kept trying to think through what would I do to make this happen.  I was like, well, like I said, tamper data, burp suite to intercept the post call, don't have those. I could forge the post call, but I didn't have curl or W get available to me.  And eventually I came to the conclusion that what I really wanted to know how to do was put whatever tool I wanted on this machine without making anybody mad.  Without getting caught, really. So, that's kind of where I ended up working on this particular problem.  So these are the conditions I had to work with. I had a closed network, sort of, right?  There are no really truly closed networks anywhere because they're basically not useful.  But this is, for all sense of purpose, is a closed secure network.  In this network, the USB ports are secured and monitored, sometimes they're physically locked.  CDUs are secured and monitored, typically from a writing standpoint, not so much a reading standpoint, but nonetheless, it is monitored.  There is an endpoint security system on this, on my workstation.  And, you know, it's generating logs for everything I do down in the mouse click, I guess, I don't know.  But only certain things, it logs, they're going to draw attention from any kind of security people, right?  So I wanted to avoid those things.  There does exist a data transfer point between a less secure network that's closer to the Internet and this secure network.  But I didn't know how it worked. I didn't know what it logged. I didn't know what rules it had for scanning.  I didn't know who it alerted. And I wasn't really in the mood to try and keep poking out of it to see what I could figure out and raise my noise level until I got through what I wanted to.  Because I didn't want to get fired. So I didn't want to use that.  And basically it's a Windows at Microsoft Office environment.  These are the tools I had available when I got right down to it.  I had Microsoft Office, which provides access to visual basic for applications.  I had professional level printers and scanners that can print and scan to a very fine level, which is really useful for what I was doing.  And Adobe Acrobat with Optical Character Recognition is what I used.  Alright, so first is getting Excel into attack mode. And this is just turning on developer mode in Excel.  Now, you know, we all get those little pop-ups that say, hey, don't run the macros, that kind of stuff, or you want to prove these macros.  But if you're the insider writing the macros, that kind of is pointless, right?  So, and I call Excel attack mode because inside of Excel, you can write arbitrary script.  And Excel with visual basic applications can modify files at the byte level.  And not only that, you can call arbitrary DLLs with arbitrary functions, with arbitrary inputs to those functions.  And that's an awful lot of arbitrary for any insider to have available to them as an attack surface.  So I call it putting Excel into attack mode. And it's not hard to do, and I'm sure you guys all know how to do it.  But you just go to the file options, you turn on Customize Ribbon, you turn on the developer checkbox,  and you get a new ribbon on your Microsoft Excel page, and you click the ribbon there, you click Visual Basic,  and then you now have access to a fully functional integrated development environment on your workstation.  Now, I think the important point here is you're an unprivileged user, and you now have integrated development environment.  And I know in many places, the users who are developers, who are the ability to write binaries,  they get extra monitoring, they get extra scrutiny. But the point is every user on a Microsoft Office-based network  can do this, and it's probably not being watched. So this is called, I call it putting phase zero, getting it set up.  Now, the next thing you want to do is you want to get an arbitrary script into your Microsoft Excel.  And the way I do that is by printing it and scanning it, basically.  There's some tricks to it. Let me show you here. This is a Mac, so I'm going to mess this up, but that's all right.  So this is the script that I'm going to talk about a little bit later. This is a script that is the phase one of the attack.  And you can see some things you need to do is you don't have any indentation, because the indentation on the OCR messes up the order of execution in the script.  So that's not super useful. And a lot of other things will kind of go wrong here when you do this.  Now, let's see. Mac me. All right. Now, I would show you if my Windows machine were here that I would do this live here.  I would just cut and paste this whole thing. So basically you scan this on your work computer, your work scanner.  You have an email to you. That's how typically the documents get to you. You just OCR it. You highlight all.  And then cut and paste it into Visual Basic. Let's see what happens if I do that here.  Of course, Visual Basic isn't turned on here, because this is not my machine.  And I don't know how to do it on a Mac. All right. So we're not going to do the scripts.  Okay. So I have some samples in my presentation, though. So let's go back to my presentation.  Nope. So we're not going to drop out of that anymore. Okay. All right. So I talked about how you do it.  You can print down to about 8.0 font. You scan it. No demo time. So let's skip it.  All right. So these are the screenshots from previous briefing I did on this.  So when you drop it into Microsoft Excel Visual Basic, it doesn't work exactly right.  You can see here that these lines here, these are all comment lines.  And the comment delimiter has fallen off. So that's one kind of error. Let's see.  Another common one right here, it gets rid of an equal sign. That happens quite a lot.  And let's see if I can find any of the function flow ones.  Nope. I don't see it. Other kind of weird errors that happen. Sometimes it interprets ones as Ls.  So I have a function called a calculate checksum one byte exclusive or.  It changed it to L byte exclusive or. But it did that for every instance of that word.  So it basically still worked even though it changed the name of the function.  So that was kind of a happy failure. But you have to watch out for all the change in the program flow.  And then once you go through and re-edit your stuff, you still find more errors.  When you go ahead and click F5 to run it, you can see there's one highlighted right there.  The value is kind of in the middle of nowhere there. And I'm not exactly sure where that came from on this one.  But it'll help you fix it. And the bottom line is you can do this.  You can get an arbitrary script into place using a scanner without too much of a problem.  Now, you could also type them. If you took out the comment lines,  the hex magic stuff I'm going to talk about in a second isn't that long.  It's only a few pages. But if you had a really long, complicated script,  you could get it in this way.  All right. So the goal is to use those methods I just talked about to make a script that will take  an arbitrary file and encode it in binary, sorry, encode it in hex,  and make it so you can print it out really nicely, and then take those to work and scan them.  And why did I go with hex? Well, I did a bunch of experiments.  I found that I could get down to a much smaller size font from a 12 point to 8 point  to get more data on there between hex encoding and base 64.  I didn't have any word length errors, meaning when the OCR ran through the document,  it interpreted the length of the words as it was supposed to be.  Whereas base 64 about, you know, over 10% of my words got messed up with length.  So like missing symbols or added symbols.  Transcription errors. I didn't have any transcription errors in my initial experiments.  It decoded every word correctly, every hex code correctly.  Whereas base 64, there was a ton of errors.  Now, other experiments showed me that there are errors in hex encoding,  but they're usually one for one, and they're usually really easy.  So it means it's like an 8 goes to an S, and it always does that.  It always interprets 8s as Ss.  So it's easy to fix that, and it's also easy to realize that an S is not a valid hex code.  So if it's an S, it's actually supposed to be an 8.  Base 64, that won't work, because almost every type of a character is included in the base 64 encoding.  And so you can't tell where your errors are.  You don't know what's going wrong.  So I didn't like base 64 encoding, even though it gave me a lot more data per page.  So this is what it looks like when you encode a file.  The script, the hex attack script, which I would have loved to have shown you running in real time.  We'll create this, and it generates two columns.  This is the data column, the information in the file there.  And this is the 2 byte exclusive or check sum, which I'll talk about here in a little bit.  And then you just export those as a CSV file and print them,  and you can take these pages and scan them and transfer your data into your closed network,  as long as the secretary is not watching you scan.  All right.  So I realized that the hex encoding wasn't going to be perfect.  I was going to have errors, so I built this kind of compact exclusive or check sum in there.  Now, the reason why I use it really, it needed to be really small, because every byte I give over to my parity,  my check sums, is another byte that I lose in data, and I needed to get as much on a page as possible.  So along with this 2 byte exclusive or taking a gamble that I wouldn't have that many collisions  between failure modes to show that the data would work.  And it did work.  And when you run the code, if it can't match the check sums,  it'll give you this little data's corrupt cannot decode the data.  And then it'll highlight the offending line in red.  And I'm going to have a hard time showing you what I usually show.  Now, what you typically have to do here is, let's see, I'll do this in a second,  but you'd think of it painting the butt to find these broken lines in your printout,  but it really isn't.  You would just take this exclusive or, and you would find it in your Adobe document and find that line.  And after you do this a few times, you realize there's a pattern to the failures.  There's certain symbols that show up like till does and stuff like that.  And any dots that happen to be between the lines of your actual printout will cause errors.  And so you learn to find them very fast.  It doesn't take very long to fix even a large amount of dot hex data using this method.  And now, since I'm briefing at Defcon, and I was warned that I have to have pictures of cats,  if you were to decode this hex code, it generates this picture of an osloot.  This is something I was working on at work.  I actually dropped a binary file, but I figured a formatted file would work.  So that's what that one does.  Now, when I really took this, took this to the next step, and I was going to use it to drop my DLL in place,  I discovered really quickly that it didn't work as well as I thought.  I had quite a bit of error, although it's only about 1% error.  It's still a lot of problems to fix.  And so I discovered all these kind of errors that you see here.  You know, B hat turns to 8 a lot, 1 to L, 5 to S, these kinds of things here.  And some of these are pretty bad, right? A B to 8, that's bad, because both B's and 8's are valid hex code.  1 to L's, not a problem. 5 to S is not a problem.  D to 0 or O, that can be a problem.  And 6's get changed.  So I came up with some alternative characters that actually show up in the printouts.  I used a hash mark for a B and a question mark for a D.  I just chose them because it didn't look like anything else.  So I thought that they would OCR pretty well.  And I was right. They did work really good.  And I auto-replaced the other major errors, and then I put strong visual indicators in the decoding to show you where your problems are.  The only thing I can show you about that right now is the one you already saw, the red one.  But when I did this with my actual DLL, I only had one manual correction and 1,210 lines of text.  That's about 19 pages of decoded text.  And so it worked out really well.  I don't think I can show you. Maybe I can try to show you.  Let's see. I did open it. Where'd it go?  Yeah. So here is...  There we go. Okay.  All right. So you can see here, here's the 2-byte Fusivore.  And here's the data line with the questions for the Ds and the hash marks for the Bs.  I don't think I can find any easy to see errors real quick.  But...  No. Not going to do it fast enough.  So it'll scan pretty well.  All right. Does anyone know how to make PowerPoint come back to the slide you just left?  Say again?  I'm on it.  All right. There you go. Thank you.  All right.  Okay. So the hex attack is really super reliable.  You really can get data very easily onto a machine, and it's not going to fail pretty much at all.  And if you really had to, you could enter it by hand.  You could type in those hex lines if you really wanted to.  And now that gets kind of tedious after 19 pages.  But if you didn't have a scanner available, you could do this and still get arbitrary binaries on your system.  The bad part is it doesn't allow data density, about 3.6 kilobytes of data per page.  And I put some common tools here. No. Go back.  Put some common tools here between PowerScold and MemeCats.  That would be like 200 pages of data you would be trying to scan at work.  So that would probably raise some flags.  So that's a little too much.  And there's no exfiltration compression advantage.  If you wanted to remove a binary file from this closed network and print it out in hex code and take it home and recreate it,  you wouldn't really be able to do it with any kind of real compression.  If that file was 3.6 kilobytes long and you printed it, it'd probably be a page long  and you're not getting any real benefit unless it's an unprintable document.  So I needed to do better.  And so I got the thinking.  How could I possibly put more data on a page?  How could it, if there was just some technology somewhere that would allow me to encode data, black and white,  two-dimensionally on a piece of paper at the pixel level, what could I possibly use?  Well, yeah, so it didn't take me too long to figure out that there's an awful lot of 2D barcode stuff out there.  And so I went with some barcode experiments.  First I practiced with data matrices.  I wanted to see how close I could get them down.  And I just took this big one you see here and I kept shrinking it using PowerPoint and saving it as an image  until it got to the point where the lines between the data bits started to blur and it wouldn't work anymore.  And I'm just trying to see how small I could get onto a page that way.  But I kept thinking about it.  And with the amount of error correction built into most two-dimensional barcodes,  I was only going to get about 25 kilobytes of data per page.  They have about 60% error correction that depends on the barcode.  But it's because they're designed for machine purposes.  They're designed for low light.  They're designed for weird orientations for people using cell phones.  And that's a different design problem than I've got,  where I'm basically taking the sheet, putting it on a scanner that scans very well in a perfect environment,  and I control the orientation from the get-go.  So I thought about, well, maybe I can make it better.  I took some features from these barcodes, timing lines,  in order to help locate the data and read Solomon Ford error correction.  But I was like, I can make it better for my purposes.  And so lo and behold, I generated the 8.5 by 11 inch big barcode.  And that's what it looks like.  And with that, I can get about 85 kilobytes of data per page.  And this is what it looks like up close when you zoom in.  It has a timing line on all four sides.  And it has the data, I call it the data meat in the middle.  And if I print that image at about 72 dots per inch,  I can get about 88 bytes of information across a single pixel line.  And each of these is a bit, right?  I mean, that's an off bit. Those are on bits.  And I get about 85 kilobytes of data on a page.  So I was pretty happy with that.  And so interpreting it,  I basically, I start with a raster scan going across the image  until I find the top leftmost timing mark.  And then I kind of stop.  And from there, I do a thing which I technically call wiggle fit,  where I've got my mask and I put it over the timing mark that I found.  And I just keep moving it around until I find the most black part of it.  Because you can see when they scan, the edges get pretty fuzzed out.  Man, that was cool. The thing got all big.  Anyway, and so I wanted to find the most black part.  So that's what it does. It moves the mask around.  It finds the mask that has the most dark,  picks the center point and moves across to the next timing line,  timing mark, and it just finds the center of the next timing mark.  And it works very well. And I do this on all four sides.  And then the end, I end up with this, where each of the centers are indicated.  And then you end up with just a bunch of grid of intersections  for each of these lines, you know, matching this mark with the one all the way at the bottom,  makes a straight line. This guy here, matched all the way to the right,  makes a straight line. And I just calculate the intersections  and at the intersection of each one is a data pixel.  And I picked the data off that pixel and I decide whether it's an on-bit or an off-bit.  And it works fairly well. I do get some errors. I didn't expect it to be perfect.  My first test runs, I ended up with something like this.  This is a heat map. All the black is bits that were read correctly in my scan.  Now, these red ones here are bad bits.  And there's a couple of little outliers. There's one here.  There's a couple over here. This is what I really expected it to look like.  Since I started in the upper left, I figured it would start getting bad by the bottom right.  It turns out I wasn't really correct.  When I took the 8.5, 11 document, I get this big heat problem in the middle here.  And stop that. So the big problem here is this is a lot of error.  Can't see the error. The red marks?  Yeah. Okay. So imagine red marks where I'm circling.  I was afraid you weren't going to be able to see it when I was thinking of doing this brief.  Sorry. So there's a bunch of red marks and they're kind of clustered.  Now, the problem is I have to adjust my error encoding on the big barcode to handle the worst error,  not the best error. So if you were able to see it, you would be amazed at how clean it is up here.  You would be astounded at how nice it is around here.  But you see this giant red stuff in the middle and that's what I have to base my error correction on,  which causes a lot of data loss for parity bytes.  So I knew I needed error correction. I knew it wasn't going to work,  so I want to read Solomon Ford error correction.  And it turns out I don't understand read Solomon Ford error correction at all.  I don't understand the math behind Galois finite field either.  So I was like, well, I don't want to do this stuff from scratch. I'm just going to find a library.  There's lots of libraries out there for forward eraser correction and forward error correction,  except the pond test I discovered that the majority of the forward error correction ones I found out there just don't work.  I don't know who's writing these opaque API libraries that I can't figure out  and actually contact university professors and they couldn't figure out.  But stop it. If you're going to put something out there, make sure it works.  So, but there's a lot of forward eraser correction libraries out there.  So I decided to go with forward eraser correction and see if I could use it.  Now the problem is forward eraser correction is for a data stream where the,  you're missing data. That doesn't make it to the receiver. That's what it's really for.  And it works a bit like this. You have a, you have some data and you separate in the blocks.  You assign a parity byte to each block, parity bytes to each block.  And then if one of those blocks turns up missing, you use the parity bytes and the remaining blocks  to recreate the missing block. And that's how forward eraser correction works.  Now my problem is not missing data. My problem is corrupted data.  So I decided, well, what if I did a checksum and if the checksum didn't match,  I consider that block dead and I just take it out.  So that's what I did. I got my block of data, my parity data, and then I've got my checksum for the whole thing.  And if one of the parity bytes turns back, or one of the checksums is bad,  then I ignore that block and try and recreate it. But it didn't work.  I had too many collisions and so I was actually trying to recreate the missing data with corrupt data  and the math will still work and it'll generally generate a corrupted response,  generate a corrupted file. So it just didn't work.  So I knew I had to go do forward error correction.  Forward error correction is for corrupted data.  So you have a word of data. You separate it into bytes.  You add parity bytes to that data.  If two of your bytes go bad, you can use two parity bytes to find the bad data  and then two parity bytes to correct it and it works very well.  And this is what I needed. But like I said, the problem was there weren't any working libraries out there for me to use.  So I had to write one, much against my will.  But I found this really good Python-based library at Wiciversity.  And a line for line, I just recreated it in C basically, C++, until I got the thing working.  There was a lot of debugging and pain and suffering involved in there.  But I finally got it working.  And this is what I had to do to get re-sum and forward error correction working for my big barcode.  All right. So because of the big heat map of error in the middle that I told you about that you couldn't see,  but you're just going to have to trust me, I needed about 45% error correction for it to work.  Which means I only got about 47 kilobytes of data per page, which resulted in, you know,  it's still order of magnitude better.  So if you have PowerSplit, you can get it in 18 pages versus 232.  So you can really start moving some data now.  You have a good kind of compression advantage over the previous methods.  And the demo is awesome. It really is.  So I'll show you how it all works.  I'll show you how you use the script and the DLL to open the, to create the barcodes  and to interpret them.  And I do live drops of everything.  So yeah, it was really good in my room.  You guys should have been there last night.  All right.  So I decided to give myself a grade on how this went for me.  So my goal was to install PowerSplit on a machine that didn't have it on it using these methods  and not using magnetic media.  So just some grades.  Interpret a page size barcode.  Yeah, I could do it.  The read solemn and encoder decoder.  I was able to make it work eventually.  There's a yellow mark there.  I'm going to talk about that in a second.  I built the library.  I call it side loading.  I was able to get the payload decoded onto my target machine, except because it was like 18 pages of data,  I just made a portion of PowerSplit.  So it was only three pages long.  So I only gave myself a yellow on that.  The hex encoder works.  I was able to replace the library using the OCR method.  And I was able to write my DLL,  hex encode it and drop it on my target machine so I could read my big barcodes.  It all worked after much effort.  It has taken my word for it.  So the POC was a success.  The kind of stuff I learned from this was that standard offers tools provide a lot of power to the user  that you know, maybe you're not fully aware of.  We basically have a user-concode.  The system is not secure.  But the bottom line is any user on a Microsoft-based machine can code.  And that is a big attack surface to pay attention to.  And a termed insider can do it.  And you can use innocuous input-output systems for creative purposes that weren't intended  and that no one's really monitoring.  No one's really monitoring the printing and scan load, even on the secure network that I was using.  And they're not watching for information to come in this way.  So it just provides a kind of a hole there to try and squeeze through.  All right, some future branch research.  I like to reduce the size of the big barcode DLL, the side load DLL.  It was 19 pages of hex code.  I like to make that a lot smaller.  Size optimization is not really my thing, but that's something that I could work on.  The error rates.  I made an experiment to add more timing lines into my big barcode thinking it would help with the error rates  for reading the big barcode.  And I was 100% incorrect. It actually messed it up.  And I still don't know why.  It doesn't make any sense.  But I like to improve the error rate so I can use less parity bytes.  But this next line is the real key.  If I can use, pardon me,  if I can use 2 to the 16th read-solving encoding, I can do a lot better.  So read-solving encoding at the 2 to the 8th means that your code words are 255 bytes long  and it has to include your parity bytes.  So you have to base your error on the amount of error you're expecting at 255 bytes.  And because of the invisible heat map, I have to plan that for the high error areas,  not the really nice areas.  2 to the 16th read-solving encoding means I can have a code word 135 kilobytes long,  which is longer than my page.  And I only get about 1% of error across that page as a whole.  So I wouldn't need very many parity bytes at all if I could use 2 to the 16th read-solving encoding.  But I couldn't get that math to work.  And it also runs much, much slower.  And so running experiments to debug it was taking me too long.  So I didn't keep pursuing that.  But if I get that working, it would improve the amount of data I could put on each page by quite a bit.  If I could add colors to the big barcode, instead of just black and white,  I did a four-color experiment to see that way I'm only using four blips instead of eight to define my bytes.  I was able to get at the work, but there's a lot of error in decoding a color from a scan, quite frankly.  But I think it's an area for future research.  And also, I got really excited about using Excel to mess with things.  Though visual basic for applications is kind of a pain, it is powerful.  The ability to write at the right level means you can do anything with it you want.  Making a hex editor at a visual basic for applications would be super easy.  I started that a little bit, a steganographic encoder, decoder.  I did that already so I could send myself stuff to work.  That's easy to do.  Restoring the command prompt.  If you're on a machine with a command prompt locked down by security policy,  it's just a matter of flipping a byte to make that work again.  And you can do that with Excel.  And I don't know for sure, but I think you can get away with some direct reflexive DLL injection as well,  messing with the way Excel calls DLLs.  I don't think any of this stuff is earth-shattering new.  People have been running it macroviruses forever.  They're all back in vogue now.  But this is from the perspective of an insider being able to just do these things to your machine.  And it's something I think you should need to watch out for.  I don't think I can show you much more, unfortunately.  Let's see.  I really wish I could show you the demo.  So here's some stuff that looks like it's left over from when I was practicing.  Let's see if I can open this here real quick.  I don't know what to do with that.  Yep, you guys are watching me mess up this guy's computer right here.  There you go.  What the heck's the...  Texted it. There you go.  All right. This thing here, I don't know if you guys can read it.  I don't know if I can zoom in.  Nope. Let's say again.  It's amazingly hard to hear people down there.  I don't know if you can read it or not.  A little bit.  So this.dat file gets dropped when you do a encoding with big barcode.  These are the important parts here.  You have to have this encoded data length and you have to have the md5 sum  in order to decode it with the big barcode on the backside.  You have to provide those as inputs to your script.  So that's important there.  When you decode the DLL, it also drops this file here,  which is a prototype for using the DLL.  Because visual basic is very, very picky about how DLLs are called and used.  So this gives you the prototype for it.  And this is all in the...  It's supposed to be in the materials that are delivered with the brief.  So that's really about it.  I'm sorry that my machine was too old in order to use super fancy screens.  That's kind of all I've got. Any questions?  Alright, thank you guys very much.
DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_0_143.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_144_239.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_240_1943.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_1944_2879.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_2880_8495.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_8496_8579.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_8580_8735.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_8736_8963.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_8964_9011.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_9012_9071.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_9072_10403.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_10404_10499.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_10500_12179.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_12180_12995.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_12996_15287.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_15288_15731.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_15732_16031.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_16032_16787.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_16788_18455.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_18456_20315.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_20316_20399.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_20400_21131.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_21132_21659.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_21660_23927.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_23928_35591.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_35592_36911.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_36912_42743.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_42744_43187.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_43188_45647.png DEF_CON_24_Conference_Mike_Use_Their_Machines_Against_Them_Loading_Code_with_a_Copier_h6TRYcx74qs_45648_45667.png
Alright. So, my name's Mike, thank you for coming to the talk. Sorry for the long delay there. They make us test our VGA to HDMI converters in the green room, but it turns out that the green room equipment is not the same as the equipment in this room. So, it didn't work. Anyway, I'm going to talk about loading code from a copier. And now, I've mentioned this title several times during the weekend, you know, with the blue badge. People ask me all the time when I'm talking about. So, I have to disabuse some notions right away. I'm not infecting the printers I'm talking about here, the scanners, by doing the firmware. I'm using them as designed as a scanner and moving documents from the scanner to a target workstation on a closed network and interpreting those documents in a way to drop binary files onto the target machine. So, I just wanted to show you understood that right away. This is definitely an insider attack. This is for something I worked on to do work on a closed network to load arbitrary tools. Here's what I'm going to go over. It's a phase attack. And each step of the phase kind of changes the amount of data I get per page on the scanner into the machine until I go from basic just text analysis down all the way to getting about 80 kilobytes of data per page onto a target machine. So, that's the different phases. We're going to go through that all with you. So, the way this all started is I was at work on a closed network and they had a collaboration portal on the network. It was kind of a share point based kind of thing. And it had these text entry boxes like you can see here. And it didn't take me long to discover that they are being, the data was being validated client side with some JavaScript. And I was like, oh, well, I bet I can beat that and put some cross-site scripting attacks on my collaboration portal at work. But that's easy to do when you're at home, right? When you're using your machine, you would use something like tamper data or burp suite to intercept the call and modify it after it's been through the JavaScript modification. But I didn't have any of those tools available to me. So, I kept trying to think through what would I do to make this happen. I was like, well, like I said, tamper data, burp suite to intercept the post call, don't have those. I could forge the post call, but I didn't have curl or W get available to me. And eventually I came to the conclusion that what I really wanted to know how to do was put whatever tool I wanted on this machine without making anybody mad. Without getting caught, really. So, that's kind of where I ended up working on this particular problem. So these are the conditions I had to work with. I had a closed network, sort of, right? There are no really truly closed networks anywhere because they're basically not useful. But this is, for all sense of purpose, is a closed secure network. In this network, the USB ports are secured and monitored, sometimes they're physically locked. CDUs are secured and monitored, typically from a writing standpoint, not so much a reading standpoint, but nonetheless, it is monitored. There is an endpoint security system on this, on my workstation. And, you know, it's generating logs for everything I do down in the mouse click, I guess, I don't know. But only certain things, it logs, they're going to draw attention from any kind of security people, right? So I wanted to avoid those things. There does exist a data transfer point between a less secure network that's closer to the Internet and this secure network. But I didn't know how it worked. I didn't know what it logged. I didn't know what rules it had for scanning. I didn't know who it alerted. And I wasn't really in the mood to try and keep poking out of it to see what I could figure out and raise my noise level until I got through what I wanted to. Because I didn't want to get fired. So I didn't want to use that. And basically it's a Windows at Microsoft Office environment. These are the tools I had available when I got right down to it. I had Microsoft Office, which provides access to visual basic for applications. I had professional level printers and scanners that can print and scan to a very fine level, which is really useful for what I was doing. And Adobe Acrobat with Optical Character Recognition is what I used. Alright, so first is getting Excel into attack mode. And this is just turning on developer mode in Excel. Now, you know, we all get those little pop-ups that say, hey, don't run the macros, that kind of stuff, or you want to prove these macros. But if you're the insider writing the macros, that kind of is pointless, right? So, and I call Excel attack mode because inside of Excel, you can write arbitrary script. And Excel with visual basic applications can modify files at the byte level. And not only that, you can call arbitrary DLLs with arbitrary functions, with arbitrary inputs to those functions. And that's an awful lot of arbitrary for any insider to have available to them as an attack surface. So I call it putting Excel into attack mode. And it's not hard to do, and I'm sure you guys all know how to do it. But you just go to the file options, you turn on Customize Ribbon, you turn on the developer checkbox, and you get a new ribbon on your Microsoft Excel page, and you click the ribbon there, you click Visual Basic, and then you now have access to a fully functional integrated development environment on your workstation. Now, I think the important point here is you're an unprivileged user, and you now have integrated development environment. And I know in many places, the users who are developers, who are the ability to write binaries, they get extra monitoring, they get extra scrutiny. But the point is every user on a Microsoft Office-based network can do this, and it's probably not being watched. So this is called, I call it putting phase zero, getting it set up. Now, the next thing you want to do is you want to get an arbitrary script into your Microsoft Excel. And the way I do that is by printing it and scanning it, basically. There's some tricks to it. Let me show you here. This is a Mac, so I'm going to mess this up, but that's all right. So this is the script that I'm going to talk about a little bit later. This is a script that is the phase one of the attack. And you can see some things you need to do is you don't have any indentation, because the indentation on the OCR messes up the order of execution in the script. So that's not super useful. And a lot of other things will kind of go wrong here when you do this. Now, let's see. Mac me. All right. Now, I would show you if my Windows machine were here that I would do this live here. I would just cut and paste this whole thing. So basically you scan this on your work computer, your work scanner. You have an email to you. That's how typically the documents get to you. You just OCR it. You highlight all. And then cut and paste it into Visual Basic. Let's see what happens if I do that here. Of course, Visual Basic isn't turned on here, because this is not my machine. And I don't know how to do it on a Mac. All right. So we're not going to do the scripts. Okay. So I have some samples in my presentation, though. So let's go back to my presentation. Nope. So we're not going to drop out of that anymore. Okay. All right. So I talked about how you do it. You can print down to about 8.0 font. You scan it. No demo time. So let's skip it. All right. So these are the screenshots from previous briefing I did on this. So when you drop it into Microsoft Excel Visual Basic, it doesn't work exactly right. You can see here that these lines here, these are all comment lines. And the comment delimiter has fallen off. So that's one kind of error. Let's see. Another common one right here, it gets rid of an equal sign. That happens quite a lot. And let's see if I can find any of the function flow ones. Nope. I don't see it. Other kind of weird errors that happen. Sometimes it interprets ones as Ls. So I have a function called a calculate checksum one byte exclusive or. It changed it to L byte exclusive or. But it did that for every instance of that word. So it basically still worked even though it changed the name of the function. So that was kind of a happy failure. But you have to watch out for all the change in the program flow. And then once you go through and re-edit your stuff, you still find more errors. When you go ahead and click F5 to run it, you can see there's one highlighted right there. The value is kind of in the middle of nowhere there. And I'm not exactly sure where that came from on this one. But it'll help you fix it. And the bottom line is you can do this. You can get an arbitrary script into place using a scanner without too much of a problem. Now, you could also type them. If you took out the comment lines, the hex magic stuff I'm going to talk about in a second isn't that long. It's only a few pages. But if you had a really long, complicated script, you could get it in this way. All right. So the goal is to use those methods I just talked about to make a script that will take an arbitrary file and encode it in binary, sorry, encode it in hex, and make it so you can print it out really nicely, and then take those to work and scan them. And why did I go with hex? Well, I did a bunch of experiments. I found that I could get down to a much smaller size font from a 12 point to 8 point to get more data on there between hex encoding and base 64. I didn't have any word length errors, meaning when the OCR ran through the document, it interpreted the length of the words as it was supposed to be. Whereas base 64 about, you know, over 10% of my words got messed up with length. So like missing symbols or added symbols. Transcription errors. I didn't have any transcription errors in my initial experiments. It decoded every word correctly, every hex code correctly. Whereas base 64, there was a ton of errors. Now, other experiments showed me that there are errors in hex encoding, but they're usually one for one, and they're usually really easy. So it means it's like an 8 goes to an S, and it always does that. It always interprets 8s as Ss. So it's easy to fix that, and it's also easy to realize that an S is not a valid hex code. So if it's an S, it's actually supposed to be an 8. Base 64, that won't work, because almost every type of a character is included in the base 64 encoding. And so you can't tell where your errors are. You don't know what's going wrong. So I didn't like base 64 encoding, even though it gave me a lot more data per page. So this is what it looks like when you encode a file. The script, the hex attack script, which I would have loved to have shown you running in real time. We'll create this, and it generates two columns. This is the data column, the information in the file there. And this is the 2 byte exclusive or check sum, which I'll talk about here in a little bit. And then you just export those as a CSV file and print them, and you can take these pages and scan them and transfer your data into your closed network, as long as the secretary is not watching you scan. All right. So I realized that the hex encoding wasn't going to be perfect. I was going to have errors, so I built this kind of compact exclusive or check sum in there. Now, the reason why I use it really, it needed to be really small, because every byte I give over to my parity, my check sums, is another byte that I lose in data, and I needed to get as much on a page as possible. So along with this 2 byte exclusive or taking a gamble that I wouldn't have that many collisions between failure modes to show that the data would work. And it did work. And when you run the code, if it can't match the check sums, it'll give you this little data's corrupt cannot decode the data. And then it'll highlight the offending line in red. And I'm going to have a hard time showing you what I usually show. Now, what you typically have to do here is, let's see, I'll do this in a second, but you'd think of it painting the butt to find these broken lines in your printout, but it really isn't. You would just take this exclusive or, and you would find it in your Adobe document and find that line. And after you do this a few times, you realize there's a pattern to the failures. There's certain symbols that show up like till does and stuff like that. And any dots that happen to be between the lines of your actual printout will cause errors. And so you learn to find them very fast. It doesn't take very long to fix even a large amount of dot hex data using this method. And now, since I'm briefing at Defcon, and I was warned that I have to have pictures of cats, if you were to decode this hex code, it generates this picture of an osloot. This is something I was working on at work. I actually dropped a binary file, but I figured a formatted file would work. So that's what that one does. Now, when I really took this, took this to the next step, and I was going to use it to drop my DLL in place, I discovered really quickly that it didn't work as well as I thought. I had quite a bit of error, although it's only about 1% error. It's still a lot of problems to fix. And so I discovered all these kind of errors that you see here. You know, B hat turns to 8 a lot, 1 to L, 5 to S, these kinds of things here. And some of these are pretty bad, right? A B to 8, that's bad, because both B's and 8's are valid hex code. 1 to L's, not a problem. 5 to S is not a problem. D to 0 or O, that can be a problem. And 6's get changed. So I came up with some alternative characters that actually show up in the printouts. I used a hash mark for a B and a question mark for a D. I just chose them because it didn't look like anything else. So I thought that they would OCR pretty well. And I was right. They did work really good. And I auto-replaced the other major errors, and then I put strong visual indicators in the decoding to show you where your problems are. The only thing I can show you about that right now is the one you already saw, the red one. But when I did this with my actual DLL, I only had one manual correction and 1,210 lines of text. That's about 19 pages of decoded text. And so it worked out really well. I don't think I can show you. Maybe I can try to show you. Let's see. I did open it. Where'd it go? Yeah. So here is... There we go. Okay. All right. So you can see here, here's the 2-byte Fusivore. And here's the data line with the questions for the Ds and the hash marks for the Bs. I don't think I can find any easy to see errors real quick. But... No. Not going to do it fast enough. So it'll scan pretty well. All right. Does anyone know how to make PowerPoint come back to the slide you just left? Say again? I'm on it. All right. There you go. Thank you. All right. Okay. So the hex attack is really super reliable. You really can get data very easily onto a machine, and it's not going to fail pretty much at all. And if you really had to, you could enter it by hand. You could type in those hex lines if you really wanted to. And now that gets kind of tedious after 19 pages. But if you didn't have a scanner available, you could do this and still get arbitrary binaries on your system. The bad part is it doesn't allow data density, about 3.6 kilobytes of data per page. And I put some common tools here. No. Go back. Put some common tools here between PowerScold and MemeCats. That would be like 200 pages of data you would be trying to scan at work. So that would probably raise some flags. So that's a little too much. And there's no exfiltration compression advantage. If you wanted to remove a binary file from this closed network and print it out in hex code and take it home and recreate it, you wouldn't really be able to do it with any kind of real compression. If that file was 3.6 kilobytes long and you printed it, it'd probably be a page long and you're not getting any real benefit unless it's an unprintable document. So I needed to do better. And so I got the thinking. How could I possibly put more data on a page? How could it, if there was just some technology somewhere that would allow me to encode data, black and white, two-dimensionally on a piece of paper at the pixel level, what could I possibly use? Well, yeah, so it didn't take me too long to figure out that there's an awful lot of 2D barcode stuff out there. And so I went with some barcode experiments. First I practiced with data matrices. I wanted to see how close I could get them down. And I just took this big one you see here and I kept shrinking it using PowerPoint and saving it as an image until it got to the point where the lines between the data bits started to blur and it wouldn't work anymore. And I'm just trying to see how small I could get onto a page that way. But I kept thinking about it. And with the amount of error correction built into most two-dimensional barcodes, I was only going to get about 25 kilobytes of data per page. They have about 60% error correction that depends on the barcode. But it's because they're designed for machine purposes. They're designed for low light. They're designed for weird orientations for people using cell phones. And that's a different design problem than I've got, where I'm basically taking the sheet, putting it on a scanner that scans very well in a perfect environment, and I control the orientation from the get-go. So I thought about, well, maybe I can make it better. I took some features from these barcodes, timing lines, in order to help locate the data and read Solomon Ford error correction. But I was like, I can make it better for my purposes. And so lo and behold, I generated the 8.5 by 11 inch big barcode. And that's what it looks like. And with that, I can get about 85 kilobytes of data per page. And this is what it looks like up close when you zoom in. It has a timing line on all four sides. And it has the data, I call it the data meat in the middle. And if I print that image at about 72 dots per inch, I can get about 88 bytes of information across a single pixel line. And each of these is a bit, right? I mean, that's an off bit. Those are on bits. And I get about 85 kilobytes of data on a page. So I was pretty happy with that. And so interpreting it, I basically, I start with a raster scan going across the image until I find the top leftmost timing mark. And then I kind of stop. And from there, I do a thing which I technically call wiggle fit, where I've got my mask and I put it over the timing mark that I found. And I just keep moving it around until I find the most black part of it. Because you can see when they scan, the edges get pretty fuzzed out. Man, that was cool. The thing got all big. Anyway, and so I wanted to find the most black part. So that's what it does. It moves the mask around. It finds the mask that has the most dark, picks the center point and moves across to the next timing line, timing mark, and it just finds the center of the next timing mark. And it works very well. And I do this on all four sides. And then the end, I end up with this, where each of the centers are indicated. And then you end up with just a bunch of grid of intersections for each of these lines, you know, matching this mark with the one all the way at the bottom, makes a straight line. This guy here, matched all the way to the right, makes a straight line. And I just calculate the intersections and at the intersection of each one is a data pixel. And I picked the data off that pixel and I decide whether it's an on-bit or an off-bit. And it works fairly well. I do get some errors. I didn't expect it to be perfect. My first test runs, I ended up with something like this. This is a heat map. All the black is bits that were read correctly in my scan. Now, these red ones here are bad bits. And there's a couple of little outliers. There's one here. There's a couple over here. This is what I really expected it to look like. Since I started in the upper left, I figured it would start getting bad by the bottom right. It turns out I wasn't really correct. When I took the 8.5, 11 document, I get this big heat problem in the middle here. And stop that. So the big problem here is this is a lot of error. Can't see the error. The red marks? Yeah. Okay. So imagine red marks where I'm circling. I was afraid you weren't going to be able to see it when I was thinking of doing this brief. Sorry. So there's a bunch of red marks and they're kind of clustered. Now, the problem is I have to adjust my error encoding on the big barcode to handle the worst error, not the best error. So if you were able to see it, you would be amazed at how clean it is up here. You would be astounded at how nice it is around here. But you see this giant red stuff in the middle and that's what I have to base my error correction on, which causes a lot of data loss for parity bytes. So I knew I needed error correction. I knew it wasn't going to work, so I want to read Solomon Ford error correction. And it turns out I don't understand read Solomon Ford error correction at all. I don't understand the math behind Galois finite field either. So I was like, well, I don't want to do this stuff from scratch. I'm just going to find a library. There's lots of libraries out there for forward eraser correction and forward error correction, except the pond test I discovered that the majority of the forward error correction ones I found out there just don't work. I don't know who's writing these opaque API libraries that I can't figure out and actually contact university professors and they couldn't figure out. But stop it. If you're going to put something out there, make sure it works. So, but there's a lot of forward eraser correction libraries out there. So I decided to go with forward eraser correction and see if I could use it. Now the problem is forward eraser correction is for a data stream where the, you're missing data. That doesn't make it to the receiver. That's what it's really for. And it works a bit like this. You have a, you have some data and you separate in the blocks. You assign a parity byte to each block, parity bytes to each block. And then if one of those blocks turns up missing, you use the parity bytes and the remaining blocks to recreate the missing block. And that's how forward eraser correction works. Now my problem is not missing data. My problem is corrupted data. So I decided, well, what if I did a checksum and if the checksum didn't match, I consider that block dead and I just take it out. So that's what I did. I got my block of data, my parity data, and then I've got my checksum for the whole thing. And if one of the parity bytes turns back, or one of the checksums is bad, then I ignore that block and try and recreate it. But it didn't work. I had too many collisions and so I was actually trying to recreate the missing data with corrupt data and the math will still work and it'll generally generate a corrupted response, generate a corrupted file. So it just didn't work. So I knew I had to go do forward error correction. Forward error correction is for corrupted data. So you have a word of data. You separate it into bytes. You add parity bytes to that data. If two of your bytes go bad, you can use two parity bytes to find the bad data and then two parity bytes to correct it and it works very well. And this is what I needed. But like I said, the problem was there weren't any working libraries out there for me to use. So I had to write one, much against my will. But I found this really good Python-based library at Wiciversity. And a line for line, I just recreated it in C basically, C++, until I got the thing working. There was a lot of debugging and pain and suffering involved in there. But I finally got it working. And this is what I had to do to get re-sum and forward error correction working for my big barcode. All right. So because of the big heat map of error in the middle that I told you about that you couldn't see, but you're just going to have to trust me, I needed about 45% error correction for it to work. Which means I only got about 47 kilobytes of data per page, which resulted in, you know, it's still order of magnitude better. So if you have PowerSplit, you can get it in 18 pages versus 232. So you can really start moving some data now. You have a good kind of compression advantage over the previous methods. And the demo is awesome. It really is. So I'll show you how it all works. I'll show you how you use the script and the DLL to open the, to create the barcodes and to interpret them. And I do live drops of everything. So yeah, it was really good in my room. You guys should have been there last night. All right. So I decided to give myself a grade on how this went for me. So my goal was to install PowerSplit on a machine that didn't have it on it using these methods and not using magnetic media. So just some grades. Interpret a page size barcode. Yeah, I could do it. The read solemn and encoder decoder. I was able to make it work eventually. There's a yellow mark there. I'm going to talk about that in a second. I built the library. I call it side loading. I was able to get the payload decoded onto my target machine, except because it was like 18 pages of data, I just made a portion of PowerSplit. So it was only three pages long. So I only gave myself a yellow on that. The hex encoder works. I was able to replace the library using the OCR method. And I was able to write my DLL, hex encode it and drop it on my target machine so I could read my big barcodes. It all worked after much effort. It has taken my word for it. So the POC was a success. The kind of stuff I learned from this was that standard offers tools provide a lot of power to the user that you know, maybe you're not fully aware of. We basically have a user-concode. The system is not secure. But the bottom line is any user on a Microsoft-based machine can code. And that is a big attack surface to pay attention to. And a termed insider can do it. And you can use innocuous input-output systems for creative purposes that weren't intended and that no one's really monitoring. No one's really monitoring the printing and scan load, even on the secure network that I was using. And they're not watching for information to come in this way. So it just provides a kind of a hole there to try and squeeze through. All right, some future branch research. I like to reduce the size of the big barcode DLL, the side load DLL. It was 19 pages of hex code. I like to make that a lot smaller. Size optimization is not really my thing, but that's something that I could work on. The error rates. I made an experiment to add more timing lines into my big barcode thinking it would help with the error rates for reading the big barcode. And I was 100% incorrect. It actually messed it up. And I still don't know why. It doesn't make any sense. But I like to improve the error rate so I can use less parity bytes. But this next line is the real key. If I can use, pardon me, if I can use 2 to the 16th read-solving encoding, I can do a lot better. So read-solving encoding at the 2 to the 8th means that your code words are 255 bytes long and it has to include your parity bytes. So you have to base your error on the amount of error you're expecting at 255 bytes. And because of the invisible heat map, I have to plan that for the high error areas, not the really nice areas. 2 to the 16th read-solving encoding means I can have a code word 135 kilobytes long, which is longer than my page. And I only get about 1% of error across that page as a whole. So I wouldn't need very many parity bytes at all if I could use 2 to the 16th read-solving encoding. But I couldn't get that math to work. And it also runs much, much slower. And so running experiments to debug it was taking me too long. So I didn't keep pursuing that. But if I get that working, it would improve the amount of data I could put on each page by quite a bit. If I could add colors to the big barcode, instead of just black and white, I did a four-color experiment to see that way I'm only using four blips instead of eight to define my bytes. I was able to get at the work, but there's a lot of error in decoding a color from a scan, quite frankly. But I think it's an area for future research. And also, I got really excited about using Excel to mess with things. Though visual basic for applications is kind of a pain, it is powerful. The ability to write at the right level means you can do anything with it you want. Making a hex editor at a visual basic for applications would be super easy. I started that a little bit, a steganographic encoder, decoder. I did that already so I could send myself stuff to work. That's easy to do. Restoring the command prompt. If you're on a machine with a command prompt locked down by security policy, it's just a matter of flipping a byte to make that work again. And you can do that with Excel. And I don't know for sure, but I think you can get away with some direct reflexive DLL injection as well, messing with the way Excel calls DLLs. I don't think any of this stuff is earth-shattering new. People have been running it macroviruses forever. They're all back in vogue now. But this is from the perspective of an insider being able to just do these things to your machine. And it's something I think you should need to watch out for. I don't think I can show you much more, unfortunately. Let's see. I really wish I could show you the demo. So here's some stuff that looks like it's left over from when I was practicing. Let's see if I can open this here real quick. I don't know what to do with that. Yep, you guys are watching me mess up this guy's computer right here. There you go. What the heck's the... Texted it. There you go. All right. This thing here, I don't know if you guys can read it. I don't know if I can zoom in. Nope. Let's say again. It's amazingly hard to hear people down there. I don't know if you can read it or not. A little bit. So this.dat file gets dropped when you do a encoding with big barcode. These are the important parts here. You have to have this encoded data length and you have to have the md5 sum in order to decode it with the big barcode on the backside. You have to provide those as inputs to your script. So that's important there. When you decode the DLL, it also drops this file here, which is a prototype for using the DLL. Because visual basic is very, very picky about how DLLs are called and used. So this gives you the prototype for it. And this is all in the... It's supposed to be in the materials that are delivered with the brief. So that's really about it. I'm sorry that my machine was too old in order to use super fancy screens. That's kind of all I've got. Any questions? Alright, thank you guys very much.
to a target workstation on a closed network and This is definitely an insider attack. This is for something I worked on to do work on a closed network to load arbitrary tools. Here's what I'm But I didn't have any of those tools available to post call, but I didn't have curl or W get to do was put whatever tool I wanted on this There is an endpoint security system on this, on that's closer to the Internet and this secure to get fired. So I didn't want to use that. And arbitrary for any insider to have available to what happens if I do that here. Of course, Visual into place using a scanner without too much of a why I use it really, it needed to be really lose in data, and I needed to get as much on a this method. And now, since I'm briefing at changed. So I came up with some alternative little too much. And there's no exfiltration four sides. And it has the data, I call it the do this on all four sides. And then the end, I write one, much against my will. But I found this working. And this is what I had to do to get really is. So I'll show you how it all works. using these methods and not using magnetic media. it on my target machine so I could read my big from a scan, quite frankly. But I think it's an looks like it's left over from when I was in the... It's supposed to be in the materials that are delivered with the brief. So that's