SigFlip

Uso e Exemplos:

Compilar/Build:

BOFs pré-compilados não são fornecidos neste projeto. Podem ser compilados usando Mingw-w64. Para .NET, use VS ou csc.exe para compilar projetos .NET (SigFlip, SigLoader). Para BOF, siga os passos abaixo;

• ➜ i686-w64-mingw32-gcc -c sigflip.c -o sigflip.x86.o
• ➜ x86_64-w64-mingw32-gcc -c sigflip.c -o sigflip.x64.o
• ➜ x86_64-w64-mingw32-gcc -c SigLoader/sigloader.c -o sigloader.x64.o
• ➜ i686-w64-mingw32-gcc -c SigLoader/sigloader.c -o sigloader.x86.o

Certifique-se de que todos os arquivos objeto estejam no mesmo diretório que sigflip.cna, depois carregue o script sigflip.cna no Cobalt Strike.

Nota rápida: os BOFs pré-compilados foram testados e são compatíveis com mingw-64 v8.0.0_3. Usar mingw-64 >= v9 pode funcionar, mas pode travar beacons ativos. Consulte https://github.com/med0x2e/SigFlip/issues/2 para mais detalhes.

Cobalt Strike:

1. Execute-Assembly

   • execute-assembly SigFlip.exe -h
   • execute-assembly SigLoader -h

2. BOF

   • Para uso com Cobalt Strike, depois de carregar o script SigFlip.cna, dois novos comandos serão registrados: SigFlip e SigInject. Use conforme abaixo;

     • SigFlip: Altera o hash de um arquivo PE (DLL, EXE, SYS, OCX, etc.) sem quebrar a assinatura ou a validade do certificado:

       • SigFlip "<CAMINHO_DO_ARQUIVO_PE>" "<CAMINHO_DO_ARQUIVO_PE_DE_SAÍDA (com extensão)>"

     • SigInject: Criptografa e injeta shellcode na tabela de certificados [WIN_CERTIFICATE] de um arquivo PE. A chave de criptografia é exibida para uso com um carregador básico C/C# e mantém a assinatura e validade do certificado intactas:

       • SigInject "<CAMINHO_DO_ARQUIVO_PE> <CAMINHO_DO_ARQUIVO_PE_DE_SAÍDA (com extensão)>" "<ARQUIVO_DE_SHELLCODE>"

     • SigLoader: Carrega shellcode criptografado de arquivos PE criados pelo SigInject, depois usa Early Bird queueuserapc para gerar/injetar sc em um processo sacrificial. A lógica de injeção de shellcode pode ser personalizada ou substituída por qualquer outra técnica de injeção de código de sua escolha:

       • SigLoader <CAMINHO_DO_ARQUIVO_PE_COM_SH> <CHAVE_DE_DESCRIPTOGRAFIA> <CAMINHO_DO_PROCESSO_SPAWNTO> <ID_DO_PROCESSO_PAI>

3. Exemplos

   • BOF:

     • Injetar dados aleatórios no msbuild.exe (ex: bit flip msbuild.exe):
       • SigFlip "C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" "C:\lolbins\modified-msbuild.exe"
     • Injetar shellcode no kernel32.dll (A ordem dos argumentos é diferente e certifique-se de anotar a chave de descriptografia):
       • SigInject "C:\Windows\System32\kernel32.dll" "C:\random\modified-kernel32.dll" "C:\shellcode\cobaltstrike_or_msf_shellcode.bin"
       • Sigloader "C:\random\modified-kernel32.dll" "CHAVE_DE_DESCRIPTOGRAFIA" "C:\Windows\System32\werfault.exe" 6300

   • Execute-Assembly:

     • Injetar dados aleatórios no msbuild.exe:
       • execute-assembly SigFlip.exe -b C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe -o C:\Temp\MSBuild.exe
     • Injetar shellcode no kernel32.dll (A ordem dos argumentos é diferente e certifique-se de anotar a chave de descriptografia):
       • execute-assembly SigFlip.exe -i C:\Windows\System32\kernel32.dll -s C:\Temp\x86shellcode.bin -o C:\Temp\kernel32.dll -e TestSecretKey
       • execute-assembly SigLoader.exe -f C:\Temp\modified-kernel32.dll -e TestSecretKey -pid 2354

Detalhes:

Esta é uma técnica conhecida usada pelo APT#10 em várias campanhas ou conjuntos de intrusão.

Assinaturas Digitais Authenticode?

O Authenticode é uma tecnologia de assinatura de código da Microsoft que identifica o editor de software assinado com Authenticode. O Authenticode também verifica se o software não foi adulterado desde que foi assinado e publicado.

Como funciona?

A Microsoft depende principalmente do formato de assinatura Authenticode para verificar a integridade e a origem de binários PE. De acordo com a especificação do formato PE do Authenticode, as assinaturas Authenticode podem ser "incorporadas" em um arquivo PE do Windows, em um local especificado pela entrada da Tabela de Certificados nos Diretórios de Dados do Cabeçalho Opcional. Quando o Authenticode é usado para assinar um arquivo PE do Windows, o algoritmo que calcula o valor hash Authenticode do arquivo exclui certos campos PE. Ao incorporar a assinatura no arquivo, o processo de assinatura pode modificar esses campos sem afetar o valor hash do arquivo. Esses campos são os seguintes: **o checksum, o RVA da tabela de certificados, o tamanho da tabela de certificados e a tabela de certificados de atributo. A tabela de certificados de atributo contém uma estrutura PKCS #7 SignedData contendo o valor hash do arquivo PE, uma assinatura criada pela chave privada do editor do software e os certificados X.509 v3 que vinculam a chave de assinatura do editor do software a uma entidade legal.

