Quase metade dos malwares agora usam TLS para ocultar comunicações

Quanto mais a Internet usa o Transport Layer Security, a análise da telemetria de detecção mostra que o volume de comunicações criptografadas por TLS por malware dobrou em um ano.

protocolo tls

Por Sean Gallagher

O Transport Layer Security tem sido um dos maiores contribuintes para a privacidade e segurança das comunicações da Internet na última década. O protocolo criptográfico TLS é usado para proteger uma parte cada vez maior do tráfego de dados de aplicativos, mensagens e web da Internet. O protocolo da web HTTP (HTTPS) seguro, protocolo de e-mail StartTLS, rede de anonimato Tor e redes privadas virtuais, como aquelas baseadas no protocolo OpenVPN, todos utilizam o TLS para criptografar e encapsular seus conteúdos, protegendo-os de serem observados ou modificados em trânsito.

Durante a última década, e particularmente após revelações sobre a vigilância em massa da Internet, o uso de TLS cresceu para cobrir a maioria das comunicações na Internet. De acordo com dados do navegador do Google, o uso de HTTPS cresceu de pouco mais de 40 por cento de todas as visitas à página da web em 2014 para 98 por cento em março de 2021.

Não deve ser surpresa, então, que os operadores de malware também tenham adotado o TLS essencialmente pelos mesmos motivos: para evitar que os defensores detectem e interrompam a implantação de malware e roubo de dados. Vimos um crescimento dramático no ano passado em malware usando TLS para ocultar suas comunicações. Em 2020, 23% dos malwares que detectamos se comunicando com um sistema remoto pela Internet usavam TLS; hoje, é quase 46% .

Uma análise das comunicações de saída de malware nos primeiros 3 meses de 2021.

Também há uma fração significativa de comunicações TLS que usam uma porta de protocolo da Internet diferente de 443 – como malware usando um Tor ou proxy SOCKS em um número de porta não padrão. Consultamos os registros de transparência de certificado com os nomes de host associados a comunicações de malware na Internet em portas diferentes de 443, 80 e 8080 e descobrimos que 49 por cento dos hosts tinham certificados TLS associados a eles, emitidos por uma Autoridade de Certificação (CA) . Uma pequena fração dos outros verificados manualmente usaram certificados autoassinados.

Mas uma grande parte do crescimento do uso geral de TLS por malware pode estar ligada em parte ao aumento do uso de serviços legítimos da web e em nuvem protegidos por TLS – como Discord, Pastebin, Github e serviços em nuvem do Google – como repositórios para componentes de malware, como destinos para dados roubados e até mesmo para enviar comandos para botnets e outros malwares. Também está vinculado ao aumento do uso de Tor e outros proxies de rede baseados em TLS para encapsular comunicações maliciosas entre malware e os agentes que os implantam.

Uma análise dos destinos do tráfego “callhome” do malware TLS por ISP nos primeiros três meses de 2021.

Os serviços em nuvem do Google foram o destino de nove por cento das solicitações de malware TLS, com o BSNL da Índia logo atrás. Durante o mês de março de 2021, vimos um aumento no uso de malware hospedado em Cloudflare, principalmente por causa de um pico no uso da rede de distribuição de conteúdo do Discord, que é baseada no Cloudflare, que por si só respondeu por 4 por cento dos Malware detectados com TLS naquele mês. Relatamos mais de 9.700 links relacionados a malware para o Discord; muitos eram específicos do Discord, visando o roubo de credenciais do usuário, enquanto outros eram pacotes de entrega para outros ladrões de informações e cavalos de Tróia.

No total, quase metade de todas as comunicações TLS de malware foi para servidores nos Estados Unidos e na Índia.

Vimos um aumento no uso de TLS em ataques de ransomware no ano passado, especialmente em ransomware implantado manualmente – em parte devido ao uso de invasores de ferramentas ofensivas modulares que alavancam HTTPS. Mas a grande maioria do que detectamos no dia-a-dia no tráfego TLS malicioso é proveniente de malware de comprometimento inicial: carregadores, droppers e instaladores baseados em documentos acessando páginas seguras da web para recuperar seus pacotes de instalação.

