O Cado Security Labs recebeu recentemente relatórios sobre o ransomware Cerber sendo implantado em servidores que executam o aplicativo Confluence por meio do exploit CVE-2023-22518 . Há uma grande cobertura sobre a variante do Windows, mas há muito pouca sobre a variante do Linux. Neste blog discutiremos uma análise da variante Linux.
Cerber surgiu e estava no auge de sua atividade por volta de 2016, e desde então tem feito apenas campanhas ocasionais, mais recentemente visando a vulnerabilidade do Confluence mencionada acima. Ele consiste em três cargas C++ altamente ofuscadas, compiladas como um formato executável e vinculável de 64 bits (ELF, o formato para arquivos binários executáveis no Linux) e compactadas com UPX. UPX é um compactador muito comum usado por muitos agentes de ameaças. Ele permite que o código real do programa seja armazenado codificado no binário e, em tempo de execução, extraído para a memória e executado (“descompactado”). Isso é feito para evitar que o software verifique a carga e detecte o malware.
Cargas úteis de C++ puro estão se tornando menos comuns no Linux, com muitos agentes de ameaças agora empregando linguagens de programação mais recentes, como Rust ou Go. Isto provavelmente se deve ao fato de a carga útil do Cerber ter sido lançada pela primeira vez há quase 8 anos, o que é significativamente mais antigo do que a maioria das campanhas observadas pelo Cado Security Labs. Embora certamente tenha recebido atualizações, as opções de idioma e ferramentas provavelmente permanecerão durante toda a vida útil da carga útil.
Foram observadas instâncias do ransomware Cerber sendo implantadas depois que um invasor aproveitou o CVE-2023-22518 para obter acesso a instâncias vulneráveis do Confluence. É uma vulnerabilidade de autorização inadequada bastante recente que permite que um invasor redefina o aplicativo Confluence e crie uma nova conta de administrador usando um endpoint de restauração de configuração desprotegido usado pelo assistente de configuração.
[19/Mar/2024:15:57:24 +0000] - http-nio-8090-exec-10 13.40.171.234 POST /json/setup-restore.action?synchronous=true HTTP/1.1 302 81796ms - - python-requests/2.31.0
[19/Mar/2024:15:57:24 +0000] - http-nio-8090-exec-3 13.40.171.234 GET /json/setup-restore-progress.action?taskId= HTTP/1.1 200 108ms 283 - python-requests/2.31.0Depois que uma conta de administrador é criada, ela pode ser usada para obter execução de código, carregando e instalando um módulo malicioso por meio do painel de administração. Neste caso, o plugin Effluence web shell é carregado e instalado diretamente, o que fornece uma UI web para executar comandos arbitrários no host.
O invasor usa esse web shell para baixar e executar o payload primário do Cerber. Em uma instalação padrão, o aplicativo Confluence é executado como o usuário “confluence”, um usuário com poucos privilégios. Como tal, os dados que o ransomware é capaz de criptografar são limitados aos arquivos de propriedade do usuário do Confluence. É claro que ele conseguirá criptografar o armazenamento de dados do aplicativo Confluence, que pode armazenar informações importantes.
Se estivesse executando como um usuário com privilégios mais altos, seria capaz de criptografar mais arquivos, pois tentará criptografar todos os arquivos do sistema.
Resumo do payload
Escrito em C++, altamente ofuscado e embalado com UPX
Serve como um stager para payloads adicionais
Usa um servidor C2 em 45[.]145[.]6[.]112 para baixar e descompactar payloads adicionais
Exclui-se do disco após a execução
O payload primário é compactado com UPX, assim como as outros payloads. Seu principal objetivo é configurar o ambiente e capturar mais payloads para funcionar.
Após a execução, ele se descompacta e tenta criar um arquivo em /var/lock/0init-ld.lo . Especula-se que isso deveria servir como um arquivo de bloqueio e evitar a execução duplicada do ransomware, porém se o arquivo de bloqueio já existir o resultado é descartado e a execução continua normalmente de qualquer maneira.
Em seguida, ele se conecta ao servidor C2 (agora extinto) em 45[.]145[.]6[.]112 e extrai o payload secundário, um verificador de log, conhecido internamente como agttydck. Ele faz isso fazendo uma solicitação GET /agttydcki64 simples para o servidor usando HTTP e gravando o corpo do payload em /tmp/agttydck.bat. Em seguida, ele é executado com /tmp e ck.log passados como argumentos.
Depois que o payload secundário terminar de ser executado, o payload primário verificará se o arquivo de log em /tmp/ck.log que ela gravou existe. Se isso acontecer, ele excluirá a si mesmo e o agttydcki64 do disco. Como ainda está em execução na memória, ele baixa o payload do criptografador, conhecida internamente como agttydcb , e a descarta em /tmp/agttydcb.bat. O packing deste payload é mais complexo.
O comando file reporta-o como um executável DOS e a extensão bat implicaria isso também. No entanto, ele não possui os bytes mágicos corretos e a alta entropia do arquivo sugere que ele está de alguma forma codificado ou criptografado. Na verdade, o payload lê-o e depois grava um arquivo ELF decodificado usando o mesmo fluxo, sobrescrevendo o conteúdo. Não está claro o mecanismo exato usado para decodificar agttydcb . O payload primário então executa o agttydcb decodificado, cujo comportamento é documentado em uma seção posterior.
2283 openat(AT_FDCWD, "/tmp/agttydcb.bat", O_RDWR) = 4
…
2283 read(4, "\353[\254R\333\372\22,\1\251\f\235 'A>\234\33\25E3g\335\0252\344vBg\177\356\321"..., 450560) = 450560
…
2283 lseek(4, 0, SEEK_SET) = 0
2283
write(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0X\334F\0\0\0\0\0"..., 450560) = 450560
…
2283 close(4) Payload de verificação de log - agttydck
Escrito em C++, altamente ofuscado e embalado com UPX
Tenta escrever a frase “sucesso” em um determinado arquivo passado em argumentos
Provavelmente uma verificação de sandbox ou para verificar o nível de permissão do malware no sistema
O payload do verificador de log, agttydck , provavelmente serve como um verificador de permissão. É um payload útil muito simples e fácil de analisar estaticamente, apesar da ofuscação. Como as outros payloads, ele é empacotado em UPX.
Quando executado, ele concatena cada argumento passado a ele e delimita com barras para obter um caminho completo. Neste caso, é passado /tmp e ck.log, que passa a ser /tmp/ck.log. Em seguida, ele tenta abrir este arquivo no modo de gravação e, se tiver sucesso, escreve a palavra “sucesso” e retorna 0. Se não tiver sucesso, retorna 1.
O objetivo desta verificação não é exatamente claro. Pode ser para verificar se o diretório tmp é gravável e pode gravar, o que pode ser uma verificação se o sistema está muito bloqueado para o criptografador funcionar. Dado que a verificação é executada em um processo separado do payload primário, também pode ser uma tentativa de detectar sandboxes que podem não manipular arquivos corretamente, fazendo com que o payload primário não seja informado sobre o arquivo criado pelo filho.
Criptografador - agttydck
Escrito em C++, altamente ofuscado e embalado com UPX
Grava o arquivo de log /tmp/log.0 no início e /tmp/log.1 na conclusão, provavelmente para depuração
Percorre o diretório raiz procurando diretórios que possa criptografar
Escreve uma nota de resgate para cada diretório
Substitui todos os arquivos no diretório por seu conteúdo criptografado e adiciona uma extensão .L0CK3D
O criptografador, agttydcb , atinge o objetivo do ransomware, que é criptografar arquivos no sistema de arquivos. Como as outros payloads, ele é empacotado em UPX e escrito com C++ altamente ofuscado. Ao iniciar, ele se exclui do disco para não deixar nenhum artefato. Em seguida, ele cria um arquivo em /tmp/log.0 , mas sem conteúdo. Como ele cria um segundo arquivo em /tmp/log.1 (também sem conteúdo) após o término da criptografia, é possível que sejam marcadores de depuração que o invasor deixou por engano.
O criptografador então gera um novo thread para fazer a criptografia real. O payload tenta escrever uma nota de resgate em /<directory>/read-me3.txt . Se tiver sucesso, ele percorrerá todos os arquivos do diretório e tentará criptografá-los. Se falhar, ele passa para o próximo diretório. O criptografador escolhe quais diretórios criptografar percorrendo o sistema de arquivos raiz. Por exemplo, ele tentará criptografar /usr e depois /var etc.
Quando identifica um arquivo para criptografar, ele abre um fluxo de leitura e gravação para o arquivo e lê o arquivo inteiro. Em seguida, ele é criptografado na memória antes de procurar o início do fluxo e gravar os dados criptografados, sobrescrevendo o conteúdo do arquivo e tornando o arquivo totalmente criptografado. Em seguida, ele renomeia o arquivo para ter a extensão .L0CK3D . Reescrever o mesmo arquivo em vez de criar um novo arquivo e excluir o antigo é útil no Linux, pois os diretórios podem ser configurados apenas para anexar, evitando a exclusão total dos arquivos. Reescrever o arquivo também pode reescrever os dados no armazenamento subjacente, tornando a recuperação com análise forense avançada também impossível.
2290 openat(AT_FDCWD, "/home/ubuntu/example", O_RDWR) = 6
…
2290 read(6, "file content"..., 3691) = 3691
…
2290 write(6, "\241\253\270'\10\365?\2\300\304\275=\30B\34\230\254\357\317\242\337UD\266\362\\\210\215\245!\255f"..., 3691) = 3691
2290 close(6) = 0
2290 rename("/home/ubuntu/example", "/home/ubuntu/example.L0CK3D") = 0Quando isso terminar, ele tenta se excluir novamente (o que falha porque já foi excluído) e cria /tmp/log.1 . Em seguida, ele sai normalmente. Apesar da nota de resgate alegando que os arquivos foram exfiltrados, os pesquisadores do Cado não observaram nenhum comportamento que demonstrasse isso.
Cerber é um payload de ransomware relativamente sofisticada, embora antiga. Embora o uso da vulnerabilidade do Confluence permita comprometer uma grande quantidade de sistemas prováveis de alto valor, muitas vezes os dados que ela é capaz de criptografar serão limitados apenas aos dados do Confluence e, em sistemas bem configurados, será feito backup deles. Isto limita enormemente a eficácia do ransomware na extração de dinheiro das vítimas, pois há muito menos incentivo para pagar.
IoCs
Os payloads são compactadas com UPX, portanto, corresponderão às regras UPX Yara existentes.
Hashes (sha256)
cerber_primary | 4ed46b98d047f5ed26553c6f4fded7209933ca9632b998d265870e3557a5cdfe |
agttydcb | 1849bc76e4f9f09fc6c88d5de1a7cb304f9bc9d338f5a823b7431694457345bd |
agttydck | ce51278578b1a24c0fc5f8a739265e88f6f8b32632cf31bf7c142571eb22e243 |
IPs
C2 (Extinto) | 45[.]145[.]6[.]112 |
Via - Cado Security
Comments