Apresentando o FalconZero v1.0 - um Windows Loader furtivo e direcionado para fornecer cargas úteis de segundo estágio (shellcode) para a máquina host sem ser detectado
Demonstração
Vamos dar uma olhada rápida em uma demonstração do Utilitário de Geração de Implantes FalconZero e, em seguida, iremos aos detalhes técnicos.
Introdução
Desde que concluí meu SLAE, estou completamente encantado com o poder do shellcode. Esse sentimento só aumentou quando ouvi um podcast dos caras maravilhosos do Mandiant Red Team da FireEye, onde eles defendiam o uso de shellcode em compromissos de equipe vermelha por sua flexibilidade e capacidade de evitar AV/EDRs, entre outras coisas.
Foi quando decidi brincar com várias técnicas de injeção de shellcode. Ao longo do caminho, pensei em uma técnica legal e fiz um implante com base nela que poderia fornecer cargas úteis do Estágio 2 para a máquina alvo de maneira furtiva. Mas por que parar por aí? Por que não adicionar alguns recursos legais a ele e criar uma estrutura para ajudar os red teamers a gerar esses implantes da maneira mais rápida e limpa possível?
Esse foi o início do projeto FALCONSTRIKE e FalconZero é a primeira versão de lançamento público Loader/Dropper do projeto FALCONSTRIKE . Ele implementa a abordagem BYOL (Bring Your Own Land) em oposição a LotL (Living off the Land) . Mas não é o seu carregador de shellcode padrão run-off-the-mill (mais sobre isso mais tarde).
Você pode pensar no FalconZero como uma doca de carregamento para malware. Em outras palavras, o FalconZero é comparável a uma arma indetectável que dispara uma bala (carga útil) na máquina host.
Esta é a razão pela qual ele pode não ser classificado como malware per se, mas sim um tipo de facilitador que ajuda o malware a não ser detectado no host.
Mas há muitas ferramentas que já fazem isso. Então, o que torna o FalconZero especial?
Embora existam muitos projetos excelentes existentes, este não foi projetado para substituí-los.
Ele foi projetado para ser único à sua maneira e existem alguns desses recursos que o separam do resto. Então, vamos discuti-los um por um.
Separação da carga útil de estágio final do Carregador
Como os invasores reais costumam fazer, precisamos separar a carga útil em 2 estágios:
Carga útil do estágio 1 - um carregador furtivo e leve - baixa e injeta o shellcode do Beacon em um processo de host benigno.
Carga útil do estágio 2 - Um agente C2 interativo completo - Meterpreter/Beacon etc.
Algumas das maneiras de armazenar o payload do Estágio 2 (shellcode) no payload do Estágio 1 (Dropper) são:
Armazenando shellcode na seção .text do Dropper
Armazenando shellcode na seção .data do Dropper
Armazenando shellcode na seção .rsrc do Dropper etc.
Embora essas técnicas permaneçam bastante populares, manter o shellcode e o Dropper agrupados (mesmo que sejam criptografados) provavelmente não é uma boa ideia do ponto de vista de OPSEC e gerenciamento de riscos.
Por que arriscar combinar todas as funcionalidades em uma única ferramenta?
Imagine se as equipes azuis conseguirem um implante não detonado, não apenas o Dropper será comprometido, mas também a carga útil do Estágio 2, que não pode ser boa. Em vez disso, hospedar a carga útil do Estágio 2 em um servidor é benéfico porque você ainda tem um interruptor de interrupção em suas mãos agora (digamos que você queira interromper a operação. Simplesmente exclua a carga útil do servidor e pronto).
Essa técnica também nos ajuda a evitar alguns AV/EDRs se o implante do Estágio 1 for projetado dessa maneira, pois o Estágio 2 tem mais chances de ser detectado.
Portanto, é uma prática recomendada de uma perspectiva de OPSEC e mitigação de risco separar o Dropper e o shellcode pela rede. Em outras palavras, o Dropper pode se conectar a um servidor remoto onde o shellcode está hospedado desde que algumas condições sejam atendidas, buscá-lo de lá, prepará-lo e injetá-lo em um processo host on-the-fly, que é exatamente o que foi implementado. Lembra BYOL? Espero que faça muito mais sentido agora.
Uso do Github para buscar a carga útil do estágio 2
Sim! Você leu isso corretamente. O Github é usado como área de armazenamento de carga útil. O implante se conecta ao repositório Github apropriado e busca a carga de lá.
Por que tal escolha?
Simplesmente porque o Github é amplamente considerado um site legítimo e o tráfego de rede observado no Github não será sinalizado como malicioso por produtos de segurança e provavelmente nem será bloqueado na maioria das organizações/escritórios, em vez de usar algum servidor da Web de propriedade do invasor que hospeda uma carga útil que poderia ser barulhento como o inferno.
Da última vez que verifiquei, não consegui encontrar nenhuma ferramenta disponível publicamente que utilizasse o Github como a estação de encaixe do shellcode, portanto, essa seria a primeira desse tipo. Espero sinceramente que o Github não me bana da plataforma deles agora:)
Como um ponto de brownie, isso também economizaria tempo e dinheiro preciosos do operador;)
Ofuscação de string sensível
Todas as strings sensíveis neste implante são criptografadas usando o algoritmo XOR com uma chave comumente encontrada em binários. Isso tornaria impossível o trabalho de extrair a string de URL e outras informações do binário usando análise estática.
Sinta-se livre para testá-lo usando FLOSS . Extraia-o, chmod +x e teste usando:
./floss <binary>
Segmentação de implante
Isso é algo de que já falei antes. Em vez de ter um código malicioso que é executado em sistemas arbitrários, o FalconZero vem com um recurso de direcionamento que impede sua execução em ativos não direcionados e garante que a implantação ocorra apenas se o host for o alvo pretendido.
Mas nós, como times vermelhos, por que deveríamos nos preocupar com isso? Isso é por que:
Para evitar a quebra acidental das regras de engajamento. Isso garantirá que o malcode não acabe sendo executado em nenhum host não intencional que esteja fora do escopo.
Para dificultar os esforços das equipes azuis que tentam fazer engenharia reversa do implante em ativos não direcionados e impedir a análise em sandboxes de malware automatizados.
Ok, mas como implementamos isso?
Usando algo conhecido como fator de chave ambiental, que pode ser qualquer identificador específico de rede/host descoberto anteriormente pelo reconhecimento do alvo.
Ao codificar esse valor no implante e compará-lo em tempo de execução, podemos verificar se o host em execução é o destino pretendido ou não.
Um problema que surge dessa abordagem é que seria trivial extrair esse identificador do binário se deixado em formato de texto simples.
Então, por que não fazemos hash? E comparar os hashes em tempo de execução em vez da string original?
O FalconZero usa o nome do host como o fator de chave ambiental, faz hashes usando o algoritmo MD5 e o que mais? Ele até criptografa esse hash usando XOR antes de codificá-lo para impedir todos os tipos de análise estática. Se as verificações falharem, o implante não será executado no host.
Como resultado, a engenharia reversa deste implante não deve ser trivial.
Killdate
Pense nas datas de morte como uma espécie de data de expiração para implantes além da qual o implante simplesmente não será executado. Obviamente, esse é um recurso muito importante, pois você deseja que seus implantes sejam inutilizados após o término do noivado.
Endereço da técnica de injeção de ponto de entrada
Graças a @spotheplanet , o FalconZero utiliza uma técnica de injeção de shellcode que passa despercebida por muitos AV/EDRs, pois não precisamos alocar páginas de memória RWX no processo do host, o que é uma ação muito barulhenta.
Citando de seu blog ,
This is a shellcode injection technique that works as follows:
1. Start a target process into which the shellcode will be injected, in suspended state.
2. Get AddressOfEntryPoint of the target process
3. Write shellcode to AddressOfEntryPoint retrieved in step 2
4. Resume target process
O crédito vai para Mantvydas Baranauskas por descrever esta técnica maravilhosa! Na forma atual, o FalconZero injeta a carga útil em . Claro, isso pode ser modificado para se adequar ao propósito do operador. explorer.exe
Uso
Há muitas coisas difíceis na vida, mas gerar um implante não deveria ser uma delas. Esta é a razão pela qual o script foi criado para tornar sua vida uma brisa. O processo é tão simples quanto: generate_implant.py
First generate your shellcode as a hex string
Upload it on Github and copy the Github raw URL
For testing(MessageBox shellcode): https://raw.githubusercontent.com/slaer … hex_32.txt
git clone https://github.com/slaeryan/FALCONSTRIKE.git
cd FALCONSTRIKE
pip3 install -r requirements.txt
python3 generate_implant.py
Siga as instruções na tela e você encontrará a saída no diretório se tudo correr bem. bin
Varredura AV do implante FalconZero
Atualizações esperadas na próxima versão
Esta é uma versão alfa e, dependendo da resposta, muitas outras atualizações para as funcionalidades existentes serão lançadas em breve.
Alguns deles são:
Integre vários algoritmos de detecção de Sandbox.
Integre o suporte para técnicas de injeção de shellcode mais furtivas.
Integre a ofuscação de função para torná-la mais discreta.
Inclua um componente de rede para retorno de chamada para um C2 quando uma carga útil do Estágio 2 for liberada ou para alterar alvos/cargas úteis e configurar outras opções em tempo real, etc.
Injetar em um processo remoto de onde a atividade de rede não é incomum para buscar o shellcode - melhor OPSEC
Incluir funcionalidade de horas ativas - o carregador se torna ativo durante um período específico do dia, etc.