Para ter uma ideia de como o uso de TLS em malware mudou, analisamos profundamente nossa telemetria de detecção para medir quanto TLS é usado por malware, identificar o malware mais comum que usa TLS e como esses malwares fazem uso de TLS – comunicações criptografadas. Com base em nossa telemetria de detecção, descobrimos que, embora o TLS ainda represente uma média de pouco mais de dois por cento do tráfego geral que o Sophos classifica como “callhome de malware” em um período de três meses, 56 por cento dos servidores C2 exclusivos (identificados por DNS nomes de host) que se comunicaram com malware usando HTTPS e TLS. E disso, quase um quarto é com a infraestrutura que reside no ambiente de nuvem do Google.

Pacotes surpresa

As comunicações de malware normalmente se enquadram em três categorias: download de malware adicional, exfiltração de dados roubados e recuperação ou envio de instruções para acionar funções específicas (comando e controle). Todos esses tipos de comunicação podem tirar proveito da criptografia TLS para evitar a detecção pelos defensores. Mas a maioria do tráfego TLS que encontramos vinculado ao malware foi do primeiro tipo: droppers, loaders e outros malwares baixando malware adicional para o sistema que infectaram, usando TLS para escapar da inspeção básica de carga útil.

Não é preciso muita sofisticação para aproveitar o TLS em um dropper de malware, porque a infraestrutura habilitada para TLS para entregar malware ou fragmentos de código está disponível gratuitamente. Freqüentemente, droppers e loaders usam sites legítimos e serviços em nuvem com suporte TLS integrado para disfarçar ainda mais o tráfego. Por exemplo, este tráfego de um dropper Bladabindi RAT mostra que ele está tentando recuperar sua carga de uma página Pastebin. (A página não existe mais.)

Captura de tela do Wireshark de um conta-gotas chamando a página Pastebin
Tráfego TLS de um dropper Bladabini RAT tentando recuperar o código de segundo estágio de Pastebin por TLS.

Vimos vários casos de malware se comportando dessa maneira em nossa pesquisa. O conta-gotas baseado em PowerShell para LockBit ransomware foi observado recuperando script adicional de uma planilha do Google Docs via TLS, bem como de outro site. E um dropper para AgentTesla  (discutido posteriormente neste relatório) também foi observado acessando Pastebin sobre TLS para recuperar pedaços de código. Embora o Google e o Pastebin frequentemente desliguem rapidamente documentos e sites que hospedam malware em sua plataforma, muitas dessas fontes C2 são abandonadas após uma única campanha de spam e os invasores simplesmente criam novos para o próximo ataque.

Às vezes, o malware usa vários serviços dessa forma em um único ataque. Por exemplo, um dos inúmeros droppers de malware que encontramos na rede de distribuição de conteúdo do Discord deixou outro estágio também hospedado no Discord, que por sua vez tentou carregar um executável diretamente do GitHub. (O código do GitHub já havia sido removido como malicioso; divulgamos os estágios iniciais do ataque de malware ao Discord, junto com vários outros malwares, que os removeu.)

Uma captura de pacotes de malware recuperando downloads do Discord e GitHub.

Na verdade, o tráfego de download de malware constitui a maior parte do tráfego C2 baseado em TLS que observamos. Em fevereiro de 2021, por exemplo, os droppers representaram mais de 90 por cento do tráfego TLS C2 – um número que se aproxima dos dados de telemetria de detecção C2 estáticos associados a malware semelhante mês a mês de janeiro a março de 2021.

Canais secretos

Os operadores de malware podem usar TLS para ofuscar o comando e controlar o tráfego. Ao enviar solicitações HTTPS ou conectar-se por meio de um serviço de proxy baseado em TLS, o malware pode criar um shell reverso, permitindo que comandos sejam passados ​​para o malware ou para que o malware recupere blocos de script ou chaves necessárias para funções específicas. Os servidores de comando e controle podem ser um servidor web dedicado remoto ou podem ser baseados em um ou mais documentos em serviços de nuvem legítimos. Por exemplo, o trojan bancário português Lampion usou um documento de texto do Google Docs como a fonte de uma chave necessária para desbloquear parte de seu código – e deletar o documento agiu como um interruptor de eliminação. Aproveitando o Google Docs, os atores por trás do Lampion conseguiram ocultar as comunicações de controle com o malware e evitar a detecção baseada em reputação usando um host confiável.

