Outlaw Linux Malware: persistente, pouco sofisticado e surpreendentemente eficaz

Prefácio

OUTLAW é um pacote de mineração de moedas autopropagante, persistente, porém pouco sofisticado, observado em várias versões nos últimos anos [1], [2], [3], [4]. Apesar da falta de técnicas avançadas de evasão e furtividade, ele permanece ativo e eficaz ao alavancar táticas simples, mas impactantes, como força bruta SSH, persistência baseada em chave SSH e cron, além de mineradores de commodities e canais IRC modificados manualmente. Essa persistência destaca como os operadores de botnets podem alcançar amplo impacto sem depender de técnicas sofisticadas.

Para obter insights mais profundos sobre o comportamento e os padrões operacionais do OUTLAW, implantamos um honeypot projetado para atrair e observar os invasores em ação. Ao criar cuidadosamente um ambiente que imitava um sistema vulnerável, conseguimos atrair os adversários para interagir com nosso servidor. Essa interação revelou ações automatizadas e manuais, com operadores inserindo comandos diretamente, fazendo modificações em tempo real e até mesmo digitando comandos incorretamente — indicadores claros de envolvimento humano. Um GIF capturado mostra esses momentos, proporcionando um raro vislumbre do processo de tomada de decisão em tempo real.

Ao analisar o OUTLAW, obtemos novos insights sobre as ferramentas usadas por seus operadores e suas estratégias em evolução ao longo do tempo. Este malware apresenta uma oportunidade valiosa para aplicar princípios de engenharia de detecção, já que sua cadeia de ataque abrange quase toda a estrutura do MITRE ATT&CK. Examinar seu processo de infecção nos permite desenvolver estratégias de detecção eficazes que capitalizam seus comportamentos previsíveis e repetitivos.

Este relatório fornece uma análise completa da cadeia de ataque, incluindo regras detalhadas de detecção e consultas de busca. Ao analisar os componentes do OUTLAW, demonstramos como até mesmo malware rudimentar pode manter a longevidade em ambientes modernos e como os defensores podem aproveitar sua simplicidade para melhorar a detecção e a resposta.

Principais conclusões

Persistente, mas pouco sofisticado: o OUTLAW permanece ativo apesar de usar técnicas básicas como força bruta SSH, manipulação de chaves SSH e persistência baseada em cron.
Ferramentas de commodities: o malware implanta mineradores XMRig modificados, utiliza IRC para C2 e inclui scripts disponíveis publicamente para persistência e evasão de defesa.
Ampla superfície de ataque: a cadeia de infecção do OUTLAW abrange quase toda a estrutura do MITRE ATT&CK, oferecendo muitas oportunidades de detecção e caça.
Propagação semelhante a um worm: o OUTLAW usa seus hosts comprometidos para lançar mais ataques de força bruta SSH em suas sub-redes locais, expandindo rapidamente a botnet.

Visão geral do OUTLAW

O OUTLAW segue um processo de infecção de vários estágios que começa com o download e a execução de sua carga útil, estabelecendo persistência e expandindo sua botnet por meio de ataques de força bruta SSH. A cadeia de execução é exibida abaixo:

1. Infecção inicial e implantação

O ataque começa quando tddwrt7s.sh baixa o pacote dota3.tar.gz de um servidor C2.
O script initall.sh extraído é executado, iniciando a cadeia de infecção.

2. Ganhar controle e persistência

O malware garante o domínio eliminando os invasores de força bruta e mineradores concorrentes.
Em seguida, ele implanta:
- XMRIG modificado para mineração de criptomoedas (conexão a um pool de mineração).
- STEALTH SHELLBOT para controle remoto via IRC C2.
- BLITZ para executar ataques de força bruta SSH.

3. Propagação e Expansão

O módulo de força bruta recupera listas de alvos de um servidor SSH C2 e tenta ataques de força bruta SSH em novas máquinas.
Sistemas comprometidos com sucesso são infectados, repetindo o ciclo.

Esse ciclo de infecção automatizado permite que o OUTLAW permaneça ativo e lucrativo com o mínimo de esforço dos invasores. Vamos analisar mais profundamente toda a cadeia de ataque.

Cadeia de execução OUTLAW

OUTLAW abrange efetivamente uma ampla gama de táticas e técnicas na estrutura MITRE ATT&CK. Esta seção mapeia seu comportamento para fornecer uma visão geral de sua cadeia de infecção e métodos.

Acesso inicial: blitz

O OUTLAW obtém acesso inicial por meio de força bruta SSH oportunista, visando sistemas com credenciais fracas ou padrão. O malware utiliza seu componente blitz , também conhecido por outros nomes como kthreadadd, para executar varreduras de alto volume e tentativas de adivinhação de senhas. Ele aproveita listas de IPs de destino e credenciais recuperadas de seus servidores C2.

