FireEye: hack de SolarWinds y el ataque al Tesoro de EE. UU.

FireEye tras la pista de los cibercriminales que atacaron al tesoro de los Estados Unidos

FireEye tras la pista de los cibercriminales que atacaron al tesoro de los Estados Unidos

El equipo profesional de Ingenieros de FireEye ha descubierto una campaña cibercriminal de intrusión global.

FireEye está rastreando a los actores detrás de esta campaña como UNC2452.

  • FireEye descubrió un ataque a la cadena de suministro que troyanó las actualizaciones del software empresarial SolarWinds Orion para distribuir el malware que llamamos SUNBURST.
  • La actividad posterior al 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 de 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 en la naturaleza. 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.

Análisis del Contexto

FireEye ha descubierto una campaña generalizada, que 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 a través de actualizaciones troyanizadas del software de gestión y supervisión de TI Orion de SolarWind.

Esta campaña puede haber comenzado ya en la primavera de 2020 y actualmente está en curso.

La actividad posterior al 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 seguridad operativa significativa.

Puerta trasera SUNBURST

SolarWinds.Orion.Core.BusinessLayer.dll es un componente firmado digitalmente de SolarWinds del marco de software de Orion que contiene una puerta trasera que se comunica a través de HTTP a servidores de terceros.

Estamos rastreando la versión troyanizada de este complemento de SolarWinds Orion como SUNBURST.

Después de un período de inactividad inicial de hasta dos semanas, recupera y ejecuta comandos, llamados “Trabajos”, que incluyen la capacidad de transferir archivos, ejecutar archivos, perfilar el sistema, reiniciar la máquina y deshabilitar los servicios del sistema.

El malware disfraza su tráfico de red como el protocolo del Programa de mejora de Orion (OIP) y almacena los resultados del reconocimiento en archivos de configuración de complementos legítimos, lo que le permite integrarse con la actividad legítima de SolarWinds.

La puerta trasera utiliza múltiples listas de bloqueo ofuscadas para identificar herramientas forenses y antivirus que se ejecutan como procesos, servicios y controladores.


Figura 1: Firma digital SolarWinds en software con puerta trasera

Varias actualizaciones troyanas se firmaron digitalmente de marzo a mayo de 2020 y se publicaron en el sitio web de actualizaciones de SolarWinds, que 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 troyano es un archivo de revisión estándar de Windows Installer que incluye recursos comprimidos asociados con la actualización, incluido el componente Trojanizado

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 inactivo de hasta dos semanas, el malware intentará resolver un subdominio de avsvmcloud [.] Com.

La respuesta de 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 API de SolarWinds normales.

La lista de infraestructura maliciosa conocida está disponible en la página de GitHub de FireEye .

Víctimas mundiales 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 habrá víctimas adicionales en otros países y verticales.

FireEye ha notificado a todas las entidades que sabemos que se han visto afectadas.

Actividad posterior al 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 de malware ligera, en su lugar prefiere credenciales legítimas y acceso remoto para acceder al entorno de la víctima.


Figura 2: Tácticas posteriores al compromiso

Esta sección detallará las técnicas notables y describirá las oportunidades potenciales de detección.

Malware TEARDROP y BEACON utilizado

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

TEARDROP es un cuentagotas de memoria que se ejecuta como un servicio, genera un hilo y lee el archivo “gracious_truth.jpg”, que probablemente tiene un encabezado JPG falso.

A continuación, comprueba que existe HKU \ SOFTWARE \ Microsoft \ CTF, decodifica una carga útil incorporada mediante un algoritmo XOR personalizado y carga manualmente en la memoria una carga útil incorporada mediante un formato de archivo personalizado tipo PE.

TEARDROP no tiene superposición de código con ningún malware visto anteriormente.

Creemos que esto se utilizó para ejecutar una BALIZA Cobalt Strike personalizada.

Mitigación :

FireEye ha proporcionado dos reglas de Yara para detectar TEARDROP disponibles en nuestro GitHub .

Los defensores deben buscar las siguientes alertas de FireEye HX: MalwareGuard y WindowsDefender:

Procesar informacion

file_operation_closed
file-path *: “c: \\ windows \\ syswow64 \\ netsetupsvc.dll
actor-proceso:
pid: 17900