Captura de tela do Google Docs
O (agora destruído) documento do Google usado para passar uma chave para o cavalo de Troia bancário Lampion.

O mesmo tipo de conexão pode ser usado por malware para exfiltrar informações confidenciais – transmitindo credenciais de usuário, senhas, cookies e outros dados coletados de volta para o operador do malware. Para ocultar o roubo de dados, o malware pode encapsulá-los em um HTTPS POST baseado em TLS ou exportá-los por meio de uma conexão TLS para uma API de serviço em nuvem, como APIs de “bot” Telegram ou Discord.

SystemBC

Um exemplo de como os invasores usam o TLS de forma maliciosa é o SystemBC, uma ferramenta de comunicação mal-intencionada multifacetada usada em vários ataques de ransomware recentes. As primeiras amostras do SystemBC, detectadas há mais de um ano, atuaram principalmente como um proxy de rede, criando o que equivalia a uma conexão de rede privada virtual para invasores com base na conexão de proxy remoto SOCKS5 criptografada com TLS – fornecendo comunicações ocultas para outro malware. Mas o malware continuou a evoluir e as amostras mais recentes do SystemBC são cavalos de tróia de acesso remoto (RATs) com mais recursos que fornecem uma porta dos fundos persistente para os invasores, uma vez implantados. A versão mais recente do SystemBC pode emitir comandos do Windows, bem como entregar e executar scripts, executáveis ​​maliciosos e bibliotecas de vínculo dinâmico (DLLs) – além de sua função como proxy de rede.

O SystemBC não é totalmente furtivo, entretanto. Há muito tráfego não-TLS e não-Tor gerado pelo SystemBC – sintomático da adição incremental de recursos vista em muitos malwares de longa duração. A amostra que analisamos recentemente tem uma “pulsação” TCP que se conecta pela porta 49630 a um host codificado no próprio SystemBC RAT.

A primeira conexão TLS é uma solicitação HTTPS para um proxy para IPify, uma API que pode ser usada para obter o endereço IP público do sistema infectado. Mas essa solicitação não é enviada na porta 443, a porta HTTPS padrão – em vez disso, é enviada na porta 49271. Esse uso de porta não padrão é o início de um padrão.

CAPTURA DE TELA DO WIRESHARK
SystemBC usando TLS e HTTPS para se conectar ao IPify para obter o endereço público da Internet do sistema.

O SystemBC tenta obter dados sobre o consenso da rede Tor atual, conectando-se a endereços IP codificados com uma solicitação HTTP GET, mas por meio das portas 49272 e 49273. O SystemBC usa as conexões para baixar informações sobre a configuração da rede Tor atual.

O SystemBC coleta dados da rede Tor.

Em seguida, o SystemBC estabelece uma conexão TLS com um gateway Tor selecionado dos dados da rede Tor. Novamente, ele usa outra porta não padrão: 49274. E constrói o circuito Tor para o destino de seu túnel Tor usando dados de diretório coletados por meio da porta 49275 por meio de outra solicitação HTTP. Lá, a progressão das portas sequenciais termina e, na amostra que analisamos, ele tenta buscar outro executável de malware por meio de uma solicitação HTTP aberta na porta padrão.

Fluxograma do comportamento da rede SystemBC

O arquivo recuperado por este exemplo, henos.exe, é outro backdoor que se conecta por TLS na porta padrão (443) a um site que retorna links para canais do Telegram – um sinal de que o ator por trás dessa instância SystemBC está desenvolvendo táticas. É provável que o SystemBC também continue a evoluir, à medida que seus desenvolvedores abordam o uso misto de HTTP e TLS e as portas não-padrão um tanto previsíveis que permitem que o SystemBC tenha suas impressões digitais facilmente identificadas.