O OUTLAW também age como um worm, instalando-se automaticamente em todos os sistemas que ele compromete com sucesso. Esse mecanismo de autopropagação permite que ele se espalhe rapidamente pelas redes, transformando cada dispositivo recém-infectado em outro nó para novas tentativas de força bruta e infecção.

Analisaremos mais detalhadamente como o OUTLAW realiza esses ataques e se propaga mais adiante no artigo.

Execução: tddwrt7s.sh

As primeiras infecções do OUTLAW parecem se originar de um script dropper simples: tddwrt7s.sh. Este script de shell verifica se há uma instalação existente. Se o malware já estiver presente e descompactado, ele executará o script initall, iniciando a cadeia de infecção. Caso contrário, ele tentará baixar o pacote de uma lista de servidores de preparação fornecidos. Para fins de ilustração, um trecho resumido do conta-gotas é mostrado abaixo:

O pacote dota3.tar.gz extraído extrai seu conteúdo em uma pasta oculta chamada .rsync e contém as seguintes entradas:

 ├── a
 │   ├── a
 │   ├── init0
 │   ├── kswapd0
 │   ├── kswapd01
 │   ├── run
 │   ├── socat
 │   └── stop
 ├── b
 │   ├── a
 │   ├── run
 │   └── stop
 ├── c
 │   ├── blitz
 │   ├── blitz32
 │   ├── blitz64
 │   ├── go
 │   ├── run
 │   ├── start
 │   ├── stop
 │   └── v
 ├── init
 ├── init2
 └── initall

Vamos desconstruir as cadeias de execução uma por uma.

Script de inicialização principal: initall

Os três scripts init controlam o fluxo geral de execução e a implantação do malware. Começando com o script initall , o inicializador principal determina qual caminho de execução seguir. Ele verifica o ambiente do sistema e decide se deve usar init ou init2 com base nas permissões de arquivo e diretórios disponíveis.

Todos esses scripts init usam ofuscação de concatenação de strings baseada em variáveis, onde os comandos são divididos em pequenos fragmentos de variáveis que são concatenados e executados dinamicamente, dificultando a análise estática. Por exemplo, o script initall se parece com isto:

Entretanto, alterando o eval para um echo, podemos obter a saída sem nenhum esforço:

Este script executará, por padrão, consistentemente init. Este é o caminho de execução principal que instala o malware no diretório oculto ~/.configrc6. O caminho de execução de fallback é init2, que é usado quando ~/.configrc6 está inacessível. A principal diferença é que esse caminho mantém todos os componentes no diretório de trabalho atual. Aplicando o mesmo princípio de desofuscação que fizemos anteriormente, terminamos com os dois scripts a seguir:

O primeiro script (init) oculta seus componentes no diretório oculto ~/.configrc6, enquanto o segundo script (init2) é executado diretamente do diretório de trabalho. Apesar dessa diferença, o fluxo de execução permanece o mesmo, iniciando o binário chamado a nos diretórios a/ e b/ como processos em segundo plano e estabelecendo persistência. Em ambos os scripts, o malware instala tarefas cron que executam seus binários em intervalos regulares e em reinicializações do sistema:

5 6 * * 0   ~/.configrc6/a/upd
@reboot     ~/.configrc6/a/upd
5 8 * * 0   ~/.configrc6/b/sync
@reboot     ~/.configrc6/b/sync
0 0 */3 * * ~/.configrc6/c/aptitude

Embora os scripts executem o binário a nos diretórios a/ e b/ quase simultaneamente, seguiremos primeiro o fluxo de execução do diretório a/ .

Execução de subrotina de um diretório: XMRIG

O primeiro script executado é a, que remove quaisquer tarefas cron existentes usando crontab -r e então armazena o diretório de trabalho atual em uma variável. Em seguida, ele cria um script de shell chamado upd que verifica se um processo (armazenado em bash.pid) ainda está em execução. Se o processo não estiver em execução, ele será executado ./run como um processo em segundo plano, garantindo que o malware seja reiniciado continuamente se for encerrado.

Além disso, vemos alguns comandos comentados, indicando que outras versões deste malware podem existir com nomes como rsync, go, kswapd0, blitz, e redtail.

Mais abaixo no script, é criada uma função que verifica se /sys/module/msr/parameters/allow_writes existe e a define como "on" para habilitar a gravação em Registros Específicos do Modelo (MSRs). Se o arquivo não existir, ele habilita gravações MSR por meio do comando modprobe msr allow_writes=on .

Em seguida, a função identifica a CPU ativa marcando /proc/cpuinfo e aplica valores específicos do registro MSR para otimizar o desempenho.

