Alerta sobre o problema na entrada da empresa

Hoje é sexta-feira, são 5 da tarde no Brasil e 9 da noite em Oslo, capital da Noruega. Na sede da Norsk Hydro, empresa com mais de 100 anos e 35 mil funcionários, tem um monte de gente trabalhando (embora isso não seja um hábito nos países nórdicos). Essas pessoas estão tentando desatar o nó causado pelo ransomware que atacou a empresa na terça-feira passada. 

Já são quatro dias de batalha e a empresa admite que ainda não é possível determinar quando as operações retornarão à normalidade. Como também é cedo para avaliar os exatos impactos financeiro e operacional. A Hydro é um dos maiores produtores de alumínio do mundo e um impacto em sua produção se reflete na estratégia industrial de muitos países. Inclusive do Brasil. Aqui, a Hydro tem uma operação em Barcarena (PA) chamada Alunorte, onde processa bauxita e produz alumina. Segundo a empresa, a produção da Alunorte não foi prejudicada e ela opera dentro da normalidade.

Ataque direcionado

Gente do mundo inteiro está trabalhando para resolver o problema já que a Hydro decidiu não gastar nenhum centavo de Euro para pagar os criminosos, até porque ela é uma empresa que tem ações na bolsa e não pode se curvar desse jeito ao crime. As primeiras suspeitas indicam que esse ataque foi cuidadosamente planejado para a Norsk Hydro e por isso há policiais noruegueses e da Europol investigando o assunto.

Na minha modesta opinião, o problema não é só da Norsk Hydro. A dimensão dele tem alcance global e deve causar enorme preocupação em todas as corporações, independente do tamanho que tenham.

Nenhum antivírus pegou

O fato de ter sido contaminada pelo ransomware Lockeroga não implica qualquer descuido ou negligência da empresa. Esse mesmo ransomware atacou uma companhia francesa em Janeiro, e ainda não se sabe como ele entrou na Hydro. Mas já é possível afirmar que ele não estava sendo detectado por nenhum antivírus ou qualquer outra solução de proteção de endpoint.

Essa revelação foi feita pelo especialista inglês Kevin Beaumont no dia 8 de Março. Ele capturou uma amostra desse ransomware e enviou ao Virustotal para verificar que solução podia detectá-lo. Descobriu nesse momento que NENHUMA das 67 soluções detectava aquele código. Ele conta que comentou isso no Twitter, que discutiu o assunto com outras pessoas e tentou entrar em contato, sem sucesso, com fabricantes de antivírus para fazer um alerta. Mas não conseguiu, conforme revelou no seu Twitter.

Num artigo que escreveu para o portal Doublepulsar, publicado na manhã de hoje,  ele conta que todos os sistemas atingidos pelo LockerGoga tinham quatro características-chaves: 1) todos rodavam Microsoft Windows; 2) todos os arquivos, incluindo alguns de sistemas, foram criptografados; 3) todas as interfaces de rede nos sistemas foram desabilitadas; e 4) foram alteradas as senhas em todas as contas de usuários locais.

Office 365 salvou

Apesar de os sistemas estarem comprometidos, a empresa continuou se comunicando por e-mail porque utiliza o Office 365 e portanto essa parte não foi afetada. Para comunicação com o público externo foi utilizada a página da empresa no Facebook, já que o seu site ficou fora do ar. A seguir foi levantado um site temporário na nuvem Azure, da Microsoft. Depois, o DNS foi movido para o Cloudflare, para ficar protegido de DDoS.

O certificado digital utilizado para assinar o ransomware, segundo Kevin, havia sido usado para assinar também outros códigos maliciosos. Nesse caso, ele foi emitido para uma empresa que tinha um capital de apenas uma libra. Depois de ser informada desse fato a autoridade certificadora revogou o certificado é claro.

Cópia foi feita pelo AD

Pela análise do especialista inglês, o LockerGoga não tem código apropriado para se reproduzir ou se propagar. Quer dizer que não pode se auto-replicar numa rede como outros ransomwares como o WannaCry ou o Notpetya.

A hipótese de Belmont é que para isso os atacantes buscaram obter credenciais do AD, o Active Directory dos servidores Windows. É possível, segundo ele, que tenham sido usados tarefas ou serviços agendados. Uma vez dentro da rede, ele supõe, seria necessário ter privilégios de administrador de domínio para fazer o ataque. Normalmente, nas empresas e isso é extremamente fácil segundo o especialista, simplesmente pescando logins fora da memória utilizando o software Mimikatz. Ou pegando senhas do Active Directory Group Policy Preferences, que ele supõe estarem nos arquivos XML, “na verdade a ‘carne-de-vaca’ dos Red Teams”.

Como quer que tenha ocorrido, afirma Kevin, os criminosos tinham  a administração do domínio. Estando nessa condição, segundo ele, é possível colocar o executável num local onde todos os sistemas da organização possam alcançá-lo, e com a vantagem de os firewalls das organizações normalmente aceitarem todo o tráfego interno.

Proteção de endpoind

Feito isso, supõe Kevin, o ataque estava resolvido, mas poderia ser bloqueado por qualquer solução de proteção de endpoint. Só que elas não tinham a informação para deter o LockerGoga.

Segundo Kevin Beaumont, uma das possibilidades é também colocar o arquivo num Domain Controller, dentro da pasta de share do NETLOGON, debaixo do SYSVOL, que é replicado dentro de todos os sites de um controlador de domínio. Depois, pode-se usar uma política de grupo (como a criação de tarefas agendadas) para automaticamente iniciar o executável do LockerGoga.

A seguir, qualquer laptop, desktop e servidor conectado ao Active Directory executa o software malicioso, afirma  o especialista.