Os dispositivos Linux estão sob ataque de um worm nunca antes visto por equipes de segurança. No ano passado, um malware autorreplicante até então desconhecido comprometeu dispositivos Linux em todo o mundo e instalou malware de criptomineração que toma medidas incomuns para ocultar seu funcionamento interno, disseram os pesquisadores.
O worm é uma versão personalizada do Mirai, o malware botnet que infecta servidores, roteadores, câmeras web e outros dispositivos baseados em Linux, chamados de Internet das Coisas. O Mirai veio à tona em 2016, quando foi usado para fornecer ataques distribuídos de negação de serviço que estabeleceram recordes e que paralisaram partes importantes da Internet naquele ano.
Os criadores logo divulgaram o código-fonte, um movimento que permitiu que uma ampla gama de grupos criminosos de todo o mundo incorporassem o Mirai em suas próprias campanhas de ataque. Depois de tomar posse de um dispositivo Linux, a Mirai o utiliza como plataforma para infectar outros dispositivos vulneráveis, um design que o transforma em um worm, o que significa que ele se auto-replica.
Warm desconhecido ataca dispositivos Linux. Malware dime-a-dozen com um toque especial
Tradicionalmente, o Mirai e suas diversas variantes se espalham quando um dispositivo infectado verifica a Internet em busca de outros dispositivos que aceitem conexões Telnet. Os dispositivos infectados então tentam quebrar a senha do telnet adivinhando os pares de credenciais padrão e comumente usados. Quando bem-sucedidos, os dispositivos recém-infectados visam dispositivos adicionais usando a mesma técnica.
O Mirai tem sido usado principalmente para realizar DDoSes. Dadas as grandes quantidades de largura de banda disponíveis para muitos desses dispositivos, as inundações de tráfego indesejado são muitas vezes enormes, dando à botnet como um todo um tremendo poder.
Na quarta-feira, pesquisadores da empresa de segurança e confiabilidade de rede Akamai revelaram que uma rede até então desconhecida baseada em Mirai, apelidada de NoaBot, tem como alvo dispositivos Linux desde pelo menos janeiro passado. Em vez de ter como alvo senhas telnet fracas, o NoaBot tem como alvo senhas fracas conectando conexões SSH.
Outra reviravolta:
Em vez de realizar DDoSes, o novo botnet instala software de mineração de criptomoedas, que permite aos invasores gerar moedas digitais usando os recursos de computação, eletricidade e largura de banda das vítimas. O criptominerador é uma versão modificada do XMRig, outro malware de código aberto. Mais recentemente, o NoaBot também foi usado para entregar o P2PInfect, conforme revelado por pesquisadores de worm separados da Palo Alto Networks em julho passado.
A Akamai monitora o NoaBot nos últimos 12 meses em um honeypot que imita dispositivos Linux reais para rastrear vários ataques que circulam na natureza. Até o momento, os ataques tiveram origem em 849 endereços IP distintos, quase todos provavelmente hospedando um dispositivo já infectado. A figura a seguir acompanha o número de ataques entregues ao honeypot no ano passado.
Ampliar / Atividade de malware Noabot ao longo do tempo.
“Superficialmente, NoaBot não é uma campanha muito sofisticada – é ‘apenas’ uma variante Mirai e um criptominerador XMRig, e eles custam uma dúzia hoje em dia”, escreveu o pesquisador sênior de segurança da Akamai, Stiv Kupchik, em um relatório na quarta-feira. “No entanto, as ofuscações adicionadas ao malware e as adições ao código-fonte original pintam um quadro muito diferente das capacidades dos atores da ameaça.”
A capacidade mais avançada é como o NoaBot instala a variante XMRig. Normalmente, quando os mineradores de criptografia são instalados, os fundos das carteiras são distribuídos e especificados nas configurações fornecidas em uma linha de comando emitida para o dispositivo infectado. Esta abordagem representa há muito tempo um risco para os agentes de ameaças porque permite aos investigadores rastrear onde as carteiras estão alojadas e quanto dinheiro fluiu para elas.
NoaBot usa uma nova técnica para evitar tal detecção. Em vez de entregar as definições de configuração por meio de uma linha de comando, o botnet armazena as configurações de forma criptografada ou ofuscada e as descriptografa somente depois que o XMRig é carregado na memória. O botnet então substitui a variável interna que normalmente conteria as definições de configuração da linha de comando e passa o controle para o código-fonte do XMRig.
Kupchik ofereceu uma descrição mais técnica e detalhada:
No código-fonte aberto do XMRig, os mineradores podem aceitar configurações de duas maneiras – por meio da linha de comando ou por meio de variáveis ??de ambiente. No nosso caso, os agentes da ameaça optaram por não modificar o código original do XMRig e, em vez disso, adicionaram partes antes da função principal. Para contornar a necessidade de argumentos de linha de comando (que podem ser um indicador de comprometimento do IOC e dos defensores de alerta), os atores da ameaça fizeram com que o minerador substituísse sua própria linha de comando (em termos técnicos, substituindo argv) por argumentos mais “significativos” antes de passar o controle. ao código XMRig. A botnet executa o minerador com (no máximo) um argumento que lhe diz para imprimir seus logs. Antes de substituir sua linha de comando, porém, o minerador precisa construir sua configuração. Primeiro, ele copia argumentos básicos armazenados em texto simples – o sinalizador rig-id, que identifica o minerador com três letras aleatórias, os sinalizadores de threads e um espaço reservado para o endereço IP do pool (Figura 7).
Curiosamente, como as configurações são carregadas através dos registradores xmm, o IDA na verdade perde os dois primeiros argumentos carregados, que são o nome binário e o espaço reservado para IP do pool.
Ampliar / Código NoaBot que copia configurações do mineradorInteligente
Em seguida, o minerador descriptografa o nome de domínio do pool. O nome de domínio é armazenado e criptografado em alguns blocos de dados que são descriptografados por meio de operações XOR. Embora o XMRig possa funcionar com um nome de domínio, os invasores decidiram dar um passo a mais e implementaram sua própriafunção de resolução de DNS. Eles se comunicam diretamente com o servidor DNS do Google (8.8.8.8) e analisam sua resposta para resolver o nome de domínio para um endereço IP.
A última parte da configuração também é criptografada de forma semelhante e é a chave de acesso para o minerador se conectar ao pool. Resumindo, a configuração total do minerador é mais ou menos assim:
-o --rig-id --threads –pass espana*tea
Notou alguma coisa faltando? Sim, sem endereço de carteira.
Acreditamos que os agentes da ameaça optaram por gerir o seu próprio pool privado em vez de um público, eliminando assim a necessidade de especificar uma carteira (o seu pool, as suas regras!). No entanto, nas nossas amostras, observámos que os domínios dos mineiros não estavam a ser resolvidos com o DNS do Google, por isso não podemos realmente provar a nossa teoria ou recolher mais dados do pool, uma vez que os domínios que temos já não são resolvíveis. Não vimos nenhum incidente recente que derrubou o mineiro, então também pode ser que os atores da ameaça tenham decidido partir para pastagens mais verdes.
NoaBot é compilado usando a biblioteca de código conhecida como UClibc, enquanto o Mirai padrão usa a biblioteca GCC. A biblioteca alternativa parece mudar a forma como as proteções antivírus detectam o NoaBot. Em vez de ser detectado como membro da família Mirai, os mecanismos AV o categorizam como um scanner SSH ou um trojan genérico.
O malware é compilado estaticamente e sem quaisquer símbolos. Isso torna a engenharia reversa do malware muito mais difícil.
Strings, as palavras legíveis incluídas no código, são ofuscadas em vez de salvas como texto simples. Esse ajuste torna ainda mais difícil para os engenheiros reversos fazer coisas como extrair detalhes do binário ou usar IDA e outras ferramentas de desmontagem.
O binário NoaBot é executado a partir de uma pasta gerada aleatoriamente no diretório /lib, um design que torna ainda mais difícil a busca de dispositivos para infecções por NoaBot.
O dicionário Mirai padrão que armazena a lista de senhas comumente usadas foi substituído por um novo tão grande que é impraticável para a Akamai testar todas elas. A variante também troca o scanner Telnet por um scanner SSH personalizado.
A adição de uma série de recursos pós-violação, incluindo a instalação de uma nova chave SSH autorizada para uso pelo invasor como backdoor para baixar e executar binários adicionais ou propagar para novos dispositivos.
Embora a segurança operacional dos criadores do NoaBot seja alta, eles também são notáveis ??pelos nomes de strings juvenis e outras adições gratuitas em algumas versões de seu código. Em um caso, eles adicionaram a letra da música “Who’s Ready for Tomorrow” de Rat Boy e IBDY.
Uma versão anterior do NoaBot incorpora a letra de “Who’s Ready for Tomorrow” de Rat Boy e IBDY.
Os 849 IPs de origem distintos estão espalhados de maneira relativamente uniforme por todo o mundo. Os pesquisadores dizem que essa uniformidade é comum nos worms, que permitem que cada nova vítima seja também um novo invasor. Outra coisa que não é compreendida: o que explica um hotspot de IPs de origem localizados na China que gera cerca de 10% dos ataques? Também não está claro quantos IPs adicionais hospedam os dispositivos direcionados ao honeypot Akamai podem existir e, nesse caso, se alguns dos dispositivos são realmente executados pelos invasores na tentativa de propagar sua botnet.
Mapa de calor de geolocalização global de fontes de ataque NoaBot.Inteligente
A Akamai publicou uma extensa biblioteca de indicadores que as pessoas podem usar para verificar sinais de NoaBot em seus dispositivos. Inclui uma instância pré-configurada do aplicativo Infection Monkey da Akamai para testar redes em busca de sinais de comprometimento. Há também um arquivo CSV que armazena todos os indicadores de comprometimento e regras YARA para detectar infecções por XMRig.
É difícil saber no momento se o NoaBot continua sendo uma botnet com menos de 1.000 hosts infectados ou se o honeypot da Akamai viu apenas uma pequena fração dos dispositivos afetados. Dada a dificuldade de detectar infecções por NoaBot, a biblioteca de indicadores de comprometimento montada pela Akamai pode ser valiosa.