Por fim, a função otimiza o uso da memória habilitando hugepages para todos os núcleos da CPU, aumentando a eficiência do acesso à memória. Ele calcula o número de hugepages necessários com base nos processadores disponíveis (nproc) e os define nos diretórios /sys/devices/system/node/node*/hugepages/ .

A função optimize_func() não foi criada pelo agente da ameaça. O agente da ameaça usou um script de código aberto do repositório XMRig , especificamente o script randomx_boost.sh , para auxiliar na cadeia de infecção.

Dependendo dos privilégios do usuário, ele executará toda a função de otimização ou tentará definir o número de hugepages a sysctl:

Todas as etapas realizadas nesta cadeia mostram sinais aparentes de otimização do sistema de mineração de criptomoedas. Por fim, o script concede permissões de execução ao arquivo upd e permissões "777" a todos os arquivos em sua pasta e executa upd.

Como vimos anteriormente na cadeia, o arquivo upd verifica se o processo armazenado em bash.pid ainda está em execução e, caso não esteja, ele executará o script run :

O script de execução iniciará o script stop , que é um script típico que derruba as defesas de qualquer configuração de minerador conhecida e mata qualquer processo de minerador conhecido com base no nome/ID do processo ou tráfego de rede. Uma versão resumida deste script é ilustrada abaixo:

Curiosamente, um segundo script de eliminação de processos chamado init0 está presente, que é um script de código aberto para eliminar mineradores de criptomoedas em um ambiente Linux. Este script não está sendo executado, pois o fluxo de execução deste script foi comentado no script a .

Após o script stop ter sido executado com sucesso, o script run inicia os binários kswapd01 e kswapd0 em segundo plano via nohup.

kswapd01

O binário kswap01 desempenha um papel fundamental em garantir a comunicação persistente dentro da infraestrutura do malware. Sua principal tarefa é monitorar e manter um processo socat contínuo, essencial para a comunicação com os servidores C2 do invasor.

Quando executado, kswap01 verifica se há algum processo socat existente em execução na máquina infectada. Se nenhuma conexão ativa for encontrada, ele prossegue eliminando todos os processos socat em execução e selecionando um endereço IP alternativo de uma lista predefinida. O binário então estabelece uma nova conexão iniciando um novo processo socat para escutar na máquina local e encaminhar o tráfego para um servidor remoto, normalmente na porta 4444. Isso garante que o malware mantenha o controle sobre o sistema infectado e possa continuar recebendo comandos do invasor.

No entanto, é importante observar que nem todas as versões do pacote de malware OUTLAW observadas incluem o binário socat . Nesses casos, a funcionalidade fornecida por socat é replicada por outros meios ou simplesmente omitida, dependendo de métodos alternativos para manter a persistência e a comunicação.

Ao executar essas verificações e modificações, kswap01 ajuda a manter a persistência da conexão C2, dificultando que os defensores interrompam o canal de comunicação entre o invasor e o sistema comprometido.

kswapd0

O arquivo chamado kswapd0 é uma cópia modificada maliciosamente do legítimo minerador de criptomoedas XMRig (especificamente versão 6.22.1).

Duas modificações principais definem o comportamento do malware:

1. Comandos do shell de inicialização

O malware remove e recria a pasta ~/.ssh da vítima, injeta uma chave pública SSH controlada pelo invasor e reaplica permissões restritivas (chattr +ia) para impedir modificações. Isso concede acesso SSH persistente.
Ele também remove ou bloqueia arquivos de configuração XMRig existentes (por exemplo, ~/.xmrig.json, ~/.config/xmrig.json) para garantir que as configurações do minerador incorporado do invasor permaneçam intactas.

2. Configuração do Minerador Incorporado

O binário é compilado com uma configuração de mineração interna, permitindo que o XMRIG seja executado sem um arquivo de configuração externo.
O tráfego de mineração é roteado para vários pools Monero por meio de portas de texto simples (:80, :4444), SSL (:442) e, ocasionalmente, endereços TOR. Observe que a porta 442 aqui não é um erro de digitação.
A configuração otimiza o desempenho por:
- Executando o minerador em segundo plano
- Habilitando páginas grandes para RandomX
- Definir o nível de doação para zero
- Maximizando o uso do thread da CPU

Ao bloquear administradores, impedir alterações de configuração e injetar uma chave SSH controlada pelo invasor, kswapd0 atua como um mecanismo de persistência furtivo, permitindo mineração contínua de Monero e acesso remoto não autorizado, tudo isso enquanto se disfarça como um processo legítimo do sistema.

Execução de subrotina do diretório b/: STEALTH SHELLBOT

Conforme descrito anteriormente, o binário a no diretório b/ também foi executado por meio dos scripts init .

