Recentemente, os especialistas do PT ESC descobriram um documento no formato do Publisher chamado “Invitation Invitation 29-30-30 2018.pub” (1edd5b6a02ec82cec381c1a1ec74a67e). Neste artigo, mostraremos como um documento de aparência comum se transforma em um Trojan, permitindo que um invasor capture uma imagem de webcams, grave som por comando ou quando uma janela do Skype for detectada, execute scripts do PowerShell, faça capturas de tela, copie arquivos de dispositivos de mídia.
Portanto, quando você abre o documento, uma janela é exibida com um stub de documento borrado e uma solicitação para incluir o script do Microsoft Publisher.
Depois que o usuário o ativa, o script incorporado no documento é executado em JavaScript. É assim:
O resultado do script será a decodificação de dois arquivos, PDF e EXE, do Base64. Ambos os arquivos serão gravados em C: \ Usuários \ {Nome de usuário} \ AppData \ Roaming \ DBFUpdate. Assim, os dois arquivos serão executados e o usuário verá um esboço na tela do documento:
Treasure Hunter RAT
Os invasores usam um RAT com vários módulos com um grande conjunto de funções que fornece acesso total à máquina infectada.
Recursos de código:
- Inteiramente escrito em C ++ com um grande número de construções STL usadas internamente.
- Aplicação da biblioteca de reforço, em particular JSON e Archive.
- Funções de depuração (mais na seção stager).
Trojan principal
O cavalo de Troia principal é fixado na máquina da vítima e é uma plataforma na qual os módulos maliciosos são carregados do C2.
Primeiro, o stager inicializa o diretório de trabalho, que posteriormente armazenará as informações coletadas pelos módulos, utilitários necessários para o funcionamento dos módulos etc.
Abaixo está a inicialização dos caminhos para criar o diretório de trabalho:
Após a criação dos diretórios necessários, o principal Trojan coleta informações sobre a máquina infectada e as envia ao servidor de controle.
Troyan está interessado em tais dados:
- identificador da versão do sistema operacional no qual o principal Trojan está sendo executado;
- O idioma da interface padrão
- O número da versão principal do SO do Service Pack;
- nome do computador e identificador da máquina (para obter detalhes sobre como obter um identificador da máquina, consulte a seção sobre o protocolo de rede).
É assim que as informações sobre a máquina infectada são coletadas:
Em seguida, o principal Trojan é corrigido na máquina infectada através da modificação do valor no registro em HKCU \ Environment \ UserInitMprLogonScript. Este é o nome do arquivo executável que foi alocado durante a inicialização do diretório de trabalho; nesse caso, é igual a “DCTHOST.exe”. Esse método é
descrito no blog Hexacorn e também foi usado pelo APT28 e pelo grupo Cobalt em seu ComDLLDroper.
E a última etapa na inicialização do Trojan principal é copiar o arquivo executável do local atual para o diretório ativo com o mesmo nome que foi selecionado quando o diretório ativo foi inicializado.
Depois que o trojan principal é inicializado, é realizada a preparação para o recebimento de comandos. O módulo Core é adicionado à lista de módulos em execução, que é o principal cavalo de Troia. Em seguida, um comando é iniciado a partir do módulo Core com o identificador 0. Não há implementação desse comando no módulo principal; em vez disso, é apenas um stub. O construtor do objeto do módulo Core é apresentado abaixo.
No final, dois threads iniciam. Um dos threads inicia um timer, que é ativado por padrão a cada segundo e tenta solicitar um comando do C2.
O segundo fluxo carrega bibliotecas adicionais e módulos padrão. Bibliotecas, como módulos, têm um identificador, mas, diferentemente dos módulos, os identificadores de biblioteca são negativos, começam em -1, crescem em direção a números mais baixos. Abaixo está uma lista de bibliotecas baixadas do C2.
Recursos de depuração do principal Trojan
No início de seu trabalho, imediatamente após a inicialização, o cavalo de Troia principal define um manipulador de exceções através do SetUnhandledExceptionFilter, que contém funcionalidades interessantes. Quando ocorrem exceções, elas caem no manipulador, que grava o minidump do aplicativo, além de salvar informações sobre a exceção. Então ele se reinicia. Na tela - criando um minidump:
Protocolo de rede
A troca entre software e C2 ocorre usando um protocolo binário auto-escrito. Cada mensagem é descrita usando o BinPackage (nome retirado do RTTI). Cada BinPackage é essencialmente um invólucro sobre std :: vector, que armazena o conjunto PackageRecord (o nome é inventado). PackageRecord é a unidade mínima para armazenar dados.
struct PackageRecord { _DWORD dataId; _DWORD datatype; _DWORD szData; char[] data; };
Mais sobre os campos dessa estrutura:
- dataId - indica o tipo de registro. A entrada é um identificador de módulo, identificador de comando ou carga útil.
- szData - o tamanho dos dados armazenados no registro.
- tipo de dados é um tipo de dados.
No total, foi registrado o uso de três tipos de dados:
- Um valor "0" significa que os dados armazenados no registro devem ser interpretados como um DWORD.
- O valor "1" - os dados armazenados no registro devem ser interpretados como uma sequência ASCIIZ.
- O valor "2" - os dados armazenados no registro devem ser interpretados como dados criptografados / buffer bruto.
Ao enviar o BinPackage para o servidor de controle, o identificador da máquina é adicionado a ele. O identificador é o GUID da seção da qual todos os caracteres especiais são cortados. Na figura - obtendo o identificador da máquina:
Antes do envio, todos os registros armazenados no BinPackage são coletados seqüencialmente em um único buffer e são criptografados. Para criptografia, a biblioteca
WinAES é
usada , especificamente AES-128-CBC.
Usando o Windows CryptoAPI, duas matrizes pseudo-aleatórias de 16 bytes são geradas. Um para IV, outro para a chave. A criptografia é realizada e os dados criptografados são adicionados novamente ao BinPackage, que contém o pacote criptografado e consiste em três entradas:
- registro com o ID 0x777 - contém a chave usada para criptografia;
- registro com o ID 0x555 - contém o IV usado para criptografia;
- registro com ID 0x999 - contém dados criptografados (em geral, um registro com esse ID indica uma carga útil e é usado não apenas para armazenar dados criptografados).
Após o final do processo de criptografia, o BinPackage gerado é novamente coletado em um único buffer e enviado via solicitação HTTP POST ao servidor de gerenciamento 151.80.237.222.
Abaixo está um exemplo de um pacote contendo informações da máquina:
E este é um exemplo de um pacote criptografado com informações do sistema:
Módulos
Cada módulo, com exceção do Core, é carregado no servidor de controle. Todos os módulos podem ser divididos em duas categorias - módulos carregados automaticamente e módulos carregados mediante solicitação do servidor de controle.
Um exemplo de um pacote solicitando um módulo:
Resposta à solicitação do módulo:
Cada módulo possui uma interface simples composta por três funções: chamada ao carregar o módulo Init, chamada após a conclusão do fini e uma função que altera a configuração do módulo. Cada módulo também possui uma exportação denominada GetModule, que cria um objeto que representa esse módulo e o retorna ao cavalo de Troia principal. Todos os módulos que descobrimos são lançados na memória usando carregamento reflexivo.
Além disso, os nomes dos módulos são fornecidos na forma em que estão presentes no RTTI como nomes de classe.
Módulo CCore
Este módulo representa a funcionalidade básica e é construído diretamente no cavalo de Troia principal. Seu construtor pode ser visto na tabela abaixo:
| ID do módulo | ID da equipe | Descrição do produto |
|---|
| 0 0 | 0 0 | Basicamente, um trojan em vez de um comando é um esboço, e seu objetivo exato não pôde ser estabelecido |
| 1 | Modificar a configuração do módulo |
| 2 | Solicitar informações do computador |
| 3 | Faça o download do utilitário no servidor de controle |
| 4 | Solicitar a listagem de um diretório contendo utilitários |
| 5 | Faça o download do módulo e execute-o |
Módulo CShell
Este módulo fornece um shell remoto para uma máquina infectada. Quando o módulo é inicializado, é criado o processo cmd.exe, ao qual estão conectados dois pipes: um para entrada padrão e outro para saída padrão, através do qual os comandos são recebidos e transmitidos do servidor de controle e vice-versa. Também neste momento, um encadeamento é iniciado, que pega automaticamente toda a saída e a envia ao servidor de controle. A figura mostra a inicialização do módulo CShell.
| ID do módulo | ID da equipe | Descrição do produto |
|---|
| 2 | 0 0 | Enviar comando para shell |
| 1 | Imprima o arquivo. Um arquivo é lido, o caminho para o qual é transmitido do servidor de controle e o conteúdo desse arquivo é carregado no servidor de controle |
| 2 | Obtenha uma lista de todos os discos existentes no sistema. Os dados são enviados para o servidor de controle no formato JSON |
| 3 | Faça o download do arquivo no servidor de controle. O caminho onde salvar o arquivo e os dados são recebidos do servidor de controle |
Módulo CFileSystemBrowser
Este é um módulo passivo, que, mediante solicitação, permite que você receba informações sobre a estrutura do sistema de arquivos. É assim que ocorre a inicialização do módulo CFileSystemBrowser:
| ID do módulo | ID da equipe | Descrição do produto |
|---|
| 3 | 0 0 | Obtenha uma lista de todos os discos existentes no sistema. Os dados são enviados para C2 no formato JSON |
| 1 | Obter lista de diretórios. A listagem é gerada no formato JSON |
| 2 | Imprima o arquivo. Um arquivo é lido, o caminho para o qual é transferido do C2 e o conteúdo desse arquivo é carregado para o C2 |
| 3 | Excluir arquivo O caminho para o arquivo é transferido do C2 |
Módulo CScreenShot
Este módulo permite tirar capturas de tela ou capturar imagens de uma webcam. Isso pode ser feito a pedido e com um período específico no temporizador.
| ID do módulo | ID da equipe | Descrição do produto |
|---|
| 4 | 0 0 | Tire uma captura de tela e envie para o servidor de controle |
| 1 | Execute um cronômetro, após o qual uma captura de tela é tirada da tela da máquina. As capturas de tela resultantes são empacotadas no BinPackage e salvas na pasta logs. Os nomes dos arquivos são gerados usando a API GetTempFileName com o prefixo "MS_". |
| 2 | Obtenha vídeos de dispositivos disponíveis em uma máquina infectada |
| 3 | Capture um quadro da webcam e envie-o para o servidor de controle |
Módulo CSender
Este módulo não está ativado inicialmente. Ele carrega o conteúdo da pasta de logs no servidor de controle. É ativado quando chega uma solicitação para alterar a configuração, que contém o período de verificação.
Módulo CKeylogger
Este módulo também não está ativado inicialmente. É ativado quando chega uma solicitação de alteração na configuração que contém o tamanho do buffer no qual o log está armazenado. A interceptação de entrada é realizada através da entrada
bruta . Além disso, o keylogger monitora a janela na qual o usuário faz uma entrada e registra seu título.
Módulo CDictaphone
Este módulo grava o som por comando ou mediante a detecção de uma janela do Skype. Quando iniciado, ele inicia um encadeamento que lista todas as janelas e suas janelas filho no sistema e procura a janela entre as classes cujo nome de classe é TLiveConversation ou TCallMonitorControl. Se uma janela desse tipo foi encontrada, a gravação inicia. Abaixo está a inicialização do módulo CDictaphone:
E janela de pesquisa do Skype
A gravação é feita através do MCI enviando comandos especiais. É assim que o ciclo de gravação do módulo CDictaphone se parece:
Após fechar a janela ou receber um comando para concluir a gravação, os dados recebidos são salvos em uma pasta temporária e, em seguida, codificados pelo codificador MP3 coxo (é considerado um utilitário e já deve estar carregado, não foi possível obtê-lo no servidor de controle). O arquivo codificado é salvo na pasta logs. Gerar um nome de pasta é semelhante a gerar nomes para capturas de tela.
| ID do módulo | ID da equipe | Descrição do produto |
|---|
| 7 | 0 0 | Comece a gravar e termine após 15 minutos |
| 1 | Parar a gravação |
| 2 | Verificar status: está gravando em andamento |
Módulo CProcessesManager
Este é um módulo passivo, capaz de retornar uma lista de processos mediante solicitação ou finalização pelo PID passado a ele.
| ID do módulo | ID da equipe | Descrição do produto |
|---|
| 8 | 0 0 | Retorna uma lista de processos: seus nomes, PID e o nome do usuário que possui o processo. |
| 1 | Conclusão do processo PID |
Módulo CDownloader
O módulo foi projetado para fazer upload de arquivos grandes no servidor de controle. Realiza a transmissão de dados por partes, cujo tamanho é estabelecido por sua configuração. O módulo lê dados de um arquivo, o caminho para o qual recebe do servidor de controle e empacota pedaços no BinPackage. Para cada BinPackage que contém o pedaço, uma entrada com o identificador 0x888 é adicionada, incluindo o caminho para o arquivo. Depois de passar cada pedaço, o sono é realizado por 5 segundos.
| ID do módulo | ID da equipe | Descrição do produto |
|---|
| 9 | 0 0 | Stub, falha ao definir o valor exato |
| 1 | Realiza a transferência de uma grande quantidade de dados (0x500000 bytes), após o que mede o tempo gasto na transferência e envia esse valor para C2 |
| 2 | Baixar um arquivo de uma máquina |
Módulo CPS
Este módulo permite executar scripts do PowerShell.
| ID do módulo | ID da equipe | Descrição do produto |
|---|
| 10 | 0 0 | Recebe um script do PowerShell do C2 e o executa |
Módulo CDeviceMonitor
Um módulo passivo que monitora os dispositivos de mídia conectados e copia os arquivos deles. Ele usa mensagens de transmissão WM_DEVICECHANGE para detectar a conectividade do dispositivo. Após conectar o dispositivo ao servidor de controle, são enviadas informações sobre quando o dispositivo foi conectado, seu rótulo de volume e o caminho para o dispositivo. O código usado para obter o caminho para o dispositivo é muito semelhante a isso. Todos os arquivos são copiados para a pasta logs. Os nomes são gerados da mesma maneira que para capturas de tela. O arquivo fsIndex.dat é criado separadamente, no qual o dicionário serializado com boost :: archive está localizado. Este dicionário armazena os caminhos originais para os arquivos que foram copiados e seus hashes MD5. Abaixo está o recebimento do DevicePath:
Como epílogo, várias recomendações:
- Não é necessário abrir anexos em cartas de destinatários desconhecidos, muito menos incluir um script do Microsoft Publisher.
- Não é menos perigoso clicar nos links nas cartas de remetentes desconhecidos. O site para onde você vai pode hospedar malware que será baixado automaticamente para o seu PC.
- Você deve atualizar regularmente o software, especialmente o Microsoft Windows e o Microsoft Office, que fecharão o acesso a uma ampla variedade de malware.