ACTUALIZACIÓN (mayo de 2022): Hemos fusionado UNC2452 con APT29. La actividad UNC2452 descrita en esta publicación ahora se atribuye a APT29. 

Resumen ejecutivo

• Hemos descubierto una campaña de intrusión global. Estamos rastreando a los actores detrás de esta campaña como UNC2452.
• FireEye descubrió un ataque a la cadena de suministro que troyanizaba las actualizaciones del software comercial SolarWinds Orion para distribuir el malware el cual llamamos SUNBURST.
• La actividad post-compromiso del atacante aprovecha múltiples técnicas para evadir la detección y ocultar su actividad, pero estos esfuerzos también ofrecen algunas oportunidades para la detección.
• La campaña está muy extendida y afecta a organizaciones públicas y privadas de todo el mundo.
• FireEye está lanzando firmas para detectar este actor de amenazas y el ataque a la cadena de suministro “in the wild”. Estos se encuentran en nuestra página pública de GitHub. Los productos y servicios de FireEye pueden ayudar a los clientes a detectar y bloquear este ataque.

Resumen

FireEye ha descubierto una campaña generalizada, la cual estamos rastreando como UNC2452. Los actores detrás de esta campaña obtuvieron acceso a numerosas organizaciones públicas y privadas de todo el mundo. Obtuvieron acceso a las víctimas por medio de actualizaciones con troyanos del software de administración y monitoreo de TI Orion de SolarWind. Esta campaña puede haber comenzado en la primavera de 2020 y actualmente está en curso. La actividad post-compromiso, después de este compromiso de la cadena de suministro, ha incluido el movimiento lateral y el robo de datos. La campaña es obra de un actor altamente calificado y la operación se llevó a cabo con una importante seguridad operativa.

Puerta trasera SUNBURST

SolarWinds.Orion.Core.BusinessLayer.dll es un componente firmado digitalmente de SolarWinds del marco de software de Orion el cual contiene una puerta trasera que se comunica por medio de HTTP con servidores de terceros. Estamos rastreando la versión troyana de este complemento de SolarWinds Orion como SUNBURST.

Después de un período inactivo inicial de hasta dos semanas, recupera y ejecuta comandos, llamados "Jobs", los cuales incluyen la capacidad de transferir archivos, ejecutar archivos, perfilar el sistema, reiniciar la máquina y deshabilitar los servicios del sistema. El malware enmascara su tráfico de red como el protocolo del Programa de mejora de Orion (OIP) y almacena los resultados del reconocimiento dentro de archivos de configuración de complementos legítimos, lo que le permite mezclarse con la actividad legítima de SolarWinds. La puerta trasera utiliza múltiples listas ofuscadas de bloqueo con el fin de identificar herramientas forenses y antivirus las cuales se ejecutan como procesos, servicios y controladores.

Ilustración 1: Firma digital de SolarWinds en software con puerta trasera

Varias actualizaciones con troyanos se firmaron digitalmente entre marzo y mayo de 2020 y se publicaron en el sitio web de actualizaciones de SolarWinds, las cuales incluyen:

• hxxps://downloads.solarwinds[.]com/solarwinds/CatalogResources/Core/2019.4/2019.4.5220.20574/SolarWinds-Core-v2019.4.5220-Hotfix5.msp

El archivo de actualización con troyanos es un archivo estándar de Windows Installer Patch el cual incluye recursos comprimidos asociados con la actualización, incluido el componente con troyanos SolarWinds.Orion.Core.BusinessLayer.dll. Una vez instalada la actualización, el archivo DLL malicioso será cargado por SolarWinds.BusinessLayerHost.exe o SolarWinds.BusinessLayerHostx64.exe legítimo (según la configuración del sistema). Después de un período de inactividad de hasta dos semanas, el malware intentará resolver un subdominio de avsvmcloud[.]com. La respuesta DNS devolverá un registro CNAME que apunta a un dominio de comando y control (C2). El tráfico C2, a los dominios maliciosos, está diseñado para imitar las comunicaciones normales API de SolarWinds. La lista de infraestructura maliciosa conocida está disponible en la página GitHub de FireEye.