Este script inicia outro script stop com o mesmo propósito que descrevemos anteriormente: eliminar quaisquer processos ruins conhecidos. Depois, ele cria um script chamado sync, com o único propósito de executar o script run . Este script é referenciado no cronjob que descrevemos anteriormente. O script run contém três blobs codificados em base64, que são canalizados para perl. Um exemplo de um script abreviado é mostrado abaixo:

Na decodificação base64, scripts perl ofuscados são identificados. Esses scripts aproveitam um utilitário público Perl Obfuscator para ofuscar seus conteúdos, tornando-os mais difíceis de analisar:

Felizmente, o autor deixou os comentários padrão nos scripts ofuscados. Usando o desofuscador disponível publicamente, podemos desofuscar o script por meio do seguinte comando:

perl decode-stunnix-5.17.1.pl < obfuscated_run.pl > deobfuscated_run.pl

Depois disso, podemos visualizar o conteúdo desofuscado:

Estas são apenas as primeiras linhas do roteiro, para fins ilustrativos. Essa técnica de desofuscação também pode ser usada para outros scripts Perl ofuscados usados pelo OUTLAW. Analisaremos esses scripts mais detalhadamente em breve.

O script termina instalando sua própria chave pública SSH para acesso persistente, definindo permissões restritivas e tornando o diretório imutável para impedir modificações por meio de chattr:

Scripts de SHELLBOT STEALTH

Os scripts STEALTH SHELLBOT usados no OUTLAW não são personalizados, mas sim scripts de bot IRC disponíveis publicamente, geralmente obtidos de antigos repositórios do GitHub e fóruns clandestinos. Esses scripts existem há mais de uma década, originalmente projetados para administração remota, automação e gerenciamento de botnets. No entanto, eles foram reutilizados por autores de malware para atividades maliciosas.

Os scripts SHELLBOT operam como backdoors baseados em IRC, permitindo que invasores controlem remotamente máquinas infectadas por meio de comandos predefinidos enviados por um canal IRC. Uma vez conectados ao servidor IRC do invasor, esses bots podem:

Executar comandos de shell arbitrários
Baixe e execute cargas úteis adicionais
Lançar ataques DDoS (em variantes mais antigas)
Roubar credenciais ou exfiltrar informações do sistema
Gerenciar mineradores de criptomoedas ou outros componentes de malware

O OUTLAW integra esses scripts SHELLBOT legados como um mecanismo de persistência secundário, garantindo que, mesmo que seus módulos de força bruta sejam interrompidos, os invasores ainda mantenham uma posição remota. O bot se conecta a um IRC C2 controlado pelo invasor, onde escuta outros comandos, permitindo a execução sob demanda de ações maliciosas.

Embora esses scripts não sejam novos, seu uso contínuo destaca como os invasores confiam em ferramentas disponíveis publicamente em vez de desenvolver novos malwares do zero.

Execução de subrotina do diretório c/: Bruteforcer do cliente

Como parte da terceira e última sub-rotina, uma ferramenta de força bruta personalizada é implantada. Esta cadeia começa, semelhante às sub-rotinas anteriores, a partir dos scripts init e init2 . Ambos os scripts chamam o script start , contendo o seguinte conteúdo:

Este script armazena o diretório de trabalho atual, fornece todas as permissões (777) para todos os arquivos no diretório atual e cria um script chamado aptitude (que também é chamado pelo cron job configurado anteriormente) para executar o script run . Após criar aptitude, ele recebe permissões de execução e é executado.

O script run é usado para coletar informações sobre a arquitetura da CPU e contar núcleos da CPU para determinar o comportamento de execução, conforme mostrado abaixo:

Se o sistema for x86_64, ele verifica se a CPU tem menos de 7 núcleos, introduzindo um atraso aleatório antes de executar ./go em segundo plano. Se 7 ou mais núcleos forem detectados, a execução será ignorada ou alterada (com um binário golan usado anteriormente agora comentado). O agente da ameaça pode ter testado ou trabalhado com um binário Golang que pode fazer uso total do número de núcleos presentes em um sistema, mas isso é apenas um palpite.

Na maioria dos cenários, o fluxo de execução passa para o script bash chamado go:

O script determina a arquitetura da CPU e atribui uma contagem de threads de acordo:

Sistemas baseados em ARM → 75 threads
i686 (32 bits x86) → 325 tópicos
Todos os outros (padrão) → 475 tópicos

Em seguida, ele entra em um loop infinito, executando as seguintes ações:

Cria e limpa arquivos temporários (v, p, ip, xtr*, a.*, b.*).
Grava valores codificados (257.287.563.234 e sdaferthqhr34312asdfa) nos arquivos c e d.
Aguarda um atraso aleatório (1-30 segundos) antes de iniciar blitz.
Executa blitz por 3 horas com parâmetros especificados (-t $threads sugere processamento multithread).
Executa a limpeza pós-execução, removendo arquivos temporários e de log antes de repetir o ciclo.

BLITZ