Em termos leigos, podemos modificar ou incorporar dados em campos excluídos do cálculo hash authenticode sem nos preocupar em quebrar a assinatura authenticode e as verificações de integridade do arquivo.

Mais detalhes sobre esses campos excluídos:

• RVA e Tamanho da Tabela de Certificados: A estrutura do cabeçalho opcional de um arquivo PE assinado contém uma matriz de diretórios de dados, incluindo a entrada do diretório de segurança IMAGE_DIRECTORY_ENTRY_SECURITY, que possui dois campos: RVA e Tamanho.

  • RVA: um deslocamento de arquivo (não um deslocamento de memória) para a tabela de certificados de atributo.
  • Tamanho: tamanho da tabela de certificados de atributo.

• Tabela de Certificados de Atributo: uma estrutura de dados WIN_CERTIFICATE que encapsula a assinatura e os certificados e possui os seguintes campos:

  • dwLength: tamanho da tabela de certificados.
  • wRevision: a "revisão" do WIN_CERTIFICATE.
  • wCertificateType: o tipo de dados de certificado encapsulado.
  • bCertificate: os dados reais do certificado. Para WIN_CERT_TYPE_PKCS_SIGNED_DATA, esta é a estrutura PKCS#7 SignedData mencionada acima (que contém o valor hash do PE, a assinatura e o certificado x.509). É exatamente aqui que o SigFlip incorpora dados aleatórios ou shellcode.

Com tudo isso em mente, agora o SifFlip faz o seguinte:

1. Verificar configuração do sistema
2. Carregar arquivo PE e verificar sua assinatura e calcular hash Sha1
3. Obter deslocamento "e_lfanew" (apontando para o IMAGE_NT_HEADERS do cabeçalho do arquivo PE)
4. Obter IMAGE_OPTIONAL_HEADER a partir do IMAGE_NT_HEADERS
5. Obter IMAGE_DATA_DIRECTORY a partir do IMAGE_OPTIONAL_HEADER
6. Obter o campo IMAGE_DIRECTORY_ENTRY_SECURITY e recuperar o RVA e o TAMANHO da Tabela de Certificados de Atributo (WIN_CERTIFICATE).
7. Modificar o blob do arquivo PE preenchendo a Tabela de Certificados com bytes extras (aleatórios/shellcode) de sua escolha.
8. Atualizar o tamanho do diretório de dados IMAGE_DIRECTORY_ENTRY_SECURITY no cabeçalho opcional
9. Atualizar o dwLength do WIN_CERTIFICATE (Tabela de Certificados)
10. Gerar o novo checksum do PE e atualizá-lo (checksum do cabeçalho opcional)
11. Salvar o PE final com o novo tamanho.
12. Verificar a assinatura do arquivo PE modificado

O primeiro passo é essencial para confirmar se o sistema está mal configurado de forma a permitir o preenchimento e a injeção de shellcode em arquivos PE assinados com authenticode. Portanto, as seguintes verificações de sanidade são realizadas:

1. Verificar se a correção MS13-098 não está instalada (KB2893294). Lembre-se de que PODE ESTAR INSTALADA, MAS AS CHAVES DE REGISTRO NÃO ESTÃO DEFINIDAS CORRETAMENTE, O QUE TORNA A CORREÇÃO INÚTIL
2. Verificar chaves de registro

   1. X86:

      • Verificar se a chave de registro "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" não está disponível
        • -> se disponível, verificar se o valor de registro "EnableCertPaddingCheck" não está disponível

   2. X64:

      • Verificar se a chave de registro "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" não está disponível
        • -> se disponível, verificar se o valor de registro "EnableCertPaddingCheck" não está disponível.

Por que não é possível ler os dados injetados quando o PE modificado é carregado como módulo em seu próprio espaço de endereçamento ou no espaço de endereçamento de outros processos?

O carregador do Windows não carrega dados de certificado no espaço de endereçamento do processo. Essa é a razão pela qual você precisa de um carregador personalizado para extrair dados como shellcode e usá-los (ex: SigLoader). Isso também explica por que o RVA da entrada do diretório de dados IMAGE_DIRECTORY_ENTRY_SECURITY é um deslocamento de arquivo em vez de um deslocamento de memória típico.

Detectar/Prevenir:

• https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2014/2915720?redirectedfrom=MSDN
• Uma vez que a correção esteja instalada e as chaves de registro apropriadas estejam definidas, nenhuma reinicialização do sistema é necessária. Você só precisa reiniciar os Serviços Criptográficos. O serviço Applocker também será reiniciado, pois depende dos serviços criptográficos.(@p0w3rsh3ll)
• Regra Yara por Adrien; https://twitter.com/Int2e_/status/1330975808941330432

Referências

• https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2013/ms13-098?redirectedfrom=MSDN
• https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2014/2915720?redirectedfrom=MSDN
• http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/authenticode_pe.docx
• https://msrc-blog.microsoft.com/2013/12/10/ms13-098-update-to-enhance-the-security-of-authenticode/
• https://www.specterops.io/assets/resources/SpecterOps_Subverting_Trust_in_Windows.pdf
• https://p0w3rsh3ll.wordpress.com/2014/05/24/testing-ms13-098-certificate-padding-check/
• http://jsac.jpcert.or.jp/archive/2021/pdf/JSAC2021_202_niwa-yanagishita_en.pdf