joana&pedro

joana&pedro

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 Veil-Evasion does.

Dark Lord Obama Project

However, EXOCET is not limited to a single codebase or platforms that are running Python. EXOCET works on ALL supported platforms and architectures that Go supports.

Exocet Overview

EXOCET, is effectively a crypter-type malware dropper that can recycle easily detectable payloads like WannaCry, encrypt them using AES-GCM (Galois/Counter Mode), which is more secure than AES-CBC, and then create a dropper file for a majority of architectures and platforms out there.

Basically...

It ingests dangerous malware that are now detectable by antivirus engines
It then encrypts them and produces it's own Go file
Then that Go file can be cross-compiled to 99% of known architectures
Upon execution, the encrypted payload is written to the disk and immediately executed on the command line
Alternatively, instead of a file-drop, it will execute the reconstitute shellcode in memory using amenzhinsky's go-memexec module github.com/amenzhinsky/go-memexec
A custom shellcode executor is in the works, it takes ordinary C shellcode and after num-transform, it will run it by creating a new process after allocating the correct virtual address space and granting it RWX permissions on Windows

That means 32-bit, and 64-bit architectures, and it works on Linux, Windows, Macs, Unix, Android, iPhone, etc. You take, anything, and I mean ANYTHING, like the 1988 Morris Worm that nearly brought down the internet (which exploited a flaw in the fingerd listener daemon on UNIX), and make it a viable cyberweapon again.

EXOCET is designed to be used with the DSX Program, or the "Cyber Metal Gear" as I envisioned it. Being able to launch and proliferate dangerous malware without a traceable launch trail.

EXOCET is written entirely in Go.

How to use

EXOCET, regardless of which binary you use to run it, requires Golang to work. By default, it generates a crypter .go file.

Windows users: Install Go Here
Linux users: run sudo apt-get update && sudo apt-get install -y golang
You must install the EXOCET source files in golang go get github.com/tanc7/EXOCET-AV-Evasion
Sub-requirements will also be downloaded and installed
For Windows and Mac x64 Users, pre-compiled binaries are in the /bin folder

To run it

go run EXOCET.go detectablemalware.exe outputmalware.go

A key is automatically generated for you. The key is 64-characters long and is entirely composed of bash and cmd.exe shell pipe redirectors to confuse and disrupt brute-forcing attempts against the key by causing unpredictable, destructive behavior on the forensic analyst's device.

For 64-bit Windows Targets...

env GOOS=windows GOARCH=amd64 go build -ldflags "-s -w" -o outputMalware.exe outputmalware.go

And out comes a outputmalware.exe file

For 64-bit MacOS Targets

env GOOS=darwin GOARCH=amd64 go build -ldflags "-s -w" -o outputMalware.macho outputmalware.go

For 64-bit Linux Targets

env GOOS=linux GOARCH=amd64 go build -ldflags "-s -w" -o outputMalware.elf outputmalware.go

See this reference on github for your parameters for other operating systems like Android Reference for Go Cross Compilation

Note that the key can still be found with the strings command, please use the upx-ucl command to pack binary to conceal the key.

Furthermore, there are prebuilt binaries that I have made, meaning you just have to run ./EXOCET or EXOCET-Windows.exe

Legal Information

I, Chang Tan, and the creators of the main module and submodules of Exocet and the packages it incorporates are NOT responsible for the misuse of this tool. This is merely a penetration testing tool. You are strictly prohibited from deploying Exocet output binaries against unauthorized protected systems or unauthorized protected government systems.

I am aware that threat actors of APT41 and the NSO Group have used and/or adopted code from this tool, particularly the go-memexec method. If I were to be approached by Federal Investigators regarding the misuse of this tool, I am not claiming responsibility.

This is the same stuff that happened to the developers of Mimikatz and PowerShell Empire (who deprecated their own development upon realization of its use among threat actors). The successors have picked up development of Empire, and there are free alternatives such as Covenant C2.

EXOCET live demo
<iframe width="560" height="315" src="https://github.com/tanc7/EXOCET-AV-Evasion/blob/master/media/exocetdemo.mp4" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
Reason for the name

On May 4th, 1982, during the Falklands War, a squadron of Argentinan Super Eterdards launched a French made Exocet missile at the HMS Sheffield. Despite the Royal Navy's attempts to stop the missile, one struck, sinking the Sheffield. That incident literally put Argentina on the map as a show of force against a global colonial power.

News Article of the sinking of the HMS Sheffield

Very much like how Onel de Guzman's actions with the ILOVEYOU virus put the Philippines on the map as a cyber threat.

ILOVEYOU Virus on Wikipedia

Incoming update, notes and ambitions

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...

Inline hooking
Obfuscation by emulating BlackRota and the gobfuscate module
Process hollowing
Reflective DLL injection
Remote process injection
ThreadLocalStorage Callbacks
Registration of Top-Level Exception Handlers
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

A court appearance in late October
National Cyber League
Accounting and Finance Classes, Computer Science was NEVER my college major and in the following weeks I will have exams back-to-back
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.
A private project involving interaction with the CoinGeckoAPI
Running the cryptoscopeinitiative.org, a to-be-filed 501c3 Non-Profit Organization
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 https://www.msys2.org/ and follow the guide. Then you must add gcc to your environment variables in Windows

Step 1: Generate shellcode, this could be from msfvenom Meterpreter payloads, Cobalt Strike Beacons, or your own custom shellcode in C compatible format

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