OUTLAW é um worm autopropagante que se espalha lateralmente por meio de ataques de força bruta SSH usando BLITZ, seu agente de força bruta personalizado. Projetado para ataques de credenciais agressivos e automatizados, o BLITZ verifica e compromete sistematicamente sistemas com credenciais SSH fracas ou padrão, permitindo que o malware expanda seu domínio com intervenção mínima do invasor.

Processo de execução BLITZ

Após a execução, o BLITZ segue uma sequência de ataque estruturada:

Recuperação de credenciais e alvos de IP
- O BLITZ contata um servidor SSH C2 para buscar uma lista de IPs de destino e pares de credenciais.
Autenticação de força bruta e criação de perfil do sistema
- Usando força bruta SSH multithread, o BLITZ tenta autenticar com credenciais roubadas.
- Uma vez obtido o acesso, ele:
  - Altera a senha do usuário para acesso persistente.
  - Executa comandos de reconhecimento do sistema, coletando:
    - Privilégios do usuário
    - Detalhes da CPU
    - Informações do banner SSH
    - Versão do SO
  - Exfiltra os dados coletados para o servidor C2.
Varredura de sub-rede e movimento lateral
- O malware verifica a sub-rede local de sistemas recentemente comprometidos, identificando máquinas adicionais acessíveis via SSH para atacar.
Auto-replicação e implantação de malware
- Em vez de baixar de um C2 externo, o BLITZ transfere diretamente o pacote de malware dota3.tar.gz do host infectador para a nova vítima, reforçando a persistência e minimizando a dependência de infraestrutura externa.

Ao combinar ataques automatizados de força bruta, criação de perfil do sistema, varredura de sub-rede e transferência direta de malware, o BLITZ maximiza a eficiência da infecção, ao mesmo tempo em que garante a expansão contínua da rede.

Análise Binária e Comunicação C2

Além das operações de força bruta, a análise revela que o BLITZ executa suas tarefas interagindo com comandos de shell do sistema e uma biblioteca SSH incorporada. Uma vez conectado a um sistema comprometido, ele consulta o servidor C2 em busca de alvos atualizados e retransmite dados de autenticação.

Além disso, o OUTLAW incorpora uma chave SSH codificada para autenticação C2, que deve ser desbloqueada usando a senha "pegasus". Após a autenticação bem-sucedida, o Blitz registra os detalhes do ataque em um arquivo "v", estruturado da seguinte forma:

Este log contém:

Nome de usuário e senha originais usados no ataque.
O endereço IP da vítima e a nova senha definida pelo malware.
Detalhes da porta SSH e do sistema operacional, incluindo especificações da CPU.

Depois que o BLITZ conclui seu ciclo de varredura, o arquivo "v" é exfiltrado para um servidor SSH C2, fornecendo aos invasores uma lista continuamente atualizada de sistemas infectados.

Pós-compromisso

Para analisar o comportamento pós-comprometimento do invasor, configuramos deliberadamente um honeypot e carregamos proativamente suas credenciais para o mesmo servidor SSH C2 usado pelo invasor. Isso efetivamente convidou o invasor para nosso ambiente controlado, permitindo-nos monitorar de perto suas ações subsequentes.

Poucos dias depois que o BLITZ usou força bruta com sucesso e definiu uma nova senha no sistema honeypot, observamos um login remoto usando essas credenciais. O login foi originado de 212.234.225[.]29. O invasor imediatamente executou um reconhecimento básico executando o comando w para verificar quem estava logado e, em seguida, executando ps para ver quais processos estavam em execução. Ao digitar os comandos, eles cometeram um pequeno erro de digitação e encerraram o prompt com um rápido Ctrl+C, indicando uma interação manual em vez de um script automatizado neste estágio. Em seguida, o invasor colou uma série de comandos para baixar uma nova cópia de dota3.tar.gz via wget, descompactou-o e executou o script recém-obtido.

Toda essa cadeia de atividades pode ser exibida por meio da visualização de sessão, uma ferramenta de investigação que permite examinar dados de processos do Linux organizados em uma estrutura semelhante a uma árvore, de acordo com o modelo de eventos lógicos do Linux, com processos organizados por ascendência e tempo de execução. Ele exibe eventos em um formato altamente legível, inspirado no terminal. Isso o torna uma ferramenta poderosa para monitorar e investigar a atividade da sessão na sua infraestrutura Linux e entender o comportamento do usuário e do serviço.

A cadeia de ataque exibida acima reflete o método de infecção original, sugerindo que o invasor estava atualizando componentes ou reinfectando o host para manter a persistência. Logo após verificar que a carga atualizada estava em execução, o invasor se desconectou do host, deixando para trás um ambiente preparado para força bruta contínua de SSH, mineração de criptomoedas e controle remoto via IRC.