AgentTesla

Como o SystemBC, o AgentTesla – um  ladrão de informações que também pode funcionar em alguns casos como um RAT – evoluiu ao longo de sua longa história. Ativo por mais de sete anos, o AgentTesla foi atualizado recentemente com a opção de  usar a rede de anonimato Tor para ocultar o tráfego com TLS. 

Também vimos o TLS usado em um dos downloaders mais recentes do AgentTesla, já que os desenvolvedores usaram serviços da web legítimos para armazenar pedaços de malware codificados no formato base64 no Pastebin e um serviço semelhante chamado Hastebin. O downloader do primeiro estágio tenta evitar a detecção corrigindo a Interface de Software Anti-Malware do Windows (AMSI) para evitar a verificação na memória dos blocos de código baixados à medida que são unidos e decodificados.

Instalador Wireshark screenshot-agenttesla
Uma captura de pacote de tráfego do instalador do AgentTesla tentando se conectar ao Pastebin por TLS.

A  adição do Tor ao próprio AgentTesla  pode ser usada para ocultar comunicações por HTTP. Há também um outro protocolos C2 opcionais em AgentTesla que  que poderia ser TLS protegido por telegrama Bot API, que usa um servidor HTTPS para receber mensagens. No entanto, o desenvolvedor do AgentTesla não implementou comunicações HTTPS no malware (pelo menos por enquanto) – ele falha  ao executar um handshake TLS. O Telegram aceita mensagens HTTP não criptografadas enviadas para sua API de bot.

Dridex

Dridex é outra família de malware de longa duração que teve uma evolução recente substancial. Principalmente um cavalo de Troia bancário, o Dridex foi identificado pela primeira vez em 2011, mas evoluiu substancialmente. Ele pode carregar novas funcionalidades por meio de módulos baixados, de maneira semelhante ao Trojan Trickbot. Os módulos Dridex podem ser baixados juntos em um comprometimento inicial do sistema afetado ou recuperados posteriormente pelo módulo carregador principal. Cada módulo é responsável por executar funções específicas: roubo de credenciais, exfiltração de dados de cookies do navegador ou certificados de segurança, registro de pressionamentos de tecla ou captura de tela.

O carregador do Dridex foi atualizado para ocultar as comunicações, encapsulando-as com TLS. Ele usa HTTPS na porta 443 para baixar módulos adicionais e exfiltrar os dados coletados para o servidor C2. Os dados filtrados também podem ser criptografados com RC4 para ocultá-los e protegê-los ainda mais. O Dridex também tem uma infraestrutura resiliente de servidores de comando e controle (C2), permitindo que o malware instalado faça failover para um backup se seu servidor C2 original cair.

Essas atualizações tornaram o Dridex uma ameaça contínua, e os carregadores Dridex estão entre as famílias mais comuns de malware detectados usando TLS – ofuscados apenas pelo próximo grupo de ameaças em nossa galeria de TLS rogues: ferramentas de “segurança ofensiva” prontas para uso, reutilizadas por cibercriminosos.

Metasploit e Cobalt Strike

Ferramentas de segurança ofensivas há muito tempo são usadas por agentes mal-intencionados e também por profissionais de segurança. Essas ferramentas comerciais e de código aberto, incluindo os kits de ferramentas modulares Cobalt Strike e Metasploit, foram desenvolvidas para testes de penetração e avaliações de segurança de “equipe vermelha” – mas foram adotadas por grupos de ransomware por sua flexibilidade.

No ano passado, vimos um aumento no uso de ferramentas derivadas de plataformas de segurança ofensivas em ataques de ransomware implantados manualmente , usados ​​por invasores para executar scripts, reunir informações sobre outros sistemas na rede, extrair credenciais adicionais e espalhar ransomware e outro malware.

Um arquivo de configuração Cobalt Strike de um ataque recente do Conti ransomware. O farol Cobalt Strike usou HTTPS e TLS para se comunicar com o servidor C2 no ataque.

