 Hello and welcome to Offensive Golang Bonanza. I'm Ben. Hi, DEF CON 29. We're going to talk about Golang malware. A little bit about myself. My first DEF CON talk was at DEF CON 13. I'm the host of a hacker themed podcast where we interview a lot of people around this community in very in depth, very technical. Please check that out. And I have a bunch of random projects on GitHub. So what this talk is going to be, there's two ways to consume it. One, you can just listen to me, describe a whole bunch of Golang malware components and you'll get a sense of what's out there, what's available, what's possible. And if you want to go in depth, there are links on all of the slides to the actual code repos themselves, code samples, interviews, news articles, all kinds of stuff. So to start with, I'm going to do a little bit of backstory on my hacker crew and a little bit on Golang and why it's so interesting to malware developers. And then we'll start going through various components and tools. So in the beginning, I was interested in anti-censorship surrounding a particular Iranian election. I was taking a look at the Torah obfuscation proxy, OBS proxy 2 at the time. And I thought I could do better. And so I started the ratnet project, which is a pretty cool NIDs evasion thing we're going to talk about later. And I was using that project as an excuse to learn Golang. And what I learned is that Golang is magic. Unlike any programming language I've used before, just anything you need, anything you would normally have to install as a separate library or utility is just there for you. Everything from crypto, networking libraries, virtual file systems are supported natively, which is totally unique. The compiler cross-compiles easily to every other architecture and operating system. There's built-in test frameworks, vendering frameworks, it's garbage collected. It has a very efficient thread implementation and it has its own assembler. And the third-party library support is totally unparalleled. So Rust is years away just to answer the question of why don't I rewrite everything in Rust. But the main reason that I love Go is that it is the fastest way to be done. And my goal is not to reinvent every wheel. My goal when I start a project is to be done with the project and use the project. And the fastest way to learn Go, the way I learned, is a document called Effective Go on the Golang website, which assumes that you already know how to program and just tells you what's different about Go. I would highly recommend that to anyone who wants to learn Go, especially if you already know how to program. So a few relevant facts about Go, it is not interpreted. I'm not sure why people seem to get that misconception. It is statically compiled. However, it also, every Go binary includes a kind of monolithic runtime. Which is like 800K on most operating systems. So it's a bit of overhead per binary. And then all of your code is statically compiled. On top of that, all of the dependencies and everything that aren't already in the runtime. The embedded assembly language is based on Plan 9's assembly language. So it's a little bit crazy. We don't have time to go into it. But I did a write up that will kind of help you cope. It's linked on this slide. I would recommend checking that out. So to get into the story, Stuxnet happened and everyone got very hot on environmental keying. Environmentally keyed payloads. Josh Pitts made a tool in GoLang to do environmentally key payloads called Ebola. It got very popular with the red teamers at the time. And so all the EDRs and AV companies wanted to write sigs for Ebola. But they had never seen a GoLang hacker tool before. And so they all ended up writing signatures for the GoLang runtime, which is included in every GoLang process. So what happened next is that all of the AV utilities triggered on every Go binary, including the installer. But it also included the very prevalent orchestration tools, Docker and Terraform. And so as a result, they all had to pull those sigs very quickly because, you know, people need their Terraform. And this is a pattern that malware developers look for. We call it a JAR to EXE pattern. We're basically, if you have anything that makes a native binary for you, but it has one legitimate user that means the AV companies need to whitelist it. And they have trouble creating sigs for like Java inside a JAR to EXE. Binary, they have trouble creating sigs for Python inside a Py to EXE. Binary, if those are whitelisted. And similarly, they have trouble creating sigs for a Go code, which is statically compiled past the Go runtime. So realizing that, and also I had this sweet exfiltration library. I had been working on Call of Ratnet. I started talking to other security people that were interested in Go. And we got together, shared ideas. Things escalated very quickly. And we, you know, this has happened in the past with Python. Now it's happening with Go. And we made a bit of a community. Probably the best example of this is there's a particular Slack server where Pound Go lang, the Slack channel, has like literally, it's like the best place on the internet. It has like all the people working in Go lang malware basically hang out there. They share ideas that are really nice to each other. There's no kind of like political or weird other internet nonsense. It's just people, you know, helping each other with projects, suggesting project ideas. And it's just amazing. So we're going to talk about tools from a lot of people in this chat room. I bold-faced the ones that are specifically mentioned in this deck, but everybody in there, just thank you. It's been totally critical for my sanity, especially over the last year. And I especially want to thank the community organizer, Jeff McJunkin, for keeping most of the crazy out. So just a quick word about, you know, offense and defense. All of these tools are open source. We post the code. We hope that the people who work on operating system and defenses and defensive tools will study these and learn how they can improve. Some of the problems, especially the bypass tools exploit, have been around for 10, 20, in some cases 30 years. So having, you know, there's no, it's not O-Day. It's just like, you know, things have been broken for a long time. You can't just bury your head in the sand. So we're trying to make things better by helping people understand how things actually work. And on that note, I'm going to talk briefly about what tools exist for reversing go binaries. There aren't a lot that are useful. Even now, the most useful one is probably the go reversing tool kit. They have a tool called redress, which is fairly successful at extracting metadata from stripped go binaries, including dependencies and compiler versions. And then there's a few Ida scripts and blog posts linked on this slide, which give you some clues as to how to go about reversing a go binary, but it's still pretty primitive. And I think a lot of the trouble is the static compilation aspect that you've ever tried to open up an embedded C program that's statically compiled in Ida. You end up having to sort of manually work out what a lot of the functions do. There are kind of flare signatures, but I haven't seen that for Golang yet. So some of the core components for the rest of the tools we're going to talk about. The first one, the one that gets used by almost everything, is our fork of go standard debug library. So go comes with a library called debug that parses all binary formats, P, E, for Windows, Alph, Linux, and Mac O for OSX. We forked that, fixed a bunch of bugs and added support for editing the file, changing things by their fields and then writing the file back out once you've changed it. So we turned it into an arbitrary binary modification framework and we also made it parse files that are already loaded into memory and also you can write them back out to memory but you need a tool we're going to talk about later. But this is especially cool because you can parse your own process, which lets you do a lot of neat malware tricks as we'll see. And you can also inject shellcode into a file on disk which is also pretty handy. So the parser entry points for P, E, Alph, and Mac O are always either new file or new file from memory. The generator entry points are always called bytes in case you're looking at the code. Also some of the stuff we added, we added base relocations and relocations. We added import address table fixups, the ability to add sections, the ability to hook entry points and the ability to access and add signatures which comes up in a lot of the malware tools we're using. But this might be useful for other things as well. Another core component is CPPGO. We got this from Lauren Siegel. We just forked it and added support for the Apple M1 for ARM64. Basically this is a way from go to make native calls into any other library using any ABI, any calling convention. So it comes with standard call, C-duckle, and this call. And so this is absolutely critical for a lot of malware functionality from go. I'd highly recommend you check it out. It's a great example of GoAssembler. Moving on to the exploitation tools category. Our first exploitation tool is called binjection and this uses the binject debug binary modification platform and adds a layer on top of it which implements a variety of different algorithms for inserting shellcode into a binary. Predominantly hooking the entry point but it wouldn't necessarily have to be. So there's a command line utility. You can also use it as a library. And so it's very extensible and we've implemented a variety of algorithms including for PE the one we use the most often these days is just adding a new section. You hook the entry point to point at the new section. At the end of the new section you have it point back to the original entry point. So basically file starts, runs your shellcode in the new section, jumps back to the original entry point. Modern PE's don't have a lot of code cave space anymore. I guess there have been compiler improvements. So this is the most successful method for PE we've found. For Elf we have a variety of different methods. We're probably going to add more. We have Silvio Cesare's original padding infection method which we updated a little bit so it supports position independent executables and we also Esplip from the channel also implemented a completely new injection method based on PT note in there and we also have C tours or constructor hooking for shared libraries so not only can you hook an executable you can also inject shellcode into a shared library and have that run when the library loads for Mako we're predominantly hooking the entry point and using the one giant code cave which is in all Mako binaries before that first load segment. I'm not sure why that is always the case but there's always one giant code cave you can fit a bunch of shellcode in. I don't know just a quick example of what the code looks like this is the whole Silvio method from binjection there are no there's no weird offsets there's no hex math you can just read it and it's referring to the actual fields in the file format and that's coming from binject debug and this is the right layer of abstraction that you want to code injection algorithms in and that's kind of the whole point so it's easy to understand the algorithm just by reading the code it's easy to add new algorithms now what kind of kicked off the binject debug and binjection project was the desire to make the old tool from Josh Pitts backdoor factory work again so backdoor factory stopped working and we were like hey let's just rewrite this whole thing and go we broke it into modules and we ended with binject the bug binjection and finally we needed to close the loop with backdoor factory so backdoor factory is the thing man in the middle someone who's trying to download a binary and inject shellcode into the binary automatically it was beautiful red teamers loved it got used all the time and then it stopped working and we were all very sad backdoor factory originally worked with a tool called Ettercap which is terrible and old I mean it worked at the time but it was in the curses and there's a better go rewrite called better cap which add support for more man in the middle methods and so we decided to use better cap for the rewrite and then we already had binjection you know so basically better cap has a scripting language called the caplet scripts and they already had implemented a script for better cap called download auto phone which intercepts web downloads and replaces them with a malicious payload so it doesn't inject it into a file it just replaces it entirely but we just started from that and then in the caplet language only exposes read file and write file commands that's the only way you can interact with anything outside of JavaScript and so we figure we'll just make a named pipe server and use read file and write file to pass the file it'll out to binjection, inject our shellcode and then use read file to read it back in through another pipe back into the caplet and return it to the user so that looks like this so you can use better cap to man in the middle someone's download using ARP spoofing, DNS poisoning, DHCP v6 or anything else better cap supports that their download request comes to you you go out to the server they were originally trying to access and download the file they were trying to get and then you pass that file through the new pipe server the new backdoor factory to binjection where shellcode gets injected into the executables and then the whole thing gets repackaged and passed back to the user and they think it was the file they were trying to download open it, run it, run your shellcode that's the general idea so our implementation of backdoor factory lives in binject, basically what it does it starts up this pipe server it spits out the caplet and better cap config files that you need and it tells you exactly what better cap command to run which is just mainly because I kept forgetting how to use better cap you may need to customize that caplet file in the better cap config you'll have to customize the caplet if you want to support different user agents if you only want to trigger on certain user agents you can do that very regular expression or if you only want to trigger on file extensions you can also edit that in the caplet also by default it will do ARP spoofing that might be too loud if you want to do DNS poisoning you'll have to edit the default better cap config that comes out of there so some features that we added we added support for unpacking archives so it'll actually if someone's trying to download a tgz or zip file it will unzip that on the fly, inject all of the binaries inside it then rezip it and pass it back to the user we're also working on adding support for re-signing the binary with a stolen or purchased key and we'll word on that in a sec and we also ported this to the wi-fi pineapple because back in the day running Backdoor Factory on a malicious access point was super fun and Golang supports easy cross compilation to MIPS32 so there are links to the better cap and Backdoor Factory packages we made on this slide so quick demo so on the right we're downloading a file with WGIT unzipping it, running it and it says I'm a simple program blah blah blah now on the upper left we're starting the pipe server which opens up some named pipes to binjection and it gave us generated some better cap configs gives us the command to run better cap in another window we run better cap and it starts the ARP spoof and intercepting files using our caplet so we go and download the same file we just downloaded again you can see the size is a little bit different unzip that run the binary inside and you can see it printed test in addition to the original output that is a shellcode we made which is a test shellcode which prints test so that's proof that our shellcode has been injected and also the original program still ran so that's the new Backdoor Factory so because the files are being passed in by a pipe we actually don't, we lose the extension of the file on the way in we don't get that through the pipe so we're actually using MIME so we're using a go library to determine the MIME type and then we have the switch statement to determine what type what injection to do that's how we figure out what file it is so if you want to extend it you can just extend it by MIME type which is actually pretty awesome there's different MIME types for like jars than zips which is pretty cool because some programs would tell you they're the same format and the main call to the injection looks like this inside Backdoor Factory Moco L4PE and then it calls, it pulls the appropriate shellcode and then calls bingect near the bottom there to inject the appropriate shellcode into the binary so signing from Golang is also very well supported the two main libraries I'd recommend that you check out one is called Limeliter it does authentic code signing of EXEs and DLLs you can either use a real cert or it'll make one up for you which is also kind of handy for EDR evasion and another one that's a little bit heavier but signs everything is Relic and Relic not only does the authentic code signing stuff it also supports like CentOS RPMs Debian Deb files, Java, JAR files Silverlight ZAP files which is pretty handy if you can still find some Silverlight PowerScript Android APKs and Makos and DMGs for Macs so there's a lot of possibilities for extending Backdoor Factory to new and interesting file formats so moving on to a different exploitation tool from CISTO we have GoWiExec which actually brings the ability to just do remote WMI Windows management interface calls to Go which lets you just run random shell commands on some target Windows machine out in space there's also another library that gives you full SMB support GoSMB2 and so if you put those two together you can replicate impact it's SMB EXEC functionality so you can upload a file with GoSMB to a target and then you can execute it with GoWiExec so you can put this in your implant and have it like auto spread or you can use this as an initial inject assuming you have creds for a Windows box and so in code it's kind of just as easy as this I couldn't fit all of the file upload stuff in there but you can see the WMI call basically you just pass it username, password or you can use a hash if you have it because CISTO is magic and like the domain and the client name and stuff you can either randomize those or they're optional so it's you know it's pretty easy to use and for a full example of SMB EXEC and Go including the file upload stuff check out the source code bundle on the DEF CON media server for my DEF CON 29 workshop writing Golang malware and there's a lot more detail in the workshop slides so some other exploitation tools don't have time to go into but GoFish is a very popular phishing tool kit GoBuster is good for brute forcing sub-domains there's a little DNS server you can use for EXECs it's also good for DNS black-holing which is good for Android reversing and there's also ModLichka which is a phishing reverse proxy which has some novel 2FA bypass stuff in it so those are all Go repos you should check out or use as a reference moving on to EDR and NIDS evasion tools the most important one is Garble this is the state-of-the-art Golang obfuscator it does not do control flow obfuscation unfortunately but hopefully that's coming but it will strip out almost all Go metadata with the optional dash literals command it will replace string literals with lambdas which is very important for avoiding sigs and gobfuscate was a bit broken it it was slow it didn't work with Go modules it had trouble with dependencies Garble fixes all of that it's actually remarkably fast it's incredibly easy to use and I haven't seen it choke yet which is amazing so there's really no reason not to use garble on everything as far as I know and definitely try that redress tool try redress on something before you garble it and then try it after you garble it and see what happens that's probably a good time so in terms of NIDS evasion there's a lot of network code out there and the project is ratnet it works it has a couple of unique features it works on store and forward so it actually is not stream based it bundles messages up into batches and each message is individually end-to-end encrypted but the batches are also encrypted separately for every hop it works on mesh routing so every ratnet node acts as a router and it also supports pluggable transports you can also support multiple transports at once and you can dynamically change between transports so the transports that we ship with we have UDP, TLS, HTTPS which is like cloud-fronting and we also have DNS and AWS S3 as a transport which is pretty neat and this also works without the internet as just a mesh routing middleware and I'm working on a hand-held ratnet-based hardware device which will come out as a crowd-supply next year so watch this space for that so a couple of use cases that we support with ratnet one is say you've hit a bunch of machines with an implant and not all of them have direct internet access and you want to pivot you want to be able to talk to all of the implants from your C2 so what you can do is get an implant where the implants find each other using mdns or multicast and if they can't get to the internet directly they will just automatically route all of their messages out through one of their peers and if any one of those peers can find their way out to the internet to the C2 you can actually it'll just automatically make a network and you can talk to all of the implants because the implants in the middleware are not that networks so there's actually a demo of this working also in the workshop source code the other use case that we want to support is if you drop an implant into an egress proxy data center so if all web traffic or like almost all traffic is blocked out to the open internet from where you are you can still usually get out with dns because the local dns server will helpfully pass out through recursion so that's what the dns transport is for you also might find yourself in a situation where lots of things are blocked but some things are whitelisted and in those situations typically aws is whitelisted because almost everything is using aws at least a little bit so there's a lot of other going tunnels and proxies to look at other than ratnet so some of the popular ones are chachal and chisel used together in a ransomware attack very recently there's a link in this to a very interesting breakdown of some ransomware that use those two and there's also wire guard is a distributed vpn which is actually a commercial product which is implemented in go and very worth checking out it's a lot easier to set up than open vpn just in general so there's a lot of other tunnel and proxy code in go because go is typically very stable probably more a result of the built in testing framework than anything else but there's a lot of good network stuff in go moving on to another edr evasion tool there's pandora's box so I mentioned that golang has native support for virtual file systems that means that anytime in go you're referring to a file you can totally control the file abstraction it doesn't really have to go to the file system you can make a for example an encrypted in memory virtual file system and use it exactly the same way from your go code that you talk to normal files and that is what pandora's box does it basically is a shim between the mem guard library which tries as hard as it possibly can to give you a secure enclave in memory to protect what you're putting in a mem guarded region from tools like volatility or other analysis tools and so basically pandora's box is the bridge between the golang file abstraction and mem guard but it gives you an encrypted vfs very very easily definitely worth checking out so this is another one of my tools I call it the universal loader I implemented reflective DLL loading in golang for all platforms including the the Apple M1 so it actually works with arm64 this might be the first loader I've seen anywhere that actually supports the M1 although other than that it's doing a lot of sort of traditional reflective DLL loading stuff so reflective DLL loading basically mimics the behavior of the system loader when it loads a dynamic library into a process it just does all the things the system loader does as best it can so it loads the library into the process lets you call functions that were in the library but doing it reflectively means that you never need to touch disk which is the main advantage if you never touch disk maybe AV never triggers you know da da da da so the the back ends for the universal loader for Windows OS X and Linux are a little bit different the windows method does not use the system loader it does use some go assembly to walk the peb and figure out and then it uses bingecta bug to like parse the process you're in and like figure out the imports and exports of everything and there is a branch of the universal loader that actually does do import address table fix ups it's called import address table and if you are loading a library that depends on other libraries you will definitely need to use the IAT branch the OS X method actually does use the system loader we followed a training from malware unicorn which I highly recommend checking out on writing OS X malware and it actually finds where the dynamic loader library is in memory and then parses it with bingecta finds a couple of key functions in there that for some reason for some reason OS X is the only operating system that has built in part of the operating system that lets you load a library from RAM both windows and Linux require a file somewhere but OS X does not so we just we just use that oh load a library from ram method and you know bodge your uncle so that's kind of why we're using the system loader for OS X and no one else and then the Linux method does not use the system loader either but it also does not use MFD it really does a reflective library load for Linux MFD is a Linux RAM disk and the previous loaders for Golang just dumped your library to MFD and then just loaded it with DL open we do not do that although it is easy and it works use of MFD is unusual and it's easy to detect so doing an actual reflective library load is a bit stealthier and that's what that's what we're doing so this is what it looks like in code the interface as I said in code is the same for all operating systems basically you got your library loaded in a buffer and you make a new loader with new loader you call loader dot load library that's the universal loading your buffer as a library and that will under the hood work differently for whatever operating system you compile it for but the interface remains the same and then you can just call exported functions in it with that library dot call in this example we're calling a function called run me we're passing it the argument 7 so this is just a super simple example but it's going to be exactly like this for every operating system the only thing that will change is the library that you actually load so a couple notes because you're not using the system loader the libraries that you're dependent on will not automatically be loaded for you so for Windows you have to use the IAT branch as I said but then every library that you depend on you have to call syscall dot mustload dll for that library to make sure that it's already loaded and present for you before you use universal but it'll automatically work it out from there and for Linux I would just recommend that you statically compile the libraries you need to load with universal because you can do that for Linux it doesn't really work for Windows but if you just statically compile the library like that'll just work fine and it's easy all right moving on to our next tool is donut donut is amazing it is a payload creation framework that lets you convert any executable dll dotnet assembly or like vbs to an encrypted injectable shellcode and then it is also the assembly loader that decrypts and loads those payloads into a process it is very configurable definitely check it out one of its cool features is that it supports remote loads so you can actually configure the loader to pull down the rest of the payload from a web server instead of having to bundle it in which is pretty sick and so I ported the utility that converts things to donut payloads to go so that you can use it from an implant or from a C2 and you might be wondering why would you want to do this we'll see an example in a minute turns out to be a surprisingly handy thing to do and because it's pure go you can now do this from any operating system so most people C2s are on Linux not Windows so that comes in handy so a note you could use both universal or donut as a module system for your implant so a note on why you might want to do one or the other so basically donuts you can make run in a process all by themselves universal will try and load a library in your current process there are a few situations that will break universal because there are things that don't like running not on the main thread for example mini cats starts up some calm hosting stuff that doesn't work right if it's not on the main thread so I don't think it's ever going to work right in universal which means but it works fine through donut as we'll see and there's also a go scheduler bug that's linked and so you can often run into problems if you try and load to go run times in the same thread so if you're loading another go program with universal you might be running off with donut instead just to avoid a load as possible it is easier to avoid having two run times in one process and so you can just use donut instead of universal in that situation there's another payload creation framework called scarecrow which is very popular and definitely worth checking out it does some kind of funny stuff it signs its loader using limelighter which I mentioned before even if you don't give it a cert it'll just sign it anyway as a way of reducing EDR signal and it's kind of unique and most badass feature is that it implements it disables the windows event toolkit which a lot of EDRs rely on by unhooking itself in memory from EDR sorry from ETW which is super cool and worth checking out really worth stealing or just use scarecrow a lot of people do so now banana phone I almost put in the core components category it is so cool and so important and so awesome for EDR evasion it is an implementation of hell's gate or direct system calls in go there's a link to the original paper here but basically what that means there are stubs in NTDLL everything in windows is compiled to use that then in turn call system calls but those stubs in NTDLL are commonly hooked or monitored by EDR and so you can just parse NTDLL because it's already loaded in your process I guarantee so you can look at your own process memory look at NTDLL figure out where those direct system calls go set up a call frame yourself and just call them directly and not bother going through NTDLL thus avoiding hooks that's what hell's gate is so banana phone is a completely transparent implementation of hell's gate it's very easy to port existing go code that uses syscall to banana phone because sisto was kind enough to make a version of the make win syscall utility that converts headers to go stubs he made a version of that called make direct win syscall which converts headers to hell's gate to go stubs and it works exactly the same way as syscall so it's just mad easy to convert syscall code over highly recommend doing that it also has a unique improvement over traditional hell's gate found kind of by accident but there's an auto mode will actually detect when your in memory NTDLL has been hooked by EDR and automatically fall back to reloading a fresh copy of NTDLL from disk instead of the hooked version the one on disk will not be hooked and you can parse the one on disk to figure out where to make the direct syscalls to and it works just as well and although this creates theoretically more signal because loading another copy of NTDLL is sketchy in practice this actually works pretty well it works on one of the more popular EDRs without triggering anything so that's kind of neat there's also an implementation of heaven's gate in go called go for heaven and this is another EDR evasion technique where you call a 64 bit code from 32 bit code because nobody is expecting 32 bit code boy and so this is pretty slick and this also has a really great example of 32 bit 386 go assembly in case you need that for some reason this is one of the few examples that works alright so we've gone over a bunch of EDR evasion and nids evasion tools let's go on to post exploitation which is super fun because it's the loot so go Mimi cats basically this combines go donut and banana phone it downloads Mimi cats to memory makes it into a donut payload injects it into itself and it lets you run Mimi cats on systems where you really shouldn't be able to the whole program is 150 lines of code this is the best example of banana phone and go donut there's the go donut bit up top the banana phone bit down bottom I couldn't fit 150 lines in a slide but you can pull it up on a browser I made a quick demo I cross compiled go Mimi cats to windows md64 that's all you have to do to cross compile and go to an SMB share with the name GM EXE I did not garble it and I set up a win 10 edge let it update defenders enabled I'm running from SMB and I got the little like proof strings up and then I just run it and bam Mimi cats runs nothing flags and I can interact with it which is just crazy so that's current Mimi cats current win 10 edge you will get caught by behavioral stuff once you start doing stuff in Mimi cats so you will have to do some other trickery to avoid the behavioral detections there's another utility worth checking out from virus called msflib which makes your implants work with metasploit it has all of the like metasploit url generation magic it also uses banana phone it also has code to run a payload in the current process or inject a payload into a remote process very cool very worth checking out writing a windows service and go can be a little bit of a pain in the ass there's an example link there but captain space hook has made the taskmaster utility that a lot of people use to interact with the windows task scheduler as a method of persistence to avoid having to create a windows service you can just schedule a task to run your thing periodically definitely check that out gscript is a whole other talk there was a defcon 26 talk on it it uses an embedded JavaScript interpreter to make a scripting language for droppers there's like a thousand samples gscript in Oz gscript repo that do things like disable av edr firewalls you can make registry changes you can set up persistence you can do all kinds of things so definitely check out gscript it's a completely other you know hour long talk another tool from CIS though for did dumping this is another thing that impact it does but impact it in python is very slow it takes hours to dump it can do it in minutes definitely check that out if you want to dump ashes from it and the old lasagna tool that steals browser passwords mail passwords all kinds of passwords it's been part of to go go lasagna however it does require a seago which means you need to set up an external C compiler however the only reason it needs seago is because of a dependency on sequel light because the browser password databases are sequel light databases but there is now a pure go implementation of sequel light which I've linked so someone someday will modify go lasagna to no longer require seago and that would be lovely thank you there's a few other post exploitation tools you should check out including a pseudo fisher which is hilarious from audible blink that actually is an ask pass replacement that will log the pseudo password so that's just like a funny thing to do and also our clone is just a utility to loot things from cloud storage so those may come in handy and then we have a couple of complete C2 frameworks entirely implemented in go the heavy hitter in the space is sliver which is an open source alternative to cobalt strike it's coming along it's under active development it's designed to be used by a team so the C2 is multi user multi operator which is pretty awesome it has a huge list of features it has an implant build an obfuscate framework there's so much in there I don't have time to go into definitely check out the wiki on their github for instructions on how to set it up and check out the dev branches because they have a lot of really cool stuff cooking and peer pressure them into doing their own def con talk at some point another C2 framework definitely worth mentioning is Merlin the only downside of Merlin is that a single operator but it has some unique features that are not really in anything else it supports a ton of injection methods but the one that sticks out is it has an implementation in go of q user APC definitely worth checking that out it also has integration with donut and another common loader which is SRDI and it does support many C2 protocols also like sliver but it has quick support which is pretty cool so that's my time thank you very much as a reminder I do host a podcast called hack the planet and there are a few interviews we've done on hack the planet relevant to this talk we have an interview with josh pits which is phenomenal the author of the Ebola and the original backdoor factory and we have another episode entirely on going malware featuring sisto and captain space hook the authors of some of the utilities I mentioned earlier thank you very much by Defcon 29 and I hope I gave you some ideas for writing going malware or even you know improving detections or reversing for going malware thank you