Um backdoor é um método oculto para aceder a um sistema que contorna a autenticação normal e os controlos de segurança.

Análise Técnica:

Análise Estática Básica:

Primeiro, faça o upload para o VirusTotal para uma análise inicial. Os resultados indicam que o ficheiro é uma DLL de 64 bits, identificada na família de malware Kalim. Além disso, várias deteções sugerem uma potencial associação com o grupo de ameaças MuddyWater.

O malware também estabelece comunicação de rede com o domínio moodleuni[.]com.

Ele deixa cair alguns ficheiros:

Agora abra-o no Die (Detect it easy):

A amostra importa um grande número de APIs do Windows, indicando que não está empacotada. No total, importa funções de seis DLLs: KERNEL32.dll, USER32.dll, ADVAPI32.dll, SHELL32.dll, ole32.dll e WININET.dll.

Embora várias APIs sejam importadas de cada DLL, várias funções são particularmente notáveis devido ao seu papel no comportamento do malware.

Especificamente, a amostra importa APIs relacionadas a networking da WININET.dll para estabelecer comunicação com o servidor de comando e controlo (C2). Também utiliza funções relacionadas com COM da ole32.dll para criar e interagir com objetos COM (Component Object Model). Além disso, o malware usa SHGetFolderPathW da SHELL32.dll para recuperar caminhos de diretório do sistema identificados por valores CSIDL.

Análise Estática Avançada:

No DllMain, a única ação realizada é a criação de uma nova thread. Dentro desta thread, são executadas duas funções: sub_1800063A0 e StartAddress.

Analisando a função sub_1800063A0, descobri que ela consiste em duas fases distintas. Na primeira fase, o malware deixa cair uma cópia de si mesmo no diretório AppData\Roaming. Para isso, cria um novo subdiretório chamado Updates, seguido da criação de um ficheiro executável chamado update.exe. O payload binário escrito neste ficheiro é obtido diretamente dos dados incorporados localizados em unk_18002AA10. Como resultado, o ficheiro final é escrito no seguinte caminho: “C:\Users<Username>\AppData\Roaming\Update\update.exe”.

Na segunda fase, o malware inicializa um objeto COM (Component Object Model) usando RCLSID: {00021401-0000-0000-C000-000000000046}, que corresponde ao Shell Link Object (CLSID_ShellLink) e RIID : {000214F9-0000-0000-C000-000000000046}, que mapeia para a interface IShellLinkW. Ao consultar toda a tabela de interfaces COM do Shell implementada pela shell32.dll, os métodos invocados podem ser identificados com precisão. O malware chama quatro métodos COM principais: SetPath, SetDescription, Save e Release. Usando essas funções, cria um atalho malicioso de inicialização chamado MicrosoftUpdateSerice.lnk dentro do diretório de Inicialização do Windows, estabelecendo assim persistência no sistema infetado.

Analisando a Função StartAddress

O malware implementa a sua lógica de comunicação de rede através de três funções distintas e cria duas threads separadas. Uma thread é responsável por criar e gerir uma shell de comandos, enquanto a segunda thread trata do upload dos dados recolhidos após a conclusão da execução do malware.

As três funções gerem coletivamente a comunicação entre o hospedeiro infetado e o servidor de comando e controlo (C2) e estão organizadas em três camadas lógicas.

A primeira camada é responsável por recolher informações de impressão digital do hospedeiro a partir do sistema comprometido. A segunda camada processa esses dados realizando encriptação e manipulação adicional para os preparar para transmissão. A terceira camada estabelece comunicação de rede com o domínio C2 moodleuni[.]com e transmite os dados processados.

As duas primeiras funções relacionadas com a rede são especificamente responsáveis pela autenticação e construção de pedidos HTTP POST, permitindo a transmissão autenticada de dados para o servidor remoto.

A terceira função é responsável por receber comandos do servidor C2. Com base na resposta do servidor, o malware determina a sua próxima ação—seja criar uma shell de comandos oculta ou fazer upload dos dados recolhidos com base no comando recebido do C2.

Analisando as duas threads para compreender totalmente o que fazem.

Na primeira thread, o malware cria um objeto de job juntamente com dois pipes e define uma certa propriedade para eles.

Em seguida, cria um CMD com algumas propriedades:

O valor 1 no quarto argumento significa que o CMD pode herdar dos handles dos pipes

O valor 0x1000200u no quinto argumento significa que o CMD tem o seguinte:

CREATE_NO_WINDOW = 0x0000000u

CREATE_NEW_PROCESS_GROUP = 0x0000200u

CREATE_UNICODE_ENVIRONMENT = 0x0000400u

E algumas informações de inicialização: {tamanho da estrutura = 104 bytes, hStdError = hWritePipe, hStdOutput = hWritePipe, hStdInput = hReadPipe2, dwFlags |= 0x100u = STARTF_USESTDHANDLES}. O primeiro pipe é responsável por ler a saída da shell e o segundo por escrever na shell.

E um ponteiro para uma PROCESS_INFORMATION

E após criar a shell, ele a associa ao objeto de job e coloca em estado pendente, aguardando comandos do C2.

A shell verifica comandos de controlo enviados via memória partilhada:

Pending: Execução normal.

Terminate: Matar a shell e limpar. Shell completamente destruída e reiniciada

Ctrlc: Força a eliminação de qualquer filho restante.

Em operação normal, se existir um comando, ele escreve o comando no CMD e depois verifica a saída usando PeekNamedPipe, armazenando-a no buffer.

A Segunda thread.

A thread começa por criar um novo ficheiro no caminho especificado. Este ficheiro é usado para armazenar temporariamente os dados antes de serem carregados para o servidor C2. Se o ficheiro não puder ser criado ou ocorrer um erro durante a inicialização, a função define uma string de estado "error" na memória partilhada e sai. O ficheiro é transmitido via HTTPS para o servidor de comando e controlo do malware (moodleuni[.]com) usando cabeçalhos personalizados e identificadores de sessão para imitar tráfego legítimo. Após a conclusão do upload, a função atualiza a memória partilhada para indicar sucesso ou falha:

- "error" se o upload falhar.

- "done" se o upload for bem-sucedido.

Resumo:

O malware backdoor Kalim concentra-se primeiro em estabelecer persistência para garantir presença a longo prazo no sistema da vítima. Consegue isso criando um atalho malicioso dentro do diretório de Inicialização (CSIDL_STARTUP):

C:\Users<User>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Este mecanismo garante que o malware é executado automaticamente sempre que o sistema arranca.

Uma vez estabelecida a persistência, o malware inicia a comunicação com o seu servidor de comando e controlo (C2), moodleuni[.]com. Realiza uma fase inicial de autenticação e recolha de impressão digital do sistema, durante a qual as informações do hospedeiro são recolhidas, processadas e encriptadas. O malware entra então num estado de espera por comandos, consultando continuamente o C2 por instruções.

Com base nos comandos recebidos, o malware pode decidir dinamicamente as suas próximas ações, incluindo criar uma shell de comandos oculta para controlo interativo ou fazer upload dos dados recolhidos de volta ao servidor C2. Este design modular permite tanto a execução remota de comandos como a exfiltração de dados, tornando o Kalim um backdoor flexível e persistente.

Táticas e Técnicas (MITRE ATT&CK):

IOCs:

Regra Yara: