Sodin: el ransomware que se introduce mediante los MSP

43 views

A finales de marzo, cuando escribimos sobre el ataque del ransomware GandCrab a los clientes de proveedores de servicios gestionados (MSP por sus siglas en inglés), ya imaginamos que no se trataría de un hecho aislado. Los proveedores de servicios gestionados son un objetivo tan tentador que los ciberdelincuentes no podrían ignorarlo.

Y, al parecer, estábamos en lo cierto. En abril, el ransomware llamado Sodin llamó la atención de nuestros expertos. A diferencia de los demás, utilizó las brechas en los sistemas de seguridad de los MSP y aprovechó una vulnerabilidad en la plataforma Oracle WebLogic. Además, normalmente el ransomware requiere la intervención del usuario en algún momento (por ejemplo, a veces la víctima debe lanzar un archivo ubicado en un correo electrónico de phishing), pero en este caso no es necesaria su participación.

Los métodos de distribución de Sodin

Para difundir el malware a través de WebLogic, los atacantes utilizaron la vulnerabilidad CVE-2019-2725 para ejecutar un comando de PowerShell en un servidor vulnerable de Oracle WebLogic. Esto les permitió cargar un dropper en el servidor, que posteriormente instaló la carga: el ransomwareSodin. Los parches que solucionaban este error se lanzaron en abril, pero a finales de junio se descubrió una vulnerabilidad similar: CVE-2019-2729.

En los ataques que utilizan a los MSP, Sodin se introduce en los dispositivos de los usuarios de diversas formas. Los usuarios de al menos 3 proveedores ya han sufrido las consecuencias de este troyano. Según este artículo de DarkReading, en algunos casos los atacantes utilizaron las consolas de acceso en remoto Webroot y Kaseya para enviar el troyano. En otros casos, según se afirma en Reddit, los atacantes penetraron en la infraestructura de los MSP mediante una conexión RDP, elevaron sus privilegios, desactivaron las soluciones de seguridad y las copias de seguridad y descargaron el ransomware en los ordenadores del cliente.

Qué deberían hacer los proveedores de servicios

En primer lugar, deberían tomarse muy en serio el almacenamiento de las contraseñas utilizadas para el acceso en remoto y utilizar la autentificación de doble factor siempre que sea posible. Las consolas de acceso en remoto, Kaseya y Webroot, admiten este tipo de autentificación. Además, después del incidente, los desarrolladores han comenzado a exigir su uso. Como podemos comprobar, los atacantes que distribuyen Sodin no esperan a la oportunidad perfecta, sino que buscan deliberadamente varios métodos para distribuir el malware mediante los proveedores de servicios gestionados. Por ello, es necesario vigilar todas las herramientas que se utilizan en este ámbito. Como comentamos siempre, el acceso RDP debería utilizarse como último recurso.

Los MSP y, sobre todo, aquellos que ofrecen servicios de ciberseguridad, deberían tomarse aún más en serio aún la protección de su infraestructura que la de su cliente. Y esto es lo que ofrece Kaspersky a los MSP para su protección y la de sus clientes.

Qué deberían hacer el resto de las compañías

Evidentemente, actualizar el software es de vital importancia. Que el malware se introduzca en tu infraestructura mediante vulnerabilidades descubiertas y cerradas hace meses puede ser un ejemplo muy vergonzoso de un error que podría haberse evitado.

Las empresas que utilizan Oracle WebLogic deberían consultar en primer lugar las recomendaciones de seguridad de Oracle para las vulnerabilidades CVE-2019-2725 y CVE-2019-2729.

Además, también es aconsejable utilizar soluciones de seguridad de confianza con subsistemas que puedan detectar ransomware y proteger las estaciones de trabajo.

Leave your comments

Post comment as a guest

0
terms and condition.

Comments