Recibir un reporte de incidente es estresante. Recibes una alerta que te dice que algo malo pasó en un dispositivo, se cortó su acceso a la red, y ahora tienes una lista de remediaciones que hacer antes de volver a conectarlo. Estás tratando de entender el reporte que Huntress acaba de enviarte, mientras recibes llamadas de tu cliente preguntando por qué no tiene acceso a internet.

Y las cosas pueden empeorar. Los hackers no siempre trabajan de 9 a 5, así que un reporte de incidente puede llegar a tu bandeja de entrada en plena madrugada o un fin de semana, dejándote con poco tiempo para resolver todo antes de que tu cliente vuelva a la oficina el lunes.

Nuestros reportes de incidente buscan un equilibrio: ser lo bastante detallados para informar, pero lo bastante concisos para ayudarte a actuar rápido. Pero a veces, el reporte por sí solo no basta para explicarte del todo lo que pasó.

Ahí es donde entra el Soporte del Centro de operaciones de seguridad (SOC). Puedes contactarnos en cualquier momento, y te explicaremos el incidente desde la perspectiva de los analistas del SOC aquí en Huntress, sin importar qué tan grande o pequeño sea el incidente.

El siguiente ejemplo muestra uno de esos casos, donde el equipo de Soporte del SOC pudo dar valor adicional a un socio que enfrentaba un incidente de seguridad.

Recorrido de un ticket

Este ticket destacó uno de los aspectos más valiosos del equipo de Soporte del SOC: colaborar con nuestros socios para construir el panorama completo de un incidente. Nuestros analistas del SOC solo pueden informar sobre lo que vemos desde la perspectiva de nuestro EDR. Pero la seguridad es un esfuerzo en equipo, y al trabajar junto con el socio pudimos armar una cadena de eventos mucho más clara.

Nuestro socio recibió el siguiente reporte de incidente, y tenía algunas preguntas mientras avanzaba con las remediaciones. 

Figura 1: Reporte de incidente de Huntress

Al revisar los detalles, el socio notó que otra herramienta de seguridad había disparado una alerta al mismo tiempo. Eso dio pie a preguntas importantes:

• ¿Ambas herramientas estaban alertando sobre lo mismo?

• ¿Aislamos el endpoint porque sentimos que el malware no había sido contenido correctamente?

• ¿Qué alerta llegó primero?

• ¿Qué hizo realmente cada herramienta?

Y, por supuesto, una de las preguntas más importantes—¿qué había que hacer a continuación?

Para responder esas preguntas, necesitábamos determinar la secuencia de eventos tal como ocurrieron. La investigación realizada por nuestro SOC se centró en la ejecución de un proceso con intención maliciosa.

Esto resalta uno de los principales beneficios de nuestro Managed EDR: el enfoque en los comportamientos que usan los atacantes para obtener y mantener acceso, lo que a menudo implica aprovechar herramientas o servicios legítimos para lograrlo. La capa adicional de antivirus (AV) dio otra perspectiva, al marcar la presencia del archivo descargado. Juntos, esto nos ayudó a responder preguntas clave sobre qué pasó, cuándo ocurrió y qué acciones se tomaron para contener la amenaza.

La perspectiva del soporte 

Cuando un socio se comunica con preguntas sobre un reporte de incidente, la prioridad del equipo de soporte del SOC es revisar la investigación desde nuestro lado, empezando por lo que informaron nuestros analistas del SOC y qué pasos de remediación se recomendaron.

Una de las herramientas más útiles que tenemos es la capacidad de revisar la señal específica que activó el reporte:

Figura 2: Pestaña de señales investigadas en el reporte de incidente

En este caso, solo hubo una señal que detectó malware que se descargaba desde un dominio sospechoso.Esto nos da un buen punto de partida: podemos ver de inmediato qué proceso activó nuestra alerta. A menudo, la señal es una que conocemos bien, lo que facilita armar rápidamente el escenario. Pero esta vez, la detección no era una que veamos todos los días, así que ameritaba unanálisis más profundo.

Nuestro siguiente paso fue entender exactamente qué activó esta detección y por qué.

Figura 3: Descripción de la regla desde el panel interno

La imagen anterior se tomó de nuestro panel del SOC, lo que nos ayudó a desglosar la naturaleza de la señal y la lógica detrás del detector.

Después de investigar, determinamos que enviamos este reporte porque vimos un comando ejecutado en esta máquina que estableció una conexión con un dominio listado en el “Living Off Trusted Sites (LOTS) Project”, una base de datos que rastrea sitios web que a menudo se usan de forma indebida en campañas de phishing.