Víctimas en todo el mundo en múltiples verticales

FireEye ha detectado esta actividad en múltiples entidades en todo el mundo. Las víctimas han incluido entidades gubernamentales, de consultoría, tecnología, telecomunicaciones y extractivas en América del Norte, Europa, Asia y Medio Oriente. Anticipamos que existen víctimas adicionales en otros países y verticales. FireEye ha notificado a todas las entidades que sabemos que están afectadas.

Actividad post-compromiso y oportunidades de detección

Actualmente estamos rastreando el compromiso de la cadena de suministro de software y la actividad posterior a la intrusión relacionada como UNC2452. Después de obtener el acceso inicial, este grupo utiliza una variedad de técnicas para disfrazar sus operaciones mientras se mueven lateralmente (Figura 2). Este actor prefiere mantener una huella ligera de malware, en lugar de preferir credenciales legítimas y acceso remoto para acceder al entorno de la víctima.

Ilustración 2: Tácticas post-compromiso

Esta sección detallará las técnicas notables y delineará las oportunidades potenciales para la detección.

Malware TEARDROP y BEACON utilizado

Se han recuperado múltiples muestras de SUNBURST, entregando diferentes cargas útiles. En al menos un caso, los atacantes desplegaron un dropper, de solo memoria, nunca antes visto el cual hemos denominado TEARDROP para desplegar Cobalt Strike BEACON.

TEARDROP es un dropper, solo de memoria, el cual se ejecuta como un servicio, genera un hilo y lee el archivo "gracious_truth.jpg" el cual, probablemente, tenga un encabezado JPG falso. A continuación, este comprueba si existe HKU\SOFTWARE\Microsoft\CTF, decodifica una carga embebida mediante un algoritmo personalizado XOR variable y carga manualmente en la memoria una carga embebida mediante un formato personalizado de archivo similar a PE. TEARDROP no tiene superposición de código con ningún malware visto anteriormente. Creemos que esto se utilizó para ejecutar un Cobalt Strike BEACON personalizado.

Mitigación: FireEye ha proporcionado dos reglas de Yara, disponibles en nuestro GitHub, para detectar TEARDROP. Los defensores deben buscar las siguientes alertas de FireEye HX: MalwareGuard y WindowsDefender:

Información procesable

Entradas de bitácora de protección contra explotaciones de Windows Defender: (Microsoft-Windows-Security-Mitigations/KernelMode event ID 12)

Se habría bloqueado el proceso "\Device\HarddiskVolume2\Windows\System32\svchost.exe" (PID XXXXX) para que no pudiese cargar el binario no firmado por Microsoft ‘\Windows\SysWOW64\NetSetupSvc.dll’.

Los nombres de host del atacante coinciden con el entorno de la víctima

El actor establece los nombres de host en su infraestructura de comando y control para que coincidan con un nombre legítimo del host el cual se encuentra en el entorno de la víctima. Esto permite que el adversario se mezcle con el entorno, evite sospechas y evada la detección.

Oportunidad de detección

La infraestructura del atacante filtra su nombre de host configurado en los certificados SSL RDP, el cual es identificable en los datos de escaneo de todo Internet. Esto presenta una oportunidad de detección para los defensores: La consulta de las fuentes de datos de escaneo de todo Internet, para los nombres de host de una organización, puede descubrir direcciones IP maliciosas las cuales pueden estar haciéndose pasar por la organización. (Nota: El historial de escaneo de IP, a menudo, muestra IP que cambian entre los nombres de host predeterminados (WIN-*) y los nombres de host de la víctima) Cotejar la lista de IP identificadas en los datos de escaneo de Internet con las bitácoras de acceso remoto puede identificar evidencia de este actor en un entorno. Es probable que exista una sola cuenta por dirección IP.

