Petya / NotPetya, esa es la cuestión

Si hace poco más de un mes el mundo quedaba suspendido por el ataque del ransomware WannaCry, la historia se ha vuelto a repetir.

Poco después del mediodía de ayer llegaban las primeras informaciones acerca de la posible infección de varias empresas y organismos gubernamentales por una variante del ransomware Petya. Entre los países más afectados se encuentran Ucrania, Rusia, Polonia o Italia, aunque todo apunta a que empresas españolas también han resultado afectadas.

 

Desde Ucrania se lo tomaban con humor

Según informa FireEye, todo parece apuntar a que el vector de infección de esta campaña es la actualización de la suite MeDoc, un software de contabilidad de uso recurrente en compañías ucranianas (algo así como un Contaplus).

Algunas fuentes no confirmadas  apuntan a posibles correos de phishing en los que te instaban a actualizar a versiones troyanizadas de este software de contabilidad (sería este sample https://www.virustotal.com/es/file/fe2e5d0543b4c8769e401ec216d78a5a3547dfd426fd47e097df04a5f7d6d206/analysis/):

 

 

Incluso hay quien que ha encontrado una posible relación entre Maersk y el MeDoc ya que en una oferta de trabajo se pedía ese conocimiento específico. Por nuestra parte, hemos confirmado que la mayoría de multinacionales afectadas tienen alguna sede en Ucrania.

A diferencia de WannaCry, el cual escaneaba Internet para la posterior explotación de EternalBlue, este nuevo ransomware utiliza el exploit SMB únicamente en parte de la infección, haciendo uso de MimiKatz para la extracción de credenciales del proceso lsass.exe, y WMIC o PSExec para el movimiento lateral, resultando de ese modo inocuo el parche de seguridad MS-17-010. Es decir, aunque un equipo esté completamente parcheado podría infectarse vía propagación.

Además, el cifrado del sistema no se produce de manera inmediata, sino que espera un intervalo aleatorio entre diez y sesenta minutos para el reinicio del sistema, programado mediante schtasks y shutdown.exe. Tras el reinicio se cifra la tabla MFT en las particiones NTFS, sobreescribiendo de ese modo el MBR con un loader donde se incluye la nota del ransomware.

También existe conflicto entorno al nombre del malware originador de la infección. En un primer momento, dadas las similitudes con la amenaza que le precede, se le otorgó la nomenclatura WannaCry2, apodo rápidamente sustituido por “variante de Petya”. Conforme las horas iban pasando, numerosos investigadores refutaron que la heurística del ransomware que nos ocupa tuviera relación con Petya y, ante la falta de nombre mejor, se le calificó como NotPetya. Incluso la firma antivirus Kaspersky, ante la duda, lo ha llamado “Schroedinger’s Pet(ya)”.

En cuanto a la existencia de una posible vacuna, diferentes informaciones apuntan hacia que la creación de un fichero perfc.dat en la carpeta C:\Windows bloquearía la infección de ese equipo, aunque no la propagación.

A pesar de que diferentes informaciones relacionaban la vulnerabilidad CVE-2017-0199 con Petya/NotPetya, todo apunta a que dichos documentos de Office pertenecen a otra campaña, aunque recomendamos obviamente estar actualizados y prevenidos ante cualquier explotación de cualquier CVE. Por ejemplo, este junio Microsoft publicaba una serie de actualizaciones de seguridad muy críticas, y que pronosticamos que en breve los ‘malos’ van a aprovechar para nuevas oleadas de malware (si no lo están haciendo ya), en particular la CVE-2017-8543 y CVE-2017-8464.

La información más oficial que hemos visto proviene del CERT de Ucrania en el que informan de un posible correo malicioso:

Como hemos indicado, explotaría la vulnerabilidad CVE-2017-0199.

MEDIDAS PREVENTIVAS GENERALES

  • Como medida preventiva se recomienda la actualización de todos los parches de seguridad pendientes y mantener los antivirus y demás sistemas de seguridad actualizados.
  • Aunque el equipo víctima lo utilice un usuario sin privilegios, si en ese equipo ha iniciado sesión un administrador para realizar tareas de mantenimiento y el equipo no se ha reiniciado, el malware podría ser capaz de obtener esas credenciales con privilegios de administración y propagarse de forma rápida al resto de equipos de la red. Recomendamos que tras las tareas de administración se reinicien los equipos para evitar esta vía de propagación. En el caso de que el administrador se conecte al equipo que administra a través de Escritorio Remoto, se recomienda configurarlo de tal manera que el administrador no deje sus credenciales en el equipo remoto. Nuestro compañero Roberto Amado nos explica esto con más detalle a continuación:

Existen dos formas de autenticarse en Windows: “Interactiva” y “Network logon”.

  • Interactiva: más peligrosa porque deja cacheados en la máquina remota con posibles credenciales de acceso (TGT ticket kerberos, NTLM Hash o lo que es peor, el WDIGEST que es el pass en claro). Ejemplos son: RDP, autenticación física local, VNC, CITRIX, RunAS o Psexec.
  • Network logon: se utiliza un TGS de kerberos o el resultado de un reto cifrado con el hash NTLM/LM/WDIGEST, pero a diferencia del anterior nunca se almacena en la maquina remota ningún tipo de credenciales. Ejemplos son: powershell, WMIC, SMB (cuando montamos una unidad o accedemos a un recurso compartido). Si en este proceso se captura la información intercambiada aparece el hash NETNTLM o NETLM, ya que es el resultado del cifrado del reto.

Lo que hace “mstsc /restrictedAdmin” es utilizar “Network logon” para hacer un “Interactive logon”, mucho más seguro pero que abre un nuevo vector de ataque y es que si se tiene el hash NTLM de un usuario podemos hacer una conexión RDP autenticando con NetworkLogon. Lo que recomendamos es siempre utilizar “Network Logon” a los administradores ya que no deja cacheadas las credenciales en el servidor remoto.

Por tanto, os sugerimos lo siguiente:

  • Utilizar “mstsc /restrictedAdmin” que no guarda las credenciales de usuario en la máquina remota (solo Windows 8.1 y 2012 Server), solo el NTLM y el TGT de kerberos de la máquina (no del usuario).
  • Deshabilitar WDIGEST (pass en claro), primero ver si impacta en la organización (http://blogs.technet.com/b/srd/archive/2014/06/05/an-overview-of-kb2871997.aspx) y aplicar el siguiente parche (https://support.microsoft.com/en-us/kb/2871997)
  • Utilizar “Protected User Group” para los usuarios “Admin del dominio”. Usa solo tickets kerberos para autenticarse y no NTLM o WDIGEST cacheado en los equipos remotos. Ojo, sí que deja el ticket TGT de kerberos durante 4 horas por lo que es importante usar  “mstsc /restrictedAdmin”.

Más información sobre esto en:

NOTA: en Kerberos hay dos tipos de tokens TGT que se da después de autenticarse y es el utilizado para generar los subsecuentes tickets de servicio TGS, de esta manera no se le vuelve a pedir el pass al usuario. Si se tiene el TGT se puede hacer passthetiket.

LSASS.exe soporta la autenticación de lo que se llaman packages (kerberos, NTLM, WDIGEST o LM):

  • Kerberos(kerberos.dll)
  • NTLM(msv1_0.dll)
  • Digest Authentication (wdigest.dll)

 

  • Recordamos que no se deben reutilizar contraseñas para diferentes servicios, y no se deben compartir contraseñas entre varios usuarios. Además, dadas las capacidades de propagación que tiene este ransomware, recomendamos restringir al mínimo necesario el uso de cuentas especiales de administración para, en el caso de infección, limitar la propagación del ransomware en la medida de lo posible.

Antes de terminar el post, y dejaros algunos enlaces de interés, queremos destacar que Microsoft acaba de publicar un artículo muy interesante y completo sobre este ataque. https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/

Enlaces de interés

Referencias

(N.d.E. Este post se ha hecho en colaboración entre Maite Moreno y Joan Soriano)

Comments

  1. Gran articulo dada la sobre informacion que ofrecian los medios! Leyendo su articulo y ya que lo mencionan, podria la CVE 2017-8464 ser consecuencia de la liberacion de documentos y herramientas de la CIA por parte de Wikileaks? Mi pregunta viene porque una de las herramientas liberadas tambien usa una vulnerabilidad basada en lnk.

  2. Gracias por tu comentario 0x!

    No tenemos constancia de que se esté explotando la CVE 2017-8464 ni tampoco hemos profundizado en la herramienta que comentas de la CIA. No obstante, ninguna teoría es descabellada así que, podría ser… :)

Deja un comentario