Entradas de registro de Windows Defender Exploit Guard: (Microsoft-Windows-Security-Mitigations / KernelMode ID de evento 12)

El proceso ”\ Device \ HarddiskVolume2 \ Windows \ System32 \ svchost.exe” (PID XXXXX) se habría bloqueado para no 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 de host legítimo que se encuentra en el entorno de la víctima.

Esto permite que el adversario se mezcle con el entorno, evite sospechas y evite la detección.

Oportunidad de detección

La infraestructura del atacante filtra su nombre de host configurado en certificados RDP SSL, que se pueden identificar en los datos de escaneo de Internet.

Esto presenta una oportunidad de detección para los defensores: consultar las fuentes de datos de escaneo de Internet para los nombres de host de una organización puede descubrir direcciones IP maliciosas que pueden hacerse pasar por la organización. (Nota: el historial de escaneo de IP a menudo muestra IP cambiando entre los nombres de host predeterminados (WIN- *) y los nombres de host de la víctima).

La referencia cruzada de la lista de IP identificadas en los datos de escaneo de Internet con registros de acceso remoto puede identificar evidencia de este actor en un entorno.

Es probable que haya 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 originaron en el mismo país que la víctima, aprovechando los servidores privados virtuales.

Información de valor para tomar decisiones

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 está utilizando 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 desde 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 línea de base y la normalización de los ASN utilizados para el acceso remoto legítimo para ayudar a identificar la actividad sospechosa.

Movimiento lateral con diferentes credenciales

Una vez que el atacante obtuvo acceso a la red con credenciales comprometidas, se movió lateralmente usando múltiples credenciales diferentes.

Las credenciales utilizadas para el movimiento lateral siempre fueron diferentes de las utilizadas para el acceso remoto.

Oportunidad de detección

Las organizaciones pueden usar el módulo LogonTracker de HX para graficar toda la actividad de inicio de sesión y analizar sistemas que muestran una relación de uno a varios entre los sistemas de origen y las cuentas.

Esto descubrirá cualquier sistema único que se autentique en varios sistemas con varias cuentas, un hecho relativamente poco común durante las operaciones comerciales normales.

Reemplazo temporal de archivos y modificación de tareas temporales

El atacante utilizó una técnica de reemplazo de archivos temporales para ejecutar de forma remota las utilidades: reemplazaron una utilidad legítima con la suya, ejecutaron su carga útil y luego restauraron el archivo original legítimo.

De manera similar, manipularon las tareas programadas actualizando una tarea legítima existente para ejecutar sus herramientas y luego devolviendo la tarea programada a su configuración original. De manera rutinaria, eliminaron sus herramientas, incluida la eliminación de puertas traseras una vez que se logró un acceso remoto legítimo.

Oportunidad de detección

Los defensores pueden examinar los registros de las sesiones SMB que muestran el acceso a directorios legítimos y seguir un patrón de eliminar-crear-ejecutar-eliminar-crear en un corto período de tiempo.

Además, los defensores pueden monitorear las tareas programadas existentes para actualizaciones tempo-rales, utilizando análisis de frecuencia para identificar modificaciones anómalas de tareas.

Las tareas también se pueden monitorear para buscar tareas legítimas de Windows que ejecuten binarios nuevos o desconocidos.

La actividad posterior al 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, centrándose en la evasión y aprovechando la confianza inherente.

Sin embargo, se puede detectar mediante 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 que contiene una puerta trasera oculta que se comunica a través de HTTP con servidores de terceros.

Después de un período de inactividad inicial de hasta dos semanas, recupera y ejecuta comandos, llamados “Trabajos”, que 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 a través de procesos, servicios y controladores.

Capacidades únicas

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

Entrega e instalación

Los administradores de sistemas autorizados obtienen e instalan actualizaciones de SolarWinds Orion a través 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 que se describe en este informe.

Después de la instalación, el marco del software 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ítimas que implementan la funcionalidad dentro del marco de Orion.

Oculto a simple vista, la clase SolarWinds.Orion.Core.BusinessLayer.OrionImprovementBusinessLayer

implementa una puerta trasera basada en HTTP.

Código dentro de la rutina SolarWinds.Orion.Core.BusinessLayer sin relación lógica.

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 se firmó el 24 de marzo de 2020.

Inicialización

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

Este hash coincide con un proceso llamado “solarwinds.businesslayerhost”.

La muestra solo se ejecuta si el tiempo de escritura del sistema de archivos del ensamblaje es al menos de 12 a 14 días antes de la hora actual; el umbral exacto se selecciona aleatoriamente de un intervalo.

La muestra continúa verificando este umbral de tiempo, ya que la ejecuta una tarea en segundo plano recurrente legítima. Una vez que se alcanza el umbral, la muestra crea la tubería con nombre 583da945-62af-10e8-4902-a8f205c72b2e para actuar como un protector de que solo se está ejecutando una instancia antes de leer

SolarWinds.Orion.Core.BusinessLayer.dll.config

del disco y recuperar AppSettings de campo XML.

Las claves de los campos appSettings son valores legítimos que la lógica maliciosa reutiliza como una configuración persistente.

La clave ReportWatcherRetry debe ser cualquier valor distinto de 3 para que la muestra continúe con la ejecución.

La muestra verifica que la máquina esté unida a un dominio y recupera el nombre de dominio antes de que continúe la ejecución.

Una ID de usuario se genera calculando el MD5 de todas las direcciones MAC de la interfaz de red que están activas y no dispositivos 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 mediante un esquema XOR personalizado después de que se calcula MD5.

La clave ReportWatcherPostpone de appSettings se lee de SolarWinds.Orion.Core.BusinessLayer.dll.config para recuperar el valor legítimo inicial.

Esta operación se realiza cuando la muestra de bits posteriores empaqueta indicadores en este campo y se debe conocer el valor inicial para poder leer los indicadores de bits.

A continuación, la muestra invoca el método Update, que es el bucle de eventos principal de la muestra.

DGA y listas de bloques

La puerta trasera determina su servidor C2 utilizando un algoritmo de generación de dominio (DGA) para construir y resolver un subdominio de avsvmcloud [.] Com.

El método de actualización es responsable de inicializar los ayudantes criptográficos para la generación de estos subdominios C2 aleatorios.

Los subdominios se generan concatenando 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 del 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 para 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 listas de nombre de proceso, nombre de servicio y ruta de controlador, y cada valor se procesa mediante el algoritmo FNV-1a + XOR como se describió anteriormente y se verifica con listas de bloques codificadas.

Algunos de estos hashes se han invertido mediante la fuerza bruta como parte de este análisis, lo que demuestra que estas rutinas están buscando herramientas de análisis y componentes del motor antivirus.

Si se encuentra un proceso en la lista de bloqueo, la rutina de actualización se cierra y la muestra continuará intentando ejecutar la rutina hasta que pase la lista de bloqueo.

Los servicios de la lista de bloqueo se detienen configurando sus entradas de registro HKLM \ SYSTEM \ CurrentControlSet \ services \ <service_name> \ Start en el valor 4 para deshabilitar.

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.

Luego, la lista de servicios detenidos se empaqueta en bits en la clave ReportWatcherPostpone de la entrada appSettings para el archivo de configuración de las muestras. Si algún servicio pasó a estar deshabilitado, el método de actualización sale y vuelve a intentarlo más tarde. La muestra recupera una lista de controladores a través de la consulta WMI Seleccione * 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 todas las pruebas de la lista de bloqueo pasan, la muestra intenta resolver api.solarwinds.com para probar la conectividad de la red.

Comando y control de red (C2)

Si todas las comprobaciones de la lista de bloqueo y la conectividad pasan, la muestra comienza a generar dominios en un bucle while a través de su DGA.

La muestra se demorará por intervalos aleatorios entre la generación de dominios; este intervalo puede ser cualquier valor aleatorio de los rangos de 1 a 3 minutos, 30 a 120 minutos, o en condiciones de error hasta 420 a 540 minutos (9 horas).

El registro DNS A de dominios generados se compara con una lista codificada de bloques de direcciones IP que controlan el comportamiento del malware.

Los registros dentro de los siguientes rangos terminarán el malware y actualizarán la clave 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 ha recuperado con éxito en una respuesta CNAME DNS, la muestra generará un nuevo hilo de ejecución invocando el método HttpHelper.Initialize, que es responsable de todas las comunicaciones y despacho C2.

El subproceso HTTP comienza retrasándose durante un período de tiempo configurable que es controlado por el comando SetTime.

El subproceso HTTP se demorará 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 del tipo de contenido se establecerá en “application / octet-stream”, de lo contrario, en “application / json”.

Una carga útil JSON está presente para todas las solicitudes HTTP POST y PUT y contiene las claves “userId”, “sessionId” y “steps”. El campo “pasos” contiene una lista de objetos con las siguientes claves: “Marca de tiempo”, “Índice”, “Tipo de evento”, “Nombre de evento”, “DuraciónMs”, “Correcto” y “Mensaje”.

La clave JSON “EventType” está codificada en el valor “Orion”, y el “EventName” está codificado en “EventManager”.

Los mensajes de respuesta de malware que se envían al servidor se comprimen en DEFLATE y se codifican en XOR de un solo byte, luego se dividen entre los campos “Mensaje” en la matriz de “pasos”.

Cada valor de “Mensaje” se codifica en Base64 por separado.

No todos los objetos de la matriz de “pasos” contribuyen al mensaje de malware; el número entero en el campo “Marca de tiempo” debe tener el bit 0x2 configurado para indicar que el contenido del campo “Mensaje” se utiliza en el mensaje de malware.

Esteganografía

En el tráfico observado, estos cuerpos de respuesta HTTP intentan aparecer como un XML benigno relacionado con los ensamblajes .NET, pero los datos de los comandos se distribuyen entre las numerosas cadenas GUID y HEX presentes.

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 que se disfrazan como cadenas GUID y HEX. Todas las subcadenas coincidentes en la respuesta se filtran en busca de caracteres no HEX, se unen y se decodifican en HEX.

El primer valor DWORD muestra el tamaño real del mensaje, seguido inmediatamente por el mensaje, con bytes de basura adicionales opcionales a continuación.

El mensaje extraído se decodifica XOR de un solo byte utilizando el primer byte del mensaje, y esto luego se descomprime DEFLATE.

El primer carácter es un entero ASCII que se asigna a la enumeración de JobEngine, con argumentos de comando adicionales opcionales delimitados por caracteres de espacio.

Luego, los comandos se envían a un JobExecution Engine en función del valor del comando como se describe a continuación.

Comandos admitidos

Mando Valor Operación
Ocioso 0 No operacion
Salida 1 Termina el hilo actual.
Fijar tiempo 2 Establece el tiempo de retardo entre las ejecuciones del bucle de eventos principal. El retardo se expresa en segundos y varía aleatoriamente entre [.9 * <delay>, 1.1 * <delay>]. Si el retraso es <300, se duplica en la siguiente ejecución a través del bucle, esto significa que debe establecerse en un intervalo de alrededor de [5, 10] minutos. Hay una segunda rutina de retardo no relacionada que se retrasa por un intervalo aleatorio entre [16 h, 83 h]
CollectSystemDescription 3 Perfile el sistema local, incluido el nombre de host, el nombre de usuario, la versión del sistema operativo, las direcciones MAC, la dirección IP, la configuración DHCP y la información del dominio.
UploadSystemDescription 4 Realice una solicitud HTTP a la URL especificada, analice los resultados y compare los componentes con valores hash desconocidos. Formatee un informe y envíelo al servidor C2.
RunTask 5 Inicia un nuevo proceso con la ruta de archivo y los argumentos dados.
GetProcessByDescription 6 Devuelve una lista de procesos. Si no se proporcionan argumentos, devuelve solo el PID y el nombre del proceso. Si se proporciona un argumento, también devuelve el PID principal, el nombre de usuario y el dominio del propietario del proceso.

 

KillTask 7 Terminar el proceso dado, por PID.
GetFileSystemEntries 8 Dada una ruta y un patrón de coincidencia opcional, enumera de forma recursiva archivos y directorios
WriteFile 9 Dada una ruta de archivo y una cadena codificada en Base64, escriba el contenido de la cadena decodificada en Base64 en la ruta de archivo dada. Escribe usando el modo de agregar. Retraso de [1s, 2s] después de terminar la escritura.
El archivo existe 10 Comprueba si existe la ruta de archivo dada.
Borrar archivo 11 Elimina la ruta de archivo especificada.
GetFileHash 12 Calcule el MD5 de un archivo en una ruta determinada y devuelva el resultado como una cadena HEX. Si se proporciona un argumento, es el hash MD5 esperado del archivo y devuelve un error si el MD5 calculado es diferente.

 