Direcciones IP ubicadas en el país de la víctima

La elección de direcciones IP del atacante también se optimizó para evadir la detección. El atacante utilizó, principalmente, solo direcciones IP que se originaban en el mismo país que la víctima, aprovechando los servidores privados virtuales.

Oportunidad de detección

Esto también presenta algunas oportunidades de detección, ya que la geolocalización de las direcciones IP utilizadas para el acceso remoto puede mostrar una tasa de viaje imposible si el usuario legítimo y el atacante utilizan una cuenta comprometida desde direcciones IP dispares. El atacante utilizó varias direcciones IP, por proveedor de VPS, por lo que una vez que se identifica un inicio de sesión malicioso de un ASN inusual, observar todos los inicios de sesión de ese ASN puede ayudar a detectar actividad maliciosa adicional. Esto se puede hacer junto con la base inicial y la normalización de los ASN utilizados para el acceso remoto legítimo con el fin de ayudar a identificar actividades sospechosas.

Movimiento lateral utilizando diferentes credenciales

Una vez que el atacante obtuvo acceso a la red, con credenciales comprometidas, se movió lateralmente utilizando múltiples credenciales diferentes. Las credenciales utilizadas para el movimiento lateral siempre fueron diferentes a las utilizadas para el acceso remoto.

Oportunidad de detección

Las organizaciones pueden utilizar el módulo LogonTracker de HX para graficar toda la actividad de inicio de sesión y analizar los sistemas que muestran una relación de uno a muchos entre los sistemas de origen y las cuentas. Esto descubrirá cualquier sistema único que se autentique en múltiples sistemas con múltiples cuentas, una ocurrencia relativamente poco común durante las operaciones comerciales normales.

Reemplazo de archivos temporales y modificación de tareas temporales

El atacante utilizó una técnica de reemplazo de archivos temporales para ejecutar utilerías de forma remota: Reemplazó una utilería legítima con la suya, ejecutó su carga útil y, posteriormente, restauró el archivo original legítimo. De manera similar, manipularon las tareas programadas actualizando una tarea legítima existente para ejecutar sus herramientas y, posteriormente, devolviendo la tarea programada a su configuración original. Rutinariamente eliminaban sus herramientas, incluida la eliminación de puertas traseras una vez que se lograba el acceso remoto legítimo.

Oportunidad de detección

Los defensores pueden examinar las bitácoras de las sesiones SMB las cuales muestran el acceso a directorios legítimos y seguir un patrón delete-create-execute-delete-create en un corto período de tiempo. Además, los defensores pueden monitorear las tareas programadas existentes en busca de actualizaciones temporales, utilizando análisis de frecuencia para identificar modificaciones anómalas de tareas. Las tareas también se pueden monitorear para observar tareas legítimas de Windows las cuales ejecutan archivos binarios nuevos o desconocidos.

La actividad post-compromiso de esta campaña se llevó a cabo con un gran respeto por la seguridad operativa, en muchos casos aprovechando la infraestructura dedicada por intrusión. Esta es una de las mejores medidas de seguridad operativa que FireEye ha observado en un ciberataque, enfocándose en la evasión y aprovechando la confianza inherente. Sin embargo, se puede detectar por medio de una defensa persistente.

Análisis detallado de malware

SolarWinds.Orion.Core.BusinessLayer.dll (b91ce2fa41029f6955bff20079468448) es un componente de complemento firmado por SolarWinds del marco de software de Orion el cual contiene una puerta trasera ofuscada que se comunica por medio de HTTP con servidores de terceros. Después de un período inactivo inicial de hasta dos semanas, recupera y ejecuta comandos, llamados "Jobs", los cuales incluyen la capacidad de transferir y ejecutar archivos, perfilar el sistema y deshabilitar los servicios del sistema. El comportamiento de la puerta trasera y el protocolo de red se combinan con la actividad legítima de SolarWinds, por ejemplo, haciéndose pasar por el protocolo del Programa de mejora de Orion (OIP) y almacenando los resultados del reconocimiento dentro de los archivos de configuración del complemento. La puerta trasera utiliza múltiples listas de bloqueo para identificar herramientas forenses y antivirus por medio de procesos, servicios y controladores.

