¿Estás listo para la etapa 2 de los ataques Log4Shell?

Los maremotos del recién descubierto ataque de día cero Log4Shell aún no se han determinado. Muchas organizaciones se han apresurado a parchear sus servidores, haciéndolos inmunes a los ataques masivos que se informaron. Sin embargo, aplicar parches a sus servidores por sí solo no es suficiente para garantizar que este superficie de ataque ha sido cubierto. Si bien ejecutar la versión actualizada de log4j protege contra futuros ataques, también se debe abordar la posibilidad de que algunos servidores hayan sido comprometidos. antes al parche. En este artículo, explicaremos la viabilidad de este escenario y realizaremos un seguimiento con recomendaciones prácticas para mitigarlo de forma proactiva.

Resumen de actividades de Log4Shell-In-the-Wild

Apache Log4j es una utilidad de registro de código abierto basada en Java ampliamente utilizada por aplicaciones empresariales. Los informes iniciales sobre Log4Shell (CVE-2021-44228) datan del 9 de diciembre. Estos informes fueron seguidos rápidamente por un desarrollo extremadamente rápido de nuevas variantes de exploit y se introdujeron rápidamente nuevas variaciones del exploit original: más de 60 en menos de 24 horas.[ 1 ] Además, solo en estas 24 horas, han aumentado los ataques a organizaciones de todo el mundo, y varios proveedores de seguridad informaron que una gran parte de sus clientes fueron atacados por piratas informáticos que intentaban explotar la vulnerabilidad. [ 2 ] Actualmente, el exploit se integra rápidamente en el arsenal de malware común.[ 3 ] y también se informa que lo utilizan grupos avanzados de ataque de estados-nación.

Suponer infracción: atacado hasta que se demuestre lo contrario

El enorme volumen de estos ataques presenta un desafío para cualquier interesado en la seguridad que haya parcheado sus servidores vulnerables. El rápido desarrollo y el ritmo de uso de la explotación de la vulnerabilidad significan que existe al menos una probabilidad viable de que sus servidores hayan sido atacados por la vulnerabilidad antes de que se aplicara el parche. Creemos firmemente que la mejor práctica de seguridad, en este caso, es actuar como si sus servidores hubieran sido comprometidos hasta que esta amenaza sea refutada de manera confiable. Repasemos las diversas implicaciones de tal compromiso para comprender mejor cómo enfrentar esta amenaza de manera eficiente.

Posibles escenarios de amenazas de etapa 2 luego de un compromiso silencioso

Pasando desapercibido hasta que sea el momento adecuado

Log4Shell por sí solo permite a los atacantes establecer un punto de apoyo inicial en su entorno. Este punto de apoyo no es el objetivo de los atacantes sino más bien una etapa previa esencial. Eso significa que si los atacantes realmente explotaron la vulnerabilidad y obtuvieron presencia en uno de sus servidores web, no hay ningún incentivo para que llamen la atención. Más bien, es más probable que operen a un nivel bajo y lento, recopilando credenciales adicionales y tal vez expandiéndose a máquinas adicionales en su red antes de intentar ejecutar el objetivo real del ataque. A juzgar por los exploits comunes que vemos, hay muchas posibilidades de que este objetivo sea un ransomware ataque que cerraría sus operaciones, pero también puede ser el robo de su propiedad intelectual o PII de sus empleados o clientes.

Vender el acceso

Alternativamente, el atacante no puede utilizar el acceso a la red por sí mismo. Más bien, podrían vender el acceso a su servidor a un tercero en la web oscura.

Resultado final: exposición al movimiento lateral y propagación de ransomware

De una forma u otra, es muy posible que haya atacantes con las claves de su reino, es decir, los nombres de usuario y las credenciales de sus usuarios estándar y administradores. Esto es malo porque si bien el compromiso inicial daña una sola máquina, es el movimiento lateral parte que convierte un evento local en un riesgo para toda la empresa. Las credenciales comprometidas permiten a los atacantes hacer precisamente eso.

El efecto navideño

No olvidemos que los atacantes suelen optar por los días festivos y los fines de semana. Las próximas vacaciones de Navidad son un momento especialmente malo para que las credenciales de sus empleados caigan en las manos equivocadas. Creemos que los atacantes de ambos tipos descritos anteriormente permanecerán en silencio mientras tanto, esperando el momento adecuado: la Navidad puede ser el momento perfecto.

Silverfort Recomendaciones de mejores prácticas para credenciales comprometidas

A la luz de todo lo anterior, hemos compilado un conjunto de mejores prácticas prácticas para enfrentar de manera proactiva la posibilidad de que algunos de sus servidores hayan sido y tal vez todavía estén comprometidos por atacantes que aprovechó la vulnerabilidad Log4Shell:

• Parche de extremo a extremo
  • Asegúrese de que todos los sistemas vulnerables estén parcheados, prestando especial atención a sus servidores conectados a Internet.

• • Aísle las aplicaciones que no puede parchear tanto a nivel de red como en la capa de identidad.

• Prevenir la capacidad de los atacantes para utilizar el Credenciales comprometidas para un mayor acceso malicioso

• • Exigir MFA para todas las cuentas de administrador para todos los recursos del entorno. Asegúrese también de que la protección MFA se aplique a las interfaces de acceso, incluidas las utilidades de líneas de comando, como PsExec, PowerShell, etc., y no solo para RDP y el inicio de sesión en el escritorio.
  • Restringir cuentas de servicio operar únicamente desde computadoras permitidas. Debe basar esto en el comportamiento predecible y repetitivo de estas cuentas.
  • Supervise de cerca su entorno para detectar eventos sospechosos y maliciosos, como un aumento en las solicitudes de acceso simultáneo de un solo usuario o cualquier otra desviación de la actividad estándar de su cuenta de usuario.

Seguir estas recomendaciones aumentará en gran medida su resistencia a un compromiso basado en Log4Shell preexistente y anulará la capacidad del atacante de aprovechar sus credenciales robadas para obtener más acceso malicioso.

El Silverfort La plataforma Unified Identity Protection permite a sus usuarios ampliar Autenticación basada en riesgos y MFA a cualquier usuario, servicio o sistema, brindando protección proactiva contra ataques basados ​​en identidad que utilizan credenciales comprometidas para acceder a recursos específicos. Esto incluye protección MFA de extremo a extremo, así como monitoreo continuo de todas las autenticaciones tanto locales como en la nube. Aprender más acerca de Silverfort esta página.