ReadRegistryValue 13 Registro arbitrario leído de una de las colmenas admitidas
SetRegistryValue 14 Escritura de registro arbitraria desde una de las colmenas admitidas.
DeleteRegistryValue 15 Eliminación arbitraria del registro de una de las colmenas admitidas
GetRegistrySubKeyAndValueNames

 

dieciséis Devuelve una lista de subclaves y nombres de valores debajo de la ruta de registro dada
Reiniciar 17 Intenta activar inmediatamente un reinicio del sistema.

Indicadores y detecciones para ayudar a la comunidad

Para que la comunidad pueda detectar esta puerta trasera de la cadena de suministro, publicamos indicadores y detecciones para ayudar a las organizaciones a identificar esta puerta trasera y este actor de amenazas.

Las firmas son una mezcla de formatos Yara, IOC y Snort.

Una lista de las detecciones y firmas está disponible en el repositorio de FireEye GitHub que se encuentra aquí .

Estamos lanzando detecciones y continuaremos actualizando el repositorio público con detecciones superpuestas para indicadores de host y de red a medida que desarrollamos nuevos o refinamos los existentes.

Hemos encontrado varios hashes con esta puerta trasera y publicaremos actualizaciones de esos hashes.

Técnicas MITRE ATT y CK observadas

CARNÉ DE IDENTIDAD Descripción
T1012 Registro de consultas
T1027 Archivos o información ofuscados
T1057 Descubrimiento de procesos
T1070.004 Eliminación de archivos
T1071.001 Protocolos web
T1071.004 Protocolo de capa de aplicación: DNS
T1083 Descubrimiento de archivos y directorios
T1105 Transferencia de herramientas de ingreso
T1132.001 Codificación estándar
T1195.002 Comprometer la cadena de suministro de software
T1518 Descubrimiento de software
T1518.001 Descubrimiento de software de seguridad
T1543.003 Servicio de Windows
T1553.002 Firma de código
T1568.002 Algoritmos de generación de dominios
T1569.002 Ejecución de servicios
T1584 Infraestructura de compromiso

Recomendaciones de mitigación inmediata

SolarWinds recomienda a todos los clientes que se actualicen inmediatamente a la versión 2020.2.1 HF 1 de Orion Platform, que actualmente está disponible a través del Portal del cliente de SolarWinds.

Además, SolarWinds ha publicado instrucciones adicionales de mitigación y refuerzo aquí .

En caso de que no pueda seguir las recomendaciones de SolarWinds, las siguientes son técnicas de mitigación inmediata que podrían implementarse como primeros pasos para abordar el riesgo del software SolarWinds troyano 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 reparación impulsada por los hallazgos de la investigación y los detalles del entorno afectado.

  • Asegúrese de que los servidores 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, considere realizar los siguientes pasos:
    • Restrinja el alcance de la conectividad a los puntos finales de los servidores de SolarWinds, especialmente aquellos que se considerarían activos de nivel 0 / joya de la corona
    • Restrinja el alcance de las cuentas que tienen privilegios de administrador local en los servidores SolarWinds.
    • Bloquee la salida de Internet desde servidores u otros puntos finales con el software SolarWinds.
  • Considere (como mínimo) cambiar las contraseñas de las cuentas que tienen acceso a los servidores / infraestructura de SolarWinds. Con base en una revisión / investigación adicional, es posible que se requieran medidas de reparación adicionales.
  • Si SolarWinds se utiliza para administrar la infraestructura de red, considere realizar una revisión de las configuraciones de los dispositivos de red para detectar modificaciones inesperadas o no autorizadas. Tenga en cuenta que esta es una medida proactiva debido al alcance de la funcionalidad de SolarWinds, no basada en hallazgos de investigación.

 

Por 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.

Gmail ha muerto, el 2020 cobra otra víctima

Ciberdelito: analizamos el forecast 2021 de este negocio oscuro

The Standoff 2020: la madre de todas las batallas hackers

5 formas en las que va a cambiar la ciberseguridad en 2021

4 cosas acerca del cibercrimen que deben saber las Pyme

 

Lea más

 

 

FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, FireEye, 

95 / 100