Capacidades únicas

• El algoritmo de generación de nombre de dominio (DGA) del subdominio se realiza para variar las solicitudes de DNS
  • Las respuestas de CNAME apuntan al dominio C2 al que se conecta el malware
  • El bloqueo de IP, de las respuestas de registro A, controla el comportamiento del malware
  • Nombre de dominio de la máquina codificado por DGA, utilizado para atacar selectivamente a las víctimas
• El tráfico de comando y control se hace pasar por el programa legítimo de mejora de Orion
• El código se oculta en un sitio simple mediante el uso de nombres de variables falsos y la vinculación con componentes legítimos

Entrega e Instalación

Los administradores de sistemas autorizados obtienen e instalan actualizaciones de SolarWinds Orion por medio de paquetes distribuidos por el sitio web de SolarWinds. El paquete de actualización CORE-2019.4.5220.20574-SolarWinds-Core-v2019.4.5220-Hotfix5.msp (02af7cec58b9a5da1c542b5a32151ba1) contiene SolarWinds.Orion.Core.BusinessLayer.dll descrito en este reporte. Después de la instalación, el marco de software de Orion ejecuta el programa .NET SolarWinds.BusinessLayerHost.exe para cargar complementos, incluido SolarWinds.Orion.Core.BusinessLayer.dll. Este complemento contiene muchos espacios de nombres, clases y rutinas legítimos los cuales implementan la funcionalidad dentro del marco de Orion. Oculta a plena vista, la clase SolarWinds.Orion.Core.BusinessLayer.OrionImprovementBusinessLayer implementa una puerta trasera basada en HTTP. El código dentro de la rutina lógicamente no relacionada SolarWinds.Orion.Core.BusinessLayer.BackgroundInventory.InventoryManager.RefreshInternal invoca el código de puerta trasera cuando se carga el complemento Inventory Manager.

SolarWinds.Orion.Core.BusinessLayer.dll está firmado por SolarWinds, utilizando el certificado con el número de serie 0f:e9:73:75:20:22:a6:06:ad:f2:a3:6e:34:5d:c0:ed. El expediente fue firmado el 24 de marzo de 2020.

Inicialización

Al ejecutar el método malicioso SolarWinds.Orion.Core.BusinessLayer.OrionImprovementBusinessLayer.Initialize, la muestra verifica que su nombre de proceso, en minúsculas, tenga el valor 17291806236368054941. Este valor hash se calcula como el hash estándar FNV-1A de 64 bits con un valor adicional XOR por 6605813339339102567 después de calcular el FNV-1A. Este hash coincide con un proceso denominado "solarwinds.businesslayerhost".

La muestra solo se ejecuta si la hora de escritura del sistema de archivos del ensamblado es al menos 12 a 14 días anterior a la hora actual; el umbral exacto se selecciona aleatoriamente de un intervalo. La muestra continúa comprobando este umbral de tiempo mientras lo ejecuta una tarea, en segundo plano, recurrente legítima. Una vez que se alcanza el umbral, la muestra crea la canalización con nombre 583da945-62af-10e8-4902-a8f205c72b2e para que actúe como un protector de que solo se está ejecutando una instancia antes de leer SolarWinds.Orion.Core.BusinessLayer.dll.config del disco y recuperar el Configuración de la aplicación de campo XML. Las llaves de los campos appSettings son valores legítimos que la lógica maliciosa reutiliza como una configuración persistente. La llave ReportWatcherRetry debe tener un valor distinto de 3 para que la muestra continúe ejecutándose.

