"¡Pero no es aburrido!": Este es el lema informal de los empleados de nuestro centro de monitoreo de amenazas cibernéticas Solar JSOC (y debo decir que 2019 correspondía totalmente a él). Al comienzo del año nuevo, a muchas personas les gusta hacer un balance y establecer nuevas metas, pero en su lugar decidimos contar algunos "horrores de nuestra ciudad": los casos de 2019, que impresionaron incluso a analistas experimentados. La conclusión de estas historias es solo una: la tecnología se desarrolla y evoluciona, y la pereza humana, la negligencia y el descuido son eternos.
Wifi para invitados
Al conectar a los clientes con el monitoreo, primero pedimos la información más importante: cuentas críticas, grupos de dominio, segmentos no confiables, direcciones blancas, DMZ, subredes críticas, etc. Las subredes no confiables son solo Wi-Fi invitado, así como redes de contratistas, segmentos de prueba con permisos para permitir cualquiera, etc. ... Por lo general, vemos que la posibilidad de interacción con dichos segmentos está ausente o muy limitada, porque controlarlos Muy difícil, si no imposible. En la red del cliente, no había posibilidad de tales interacciones, excepto la página de autorización en la red de invitados. Nos calmamos agregando una prohibición de interactuar desde Wi-Fi con TOR, servidores C&C y otros espíritus malignos, para que no nos bombardearan con operaciones que no eran interesantes para un cliente potencial (aunque recopilamos estadísticas sobre estos incidentes para informes resumidos). Y en la tercera mañana del proyecto piloto, notamos una anomalía: ¡el flujo de eventos desde el firewall aumentó 4 veces!
Comenzaron a buscar la causa del "bloqueo" y, con sorpresa, la encontraron en el segmento de Wi-Fi para invitados. Cierto host generó 4 millones (!) Eventos por hora. Y los eventos son bastante interesantes: conexiones en el puerto 445 a direcciones blancas aleatorias del espacio de Internet. ¡Cuatro millones, Karl!
Habiendo informado al cliente sobre esto, comenzaron a esperar información sobre el host y el incidente, ya que DHCP (es el servidor de autorización) no estaba conectado a SIEM. Después de aproximadamente 3-4 horas, el cliente informó que el host es un teléfono móvil. Decir que nos sorprendió es no decir nada. Un teléfono móvil ordinario no puede generar ese flujo de eventos. Comenzaron a descubrir los detalles, y resultó que el teléfono móvil no tenía nada que ver con eso: alguien simplemente usó uno de los dispositivos registrados como tapa. No fue posible encontrar la verdadera fuente de actividad, y nuestro cliente dijo que no estaba interesado en este caso, por lo que la actividad tuvo que ser minimizada. Sin embargo, advertimos a los especialistas del cliente acerca de los posibles riesgos: dado que la actividad (obviamente maliciosa) proviene de sus direcciones, pueden, por ejemplo, ingresar a las listas de servidores C & C de proveedores de antivirus y recibir quejas de las agencias de aplicación de la ley (no es suficiente qué infraestructura escaneará este host) - después de todo, puede haber KII, y el análisis de vulnerabilidades se refiere a incidentes que deben informarse a GosSOPKA). Después de tales argumentos, el cliente aún decidió comprender con más detalle y cumplir con nuestras recomendaciones. Y fueron los siguientes:
- cierre todos los puertos, excepto 80 y 443 (esto resultó ser la decisión correcta, porque después de 445 siguió un escaneo en el puerto 22),
- introducimos restricciones en la velocidad de la entrega de Internet,
- active chips UTM, incluido el control de aplicaciones, y corte categorías extrañas como torrents, navegadores TOR, escáneres detectados y más,
- active el límite en el número de conexiones por intervalo de tiempo.
El cliente nunca pudo descubrir quién era este usuario activo de Wi-Fi, pero al menos lo bloquearon con oxígeno (y, lo más probable, el atacante fue a buscar el próximo Wi-Fi disponible).
Unos meses más tarde, este piloto se cerró con éxito y se transfirió al contrato, pero aún encontramos casos similares en compañías completamente diferentes, por lo que las recomendaciones anteriores se pueden clasificar como universales.
Por defecto, o sabotaje de proveedores
En paralelo con la conexión piloto a la monitorización Solar JSOC, el cliente encargó un nuevo UTM. La migración a ella fue gradual: primero transfirió la ACL a través de las subredes, luego las políticas de la aplicación. El postre es el más interesante.
Todo sucedió según los clásicos, el viernes por la noche. La primera línea registró percances al contactar a la infraestructura del cliente para los nodos TOR, apareciendo como C&C en una de las listas de correo de FinCERT. Como el proyecto era piloto y el cliente transfirió todos los incidentes a Low-criticity, no se proporcionó una tarjeta de incidente, además de la notificación por correo, una tarjeta de incidente. Por lo tanto, la primera operación desde diferentes hosts a una dirección, aunque despertó sospechas entre los ingenieros de monitoreo, no se intensificó aún más. Cuando el número de viajes llegó a tres, los chicos sintieron que algo andaba mal e informaron al analista que llevó el incidente al trabajo.
Primero, el analista contactó a los empleados responsables del cliente y sugirió conectar hosts en el nivel de registro local para identificar la fuente de actividad. En el momento de la discusión con los especialistas del cliente, el número de hosts había aumentado a 7. La situación era muy similar a la epidemia, pero el antivirus en los hosts funcionaba y era silencioso, no hubo acciones activas e interacciones de host en la red.
La conexión de tres hosts en el nivel de registro local tampoco dio una idea de qué proceso generó la actividad. La ansiedad creció, la única opción de trabajo era el aislamiento de los hosts con la eliminación paralela de un volcado de RAM y la imagen del disco duro. El analista comenzó a preparar instrucciones y, al mismo tiempo, decidió buscar en Google la IP a la que accedían los hosts para conocer la disponibilidad en otros correos e incidentes (porque el tipo de actividad que observamos era diferente de la descrita en el boletín FinCERT). En su mayor parte, la idea es bastante miserable, pero esta vez no.
Se llamó la atención sobre el artículo en cuyo título figuraban la dirección IP y el nombre del proveedor de UTM. Para resumir la esencia de la publicación, el proveedor compró una dirección IP que anteriormente pertenecía al nodo TOR, que apareció en el boletín FinCERT. ¡Y esto no es solo todo! Además, el proveedor decidió hacer que esta dirección sea predeterminada para la redirección de todas las llamadas sospechosas de la infraestructura de sus clientes a direcciones potencialmente maliciosas. Es decir, cualquier conexión con una dirección IP extraña fue interpretada por UTM como ilegítima y redirigida a esta dirección milagrosa.
Después de especificar si el módulo de protección antimalware ya está activado y haber recibido la confirmación, el analista y los especialistas del cliente exhalaron.
PS El análisis de las fallas que UTM detectó confirma que las 7 actividades fueron Falso Positivo.
Prometimos recomendaciones para cada caso, pero aquí, tal vez, solo daremos una: no despliegue el viernes. Y advertir a todos los interesados y simpatizantes.
Historicamente
Este leitmotif reúne una amplia variedad de casos. Tome el desmantelamiento, por ejemplo. A menudo, los procesos que han perdido relevancia en las empresas simplemente se olvidan: nadie "analiza" la infraestructura anterior, dejando las antiguas máquinas virtuales, servidores y accesos a la red. Al mismo tiempo, nadie monitorea actualizaciones, antivirus y eventos en estos hosts, e incluso los administradores a menudo no conocen a los propietarios de los sistemas. Por lo tanto, después de un tiempo, tales elementos de infraestructura no presentan las sorpresas más agradables. ¡Cuánto cuesta solo enviar telemetría significativa de una organización ambiental en un proyecto completado en 2005 a servidores FTP de un país no amigable!
A menudo, nadie se ocupa del mantenimiento de sistemas de 10 años, aunque continúan utilizándose. Por ejemplo, un portal de restablecimiento de contraseña que utiliza el motor antiguo y para la comodidad de los usuarios mira en Internet, o RDP, que el contratista necesita para configurar aplicaciones comerciales y sobresale durante 5-6 años.
La existencia de tales problemas generalmente se conoce cuando:
- el host fue pirateado y el cifrado se produjo con más extorsión (últimamente ha habido muchos incidentes de este tipo),
- hay una migración de una solución en el perímetro a otra,
- llegamos al piloto y recopilamos el perfil de los puertos abiertos en el perímetro.
Pero también hay situaciones completamente míticas: en 2013, la compañía construyó un túnel con un contratista al servicio de su sistema financiero. El contrato finalizó, pero el túnel permaneció, ya que fue realizado por la compañía a la que el contratista alquiló las instalaciones junto con la infraestructura de TI. Una nueva compañía tomó el mismo lugar y se sorprendió al encontrar las direcciones disponibles de la infraestructura de otras personas. La curiosidad se hizo cargo, y luego la tentación y la sed de lucro. Lanzaron una base de datos de contrapartes y contratos al ruido; el beneficio de la competencia fue interesante, pero nadie hizo ruido en la empresa víctima. La historia duró más de un año (no fue posible rastrear más a lo largo de los registros), pero al final, la investigación, los despidos y la guinda del pastel son un caso penal.
AWOL, o porque es más conveniente
El caso en su conjunto es bastante trivial, lo que no se puede decir sobre la "metodología de implementación".
Dado:
- proyecto piloto de monitoreo del cliente;
- fuentes conectadas en el perímetro, así como entre los segmentos corporativo y tecnológico;
- administrador de turno en el lugar de trabajo y sirviendo al segmento de red cerrado;
- el agudo deseo del administrador es trabajar menos, dormir más y hacer todo con comodidad.
Como ya dije, cuando nos conectamos, le pedimos al cliente información diversa, incluidas las direcciones blancas, para recopilar estadísticas sobre las conexiones a ellas desde Internet y así formar un perfil perimetral externo. Después de haber creado una regla que llena la lista en SIEM, en aproximadamente una semana o dos recopilamos estadísticas sobre todos los puertos abiertos en el perímetro, la descargamos al cliente, la observamos y la arreglamos (mientras cerramos lo que es ilegítimo). Recopilando información para el perfil, revisamos periódicamente la lista, verificando que los puertos estén abiertos a todas o solo a algunas direcciones en las listas blancas. Se llamó la atención sobre el puerto 43388, que parecía no ser notable, pero se transmitió en 3389 y la dirección gris, cuyo propietario desconocíamos para nosotros en ese momento.
Al verificarlo resultó que está cerrado a nuestras direcciones. Pensamos que estaba abierto en las listas blancas, pero durante el día no observamos ninguna conexión exitosa con él. Al llegar a la mañana siguiente, nuevamente notaron que un paquete de eventos había llegado durante la noche. Esta vez observamos más de cerca las direcciones de origen y vimos varias sesiones desde Moscú con una duración total de más de 5 horas y un número bastante grande de sesiones cortas de todo el mundo. Luego quedó claro que el punto no era que el puerto fuera accesible solo a las direcciones de la lista blanca, sino que se abría solo de noche, de aproximadamente 00.00 a 06.00 de la mañana. Después de desenterrar los registros del dominio y el antivirus (ya se habían conectado en ese momento), nos sorprendió descubrir que la dirección pertenece al administrador de turno, ¡que debería estar en el lugar de trabajo durante este intervalo de tiempo! Después de analizar las conexiones desde su automóvil, encontramos otra situación interesante: todas las noches, el puerto también se abría (creo que no es difícil adivinar cuál) en el segmento dedicado cerrado. Es casi imposible notar tal actividad en el cuarto día del piloto, para ese momento el número de conexiones permitidas entre segmentos es aún más que los puertos abiertos en el perímetro. Habiendo informado a los guardias de seguridad sobre la situación, conectaron al host en el nivel de registro local y se aseguraron de que el administrador escapara silenciosamente a casa del trabajo. Al final resultó que, él vivía casi en una casa vecina, y la conexión remota, por supuesto, se convirtió en una gran tentación.
Quizás si el administrador describiera la situación, se le permitiría trabajar de forma remota a través de SKDPU, siempre que en el momento del accidente pudiera venir a trabajar en 15 minutos, y no habría ningún problema.
Total
En realidad, una de las principales amenazas para la seguridad de la información es la desarticulación. Por lo tanto, minimice los riesgos:
- Realice un seguimiento de las configuraciones de perímetro y firewall.
- Intente hacer que el control remoto en una empresa sea administrado (VPN a través de un servidor terminal). Y si ya existe, controle quién lo usa (eliminando varias RAT en hosts que ahora detectan fácilmente casi todos los motores antivirus).
- Siga las acciones de los usuarios privilegiados: muy a menudo pierden la vigilancia, creen que tienen todo bajo control y facilitan el acceso de los atacantes a los datos críticos.