â"Œâ"€â"€(rootðŸ'€kali)-[/opt/EXOCET-AV-Evasion]
â""â"€# 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

Related news

joana&pedro

1. Overview

Is an elf32 static and stripped binary, but the good news is that it was compiled with gcc and it will not have shitty runtimes and libs to fingerprint, just the libc ... and libprhrhead
This binary is writed by Ricardo J Rodrigez

When it's executed, it seems that is computing the flag:

But this process never ends .... let's see what strace say:

There is a thread deadlock, maybe the start point can be looking in IDA the xrefs of 0x403a85
Maybe we can think about an encrypted flag that is not decrypting because of the lock.

This can be solved in two ways:

static: understanding the cryptosystem and programming our own decryptor
dynamic: fixing the the binary and running it (hard: antidebug, futex, rands ...)

At first sight I thought that dynamic approach were quicker, but it turned more complex than the static approach.

2. Static approach

Crawling the xrefs to the futex, it is possible to locate the main:

With libc/libpthread function fingerprinting or a bit of manual work, we have the symbols, here is the main, where 255 threads are created and joined, when the threads end, the xor key is calculated and it calls the print_flag:

The code of the thread is passed to the libc_pthread_create, IDA recognize this area as data but can be selected as code and function.

This is the thread code decompiled, where we can observe two infinite loops for ptrace detection and preload (although is static) this antidebug/antihook are easy to detect at this point.

we have to observe the important thing, is the key random?? well, with the same seed the random sequence will be the same, then the key is "hidden" in the predictability of the random.

If the threads are not executed on the creation order, the key will be wrong because is xored with the th_id which is the identify of current thread.

The print_key function, do the xor between the key and the flag_cyphertext byte by byte.

And here we have the seed and the first bytes of the cypher-text:

With radare we can convert this to a c variable quickly:

And here is the flag cyphertext:

And with some radare magics, we have the c initialized array:

radare, is full featured :)

With a bit of rand() calibration here is the solution ...

The code:
https://github.com/NocONName/CTF_NcN2k15/blob/master/theAnswer/solution.c

3. The Dynamic Approach

First we have to patch the anti-debugs, on beginning of the thread there is two evident anti-debugs (well anti preload hook and anti ptrace debugging) the infinite loop also makes the anti-debug more evident:

There are also a third anti-debug, a bit more silent, if detects a debugger trough the first available descriptor, and here comes the fucking part, don't crash the execution, the execution continues but the seed is modified a bit, then the decryption key will not be ok.

Ok, the seed is incremented by one, this could be a normal program feature, but this is only triggered if the fileno(open("/","r")) > 3 this is a well known anti-debug, that also can be seen from a traced execution.

Ok, just one byte patch, seed+=1 to seed+=0, (add eax, 1 to add eax, 0)

before:

after:

To patch the two infinite loops, just nop the two bytes of each jmp $-0

Ok, but repairing this binary is harder than building a decryptor, we need to fix more things:

The sleep(randInt(1,3)) of the beginning of the thread to execute the threads in the correct order
Modify the pthread_cond_wait to avoid the futex()
We also need to calibrate de rand() to get the key (just patch the sleep and add other rand() before the pthread_create loop

Adding the extra rand() can be done with a patch because from gdb is not possible to make a call rand() in this binary.

With this modifications, the binary will print the key by itself.

Related news

joana&pedro

In this tutorial series I'm going to walk you through the damn vulnerable web application (DVWA) which is damn vulnerable. Its main goal according to the creators is "to aid security professionals to test thier skills and tools in a legal environment, help web developers better understand the process of securing web applications and to aid both students & teachers to learn about web application security in a controlled class room environment."

I am going to install DVWA in docker so the prerequisite for this tutorial will be an installation of docker (Docker is not the only way to install DVWA but if you have docker already installed then it may be the easiest way to install DVWA).

To install DVWA in docker run your docker deamon if it's not running already and open a terminal or powershell and type:

docker rum --rm -it -p 8080:80 vulnerables/web-dvwa

It will take some time to pull the image from docker hub depending on your internet speed and after it is complete it will start the dvwa application. In the command we have mapped the image instance's port 80 to our hosts port 8080 so we should be able to access the web application from our host at http://localhost:8080

Now open your favorite web browser and go to http://localhost:8080
You should be prompted with a login screen like this:

login with these creds:
username: admin
password: password

After login you'll see a database setup page since this is our first run. Click on Create / Reset Database button at the bottom. It will setup database and redirect you to login page. Now login again and you'll see a welcome page.

Now click on DVWA Security link at the bottom of the page navigation and make sure the security level is set to Low. If it is not click on the dropdown, select Low and then click submit.

Now our setup is complete, so lets try a simple SQL attack to get a taste of whats about to come.

Click on SQL Injection in navigation menu.
You'll be presented with a small form which accepts User ID.
Enter a single quote (') in the User ID input field and click Submit.
You'll see an SQL error like this:

From the error message we can determine that the server has a MariaDB database and we can see the point of injection.
Since there are many quotes we are not able to determine the exact location of our injection. Lets add some text after our single quote to see exactly where our injection point is.
Now I am going to enter 'khan in the User ID field and click Submit.

Now we can see exactly where the point of injection is. Determining the point of injection is very important for a successful SQL injection and is sometimes very hard too, though it might not be that much useful here in this exercise.

Now lets try the very basic SQL Injection attack.
In the User ID field enter ' or 1=1-- - and click Submit.

We will explain what is going on here in the next article.

References:-
1. DVWA Official Website: http://www.dvwa.co.uk/