 Hey, this is Alex, this is Dan, and I got something really cool to talk about. How you guys doing? Last talk of the day, then you guys are going to go to bed right after this, I imagine. Thanks for coming out, guys. This is pretty exciting for us. My name is Alex Levinson, got Dan here. Today we're going to go through a tool that we wrote, the agenda today. We're going to talk about droppers and stages that some of you might call them. Not really going to get pedantic about the terminology there. And how we got here today. After that, we're going to go into this technology that we built and how it works. Then we'll talk about some of the real world applications and then we'll give you a demo which will inevitably fail. But, you know, we'll see how that goes. So first off, just an introduction for us. So my name is Alex Levinson. I'm a senior security engineer at Uber. I've been there for a couple of years. My specialty is really in tool development and red teaming. I am a core red team member at the national CCDC and also the western regional CCDC as well. Thank you. Hey, guys. I'm Dan Borges. I'm a senior red team operator in Dev. I also partake in national CCDC on the red team. And Alex and I play a lot of cyber competitions together. So we're just here to show you some of our cool tools. So we got to go back a little bit. We got to cover some basics. First, we're going to talk about what is a dropper. What is this classification of thing we're talking about? In our little hyper local kill chain right here, we have an exploit. This is your initial vector. This is how you're getting on the server. This is usually like a memory corruption attack, something like that. Next attackers usually move to some kind of stager. This is moving from memory to their next tool. Often this can reach out and download more shell code, do something like that. And then this is really where we're going to focus on. This is kind of your stage one some people call it the stage one, the stage two. This is the dropper. You're moving from your exploit to bringing over your tools. This is what's going to bring over your malware. It's going to put your persistence on the box, your deep, slow stuff. And then finally you have your own malware. These are your custom applications, maybe your specific TTPs that you want to put on a box. And again, using a dropper here is important because you can protect your TTPs, your tools and tactics and procedures by using the dropper. So where are droppers used? We're trying to emulate what we see in the wild. What we see is a lot of third party crime where people use these exploit kits and then between the exploit kit and their own private malware, they'll usually lever some kind of dropper. They can do this as a form of packing to either bundle it with other executables or just as a way to get their malware onto the system. We can also use a dropper to be contextually aware and have contextually aware implants. This is kind of like Stuxnet. So do you want to land on this system? Do I want to deploy my payload? Because sometimes you don't want to infect this host. And that's a good thing for a dropper to say and then kind of back off and not put the malware down. And then we use it a lot in our red team operations for CCDC. We like to go fast and hard. So this is the perfect tool for us to really like lay on the pain fast. So a little bit of history about how we arrived here. Back in the day on the CCDC red team, all these people would be bringing these super cool kits. We'd have really advanced techniques and they'd be going against a single team and they'd be using this technique on this team. And what we wanted to do is we wanted to apply this pain to everybody equally. So we started wrapping it in shell scripts and PowerShell, Bash, and all these great techniques to really just kind of drop six, seven implants, up to ten on a single team. So now each team is not getting just one implant made especially for them. They're getting all ten implants we made for everybody. So we can really share. And then around 2015, 2016 we moved to these, like I said, these scripts but they started to have drawbacks, right? They had like a forensic drawbacks, right? People could find the scripts on the systems, PowerShell, script lock logging and they could tell exactly what we were doing. They could get our source code which was pretty dangerous for us as operators. So in late 2016, early 2017, we moved a lot of our tool chain to Golang. We did this for a number of reasons mostly because you get natively compiled executables so you can get a binary that runs specifically on an architecture. This means you have to disassemble it. It's hard to decompile which means you can't get that source code back. It's difficult to reverse. And while we were doing this, we also started looking at what is a dropper, right? This had all of our tactics built into it and we really wanted to say let's abstract our specific techniques out and make a pure dropper that we can put any technique into. And at 2017 at National CCDC, we had a few friends, virus, Lucas and they put together this thing called Genesis where we had an SMB share and you could just drop binaries in it and we bundled them all into one executable and we just ran it on the disk. It run everything that you put into this SMB share. It's just a native executable. This was really cool. This was really good but it had a few drawbacks. We basically, instead of just running everything together, we wanted to specifically instrument them in a certain way. So I think it was late 2017 into the 2018 CCDC season, Alex started working on this prototype of G script, the Genesis scripting engine which we'll get to. And we used it. We used it all through this last CCDC season and it was really successful. We dropped it on every single team at Nationals. Everybody felt the pain. And then between then, which was April 2018 and now, we've added a ton of cool new features, like really sweet stuff. And that's what we're going to get into today. Thank you, Dan. Yeah, as Dan said, today we are going to show the world, you guys, the awesome information security community that we're a part of. Basically what we've done humanively over the last several years, but also some really awesome features that even if you were at CCDC, you really didn't get a chance to play with. But from now on, I'd like to introduce the Genesis scripting engine or as we call it, G script. What is G script? Dan covered sort of this thing. It's this dropper. It lets us take malware and bundle it together and tape it up in a big ball and throw it at somebody. Great, that's a good explanation. But how do you use it? What does it look like to you as the Red Teever? It's really easy. You have your payloads. You write a script for your payload. You use the G script compiler on the command line. You get out a native binary. It couldn't be more simple than that. I use this all over our documentation. G script is a framework that allows you to rapidly implement custom droppers for all three major operating systems. So let's talk about what makes this, what makes up G script, right? So first off, there's the engine. The engine is the thing that is inside of that native binary that you made that actually runs and executes the logic that you specified in your script. There's the compiler. The compiler takes your script and turns it into that native binary. There's an obfuscator that's hooked into the compiler that we wrote. Try and make it a little bit harder for you blue team folks out there. We really do like you but we want to make you mad sometimes. We've got a standard library. These are functions that you can use inside of your Genesis scripts. We've got a command line tool. That's how you interact with the compiler and other things. And we also have an interactive debugger to help you develop these scripts in a more reliable way, let you test them out ahead of time so you're not doing stuff live. A high-level walk-through, here's what happens. When you use the compiler in that three-step process we just showed, what ends up happening very first is the compiler goes and creates essentially representations of engines within memory for each of the scripts that you pass into it. The next thing it's going to do is every one of the payloads that you gave into it, this is a, we'll have a interpreter payload, we'll have some shell code, we'll have some, you know, SSH keys that we're going to drop somewhere. It encrypts and embeds them directly into that virtual machine that it's got in memory. After that it's going to take all in number of virtual machines. Remember it has a virtual machine isolated for each script. It's going to take all in number of those and it's going to sew it all together, it's like with needle and thread, into an actual executable for whatever platform you're targeting. And then when that executable is run, that main that it's sewed up together is going to launch every one of those run times in parallel. So let's do just a quick, a quick walk-through. Can you hold my water? Thank you. So a quick walk-through of this, just to kind of hopefully illuminate you guys on how easy this is to use. So I've got a little example here. The example isn't, isn't crazy, it's really simple. So we're going to write a script, it's eight lines. There's some important things to note in this though. It looks like JavaScript, for all intents and purposes it is JavaScript. We've sprinkled some syntactic sugar in the form of comment macros, so compiler macros that you see in the very first line there. That import statement is telling the g-script compiler, I want you to import this file off my disk when we go to bundle this together. The next line, line three, is just a normal variable declaration like you would call in JavaScript. And then lines five through eight there is a function called deploy. Now when I talked before about when you run main it launches all those virtual machines, the JavaScript VMs essentially need an entry point to launch when that happens, that's what it launches. It launches the deploy hook. So every one of your g-scripts, no matter what you're doing in it, will always have a function deploy with something defined in it. What's defined in ours here? We get the payload dot text, the data that was in that file, we get it as a string called payload data, and then we write that to the destination file which we defined in line three. So very quick, very easy g-script that anybody can write. But hey, this is not just for one script, this can be for multiple things, right? So let's write another one. What's this one doing? It's simply writing a file, second underscore file dot text with the string rect. So what do we do now? Step three, just use the compiler, one command, g-script compile with an output file, star dot g-s. g-s is our file extension for g-script. That's it. And what did we get? At the top, we got dropper dot bin. What is dropper dot bin? It's a 64-bit macho executable. I'm doing this on OSX. What else is in? I run it on the bottom of the first box there. And then what happens? All of a sudden you see desk dot text and second file dot text in that directory. What's in those? Exactly the contents that we had placed in them initially. All of you guys seem pretty quiet. Was that too easy? Thank you. All right. So let's just talk about that. That seemed, you know, why couldn't you do that with PowerShell or shell script or something like that? Well, first off, you're getting a native binary. You're getting a native binary that I could have written the first script, Dan could have written the next one. And if Dan messed his up or I messed mine up, it's not going to take down the entire binary. It's going to keep executing, right? That's the whole point of this is to be robust and resilient in the case of failure. When you do these large scale red team ops and you have many people contributing code, you don't necessarily have the luxury of constantly testing to make sure that somebody's payload isn't going to mess up something in your process, right? So we really wanted to give the people writing the payloads the ability to come up with their logic on how they wanted this to be bundled in to the actual final binary. So you've got your native binary, you've got your isolated G script engines, you've got the user defined logic in those scripts that is actually encrypted and embedded just like the assets are into the binary. And then you've got the embedded assets in their payloads. Those all get bundled together into one container inside of your native binary. So let's talk about some of the features here, right? So first off, number one feature we saw was that you get to do this in JavaScript. Now I'm not a JavaScript developer, but I think that we need to be making tools that are as easy for the broadest selection of us to use, right? So I know a lot of people in here probably see programmers, a lot of people in here do a lot of low level stuff. I wanted to make something common that people were familiar with, there's a lot of people who do web pen testing. JavaScript seems pretty familiar right now to a lot of people, so let's just go ahead and go with that. So it's easy to write, it's easy to learn, there's good documentation on how to write JavaScript well. Next thing is it's resilient to failure. As we talked about, if script two failed, script one would have kept on going. Third, it's highly customizable. So things like order of operations of your script, timeouts, all of this stuff you can customize with those compiler macros that we showed you, right? We showed you one but there's many more you can go with. So how is this cross platform? It's written in Go. Essentially, this whole thing is sort of leveraging the power of the Go compiler to make cross platform malware for anybody to be using here. Number five, it's secure. We ran into this at CCDC where we had our droppers essentially be reverse engineered very easily by just looking at the power shell logs. I'm excited to release this today because I'm excited to see how hard it is for somebody to actually reverse engineer one of these binaries. That is a challenge. Let me know if you do. I'd love to see it. And the number one thing that is new to anybody who has seen Genesis in the past is now you can actually call native Go from within your JavaScript. We'll get into that. I know that sounds kind of wacky. So we talked about this initially, but this diagram kind of gives you a little bit more context as to what happens. You've got your main of your final binary and when that gets run, you have all of these engines running and you have all of these engines that are in their own isolated name space essentially get created. They initialize the JavaScript virtual machine within them. They inject the scripts, all the assets in any libraries, native Go libraries that you've called into it. And then it calls that deploy function, that entry point, if you will, on each of those. And that happens, pending any custom order of operations with your macros, that happens all concurrently. So what does G-Skip really let you do? What does G-Skip really do? It lets you focus on what your stature is doing, not how am I going to implement this for OSX, even though I don't really know OSX or Windows or Linux. So this has been a process for us, right? I'm not a computer science, you know, master's student who's studied the deep internals of how software is made. I would like to say I was, but I definitely wasn't. I started to take an operating systems class in college and I started to take an operating systems class in college and I started to take an operating systems class in college and I was way over my head. So this has been a learning experience for me and this is sort of some of the technology that I've figured out and implemented here within G-Skip. So when you go to do a compile, what happens? Straight forward, the first thing that happens is it looks through all your scripts and gets a, essentially a mapping of all the macros that you've defined. The next thing it's going to do is it's going to walk the abstract syntax tree of your JavaScript, notating things like, oh, you imported a Go library with this macro and then you called it down here and registers, you know, things like, how many arguments are you calling with it? What might the type be? What can I infer the type might be of that argument? It then goes through all the Go packages that you've included in that as well and does the same thing, walks all the AST there looking for places where functions are defined that you've called from your JavaScript. Next, it's going to start marrying those foreign function interface wrappers in Go on the fly for all of the functions that you've called in JavaScript that are instrumented in native Go so that you're, and then inject those into the VM that we're bundling itself together. That's probably another three talks worth of material to get into, but if you'd like to, it's definitely on GitHub, you can go check it out. After that, we embed all of the assets, we encrypt them, each VM has its own function that all the assets get embedded with, and the assets themselves don't actually get decrypted until you call them within your script. So until you retrieve the asset, the asset isn't sitting in memory unencrypted. And then the final step, optional, but we do enjoy it, is the obfuscation step. So we do the obfuscation both before and after native compilation, and we've got some interesting stuff we'll cover as to how that works there. Creating these standalone executables, right? How do we go about doing that? Well, I said we leverage the Go compiler to do that. Now, what's interesting about this is, if you can kind of see up here on this, on the picture, we take your scripts and payload, and we actually write out an entire Go program that contains the logic and everything needed that we just covered into this Go program. Now there's flags in our compiler, you can go look at that code and see what it's incredibly unreadable. We needed to make it that way for security, right? But it's been a really interesting thing to consider that we're in a place in time where it's no longer enough to just write malware. You have to write code that writes code that writes here that writes your malware, right? So we talked about this before too, and now I'm going to dive into this. Linking JavaScript in native Go, I was called crazy a couple of times in the process of this. This was definitely one of those. And I still think it might be crazy. It's probably not the safest thing you can be doing in the world, but it is crazy. Thank you. It's an interesting thing, right? You've got two languages on completely opposite ends of the spectrum in terms of how they work and figuring out a way for a user to almost not know the difference between them is a fascinating endeavor for me and Dan for us to kind of implement this and somebody in the back who shall remain nameless. So here I've got a little example, right? So we use the Go import macro, the compiler macro we talked about. We're going to import Redis. We're going to import Redis because as far as I know, other than Node.js there's really just not an easy Redis library for JavaScript. There certainly isn't one for G-Script. You can't import Node.js modules into this. So how are we going to interact with Redis and G-Script? Well we're going to import the Go package for Redis. So we import that and from there, you import it as you see there as Redis. That as blank, blank is equal to the namespace within the JavaScript program that you're defining here in your G-Script. So on the next one I call the functions directly. So Redis.parseurl is actually a exported function within that Go package and I can call it just like I would in Go. Now one thing to note, there's no multiple assignment in JavaScript. We're in ES5 not ES6. In this version there's no multiple assignment. So if you look on line 5 you'll see r0. r0 is because in our linker that we do, when we see that you're calling a Go function that's returning multiple assignment we actually make a dynamic array of that and give you back the return inside a single object that is an array of various types. So r0 in that is going to actually be the Redis client the Redis connection URL. So line 5 we create a Redis client and line 6 we simply interact with it as we would any Go program, right? And then down there you look at the script we compiled it normally and ran it and boom. Got the, was able to interact with Redis right from G-Script using this native bridge. So I wouldn't give you something incredibly unsafe without some way to at least play around with it and see how it worked and test your stuff, right? So we spent a lot of time on an interactive debugger. It's pretty nice and easy to use. So at any time after you've installed G-Script you can simply do G-Script shell and it will drop you into a REPL right there. The REPL has the entire standard library that you've bundled into it and you can do kind of some various things. So for example we talked about macros. How do you get a macro into the shell when it's something that the compiler knows? Well in G-Script shell you can just pass the dash into it with macros you can pass multiple as many as you'd like into it and then when it drops into that shell it says if you've dropped into the deploy function with that VM instrumented. Other things you can do is you can see that I'm essentially doing the exact same thing that we were in the previous demonstration of the native linking. Except now I've got some functions that as I'm stepping through help me understand a little bit more about what's going on. So the function type of which you can see is the third function I'm calling there. It's actually showing me that under the hood in JavaScript this is actually a pointer to a Redis client object in Go's namespace. That's a pretty nice thing to have to be able to use here as well. Also any time you're in a script if you want to compile a binary for yourself but then be able to drop into a debugger we have a compiler flag enable debugging and you can just use the function debug console just like you would debugger in Chrome or anything like that and when you run your binary it will drop you into the same console right where you're at in the context of your script. Outside of that as I mentioned before especially functions that are only available from within the debugger that's been something we've expanded on the last couple weeks to try and make the native linking a lot more easy for people to do. Another one is symbol table so you can call the symbol table function in the interactive debugger and that's actually going to go through and show you all the functions within Go's namespace that you've imported in there. Our standard library is actually instrumented in Go. You don't have to import it as a Go module because the compiler is smart enough to know oh you're calling a standard library function I need to link against that. So we talked about how cool it is there are some limitations and we'll just get these out of the way real quick. First thing no free VSD support I know that some of you neckbeards in the crowd I'm looking front row here are going to be real upset about that. But I don't think it's impossible it's just something where it was on a medium priority list to go and get done. I think as Go becomes more free VSD compliant and things like its OS and user lib we'll be able to extend support to this as well. One of the other limitations that kind of people I've seen have issues with is these are large binaries. If you've ever worked with Go before you know that Go binaries are never known to be the smallest, tiniest payloads in the world. Another limitation is the regular expressions if you're going to do any regular expressions they need to be essentially compliant with the RE2 library that Go uses. So things like look ahead and stuff like that you're not going to have compatibility in that so you've got to be careful you can't use crazy complex regular expressions in it. Another thing that's been kind of difficult for us has been versioning. Go's versioning story has not been the greatest part of the language as it's evolved over the years and that made it hard for us to do a version of it so as Dan and I have done this Dan will go write a bunch of G scripts and then I'll come around and I'll make a compiler change that'll break all his scripts and he'll be like oh why can't I still stick with the old version. Well a lot of that has been tied to this Go versioning problem. In the future Go is releasing in 1.11 their new Go mod support I think in the next major version of G script we'll actually release with an ability to lock it in and be able to have backwards compatibility. As we said before ES5 is the only thing we support right now. Working on ES6 support there's complicated reasons why that's difficult for us but something we'd like to do as we talk to people that write a lot of JavaScript they seem to think that would have been a really nice feature for us so we're working on that. Also something that we don't have is a lot of the JavaScript concurrency primitives that you guys might be used to because our virtual machine is actually instrumented in native Go we have to do all of this concurrency actually outside of that virtual machine's namespace. But as I mentioned before we have the standard library you don't need to be a Go programmer to know how to use this on a basic level. We've got libraries that cover almost every type of basic OS functionality you'll need. They're entirely cross platform they're supported by us if there's ever a bug in one of these and please file it against us we will fix it immediately. It is exactly the type of stuff where as we sat down and used GScript in our jobs and at CCDC we were able to say oh there's some parts of Go that are just complicated and maybe not straightforward for the normal person so let's just go kind of wrap that basic functionality in our standard library and present that to users for ease. So with that I'm going to hand it back to Dan to talk about some of the ways that we've used this in the real world and why it just has really been powerful for us. So like Alex was saying one of the number one reasons we use it is because we encounter a wide array of systems Windows, Linux and Mac and we didn't want to keep rewriting our techniques for these different operating systems it was really kind of a pain so we really like the cross platform features of it you can actually write G scripts completely system like let them completely cross platform where the binary itself will determine which operating system it's on using Go and then execute according to that obviously you have to compile it to a specific architecture so at the compilation time there's always that and when you're embedding assets you still need to embed assets that can run on that specific architecture but the platform itself is cross-platform so I love that. It's also really easy to use originally we were considering like having people write the Golang for that original software and then use that to embed their stuff and it was a really hard kind of ask for people to learn Golang so instead we decided to roll this out because now all they have to do is learn JavaScript and JavaScript is really forgiving unlike Golang where it's really opinionated and you have to like handle all your errors so we think the barrier to entry with JavaScript is a lot lower than Golang another neat feature of that is when we added the Golang native linking now it's also a good feature to learn Golang right? You can start with JavaScript, you can play around in the debugger and eventually you can just start writing your own Golang native Libs and then call them from GScript which is pretty cool. Just like I was saying where you can call any Golang native library like off a GitHub which is really freaking sweet you can also wrap your existing tools so you don't really have to change any of your existing tactics or any of your existing methodology you can just instrument them now with Golang which is this is now like persistence and techniques as code it's very auditable we can give somebody this script that says this is exactly what it's going to do when it hits disk which is really nice because as you'll see we've been building a community around documenting all of these different G scripts or I'm sorry documenting MITRE attack techniques in G script so now if you're familiar with MITRE attack we have these small little atomic techniques we've been writing G scripts such that you can compile native unsigned binaries with these techniques it's kind of neat because this way you can see can I detect an unsigned binary doing this from a blue team perspective as opposed to like a script doing this which might be easier or harder depending on your instrumentation so like I was saying we've been writing a ton of G scripts and we've been writing them to the MITRE attack framework I try to make them as atomic as possible so I try to keep the techniques as small as I can compile any number of G scripts into a single binary so the idea is you have a bunch of little techniques that all play well together and again we really want people to contribute stuff we want to continue to catalog that MITRE attack framework such that we can compile it to these native binaries so again this tool was really built with a community in mind this tool was built with multiple red teamers contributing payloads to build a single binary it's really collaborative first like collaborative post exploitation is the idea we want everybody to contribute a G script and an implant and we're going to run them all on the victim because we're a team so here's a quick little example just showing some stuff up here we have a go import of a native package which is OS we're going to use this to create a temp directory later but we also import a special library we we made called the X library we had a lot of help with a unnamed person in the back and this is an amazing library because these are the functions that yes they're platform specific but we would be remiss to leave them out right this is windows registry editing this is process injection this is kind of that fancy stuff that is platform specific and again we move that into the X library because the core of G script is supposed to be cross platform and then below that we're creating this croissant.exe this is any arbitrary executable in our case it pops a croissant because croissant rock we croissant okay so first thing we're doing is in this first block this is just prepping the asset this is just saying we have an embedded asset from compile time and we're just going to create this random temp directory string and that's where we're going to write this asset execution just to write that file to a path we're dropping a file so this is like a great detection exercise and then here is a run once key and we're just adding this to show this persistence method so the idea here is we're creating persistence as code and we're abstracting the implant from it right so now you have this arbitrary now you have this arbitrary persistence technique and you can just persist any old implant and it's great for detection ops because we do we detect persistence technique it's also really cool for hunting ops one thing that I really like is this idea of compiling a g-script with multiple techniques in it like a technique A and a technique B and we can run this and then later a blue team can find this they can dissect this and they can understand the techniques in it then they can hunt on those techniques let's say they had an alert for technique A they reverse it and they learn about technique B then they can hunt their data for technique B and then they can use these techniques in games where we also compile a binary with technique B and technique C and do they find that right something they may not have the alert for so it's kind of cool for these advanced hunt operations if you can get there in your organization so kind of just like why do we really love this like if I could give you like one line and number of techniques we keep the techniques really small and auditable we wrap our existing tools our favorite tools on disk or in memory but we can codify the techniques of how we're instrumenting them and then run them with a single click so like what's not to love so this always works right one really cool part about CCDC Dave Cohen is like the grand master and he has this great strategic vision and at the end of day two at some point he really like he unleashes the hounds and we have to burn things down so like taking down services is pretty straightforward right like service whatever stop pretty basic and boring so you want to get creative with it and you want to have some fun so one thing we like to do is make these troll payloads or troll wear if you will so here we've bundled a ton of different troll wear and we're just executing it on a windows machine the idea here is you just see how much stuff can happen at once you can really deal with it it's a little overwhelming when it will execute and then it blue screens the box but it's cool so I'm just stepping into the directory where it is I'm making the screen bigger so you can kind of see stuff as it happens but once we execute this the whole machine just goes to hell so this is going to run multiple payloads this runs the MEMS which was made by Leoric and Koot we had a good friend reverse a bunch of malware on the internet and we instrumented that so that's just some of the troll wear we like to throw around one demo down one more to go the next one is live the next one is actually live that was just a video but we're going to do this one live too we had another demo as well planned RIP in the back there but I'm going to save that for next year so I'm going to boot up a virtual machine here called Defcon 26 demo this is just a standard OSX virtual machine I'll make it full screen in a minute here but first thing I want to do is I'm going to let's go through and make one of these together so I've got my terminal up here you guys can read that I'll make it a little bit bigger for you guys cool so I've got my terminal I'm going to do an LS I've got in here we'll just go ahead and remove my test one so we can actually do it live in it I've got a folder with a bunch of G scripts this is all just Mac persistence technique doing things like disabling the firewall and enabling guests and doing some SSH key persistence and all of these I'll show you one like a service installer it goes through and uses a library that we wrote called xService so this is an experimental library but it actually is a cross platform service installer so it doesn't matter if there's like sysvnet or systemd or it's a windows box you can very easily in one unified library install a system service which is always fun we love to do that when we're red teaming I'm going to just go through and make one now live here with you so I'm going to do gscript compile dash dash output file users demo osx live.bin and then I'm going to say gscripts star.gs we're going to run this in what it's doing most of the time it's spending right now on this it's spending actually embedding and encrypting all of the payloads that we're putting into this into the binary itself so I think this takes about 20-30 seconds right now but as you see here it does tell you all the scripts that it's essentially bundling into this executable it lets you see some information that we're doing this for Darwin here's the output file which I talked about before so being able to keep the build directory which will show you the source code that was used to make this enabling upx compression disabled by default a lot of different options will give you and boom scroll down it's done I'm going to look in there it is a 26 megabyte binary what payloads are you putting in here lord thank god that's local and we have internet into while I'm here SSH into our Merlin server Tmux uh there we go we've got some old dummy agents but it's fine they're not connected yet let's go into our VM now and take the executable that we just built OSX live copy it over there we go I didn't enable any of that so it's going to be silent so we're going to say sudo dot slash desktop OSX live enter and a bunch of stuff is happening and then enter my password that's not phishing at all boom so something happened I don't really know what if I look back at my Merlin I've now received a new agent check-in let's just come in here and look and see some things file sharing, remote login, remote management all this stuff was turned on so all of the attack techniques that we just bundled into this were actually run on this machine so if you're a red teamer I think you can extrapolate why this is so valuable tool to use in your tool chain if you're a blue teamer if you work at a company that has a bunch of detection systems man how many of you guys have always wanted to know is actually telling the truth that they detect this thing or not you can write the g-script and I promise you they're not going to detect the binary if they detect the actual activity then you can validate that and that's really the fundamental problem right now in the blue team space is how do I trust that when a vendor sells me something that says it does X that I actually know it can actually do that what we're trying to do here is provide blue and red teams alike the ability to codify these techniques and ensure detection on a file is not going to just cheat the actual result of saying yeah I detect when something does shellcode injection well do you actually detect that or do you just detect that a file has a string in it that matches a certain thing right this is the type of evolution insecurity that we're trying to present to the world so we'll come back to our talk here and that's it version one is live right now on github I've written some documentations out I've got some shout outs for some awesome people who helped us with this on the side as well as somebody totally unnamed who didn't help at all with this project and he's not here he didn't help us his name is not at the bottom of that list of authors there so with that I'd like to open it up to you guys for questions, comments anything thank you good say that one more time you probably could I've not so the big problem with it has been the regular expression compatibility so the question was could you run a normal JavaScript application within g-script yes as long as it didn't break the regular expression or the asynchronous incompatibilities right now it should be fine so something like underscore for example does work within it underscore library into that and it would work just fine the ES6 compatibility is something where I think if we can get that actually implemented it'll give us a lot more flexibility in being able to allow more current JavaScript tools to be able to be brought inside of it yes right here yes no everything is so the question was does the dropper do such things from the github URL it doesn't when you run g-script compile it contains everything you need right then and there into the binary so everything happens at compile time all the embedding does it was one thing we were kind of on the fence about saying should our droppers reach out and get stuff or should we just really try and pack them tightly and safely internally one of the ideas there is when you're in a high security context solution you can do things locally and then use that existing c2 channel to shuttle stuff over right so we have a request library and you can like pull stuff down but personally I like to kind of do stuff and then go out of existing c2 channels and just operate through those channels I think we had a question over here yes yeah so the encryption of the assets is just 8 ES 256 I'm not going to claim to be a crypto expert I just follow best practices on that it is isolated per VM and it's unique every time you compile so it's not generated in any sort of deterministic way now the obfuscation I'm glad you asked the obfuscation I would say is implemented in a way that assures zero reproducibility of builds so if you're trying to reproduce an MD5 hash of two exact same inputs and outputs of a g-script binary I doubt that would happen the obfuscator is meant to try and remove the ability to find static strings within it it's meant to randomize things like function names and address space within the binary itself and then we also have a post obfuscator that is not turned on by default but you can play with it it works really well on Windows and OS X Windows, excuse me it works really well on Linux and OS X Windows it kind of has some problems sometimes it basically after Go compiles your native binary it just goes through and starts patching stuff out of the native executable it's really dirty but it does actually work it does a great job sometimes yeah sometimes that's why we test right anybody else have a question we've got about five minutes left maybe over here I haven't no come on everybody just wants to go sleep right yeah we got a question in the back there what if you want to write your own compiler that's a great question so we've implemented gscript basically as in everything you've seen here whether from the obfuscator to the compiler to the engine itself it's all implemented itself as a library so if you wanted to implement your own compiler you could actually take the engine library figure out how to translate whatever it is you want it as your input into an engine itself bundle that together and then boom you've got you've implemented your own essentially gscript compiler we've got some stuff on the works if you're going to be at our workshop tomorrow if you're going to be at our workshop tomorrow we'll touch on that a little bit of how we're actually looking at implementing a C2 in gscript so that the C2 itself can supply the binary with gscripts at execution time so there's not actually something bundled into it or it can say hey switch up the C2 channel talk to me now on this other channel interesting stuff like that is I think what you probably see from us next year in another follow up talk yes right here so we don't have a slack we probably should have a slack that's probably a good idea at this point it's just been on github if you send me a pull request I would love it we put a lot of effort into this it's taken a lot of engineering hours and we're excited to kind of share it with the community a lot of stuff we do at ccdc it's released so this has been something where we're excited to say look here it can be good for the greater community at large we have a few contributor guidelines too and then there's a lot of ways to get involved you can write gscripts you can help write different native libraries you can help add to the compiler itself and you can even just help with the documentation like anybody that wants to get involved we're really receptive to people helping I think we're yes so inside the documentation if you go to this github there will be a link to Dan's repo where he is actually doing all of that mitre mapping in a separate repo I'm open to suggestions so when you check it out if you think there's a better folder structure right now I was just doing it based on platforms and then I have each of the techniques linked in like the meta information in the top but if there's a better way to organize it I'm all ears cool I think two minutes left anything else anybody raise your hand do you think you might use this at some point maybe a little sweet awesome maybe we'll have a little gscript con sometime thanks guys