No final de março, escrevemos sobre o ataque ao clientes de MSPs pelo ransomware GandCrab, achamos improvável que fosse um caso isolado. Provedores de serviços gerenciados são muito tentadores para serem ignorados por cibercriminosos.
Infelizmente, parece que estávamos certos. Em abril, o ransomware Sodin chamou a atenção de nossos especialistas. Ao contrário dos outros, além de usar as falhas nos sistemas de segurança dos MSPs, explorou também as vulnerabilidades da plataforma Oracle WebLogic. Inclusive, na maioria das vezes, o ransomware precisa de alguma ação da vítima em algum momento (por exemplo, iniciar um arquivo localizado em um e-mail de phishing), mas neste caso não houve necessidade.
Neste artigo do Securelist, você encontrará mais informações técnicas sobre o ransomware. Do nosso ponto de vista, a coisa mais interessante sobre ele é a forma de distribuição.
Os métodos de distribuição do Sodin
Para espalhar o malware pelo WebLogic, os cibercriminosos exploraram a vulnerabilidade CVE-2019-2725 para executar um comando do PowerShell em um servidor vulnerável do Oracle WebLogic. Isso permitiu que carregassem um dropper no servidor, que posteriormente instalou a carga: o Sodin. As patches que solucionaram esse erro foram lançadas em abril, mas no final de junho uma vulnerabilidade semelhante foi descoberta: CVE-2019-2729.
Nos ataques que usam MSPs, o Sodin é introduzido nos dispositivos dos usuários de várias maneiras. Usuários de pelo menos três provedores já sofreram as consequências da invasão deste Trojan. De acordo com este artigo do DarkReading, em alguns casos, os cibercriminosos usaram os consoles de acesso remoto Webroot e Kaseya para enviar o Trojan. Em outros casos, segundo relato no Reddit, os golpistas penetraram na infraestrutura do MSP por meio de uma conexão RDP, aumentaram seus privilégios, desativaram as soluções de segurança e cópias de backups e baixaram o ransomware para os computadores dos clientes.
O que deveriam fazer os provedores de serviços?
Primeiro, o armazenamento de senhas usadas para acesso remoto deve ser levado muito a sério e a autenticação de dois fatores deve ser usada sempre que possível. Os consoles de acesso remoto Kaseya e Webroot suportam esse tipo de autenticação. Além disso, após o incidente, os desenvolvedores começaram a exigir seu uso. Como podemos ver, os cibercriminosos que distribuem Sodin não esperam pela oportunidade perfeita, mas deliberadamente buscam vários métodos para distribuir o malware por meio dos provedores de serviços gerenciados. Portanto, é necessário monitorar todas as ferramentas utilizadas neste âmbito. Como sempre dissemos, o acesso RDP deve ser usado como último recurso.
Os MSPs e, acima de tudo, aqueles que oferecem serviços de cibersegurança, devem levar ainda mais a sério a proteção de sua infraestrutura do que a de seus clientes. E é isso que a Kaspersky oferece para a proteção de seus MSPs e de seus clientes.
O que as demais companhias poderiam fazer?
Obviamente, atualizar o software é de suma importância. Uma invasão por malware em sua infraestrutura por meio de vulnerabilidades conhecidas e resolvidas há meses pode ser um caso muito embaraçoso, já que poderia ter sido evitado.
As empresas que usam o Oracle WebLogic devem primeiro consultar as recomendações de segurança da Oracle para as vulnerabilidades CVE-2019-2725 e CVE-2019-2729.
Além disso, é fundamental utilizar [KESB Placeholder] soluções de segurança confiáveis [KESB placeholders] com subsistemas de detecção de ransomware e de proteção para as estações de trabalho.