Este breve login serve como um lembrete de que até mesmo campanhas pouco sofisticadas podem incluir focos de atividade interativa do invasor — uma espécie de "verificação de qualidade" manual — ressaltando a importância da detecção oportuna e da contenção rápida.

Detectando OUTLAW através do MITRE ATT&CK

OUTLAW é um malware Linux que depende de ataques de força bruta SSH, mineração de criptomoedas e propagação semelhante a worms para infectar e manter o controle sobre os sistemas. Embora não seja altamente sofisticado, ele abrange uma ampla gama de técnicas MITRE ATT&CK, o que o torna um caso eficaz para engenharia de detecção.

Esta seção mapeia a cadeia de ataque do OUTLAW para o MITRE ATT&CK, destacando as regras do Elastic SIEM e do endpoint e as consultas de busca de ameaças que podem identificar sua atividade em diferentes estágios.

OUTLAW segue um fluxo de infecção estruturado:

Acesso inicial – Força bruta SSH contra credenciais fracas.
Execução – Executa scripts maliciosos para iniciar vários estágios de infecção por malware.
Persistência – Instala tarefas cron e modifica chaves SSH.
Evasão de defesa – Oculta-se em diretórios ocultos, modifica permissões de arquivo, usa técnicas de compactação, codificação de comando e ofusca scripts.
Acesso de Credencial – Modifica credenciais e injeta chaves SSH públicas.
Descoberta – Enumera detalhes do usuário, sistema e hardware.
Movimento lateral – Propaga-se por meio de força bruta SSH interna e transferência de malware.
Coleta e exfiltração – coleta e exfiltra dados do sistema para seu C2.
Comando e Controle – Usa socat e STEALTH SHELLBOT para comunicação C2.
Impacto – Lança o XMRIG para minerar criptomoedas e utiliza o host infectado como um nó de força bruta.

As seções a seguir detalham estratégias de detecção para cada técnica, ajudando os defensores a identificar e mitigar efetivamente as infecções do OUTLAW.

TA001: Acesso Inicial

O OUTLAW obtém acesso inicial por meio de força bruta SSH oportunista, visando sistemas com credenciais fracas ou padrão. Regras de detecção pré-criadas elásticas podem detectar com sucesso esse método de acesso inicial. Isso inclui:

Além disso, existem várias regras baseadas em logs de autenticação para detectar autenticações SSH suspeitas:

Além de depender de detecções, é importante incorporar a busca por ameaças ao seu fluxo de trabalho. O Elastic Security fornece diversas consultas de busca usando ES|QL e OSQuery, disponíveis publicamente em nosso repositório de Regras de Detecção, especificamente no subdiretório de busca do Linux. Por exemplo, as duas buscas a seguir podem ajudar a identificar diferentes estágios do ataque:

TA002: Execução

Após obter acesso inicial, o OUTLAW executa uma série de scripts e binários para estabelecer o controle. Ao baixar e descompactar, detectamos:

O script STEALTH SHELLBOT é detectado através de:

Script executado por meio de processo pai incomum

Além disso, o malware executa vários comandos de sistema suspeitos, acionando:

Comandos suspeitos do sistema executados por um executável anteriormente desconhecido

TA003: Persistência

Essa combinação de execução baseada em cron e manipulação de chave SSH permite que o OUTLAW mantenha uma posição persistente em sistemas comprometidos. Ambas as técnicas de persistência são amplamente pesquisadas em nossa publicação "Linux Detection Engineering - A primer on persistence mechanism". Podemos detectar essas técnicas por meio das seguintes regras de SIEM e endpoint:

Além disso, podemos procurar essas técnicas por meio das seguintes buscas ES|QL e OSQuery:

TA005: Evasão de Defesa

OUTLAW emprega diversas técnicas de evasão de defesa para evitar a detecção. Um dos seus métodos principais é a decodificação Base64, que é detectada por meio das seguintes regras pré-criadas:

Além disso, os binários do malware são compactados com UPX, reduzindo seu tamanho e alterando sua assinatura para evitar a detecção tradicional de malware. Depois que o malware é descompactado na memória, isso é detectado por meio de nossas detecções gerais de malware.

Continuando na cadeia de execução, o malware cria vários arquivos e diretórios ocultos e os modifica usando chattr:

Podemos melhorar ainda mais a detecção por meio da seguinte consulta de busca:

Execução de Processo Oculto

TA006: Acesso de Credencial

OUTLAW mantém acesso persistente a um sistema comprometido manipulando credenciais. Após a autenticação de força bruta SSH bem-sucedida, o malware substitui o arquivo authorized_keys SSH existente por uma nova versão contendo uma chave pública SSH maliciosa, concedendo assim acesso persistente. Isso é detectado através dos seguintes sinais:

