EXOCET – AV-evading, Undetectable, Payload Delivery Tool

Click the icon to Follow me:- twitterTelegramRedditDiscord

EXOCET is superior to Metasploit’s “Evasive Payloads” modules as EXOCET uses AES-256 in GCM Mode (Galois/Counter Mode). Metasploit’s Evasion Payloads uses a easy to detect RC4 encryption. While RC4 can decrypt faster, AES-256 is much more difficult to ascertain the intent of the malware.

However, it is possible to use Metasploit to build a Evasive Payload, and then chain that with EXOCET. So EXOCET will decrypt via AES-256, and then the Metasploit Evasive Payload then decrypts itself from RC4.

Much like my previous project, DarkLordObama, this toolkit is designed to be a delivery/launch vehicle, much like


So this month, and the next month is going to be a busy month for me, and there will be delays in implementing these methods. But I am excited to get started on implementing new AV evasion techniques such as…

  1. Inline hooking
  2. Obfuscation by emulating BlackRota and the gobfuscate module
  3. Process hollowing
  4. Reflective DLL injection
  5. Remote process injection
  6. ThreadLocalStorage Callbacks
  7. Registration of Top-Level Exception Handlers
  8. Custom UPX packing

I am a very busy man, I have the following priorities and I would like to request some help, some pull requests to aid in the project. Since I have the following things to do

  1. A court appearance in late October
  2. National Cyber League
  3. Accounting and Finance Classes, Computer Science was NEVER my college major and in the following weeks I will have exams back-to-back
  4. Federal Supervised Release Conditions and the FBI trying to implicate me in new unproven crimes. I have dash camera videos I uploaded to the cloud to prove it that I am sending to my lawyers. I have documented multiple attacks against me, vandalism of my car, my house, filed police reports and counter reports and will be building my case to file a Federal lawsuit. One of the perpetrators, who ripped out my front bumper of my car, has been arrested.
  5. A private project involving interaction with the CoinGeckoAPI
  6. Running the cryptoscopeinitiative.org, a to-be-filed 501c3 Non-Profit Organization
  7. Teaching three online classes on Exploit Development

Upcoming update! Direct encrypted shellcode execution! (Implemented in test versions, not released yet)

I need a bit of help, because I successfully implemented CGO to execute encrypted shellcode but it is throwing memory access violations exit status 0xc0000005. It shouldn’t be anything related to DEP (Data Execution Prevention) because the file CGOTest/working-template-shellcode-executor.go did run.

Problem Discovered

As it turns out, VirtualAlloc must be called from kernel32.dll and ntdll.dll to properly make the memory page where the shellcode lands, readable, writable, and executable, in other word, set the PAGE_EXECUTE_READWRITE to ON. Read the Note on Memory Access Violation Problem below.

Once I figure this out, CGO was a pain in the ass to implement, we can now create crypters that execute INLINE-ASSEMBLY. Which was considered a impossibility until now.

Note this requires Golang and the MinGW toolchain to be installed on Windows with you running and generating the shellcode on Windows. The reason why, is because CGO cannot be cross-compiled like our other EXOCET modules. To install the toolchain you need to go to


Step 1: Generate shellcode, this could be from msfvenom

Step 2: Copy only the bytes of the shellcode, excluding the quotes into a text file like sc.txt

Step 3: Your shellcode file should look like this. Raw shellcode

Step 4: Now run the command go run exocet-shellcode-exec.go sc.txt shellcodetest.go KEY

Step 5: You can attempt to run it but you’ll run into memory access violation errors for some reason, which I am still working on

Note on Memory Access Violation Problem

Apparently, aside from the major limitations of CGO that prohibit or dramatically frustrates cross-compilation, the issue is that the shellcode we want to execute is landing in a section of memory (analyzed in WinDBG x64) that is not RWX. In other words, unless we write C code that explicitly allows execution in memory of the shellcode, it will always throw access violation errors.

The other method, that I observed other developers of rudimentary Go modules https://gist.github.com/mgeeky/bb0fd5652b234fbd1c7630d7e5c8542d, is that they use Go’s Windows API to interact with ntdll.dll and kernel32.dll to call VirtualAlloc and specify areas of RWX memory pages. This method works better, but it seems that the shellcode must be in num-transformed format only for it to work.

I am still working on this you guys. I may combine multiple programming languages together to write a proper shellcode execution module

Note on Apple M1 Chips for precompiled binaries

Unfortunately I am running into errors for making a pre-compiled binary for MacBooks running the new M1 CPUs. It may be a issue with my Golang installation

└─# GOOS=darwin GOARCH=arm64 go build exocet.go
# command-line-arguments
/usr/lib/go-1.15/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/tmp/go-link-477718799/go.o: file not recognized: file format not recognized
collect2: error: ld returned 1 exit status

Either way, you still require Golang to compile or cross-compile the malware to the platform you are targeting.

Download EXOCET-AV-Evasion

If you like the site, please consider joining the telegram channel or supporting us on Patreon using the button below.


Original Source
Available for Amazon Prime