El ejemplo comprueba que la máquina esté unida al dominio y recupera el nombre de dominio antes de que continúe la ejecución. Un ID de usuario se genera calculando el MD5 de una dirección MAC de interfaz de red que está activa y no es un dispositivo de bucle invertido, el nombre de dominio y el valor de registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid. El ID de usuario se codifica por medio de un esquema XOR personalizado después de calcular el MD5. A continuación, se lee la llave ReportWatcherPostpone de appSettings de SolarWinds.Orion.Core.BusinessLayer.dll.config para recuperar el valor legítimo inicial. Esta operación se realiza a medida que los paquetes de bits posteriores de muestra marcan este campo y se debe conocer el valor inicial para poder leer los indicadores de bits. Posteriormente, la muestra invoca el método “Update”, que es el bucle de eventos central de la muestra.

DGA y listas de bloqueo

La puerta trasera determina su servidor C2 mediante un algoritmo de generación de dominios (DGA) para construir y resolver un subdominio de avsvmcloud[.]com. El método Update es responsable de inicializar ayudantes criptográficos para la generación de estos subdominios C2 aleatorios. Los subdominios se generan mediante la concatenación de un ID de usuario de la víctima con una codificación reversible del nombre de dominio de la máquina local de la víctima. Es probable que el atacante utilice el subdominio DGA para variar la respuesta de DNS a las víctimas como un medio para controlar la orientación del malware. Estos subdominios se concatenan con uno de los siguientes para crear el nombre de host a resolver:

• .appsync-api.eu-west-1[.]avsvmcloud[.]com
• .appsync-api.us-west-2[.]avsvmcloud[.]com
• .appsync-api.us-east-1[.]avsvmcloud[.]com
• .appsync-api.us-east-2[.]avsvmcloud[.]com

Se obtienen listados de nombre de proceso, nombre de servicio y ruta de controlador, y cada valor se cifra por medio del algoritmo FNV-1a + XOR como se describió anteriormente y se compara con listas de bloqueo codificadas. Algunos de estos hashes se han revertido, por fuerza bruta, como parte de este análisis, lo que demuestra que estas rutinas buscan herramientas de análisis y componentes del motor antivirus. Si se encuentra un proceso en la lista de bloqueo, la rutina de actualización sale y la muestra continuará intentando ejecutar la rutina hasta que pase la lista de bloqueo. Los servicios bloqueados se detienen configurando sus entradas de registro HKLM\SYSTEM\CurrentControlSet\services\<service_name>\Start en el valor 4 para deshabilitarlo. Algunas entradas en la lista de servicios, si se encuentran en el sistema, pueden afectar el comportamiento de los algoritmos DGA en términos de los valores generados. La lista de servicios detenidos se empaqueta en bits en la llave ReportWatcherPostpone de la entrada appSettings para el archivo de configuración de las muestras. Si algún servicio se transfirió a deshabilitado, el método de actualización sale y vuelve a intentarlo más tarde. El ejemplo recupera una lista de controladores por medio de la consulta WMI Select * From Win32_SystemDriver. Si se ve algún controlador en la lista de bloqueo, el método de actualización sale y vuelve a intentarlo. Si pasan todas las pruebas de la lista de bloqueo, la muestra intenta resolver api.solarwinds.com para probar la conectividad de la red.

Red de Comando y Control (C2)

Si se aprueban todas las comprobaciones de listas de bloqueo y conectividad, la muestra comienza a generar dominios en un bucle “while” pormedio de su DGA. La muestra se retrasará por intervalos aleatorios entre la generación de dominios; este intervalo puede ser cualquier valor aleatorio entre los rangos de 1 a 3 minutos, de 30 a 120 minutos, o en condiciones de error de hasta 420 a 540 minutos (9 horas). El registro DNS A, de los dominios generados, se compara con una lista cifrada de bloqueos de direcciones IP los cuales controlan el comportamiento del malware. Los registros dentro de los siguientes rangos eliminarán el malware y actualizarán la llave de configuración ReportWatcherRetry a un valor que impida una mayor ejecución:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16
• 224.0.0.0/3
• fc00:: - fe00::
• fec0:: - ffc0::
• ff00:: - ff00::
• 20.140.0.0/15
• 96.31.172.0/24
• 131.228.12.0/22
• 144.86.226.0/24