O malware então altera as credenciais do usuário para a conta autenticada inserindo uma nova senha usando o utilitário passwd :

Modificação de credencial de conta de usuário Linux

TA007: Descoberta

O OUTLAW coleta informações do sistema após uma infecção bem-sucedida para criar um perfil do ambiente comprometido. O malware executa vários comandos para coletar detalhes sobre a CPU do sistema, privilégios do usuário, sistema operacional, uso de memória e binários disponíveis. Essa etapa de reconhecimento ajuda o invasor a avaliar as capacidades do sistema e determinar a melhor forma de utilizar a máquina comprometida. Tudo isso é detectado por meio de diversas regras de blocos de construção, conforme listado em nosso diretório rules_building_block. Abaixo está uma pequena lista dos mais importantes acionados pelo OUTLAW:

As configurações de interface padrão não incluem regras de blocos de construção devido aos seus níveis de ruído relativamente altos. No entanto, essas regras podem ser ativadas para auxiliar na identificação de ameaças potenciais.

TA008: Movimento Lateral

O malware OUTLAW se espalha por uma rede comprometida realizando ataques internos de força bruta SSH. Podemos identificar esse comportamento por meio das seguintes regras ES|QL:

Depois que um sistema é atacado com força bruta, o pacote de malware, dota3.tar.gz, é implantado do host infectado para o novo alvo. A sub-rede local é então verificada em busca de alvos adicionais para garantir a propagação contínua do malware.

Regras de detecção pré-definidas elásticas podem identificar essas tentativas de movimento lateral:

Além disso, ao copiar o malware OUTLAW para um host remoto, alertas de prevenção de malware são ativados.

TA009: Coleta e TA010: Exfiltração

O OUTLAW coleta informações básicas do sistema, credenciais e detalhes de SSH de máquinas comprometidas, principalmente para rastrear hosts infectados e facilitar novos ataques. Esses dados são armazenados em um arquivo de texto simples antes de serem enviados para um servidor C2. Como essa atividade de coleta se limita a reunir detalhes do sistema e gravá-los em um arquivo, ela não é inerentemente suspeita por si só.

A exfiltração ocorre quando o OUTLAW inicia uma conexão SSH de saída via sftp-server para transferir as informações coletadas para um servidor C2 predefinido. Embora isso possa se assemelhar a uma atividade SSH normal, podemos detectar a execução suspeita de utilitários de transferência de arquivos por meio do ES|QL:

Lançado utilitário incomum de transferência de arquivos

TA011: Comando e Controle

O OUTLAW mantém comunicação com sua infraestrutura C2 por meio de vários canais, permitindo que invasores emitam comandos, extraiam dados e gerenciem sistemas infectados. Podemos detectar vários dos utilitários usados pelo malware por meio das seguintes regras:

As mesmas consultas de busca que foram relevantes para detectar as tentativas iniciais de acesso do malware também podem ser usadas para procurar essa atividade C2. Além disso, as seguintes consultas de busca podem ser usadas:

TA040: Impact

O OUTLAW afeta os sistemas infectados consumindo recursos da CPU para mineração de criptomoedas e realizando ataques de força bruta SSH para se propagar. Várias otimizações de CPU e memória são tentadas antes de iniciar o software de mineração XMRIG modificado, incluindo habilitar o acesso de gravação MSR e definir parâmetros do kernel, como hugepages. Essas modificações podem ser detectadas através das seguintes regras:

Como o OUTLAW tenta habilitar o acesso de gravação do MSR via modprobe, mas não possui as permissões necessárias, regras relacionadas ao driver do kernel são acionadas:

Essas regras monitoram diretamente as chamadas de sistema init_module() e finit_module() por meio do Auditd. Para obter mais informações sobre como configurar a integração do Auditd Manager para capturar eventos de driver e muito mais, confira a publicação Linux Detection Engineering with Auditd .

Simultaneamente, tentativas de força bruta SSH são iniciadas a partir do host infectado, acionando:

Possível tentativa de força bruta SSH acionada por malware

Durante sua execução, o OUTLAW executa scripts de eliminação para encerrar malwares concorrentes ou processos remanescentes de infecções anteriores. Esse comportamento desencadeia:

Indicadores de Compromisso (IOCs)

O conjunto completo de indicadores pode ser encontrado como um pacote no Github.

Assinaturas Yara