En este punto, teníamos suficiente información para evaluar con confianza que el usuario mencionado en el reporte de incidente probablemente había sido víctima de phishing, y aislamos el endpoint después de ver una conexión establecida con un dominio comprometido que alojaba malware. Con ese contexto, estábamos listos para explicarle al socio el incidente desde la perspectiva de Huntress.

Revisión de la alerta del antivirus

Con una comprensión clara de la actividad que habíamos reportado, el siguiente paso fue revisar la alerta que el socio había compartido para crear una línea de tiempo de los eventos y armar el panorama completo. La alerta en cuestión mostraba que un archivo descargado había sido detectado, puesto en cuarentena y eliminado por el AV.

El archivo se descargó segundos después de la ejecución del comando, y estaba vinculado al mismo perfil de usuario que habíamos visto ejecutar el comando. Además, la alerta del AV tenía la misma marca de tiempo que la incluida en nuestro reporte. Esto fue lo que originalmente llevó al socio a cuestionar la secuencia de eventos: ¿ambos estábamos respondiendo a lo mismo, o se había pasado algo por alto?

En este punto, el panorama se volvía más claro, y parte del lenguaje de nuestro reporte de incidente cobraba más sentido. Nuestro analista del SOC había anotado:

"Esto típicamente intenta ejecutar malware adicional comenzando con un archivo .lnk alojado en este recurso, pero la interacción del usuario parece haber cesado después de acceder inicialmente a este recurso remoto."

En pocas palabras, observamos la conexión inicial al dominio malicioso y esperábamos que descargara un payload secundario, pero en este caso, no vimos evidencia clara de que se hubiera descargado un archivo malicioso.

Respondiendo las preguntas del socio

Ahora que ambos reportes habían sido revisados, pudimos abordar las preguntas específicas del socio.

¿Ambos estábamos alertando sobre lo mismo? ¿Qué ocurrió primero en la línea de tiempo? Nuestra respuesta a continuación abordó directamente la solicitud del ticket del socio sobre las líneas de tiempo de ambas alertas. 

Huntress detectó la ejecución primero, pero la descarga real del malware ocurrió segundos después.

Más específicamente, Huntress Managed EDR detectó el proceso (Rundll32.exe) responsable de comunicarse y descargar el malware. El AV nos alertó sobre el archivo de malware que se descargó desde ese dominio. Esto coincide con las detecciones típicas de las soluciones de AV que realizan análisis de archivos basado en firmas.

Esto explicó por qué ambas alertas tenían marcas de tiempo tan cercanas: nuestro EDR vio el comando ejecutándose, mientras que el AV vio el payload una vez que llegó al disco.

¿Por qué Huntress aisló el endpoint?

Explicamos:

Huntress no aísla un endpoint solo porque haya malware presente; lo hacemos para evitar que siga ejecutándose y para impedir que se propague por la red

Una de las mayores preocupaciones del socio fue por qué Huntress había aislado el endpoint a pesar de que su AV había eliminado con éxito el malware. Esta es una pregunta común y una excelente oportunidad para explicar el valor de EDR frente a AV.

Incluso si una solución de AV elimina con éxito un archivo malicioso, aún existen riesgos:

• El atacante podría haber implementado payloads adicionales antes de que se eliminara el archivo.
• Podrían quedar mecanismos de persistencia que le permitan al atacante recuperar el acceso.
• El malware podría haber ejecutado otros comandos antes de ser puesto en cuarentena.

Al aislar el endpoint, nos aseguramos de impedir la actividad de red del malware, el administrador tuvo tiempo de investigar a fondo en busca de amenazas persistentes, y se preservó la integridad del sistema antes de reconectar el dispositivo a la red.

¿Qué debe hacerse a continuación?

Este ticket fue un ejemplo de interacción con un socio cuando el riesgo era bastante bajo, y un incidente ya se había remediado, pero eso no quedó claro de inmediato para el socio solo a partir del reporte de incidente. Al final de la conversación, el socio comprendió lo que había ocurrido y el propósito detrás de las remediaciones que sugerimos.

Conclusión

El riesgo no siempre es bajo, y muchos incidentes tienen el potencial de causar un daño aún mayor. Lidiar con esos incidentes en solitario puede ser estresante.

El equipo de soporte del SOC está aquí para ayudar a nuestros socios a entender los detalles de nuestros reportes de incidente, o si solo necesitan otro par de ojos revisando cualquier inquietud relacionada con seguridad.