Estudios de casos para usar herramientas de análisis de anomalías de red: descubrimiento de campañas de DNSpionage

Continuamos revisando casos para sistemas de análisis de tráfico de red (NTA) para objetivos de ciberseguridad. Hoy veremos cómo se pueden usar estas soluciones para detectar campañas muy complejas, específicas y muy efectivas llamadas DNSpionage y Sea Turtle.

Pero antes de eso, recordaré brevemente cómo funciona el Sistema de nombres de dominio (DNS), que subyace a la interacción en Internet. El cerebro humano está tan organizado que no puede memorizar muchos números y números que una persona no asocia con nada familiar. Y el número de combinaciones memorables de números y números es, en cualquier caso, pequeño. Por lo tanto, para no memorizar y almacenar en el cuaderno cientos y miles de direcciones IP de los sitios que nos interesan, se inventó el sistema DNS, que traduce las direcciones simbólicas de los sitios que son más comprensibles para los humanos en sus direcciones IP. Si necesito acceder a cualquier sitio, entonces envío una consulta DNS con el nombre del sitio al servidor DNS, que me devuelve su dirección IP, a la que voy.



Si profundiza un poco más en los detalles, entonces el esquema parece más complicado. Si el servidor DNS más cercano a mí no conoce la dirección IP del sitio que me interesa, me dirige al servidor raíz, que luego me dirige al servidor DNS de la zona en la que se encuentra el sitio que me interesa (por ejemplo, ".ru"), y más a lo largo de la cadena hasta que llegue a un servidor DNS que conozca la dirección IP que necesito.



Resulta que confiamos en los servidores DNS que nos envían las direcciones IP de los sitios que queremos visitar. ¿Y si alguien irrumpe en un servidor DNS y falsifica un registro para que coincida con un nombre simbólico y una dirección IP? ¿Qué sucede si nos dirigen a un sitio falso que parece real y que puede robar nuestros inicios de sesión y contraseñas, así como otra información confidencial sobre nosotros? Esta suplantación de identidad se llama redirección de DNS y es utilizada por los ciberdelincuentes en ataques especialmente peligrosos.



En 2009, el "Ejército cibernético iraní" reemplazó a twitter.com. En 2011, 186 dominios fueron reemplazados por hackers turcos, incluidos HSBC, Vodafone, Acer y otros. En 2013-2014, el Ejército Electrónico Sirio reemplazó los sitios NYT, Twitter, Huffingtin Post (el intento falló contra Facebook). En el mismo año, se llevaron a cabo acciones similares contra WhatsApp, AVG, Avira. Un año después, se reemplazaron los sitios de Google de Vietnam y Malasia, así como el dominio del Banco de la Reserva Federal de St. Louis. En 2016, se robó una cierta cantidad de criptomonedas de blockchain.info de esta manera.

De hecho, hay más vectores de ataque DNS, pero hoy solo veremos los relacionados con las campañas DNSpionage y Sea Turtle .



Ahora que hemos visto rápidamente cómo funciona DNS y cómo puede usarlo en detrimento, podemos pasar directamente a las campañas DNSpionage y Sea Turtle, comenzando por la primera. En 2018, la división Cisco Talos lo encontró en varios países de Medio Oriente. Consistió en dos partes: infección de usuarios y redirección de DNS, que no siempre estaban relacionadas, pero por una serie de signos, concluimos que el mismo grupo probablemente esté detrás de ambas partes.



En el primer caso, los usuarios víctimas recibieron ofertas de trabajo a través de LinkedIn y otros sitios de búsqueda de empleo. Todas las vacantes condujeron a sitios falsos en los que se publicaron vacantes tentadoras. Se registraron dos sitios: hr-wipro [.] Com y hr-suncor [.] Com, que redirigió a los usuarios a wipro.com y suncor.com legales. Los enlaces colocaron archivos en formato MS Word con macros incrustados, cada uno de los cuales funcionó cuando el documento se abrió y cerró, respectivamente.



La primera macro decodificó el archivo PE y lo guardó en la dirección "% UserProfile% \. OracleServices \ svshost_serv.doc". La segunda macro cambió el nombre de "svshost_serv.doc" a "svshost_serv.exe". Luego, la macro creó la tarea "chromium Updater v 37.5.0", que ejecutó el archivo ejecutable y lo repitió cada minuto. Este malware realizó las funciones de RAT (herramienta de administración remota), que se llamaba DNSpionage. Interactuó con un dominio especialmente creado, solicitando / recibiendo comandos que ejecutó. Entre estos comandos están solicitar contenidos del directorio, escanear la red, copiar archivos, usar utilidades remotas (WinSSHD, Putty, mimikatz), etc. Los comandos del servidor de comandos, así como los resultados del trabajo, se enviaron en uno de los dos modos: HTTP o DNS. La segunda opción suele ser más simple, ya que existe una alta probabilidadque no tiene una inspección completa del tráfico DNS y simplemente no nota el código malicioso DNSpionage que se comunica con el servidor de comandos.

Lo más interesante comienza en el momento en que las partes cliente y servidor del malware se comunican. El cliente envía la siguiente consulta DNS ofuscada a 0ffice36o [.] Com (el primer carácter es cero y la última letra es "o"): RoyNGBDVIAA0 [.] 0ffice36o [.] Com, donde se generan aleatoriamente los primeros 4 bytes y el resto (GBDVIAA0 ) son una solicitud codificada en base32 (para cada víctima, se seleccionó su propio alfabeto base64 / dase32). Descifrarlo nos da "0GT \ x00", donde GT es el identificador de la víctima, y ​​\ x00 es el número de solicitud. El servidor de comandos nos responde en forma de una dirección IP, que no siempre es correcta, por ejemplo, 0.1.0.3 (el protocolo DNS lo permite). La segunda consulta DNS se ve así: t0qIGBDVIAI0 [.] 0ffice36o [.] Com. El servidor de comandos nos devuelve la dirección IP: 100.105.114.0, que es de 4 caracteres en la codificación ASCII normal,que en este caso significa el comando ejecutable "dir \ x00". En respuesta, el lado del cliente de DNSpionage envía:

GLtAGJDVIAJAKZXWY000 0ffice36o com [.] [.] -> GJDVIAJAKZXWY000 -> "2 GT \ x01 vol»
TwGHGJDVIATVNVSSA000 0ffice36o com [.] [.] -> GJDVIATVNVSSA000 -> «2 GT \ x02 ume»
1QMUGJDVIA3JNYQGI000 0ffice36o com [.] [.] - > GJDVIA3JNYQGI000 -> "2GT \ x03 en d"
iucCGJDVIBDSNF3GK000 [.] 0ffice36o [.] Com -> GJDVIBDSNF3GK000 -> "2GT \ x04 rive"
viLxGJDVIBJAIMQGQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ? Con IQQ? Con QQQQQQQQQQQQQ? CQ? "? ¿QQQQQQQQQ de QQ? De QQ? h "

Como parte de la segunda parte de la campaña DNSpionage, el administrador del administrador del servidor DNS fue robado, los registros DNS correspondientes se cambiaron y los certificados se crearon usando LetsEncrypt, que se usará más adelante en el ataque del "sitio intermedio". Es en tal sitio que el ataque de redirección de DNS descrito anteriormente enviará a víctimas seleccionadas (en solo 2 años de esta campaña, pudimos identificar 25 redirecciones, lo que indica que no es un ataque masivo, sino un ataque dirigido). Tenga en cuenta que tanto su propio servidor DNS (si tiene uno) como los servidores DNS de terceros que ya no controla pueden ser atacados.

Como parte de sus actividades, los atacantes pudieron interceptar todo el tráfico que se dirigía a los dominios indicados de los organismos gubernamentales del Líbano y los Emiratos Árabes Unidos (el Ministerio de Finanzas, la policía, el Ministerio de Comunicaciones y Telecomunicaciones, la aerolínea, etc.), incluidos el correo electrónico y la VPN, que podrían permítales reunir información adicional sobre sus víctimas.

La campaña Cisco Talos Sea Turtle fue aún más complicada que DNSpionage, ya que los atacantes atacaron no solo servidores DNS, sino también servidores TLD (incluidos ccTLD y gTLD), lo



que permitió a piratas informáticos desconocidos atacar organizaciones estatales y militares en el Medio Oriente y el Norte África, así como servicios especiales y compañías de petróleo y gas.



Ahora regrese a la tarea original y vea cómo los sistemas de análisis de tráfico de red pueden ayudar a identificar las campañas mencionadas. Cabe señalar de inmediato que, dada su complejidad y el hecho de que pueden dirigirse contra servidores DNS externos, los sistemas de clase NTA no siempre nos ayudarán. Pero en esos casos, cuando se trata del modo de operación DNS de DNSpionage o un ataque a servidores DNS locales en el marco de DNSpionage o Sea Turtle, podemos usar Netflow para ver todos los signos de un ataque que necesitamos y bloquearlos de manera oportuna.

En primer lugar, necesitamos definir nuestros servidores DNS internos y agregarlos a un grupo. Aquí es donde comienza la introducción de casi cualquier sistema de monitoreo de anomalías. Para comprender si encontramos anomalías en el tráfico de red o no, primero debemos decidir qué es normal y legítimo. Y solo después de eso, el sistema comienza a funcionar con toda su fuerza.



Esto se puede hacer manualmente, pero es mejor usar la función de clasificar nodos por tipo de tráfico, lo que le permite identificar todos los nodos, incluso aquellos que no conocemos, pero que funcionan como servidores DNS.



En nuestro caso, encontramos 5 servidores:



Después de haber decidido los servidores DNS legales, solo podemos monitorear todo el tráfico DNS, lo cual es anómalo, es decir, más allá de lo permitido. Por ejemplo, así es como podemos describir una regla para identificar servidores DNS internos que funcionan ilegalmente:



y esta regla se verá así, lo que demuestra que por alguna razón tenemos 2 servidores DNS en nuestra red, uno de los cuales se encuentra en el segmento de servidor confidencial , y el segundo en el segmento de dispositivos de usuario.



La siguiente regla nos permite identificar servidores DNS externos sospechosos que interactúan directamente con los hosts internos, lo que puede ser una señal de que el servidor de comandos DNSpionage funciona con dispositivos corporativos infectados:



Y encontramos ejemplos de dicha interacción:



De manera similar, podemos configurar el sistema de detección de anomalías de red (y este artículo usa Cisco Stealthwatch como ejemplo) para detectar intentos no autorizados de acceder a nodos internos al servidor DNS local (esto puede indicar que DNSpionage o Sea Turtle están funcionando), así como la interacción activa hosts internos con hosts externos que utilizan el protocolo DNS (esto registrará el funcionamiento de DNSpionage en modo DNS).

Después de corregir las anomalías correspondientes y las violaciones de la política de seguridad, debemos desarrollar reglas que nos permitan señalar cualquier intento futuro de conectar nodos internos, excluyendo servidores DNS locales, a servidores DNS externos (y viceversa).



La segunda regla nos permite registrar cualquier intento de interactuar usando el tráfico DNS dentro de la red corporativa, excluyendo los servidores DNS locales.



Así es como el monitoreo de Netflow (así como otros protocolos de flujo) nos permite identificar etapas individuales de ataques bastante complejos que pueden dañar las corporaciones modernas y las agencias gubernamentales.

Source: https://habr.com/ru/post/undefined/