rule Linux_Hacktool_Outlaw_cf069e73 {
    meta:
        author = "Elastic Security"
        description = "OUTLAW SSH bruteforce component fom the Dota3 package"
        reference_sample = "c3efbd6b5e512e36123f7b24da9d83f11fffaf3023d5677d37731ebaa959dd27"
      
    strings:
        $ssh_key_1 = "MIIJrTBXBgkqhkiG9w0BBQ0wSjApBgkqhkiG9w0BBQwwHAQI8vKBZRGKsHoCAggA"
        $ssh_key_2 = "MAwGCCqGSIb3DQIJBQAwHQYJYIZIAWUDBAECBBBC3juWsJ7DsDd2wH2XI+vUBIIJ"
        $ssh_key_3 = "UCQ2viiVV8pk3QSUOiwionAoe4j4cBP3Ly4TQmpbLge9zRfYEUVe4LmlytlidI7H"
        $ssh_key_4 = "O+bWbjqkvRXT9g/SELQofRrjw/W2ZqXuWUjhuI9Ruq0qYKxCgG2DR3AcqlmOv54g"
        $path_1 = "/home/eax/up"
        $path_2 = "/var/tmp/dota"
        $path_3 = "/dev/shm/ip"
        $path_4 = "/dev/shm/p"
        $path_5 = "/var/tmp/.systemcache"
        $cmd_1 = "cat /proc/cpuinfo | grep name | head -n 1 | awk '{print $4,$5,$6,$7,$8,$9;}'"
        $cmd_2 = "cd ~; chattr -ia .ssh; lockr -ia .ssh"
        $cmd_3 = "sort -R b | awk '{ if ( NF == 2 ) print } '> p || cat b | awk '{ if ( NF == 2 ) print } '> p; sort -R a"
        $cmd_4 = "rm -rf /var/tmp/dota*"
        $cmd_5 = "rm -rf a b c d p ip ab.tar.gz"
    condition:
        (all of ($ssh_key*)) or (3 of ($path*) and 3 of ($cmd*))
}

Visão geral das regras de SIEM e endpoint pela tática MITRE ATT&CK

ID da técnica	Descrição
TA001: Acesso Inicial	Possível força bruta externa de SSH do Linux detectada Possível ataque bem-sucedido de força bruta em SSH Autenticação SSH bem-sucedida de uma chave pública SSH incomum Autenticação SSH bem-sucedida de usuário incomum Autenticação SSH bem-sucedida de endereço IP incomum
TA002: Execução	File Downloaded from Suspicious Source by Web Server Linux.Trojan.Pornoasset Script executado por meio de processo pai incomum Comandos suspeitos do sistema executados por um executável anteriormente desconhecido
TA003: Persistência	Cron Job Created or Modified Modificação de arquivo de chaves autorizadas SSH Persistência potencial por meio de modificação de arquivo
TA005: Evasão de Defesa	Carga útil decodificada em Base64 canalizada para o interpretador Atividade incomum de codificação/decodificação Base64
TA006: Acesso de Credencial	Modificação de arquivo de chaves autorizadas SSH Exclusão de arquivo de chaves autorizadas SSH Modificação de credencial de conta de usuário Linux
TA007: Descoberta	Descoberta de informações do sistema Linux
TA008: Movimento Lateral	Atividade potencial de varredura de porta do host comprometido
TA009 e TA010: Coleta e Exfiltração	Lançado utilitário incomum de transferência de arquivos
TA011: Comando e Controle	Atividade Socat Reverse Shell ou Listener
TA040: Impact	Atividade de recurso de kernel suspeito

Conclusão

OUTLAW exemplifica como até mesmo malware pouco sofisticado pode persistir e escalar efetivamente em ambientes modernos. Apesar da falta de técnicas avançadas de evasão, sua combinação de ataques de força bruta SSH, autorreplicação e componentes modulares permite que ele mantenha uma botnet de longa duração. O OUTLAW garante expansão contínua com intervenção mínima do invasor, aproveitando hosts comprometidos para propagar ainda mais as infecções.

Nosso experimento honeypot forneceu um raro vislumbre do comportamento do invasor no mundo real, confirmando que, embora grande parte da operação do OUTLAW seja automatizada, há momentos de interação humana direta. A capacidade de observar comandos manuais, tentativas de reconhecimento e até mesmo erros tipográficos simples destaca um aspecto frequentemente esquecido da manutenção de botnets: o controle de qualidade orientado pelo operador. Esses insights reforçam a necessidade de estratégias de detecção que levem em conta não apenas ataques automatizados, mas também atividades manuais pós-comprometimento.

Ao entender como o OUTLAW opera, espalha e monetiza infecções, os defensores podem desenvolver estratégias de detecção robustas para mitigar seu impacto. Este relatório fornece regras SIEM acionáveis, consultas de busca de ameaças e insights forenses, permitindo que as equipes de segurança fiquem à frente de ameaças semelhantes em evolução.

Referências

[1] CounterCraft, DOTA3 Malware de novo e de novo

[2] Juniper Networks, DOTA3: Seu dispositivo de Internet das Coisas está fazendo bico?

[3] SANS ISC, Higiene Higiene Higiene

[4] Darktrace, Outlaw Returns: Descobrindo características de retorno e novas táticas