Una vez que un dominio se haya recuperado con éxito en una respuesta CNAME DNS, la muestra generará un nuevo hilo de ejecución el cual invocará el método HttpHelper.Initialize, el cual es responsable de todas las comunicaciones y envíos de C2. El subproceso HTTP comienza retrasando una cantidad de tiempo configurable que se controla mediante el comando SetTime. El subproceso HTTP se retrasará un mínimo de 1 minuto entre llamadas. El malware utiliza solicitudes HTTP GET o HTTP POST. Si la muestra intenta enviar datos salientes, el encabezado HTTP de tipo de contenido se establecerá en "application/octet-stream", de lo contrario, en "application/json".

Una carga JSON está presente para todas las solicitudes HTTP POST y PUT y contiene las claves "userId", "sessionId" y "steps". El campo "steps" contiene una lista de objetos con las siguientes llaves: “Timestamp”, “Index”, “EventType”, “EventName”, “DurationMs”, “Succeeded” y “Message”. La llave JSON "EventType" está codificada en el valor "Orion" e "EventName" está codificada en "EventManager". Los mensajes de respuesta de malware para enviar al servidor se comprimen con DEFLATE y se codifican con XOR de un solo byte, posteriormente se dividen entre los campos de "Message" en la matriz de "steps". Cada valor de "Message" se codifica en Base64 por separado. No todos los objetos en la matriz de "steps" contribuyen al mensaje de malware: el número entero en el campo "Timestamp" debe tener el bit 0x2 establecido para indicar que el contenido del campo "Message" se utiliza en el mensaje de malware. Los objetos de paso cuyo bit 0x2 está claro en el campo del registro de fechas contienen datos aleatorios y se descartan al ensamblar la respuesta de malware.

Esteganografía

En el tráfico observado, estos cuerpos de respuesta HTTP intentan aparecer como XML benigno relacionado con ensamblados .NET, pero los datos de comando, en realidad, se distribuyen entre las muchas cadenas presentes GUID y HEX. Los comandos se extraen de los cuerpos de respuesta HTTP buscando cadenas HEX utilizando la siguiente expresión regular: "\{[0-9a-f-]{36}\}"|"[0-9a-f]{32}"|" [0-9a-f]{16}". Los datos de los comandos se distribuyen en varias cadenas las cuales se disfrazan como cadenas GUID y HEX. Todas las sub-cadenas coincidentes, en la respuesta, se filtran en busca de caracteres no HEX, se unen y se decodifican HEX. El primer valor DWORD muestra el tamaño real del mensaje, seguido inmediatamente por el mensaje, seguido de bytes adicionales opcionales no deseados. El mensaje extraído se decodifica con XOR de un solo byte utilizando el primer byte del mensaje y, posteriormente, se descomprime con DEFLATE. El primer carácter es un entero ASCII el cual se asigna a la enumeración JobEngine, con argumentos adicionales opcionales de comando delimitados por caracteres de espacio.

Posteriormente, los comandos se envían a un JobExecutionEngine según el valor del comando, como se describe a continuación.

Comandos compatibles

Indicadores y detecciones para ayudar a la comunidad

Para empoderar a la comunidad con el fin de que detecten esta puerta trasera en la cadena de suministro, estamos publicando indicadores y detecciones para ayudar a las organizaciones a identificar esta puerta trasera y este actor de amenazas. Las firmas son una mezcla de los formatos Yara, IOC y Snort.

