Rootkit furtivo para Linux é encontrado em circulação após passar despercebido por 2 anos

Controle de tráfego de saída e egress

• Vários comentários focam nas portas de saída ocultas do malware e observam que a maioria dos ambientes restringe fortemente o tráfego de entrada, mas permite quase todo o tráfego de saída.
• Mitigações sugeridas:
  • Registrar e criar uma linha de base das portas de saída comuns e, então, bloquear o restante e ver o que quebra.
  • Reduzir o “ruído de fundo” (por exemplo, pings DNS constantes, NTP externo) e mover serviços para dentro.
  • Aplicar regras de firewall por horário, para que nada fale com a internet durante a noite, mas com exceções de emergência.
• Alguns argumentam que muitos incidentes (por exemplo, exploração do Log4Shell) teriam sido muito menos danosos com políticas de egress mais rígidas.

Canais de comando e controle (C2)

• Vários comentários dizem que malware do mundo real frequentemente oculta C2 sobre HTTPS na porta 443 e por meio de grandes provedores (Cloudflare, grandes clouds, serviços do Google).
• Propostas como “permitir HTTPS apenas para FAANG ou Cloudflare” são criticadas como ineficazes porque os invasores podem fazer fronting de C2 justamente por esses provedores.
• Há relatos e exemplos de Cloudflare Workers e infra semelhante sendo usados para C2 e DDoS, com alegações de que as derrubadas são lentas; outros contestam pedindo evidências concretas, que são parcialmente fornecidas por meio de relatórios vinculados.
• Domain fronting, uso de Google Drive/Docs/Apps Script e “protocolos estranhos” (por exemplo, SCTP) são citados como técnicas de evasão de C2.

Vetores de infecção e alvo

• Os pesquisadores do artigo supostamente não sabem o caminho inicial de infecção; entre os vetores possíveis listados estão exploração de vulnerabilidades, roubo/adição de credenciais e instaladores/atualizações trojanizados.
• Outras vias prováveis: SSH fraco ou sem autenticação em dispositivos Linux de IoT e bugs em apps/frameworks web.
• Alguns sugerem que este RAT é um mecanismo de persistência de estágio posterior após um comprometimento anterior, tornando a entrada original difícil de reconstruir anos depois.
• O fato de mirar em telecoms e usar protocolos novos leva alguns a especular sobre atores estatais; outros observam que também pode ser “fruto de baixo risco” ou crime comercial.

Rootkits e técnicas de persistência

• Comentadores observam que os padrões de rootkits em Linux pouco mudaram desde o fim dos anos 1990: substituição de binários, hooking de syscalls do kernel e hooking em userland (por exemplo, LD_PRELOAD).
• Manter rootkits de kernel em muitas versões de kernel é descrito como penoso; alguns operadores preferem backdoors mais simples em userland.
• Truques mencionados incluem renomear processos via prctl para parecerem threads do kernel e criar artefatos de sistema de arquivos difíceis de notar (por exemplo, diretórios ...).
• Secure Boot, a menos que esteja muito bem configurado, é visto como insuficiente depois que os atacantes já têm execução em ring-0.

Postura de segurança do desktop Linux

• Há debate sobre se o Linux desktop é “mais fácil” para atores de Estado, porque muitos usuários não têm AV/EPP e instalam software via curl | sudo bash ou gerenciadores de pacotes específicos de linguagem.
• Vários argumentam que AV é amplamente ineficaz contra rootkits/APTs desconhecidos e apenas corresponde a padrões conhecidos; os invasores podem simplesmente recompilar para burlar assinaturas.
• Outros contrapõem que a proteção moderna de endpoint usa heurísticas/ML e indicadores comportamentais, bloqueando muitos payloads comuns e elevando a barreira, especialmente no Windows.
• Vários comentários destacam fragilidades estruturais dos desktops Linux típicos:
  • O X11 permite keylogging global.
  • Qualquer app executado como o usuário normalmente tem acesso total ao diretório home.
  • Não há um modelo per-app de permissões de arquivo, amigável ao usuário, como no macOS/Windows modernos.
• Uma vez que o malware consegue gravar no diretório home do usuário, ele pode alterar arquivos de inicialização do shell, fazer wrap de sudo, roubar chaves SSH ou sequestrar configurações, muitas vezes tornando a escalada para root apenas uma questão de tempo ou até desnecessária para roubo de dados.

Antivírus / EPP no Linux

• Há discordância sobre se vale a pena executar AV/EPP em desktops Linux.
  • Críticos: o AV precisa rodar com privilégios muito altos, aumentando a superfície de ataque, e oferece pouca defesa contra adversários capazes.
  • Defensores: segurança é em camadas; mesmo imperfeito, o EPP pode capturar muitos payloads conhecidos e toolkits comuns (Metasploit, binários reencodificados) e é relativamente pouco incômodo em desktops.
• É mencionada a compatibilidade do Ubuntu com ClamAV; contudo, ele é caracterizado como majoritariamente baseado em assinaturas e focado em malware conhecido (muitas vezes Windows), com valor limitado contra ameaças Linux novas.

Gerenciamento de pacotes e risco de supply chain

• Vários comentários contrastam gerenciadores de pacotes de distribuições (com repositórios assinados por GPG) com ferramentas do ecossistema como pip/npm/cpan, que frequentemente dependem apenas de TLS e têm proveniência mais fraca.
• Comprometer repositórios de distro é visto como mais difícil e mais visível (muitas chaves, validação GPG, possível uso de Certificate Transparency), enquanto pacotes em nível de linguagem podem ser sequestrados ou substituídos com mais facilidade.
• É levantado o risco de atualizações maliciosas ou pacotes abandonados (incidentes no estilo “left-pad”); lockfiles ajudam, mas também atrasam patches de segurança.
• Para adversários de alto nível, a interceptação por meio de certificados TLS maliciosos é mencionada como uma preocupação, mas a assinatura GPG e os logs de CT complicam tais ataques.

Ferramentas de detecção e arquiteturas alternativas

• Ferramentas tradicionais como chkrootkit são consideradas de utilidade limitada hoje; malware sofisticado pode burlar scanners simples baseados em assinatura.
• Alguns olham para soluções arquiteturais:
  • Qubes OS (forte isolamento por VM para tarefa/app), embora a adoção e o tamanho da base de código sejam preocupações.
  • ChromeOS pelo seu modelo travado, embora fortemente acoplado ao Google.
  • Debian “Minimax”, com a maioria dos apps do usuário rodando dentro de VMs dedicadas.