Juntos, os beacons Cobalt Strike e os derivados Metasploit “Meterpreter” representaram mais de 1 por cento de todos os malwares detectados usando TLS – um número significativo em comparação com outras famílias importantes de malware.

E todo o resto

Aplicativos potencialmente indesejados (PUAs), especialmente na plataforma macOS, também aproveitam o TLS, geralmente por meio de extensões de navegador que se conectam clandestinamente a servidores C2 para exfiltrar informações e injetar conteúdo em outras páginas da web. Vimos o Bundlore usar TLS para ocultar scripts maliciosos e injetar anúncios e outros conteúdos em páginas da web, sem serem detectados. No geral, descobrimos que mais de 89% das ameaças do macOS com comunicações C2 usavam TLS para ligar para casa ou recuperar código prejudicial adicional.

Existem muitas outras ameaças à privacidade e à segurança à espreita no tráfego TLS, além de malware e PUAs. As campanhas de phishing dependem cada vez mais de sites com certificados TLS – registrados com um nome de domínio enganoso ou fornecidos por um provedor de serviços em nuvem. Os ataques de phishing do Formulários do Google podem parecer fáceis de detectar, mas os usuários treinados para “procurar o cadeado” ao lado dos endereços da web em seus navegadores podem digitar casualmente seus dados e credenciais de identificação pessoal.

Mesmo com a fonte Comic Sans e o URL do Google Forms, alguns ainda podem cair nesse phishing.

Análise de tráfego

Tudo isso representa um aumento de mais de 100 por cento nas comunicações de malware com base em TLS desde 2020. E essa é uma estimativa conservadora, pois se baseia exclusivamente no que poderíamos identificar por meio de análises de telemetria e dados de host.

Como observamos, alguns usam o TLS em vez de portas IP não padrão, tornando impossível uma avaliação totalmente precisa do uso do TLS sem uma análise mais profunda dos pacotes de suas comunicações. Portanto, as estatísticas apresentadas neste relatório não refletem toda a gama de comunicações maliciosas baseadas em TLS – e as organizações não devem confiar apenas nos números de porta relacionados às comunicações para identificar o tráfego malicioso em potencial. O TLS pode ser implementado em qualquer porta IP atribuível e, após o handshake inicial, ele se parece com qualquer outro tráfego de aplicativo TCP.

Mesmo assim, a tendência mais preocupante que observamos é o uso de nuvem comercial e serviços da Web como parte da implantação, comando e controle de malware. O abuso de plataformas de comunicação legítimas por autores de malware lhes dá o benefício de comunicações criptografadas fornecidas pelo Google Docs, Discord, Telegram, Pastebin e outros – e, em alguns casos, eles também se beneficiam da reputação de “segurança” dessas plataformas.

Também vemos o uso de ferramentas de segurança ofensivas prontas para uso e outras ferramentas prontas e interfaces de programação de aplicativos que tornam o uso de comunicações baseadas em TLS mais acessível e continua a crescer. Os mesmos serviços e tecnologias que tornaram a obtenção de certificados TLS e a configuração de sites HTTPS muito mais simples para pequenas organizações e indivíduos também tornaram mais fácil para os agentes mal-intencionados se misturarem ao tráfego legítimo da Internet e reduziram drasticamente o trabalho necessário para alternar ou replicar frequentemente Infraestrutura C2.

Todos esses fatores tornam a defesa contra ataques de malware muito mais difícil. Sem uma defesa profunda, as organizações podem ter cada vez menos probabilidade de detectar ameaças na rede antes de serem implantadas por invasores.

A SophosLabs GOSTARIA DE AGRADECER A SURIYA NATARAJAN, ANAND AIJAN, MICHAEL WOOD, SIVAGNANAM GN, MARKEL PICADO E ANDREW BRANDT POR SUAS CONTRIBUIÇÕES PARA ESTE RELATÓRIO.

do original em: https://news.sophos.com/en-us/2021/04/21/nearly-half-of-malware-now-use-tls-to-conceal-communications/?cmp=30728

Gostou? Compartilhe:

Deixe um comentário