Una lista de las detecciones y firmas está disponible en el repositorio de FireEye GitHub. Estamos liberando detecciones y continuaremos actualizando el repositorio público con detecciones superpuestas para indicadores basados en red y host a medida que desarrollamos nuevos o refinamos los existentes. Hemos encontrado múltiples hashes con esta puerta trasera y publicaremos actualizaciones de esos hashes.

Técnicas observadas de MITRE ATT&CK

Recomendaciones de mitigación inmediata

Antes de seguir la recomendación de SolarWind de utilizar la versión 2020.2.1 HF 1 de la plataforma Orion, la cual actualmente está disponible por medio del Portal del cliente de SolarWinds, las organizaciones deberán considerar conservar los dispositivos afectados y crear nuevos sistemas con las versiones más recientes. La aplicación de una actualización a una caja afectada podría potencialmente sobrescribir la evidencia forense y dejar puertas traseras adicionales en el sistema. Además, SolarWinds ha publicado instrucciones adicionales de mitigación y fortalecimiento.

En caso de que no pueda seguir las recomendaciones de SolarWinds, las siguientes son técnicas inmediata de mitigación las cuales podrían implementarse como primeros pasos para abordar el riesgo del software SolarWinds con troyanos en un entorno. Si se descubre actividad de un atacante en un entorno, recomendamos realizar una investigación exhaustiva y diseñar y ejecutar una estrategia de remediación impulsada por los hallazgos de la investigación y los detalles del entorno afectado.

• Asegurarse de que los servidores de SolarWinds estén aislados/contenidos hasta que se lleve a cabo una revisión e investigación adicionales. Esto debería incluir el bloqueo de todas las salidas de Internet de los servidores SolarWinds.
• Si la infraestructura de SolarWinds no está aislada, considerar seguir los siguientes pasos:
  • Restringir el alcance de la conectividad a los puntos finales desde los servidores de SolarWinds, especialmente aquellos que se considerarían activos de nivel 0/ joyas de la corona
  • Restringir el alcance de las cuentas que tienen privilegios de administrador local en los servidores de SolarWinds.
  • Bloquear la salida de Internet desde servidores u otros puntos finales con el software de SolarWinds
• Considerar (como mínimo) cambiar las contraseñas de las cuentas que tienen acceso a servidores/infraestructura de SolarWinds. Con base en una revisión/investigación adicional, es posible que se requieran medidas adicionales de remediación.
• Si SolarWinds se utiliza para la infraestructura de red administrada, considerar realizar una revisión de las configuraciones de los dispositivos de red con el fin de detectar modificaciones inesperadas o no autorizadas. Tener en cuenta que esta es una medida proactiva debido al alcance de la funcionalidad de SolarWinds, no basada en hallazgos de investigación.

Agradecimientos

Esta publicación de blog fue el esfuerzo combinado de numerosos miembros del personal y equipos de FireEye. Agradecimientos especiales a:

Andrew Archer, Doug Bienstock, Chris DiGiamo, Glenn Edwards, Nick Hornick, Alex Pennino, Andrew Rector, Scott Runnels, Eric Scales, Nalani Fraser, Sarah Jones, John Hultquist, Ben Read, Jon Leathery, Fred House, Dileep Jallepalli, Michael Sikorski , Stephen Eckels, William Ballenthin, Jay Smith, Alex Berry, Nick Richard, Isif Ibrahima, Dan Perez, Marcin Siedlarz, Ben Withnell, Barry Vengerik, Nicole Oppenheim, Ian Ahl, Andrew Thompson, Matt Dunwoody, Evan Reese, Steve Miller, Alyssa Rahman, John Gorman, Lennard Galang, Steve Stone, Nick Bennett, Matthew McWhirt, Mike Burns, Omer Baig.

También un agradecimiento especial a Nick Carr, Christopher Glyer y Ramin Nafisi de Microsoft.