Antecedentes
A última hora de la noche del 16 de abril de 2026 (UTC), Huntress registró un conjunto de detecciones de alta gravedad en una sola estación de trabajo, [REDACTED-WRKSTN], en uno de los entornos de nuestros socios. Las señales de Huntress Managed EDR le contaron al SOC una historia conocida: un cmd.exe que se genera como servicio, un patrón de nombre de servicio al estilo de smbexec.py, una cuarentena de Microsoft Defender en un archivo etiquetado como svchost.exe identificado como Behavior:Win32/RegDump.SA; pero el final de la cadena de detección era nuevo: una línea de PowerShell que descargaba un instalador desde raw.githubusercontent[.]com/komari-monitor/komari-agent y lo configuraba como un servicio SYSTEM llamado “Windows Update Service”.
Los analistas del SOC y del equipo Hunt de Huntress han pasado los últimos dos años documentando la constante desviación de configuración de herramientas de DFIR y administración de sistemas de código abierto hacia el arsenal de los atacantes: Velociraptor, SimpleHelp, Net Monitor for Employees, ScreenConnect, AnyDesk, Nezha, y Atera. Komari es la nueva incorporación a esa lista, y resulta particularmente reveladora porque, a diferencia de las otras herramientas de esa lista, Komari no necesita ningún abuso para funcionar como canal de comando y control (C2). El canal de control viene habilitado de forma predeterminada. No hace falta convertirla en arma; basta con apuntarla a un servidor que “te pertenece” y escribir un comando de instalación.
Lo que sigue es la historia de esa intrusión en el orden en que ocurrió realmente: una estación de trabajo, [REDACTED-WRKSTN]. Una cuenta comprometida, [User 1]. Un nuevo C en escena.
Acceso inicial: El SSLVPN
El primer evento de esta historia no ocurre en la estación de trabajo, sino en el FortiGate. El 16 de abril de 2026 a las 23:23:33 UTC, se estableció una nueva sesión SSLVPN desde la IP remota 45.153.34[.]132 y se autenticó como [User 1]:
Nota: Las marcas de tiempo de FortiGate son locales -0500; suma 5 horas para obtener los valores UTC que usamos en el resto de esta publicación.
Dos detalles a tener en cuenta. Primero, remip=45.153.34[.]132 se resolvió como VMHeaven[.]io (Países Bajos), ASN 51396, un proveedor de hosting/VPS que hemos visto en intrusiones anteriores usado tanto como salida de SSLVPN como servidor de preparación (según nuestros recursos externos de inteligencia de amenazas). Segundo, tunnelip=10.212.134[.]200 es la dirección que FortiGate asignó a la sesión SSLVPN; es la IP de origen que aparecerá en todos los eventos de inicio de sesión posteriores al compromiso en [REDACTED-WRKSTN] durante los siguientes veinte minutos.
Enumeración desde el túnel VPN
Una vez que el túnel estuvo activo, el laptop del operador —que se identificaba ante Active Directory con el nombre de estación de trabajo VM8514— comenzó a acceder al entorno del socio desde 10.212.134[.]200. Ese nombre de estación de trabajo, VM8514, no es algo que el socio asigne. Es un nombre predeterminado forénsicamente "barato", típico de una máquina virtual recién clonada, el tipo de etiqueta que un operador podría dejar en una VM desechable si está actuando con rapidez. El patrón ("VM" + cuatro dígitos, sin sufijo de dominio, sin prefijo de etiqueta de activo) es uno que hemos visto repetirse en intrusiones de operadores de productos básicos, donde el actor trabaja desde infraestructura desechable en lugar de un equipo de ataque dedicado.
[REDACTED-WRKSTN] fue la estación de trabajo de destino, y a partir de las 23:37:41 UTC, los inicios de sesión de red tipo 3 como [User 1] desde 10.212.134[.]200 comenzaron a acumularse en el registro de eventos de seguridad de la estación de trabajo.
Remote Registry y una intervención de Defender
A las 23:38:00 UTC, Remote Registry se activó en [REDACTED-WRKSTN]:
2026-04-16 23:37:00 UTC svchost.exe -k localService -p -s RemoteRegistry
A las 23:39:52 UTC, services.exe ya había generado el primero de una cadena de cinco comandos de smbexec.py , un cd de una línea como comprobación de que el método de ejecución remota funcionaba:
Esta es una forma clásica de salida de smbexec.py de Impacket sobre SMB: %COMSPEC% /Q /c echo, con la salida redirigida a \\<COMPUTERNAME>\C$\__output_<random>, un archivo por lotes de 8 caracteres con nombre aleatorio en disco, y autoeliminación inmediata.
Un instante después, a las 23:39:55 UTC, el Event ID 7040 del sistema registró la transición de Remote Registry de deshabilitado a inicio bajo demanda, atribuida al SID S-1-5-21-...-1153, el SID de dominio de [User 1].
Para las 23:40:02 UTC, Windows Defender tenía algo que decir al respecto. El Event ID 1116 se activó en svchost.exe con el nombre de amenaza Behavior:Win32/RegDump.SA, y fue puesto en cuarentena.
Figura 4: Detección de Huntress para RegDump.SA en el equipo [REDACTED-WRKSTN]
RegDump.SA es la firma de comportamiento de Microsoft para el volcado de hives del registro: el tipo de acción que realizan reg save, reg export, o (más común en IR moderno) secretsdump.py de Impacket cuando accede mediante MS-RRP/WINREG para extraer los hives SAM, SYSTEM y SECURITY de un equipo remoto. El artefacto depositado, C:\Windows\Temp\aRhRnnHI.tmp, coincide con el perfil de tamaño de un extracto comprimido de un hive del registro. Aunque Defender puso en cuarentena con éxito el archivo de preparación, el actor de amenazas ya había escalado a SYSTEM en el endpoint; la acción maliciosa que generó el volcado ya se había completado.
El actor ahora tenía dos opciones: hacer más ruido y volver a intentarlo con un método diferente de volcado de hive, o cambiar todo el enfoque.
Spoiler: cambiaron el enfoque.
El giro hacia RDP mediante smbexec.py
Entre las 23:40:07 y las 23:40:41 UTC, la misma cadena de smbexec.py ejecutó los cuatro comandos que realmente importan. Los cuatro tenían como proceso principal el mismo services.exe que se ejecutaba bajo el contexto privilegiado NT AUTHORITY\SYSTEM, la firma distintiva de smbexec.py de Impacket usado como ejecutor de comandos lateral.
Los cuatro nombres de archivo por lotes aleatorios de 8 caracteres (SCnRMUvT, BPzrQOLa, HBBJLmCW, PlYHZsEC), junto con el sufijo coincidente _iDhLsdpD en el pipe __output, son la pista reveladora: lo más probable es que sea el resultado de la función randomString() de smbexec.py. El Impacket estándar viene con un nombre de servicio estático BTOBTO y un nombre de archivo __output simple, así que el hecho de que veamos artefactos aleatorios nos indica que el operador estaba usando una bifurcación personalizada de smbexec diseñada para evadir la detección.
Unidos, los cuatro comandos (después de la verificación inicial de “cd”) hacen tres cosas:
- Un "reg add" que cambia HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\fDenyTSConnections de 1 a 0, pasando RDP de "deny" a "allow" en todo el sistema.
- Una regla de "netsh advfirewall" llamada "Allow RDP" que abre el puerto entrante TCP/3389.
- El par "net stop termservice /y" y "net start termservice", que reinicia la pila de Terminal Services para que los cambios en el registro y el firewall surtan efecto de forma limpia.
En conjunto, esto es un kit clásico de habilitación manual de RDP: el tipo de acción que solemos ver como precursor del acceso interactivo y, muy a menudo, de la implementación de ransomware.
El salto a RDP
Ahora que RDP está escuchando en TCP/3389, el operador abandonó el método automatizado de smbexec.py y cambió a una sesión interactiva. A las 23:44:03 y 23:44:05 UTC, se produjeron dos inicios de sesión de red de Tipo 3 como [User 1] en [REDACTED-WRKSTN] desde 10.212.134[.]200, esta vez con el nombre de estación de trabajo VM8514.
Dos segundos después, a las 23:44:07 UTC, el RemoteConnectionManager de Terminal Services registró el evento con ID 1149, “User Authentication Succeeded” (autenticación de usuario exitosa) para [User 1], seguido de inmediato a las 23:44:08 UTC por el evento LocalSessionManager con ID 25 (“RDP Session Connected”) desde el mismo origen 10.212.134[.]200:
2026-04-16T 23:44:07.331Z
Microsoft-Windows-TerminalServices-RemoteConnectionManager/1149
Computer: [REDACTED-WRKSTN].[REDACTED].local
User: [User 1]
Domain: [REDACTED].local
IP: 10.212.134[.]200
2026-04-16T 23:44:08.977Z
Microsoft-Windows-TerminalServices-LocalSessionManager/25
"RDP Session Connected"
Computer: [REDACTED-WRKSTN].[REDACTED].local
User: [REDACTED]\[User 1]
IP: 10.212.134[.]200
Cincuenta segundos después, a las 23:44:58 UTC, el gráfico de procesos muestra la primera acción "humana" en la sesión RDP: cmd.exe, generado por Explorer.EXE y con proceso padre el userinit.exe de [User 1]. No más instalaciones de servicio de smbexec.py. No más redirección de salida a \\C$\__output_.... El atacante ahora estaba escribiendo directamente en un símbolo del sistema.
Escribiendo en el símbolo del sistema: la instalación
A las 23:45:00 UTC, el símbolo del sistema produjo el comando que es la razón de ser de este blog:
Y ahí está: el script de instalación, en todo su esplendor, obtenido directamente del repositorio oficial de Komari en GitHub, sin proxy, sin acortador de URL y sin ningún intento de ocultar el origen.
¿Y por qué lo ocultarían? Es el instalador legítimo de una herramienta legítima. Si un proveedor de detección (o un ingeniero de endpoints molesto) bloquea raw.githubusercontent[.]com, rompe mucho más de lo que detecta.
Sobre la divulgación responsable: el servidor C2 de Komari del operador ha sido ocultado en esta publicación. Nuestra visibilidad sobre esta infraestructura sugiere que otras organizaciones fuera de la base de socios de Huntress están emitiendo señales hacia ella actualmente, y estamos coordinando con las partes correspondientes para notificar a esas víctimas.
Figura 7: Captura de pantalla de un agente de Komari instalado en una VM interna "infectada" de Huntress, registrado como Windows Update Service mediante nssm y emitiendo señales hacia 172.16.57[.]149:25774
Komari no es (solo) una herramienta de monitoreo. Es un C2.
Lo primero que notas al leer la documentación de Komari es que el proyecto no intenta ocultar sus capacidades. En la página del repositorio de GitHub (github.com/komari-monitor/komari), las tres etiquetas de tema que eligieron los mantenedores son remote-control, monitoring y monitoring-tool. "Control remoto" no es una capa de armamentización que estemos infiriendo: es la primera palabra en la propia autodescripción del proyecto en la barra lateral. El repositorio tiene licencia MIT, 4.3k estrellas, 407 forks, 46 lanzamientos y desarrollo activo; el último lanzamiento al momento de escribir esto (v1.1.9) salió el 30 de marzo de 2026.
De la documentación del protocolo del agente en komari-document.pages.dev/dev/agent.html:
Komari Agent es un agente de monitoreo de sistema liviano que se comunica de forma bidireccional con el servidor a través de WebSocket y HTTP.
Figura 8: Captura de pantalla del panel de administración de Komari en /admin, que muestra la fila de acciones por nodo para una VM interna "infectada" de Huntress: victim1 (v1.1.9). La acción interactiva "Terminal" aparece en línea junto a los íconos de descarga, edición, facturación y eliminación: el acceso interactivo a shell es una función "de primera clase" predeterminada de la interfaz de monitoreo, no una opción de desarrollador escondida. Se ocultó la IP pública.
“Bidireccionalmente” es la palabra clave. El agente no "recopila telemetría y la reporta". El agente abre un WebSocket persistente hacia el servidor, lo mantiene abierto, transmite telemetría cada segundo de forma predeterminada, y acepta eventos de comandos de vuelta por el mismo socket. Hay tres tipos de estos eventos de servidor a agente. Los tres vienen activados de forma predeterminada. La bandera de exclusión, --disable-web-ssh, es exactamente eso: de activación voluntaria. Un atacante que ejecuta la instalación predeterminada de un clic obtiene las tres capacidades sin mover un dedo.
La autenticación es un token de portador que se pasa como parámetro de consulta en la URL; el operador lo genera en su propio panel de Komari cuando registra un nuevo agente. En nuestra intrusión, ese token fue vomtLDXyggveYfjFxdoo7Z. La bandera estándar de fábrica --ignore-unsafe-cert significa que los certificados TLS autofirmados en el servidor del atacante se aceptan sin ningún reclamo.
El protocolo: un WebSocket, tres eventos
El agente abre un WebSocket persistente hacia ws(s)://<server>/api/clients/report?token=<token> y lo mantiene activo indefinidamente, reconectándose automáticamente si se corta. En la red, el tráfico es indistinguible de cualquier otra sesión HTTPS de larga duración: no hay una cadencia de baliza que identificar, ningún puerto inusual (el operador casi siempre usa un proxy inverso hacia el puerto 443), y ninguna anomalía de JA3/JA4, porque el TLS es el que negocie el servidor web que lo expone.
Tres eventos llegan por ese canal.
- Exec: ejecución de comandos arbitrarios
{
"message": "exec",
"task_id": "<unique-identifier>",
"command": "<shell-command-string>"
}
El agente ejecuta el comando mediante PowerShell en Windows (o sh en Linux), captura stdout/stderr/el código de salida, y envía el resultado mediante POST a /api/clients/task/result?token=<token>. Eso es ejecución de comandos arbitrarios con salida capturada, funcionalmente equivalente al método de shell en cualquier framework de C2 convencional. En el equipo con Windows, los eventos exec generan procesos hijos PowerShell.exe de komari-agent.exe, que ejecutan la cadena de texto que el operador haya escrito en la interfaz web.
- Terminal: shell inverso PTY interactivo
{
"message": "terminal",
"request_id": "<session-id>"
}
Cuando ocurre este evento, el agente abre un segundo WebSocket hacia /api/clients/terminal?token=<token>&id=<request_id> y establece ahí un shell interactivo: un shell inverso con toda la semántica PTY, controlado desde el navegador del operador. En Linux, ese shell es root; en Windows, dado que el servicio gestionado por NSSM se ejecuta como LocalSystem, el shell es SYSTEM.
- Ping: reconocimiento de red distribuido.
{
"message": "ping",
"ping_task_id": 123,
"ping_type": "icmp|tcp|http",
"ping_target": "<destination-address>"
}
A primera vista, esto es monitoreo: "¿Los equipos que me importan están disponibles?". Para un actor de amenazas con una flota de equipos comprometidos, cada uno con un agente en ejecución, se trata de un reconocimiento distribuido: los pings TCP en puertos arbitrarios son un escáner de puertos, los pings HTTP contra URLs arbitrarias son una sonda web, y cada sondeo se origina en la red de una víctima en lugar de en la infraestructura del operador.
NSSM: cómo Komari se convierte en persistencia
NSSM no necesita que un atacante invente nada. Toda su función es "convertir un .exe arbitrario en un servicio de Windows que se reinicia cuando falla, registra su salida y se ejecuta al iniciar el sistema". El instalador de Komari invoca NSSM en la secuencia exacta capturada en el historial de procesos de la estación de trabajo, a partir de las 23:45:08 UTC:
Figura 9: Los seis comandos de NSSM que registran komari-agent.exe como un servicio de inicio automático a nivel de SYSTEM llamado "Windows Update Service" y el C2 del operador codificado directamente en AppParameters
Seis líneas. Eso es la persistencia. La entrada de servicio resultante en el registro muestra la forma completa del envoltorio (preservada textualmente a partir del análisis forense de la estación de trabajo):
Figura 10: La clave de registro Parameters de "Windows Update Service" extraída forensemente de la estación de trabajo, que muestra la configuración del agente Komari
A las 23:45:08.908 UTC, el Service Control Manager inicia komari-agent.exe como SYSTEM bajo services.exe. Este es el proceso de C2 persistente: el demonio de larga duración que mantiene abierto el WebSocket saliente hacia /api/clients/report durante todo el tiempo que el servicio siga en ejecución.
Tres segundos después, a las 23:45:11.936 UTC, un segundo komari-agent.exe se dispara en el contexto de usuario de [User 1] con --show-warning, generado por el proceso padre SYSTEM. Este es de un solo uso: existe para ejecutar el primer barrido de inventario de primer contacto del agente. 48 milisegundos después de iniciarse, a las 23:45:11.984 UTC, genera un proceso hijo de PowerShell que lee un script de un solo uso colocado en el directorio temporal del usuario:
PowerShell -ExecutionPolicy Bypass -File C:\Users\[User 1]\AppData\Local\Temp\102184ef-a26d-4fb6-4bff-d4e4bd5e8de0.ps1
Ese .ps1 es el recolector estándar uploadBasicInfo del agente: un único POST /api/clients/uploadBasicInfo?token=... que lleva arch, cpu_cores, cpu_name, disk_total, ipv4, ipv6, mem_total, os, kernel_version, virtualisation y cada otro campo que el panel del operador quiera mostrar (según la documentación para desarrolladores aquí). En Elastic, toda la secuencia aparece como una cadena limpia de padre e hijo que llega hasta nssm.exe:
Figura 11: Árbol de procesos que muestra la relación entre smbexec.py y komari-agent.exe en [REDACTED-WRKSTN]
Ese proceso hijo de PowerShell es la señal visible de que el servidor del operador acababa de ver al agente conectarse: se envió la huella digital del equipo, el agente dio la señal de inicio y el canal de C2 quedó activo. Desde ese momento, ya no se necesitaba la sesión de RDP.
Cuatro minutos después, a las 23:49:22 UTC, el Event ID 24 de LocalSessionManager registró la desconexión de la sesión de RDP.
2026-04-16T23:49:22.126Z
Microsoft-Windows-TerminalServices-LocalSessionManager/24
"RDP Session Disconnected"
Computer: [REDACTED-WRKSTN].[REDACTED].local
User: [REDACTED]\[User 1]
IP: 10.212.134[.]200
El operador ya tenía lo que buscaba: un canal de comando persistente, a nivel SYSTEM, con fachada TLS, disfrazado con el nombre "Windows Update Service". Ya no necesitaba escribir en un símbolo del sistema; Komari era el canal. Desde las 23:49:22 UTC en adelante, no se registraron más sesiones de RDP en [REDACTED-WRKSTN], no hubo más eventos de autenticación para [User 1], y el túnel SSLVPN quedó prácticamente en silencio hasta que FortiGate lo cerró por tiempo de inactividad. El operador había cambiado una sesión interactiva ruidosa por un WebSocket silencioso, persistente y con privilegios de nivel SYSTEM.
Entonces, ¿qué le dio Komari al operador?
Komari se comercializa como supervisión de servidores, pero, como lo aclara su propia documentación, Komari es un conjunto de supervisión con un plano de control integrado que el proyecto considera una función de primera clase. Si nos alejamos de los tres eventos, la forma operativa es clara: un controlador, muchos agentes, ejecución arbitraria de comandos por agente. Como muestra la figura 12, si un actor multiplica esto en 100 redes de víctimas, el resultado es la arquitectura básica de un botnet ligero con una interfaz web limpia. Komari no incluye un módulo de DDoS ni propagación tipo gusano, así que no intenta ser Mirai ni uno de sus derivados, pero para un operador que controla una red de víctimas comprometidas, el conjunto de capacidades ya está ahí. Lo desconcertante es que el mismo binario, la misma unidad de systemd y el mismo flujo de WebSocket también son el patrón de implementación legítimo para ejecutar Komari en tu propio laboratorio casero. La herramienta en sí está bien. El problema es el conjunto de capacidades que se convierte en C2.
Figura 12: Captura de pantalla del panel de ejecución remota de Komari enviando Invoke-AtomicTest T1003.001-TestNumbers 2 (volcado de memoria de LSASS mediante comsvcs.dll) contra una máquina virtual interna de Huntress “infectada”
Vale la pena notar que el repositorio de Komari incluye un directorio compat/nezha, una capa de compatibilidad para el agente de supervisión Nezha, que ya tiene antecedentes de haber sido usado indebidamente como C2 disfrazado de herramienta de supervisión en entornos reales.
Entonces, ¿qué hizo Huntress?
La combinación de señales—smbexec, la cuarentena de RegDump.SA de Defender, la descarga sospechosa de iwr desde GitHub, y la nueva persistencia a través del Windows Update Service con nssm.exe como el binario registrado—fue clasificada como un incidente de alta severidad dentro del SOC.
Los analistas de inmediato:
- Aislaron la estación de trabajo afectada ([REDACTED-WRKSTN]) al momento de la detección.
- Deshabilitaron a [User 1] en el controlador de dominio primario del socio para eliminar la credencial comprometida.
Aunque Defender había puesto en cuarentena los hives extraídos, la falta de MFA en todo el entorno significaba que varias credenciales podrían seguir en juego—suficiente para que ocurriera un movimiento lateral a través del SSLVPN. En lugar de esperar para confirmarlo, aislamos todos los dispositivos en la red del socio para evitar que más usuarios comprometidos pudieran autenticarse.
El aislamiento también ocurrió antes de que el operador emitiera su primera tarea de ejecución desde el panel de Komari; no se observó ninguna ejecución de comandos ni sesiones de terminal posteriores a la instalación en el endpoint.
Para cuando el socio llamó por teléfono, la persistencia estaba eliminada, el WebSocket estaba cerrado, la ruta de RDP estaba bloqueada, y el token de inicio de sesión de [User 1] ya no era válido. Huntress además brindó un informe completo de remediaciones inmediatas para que el socio las siguiera y así restablecer su entorno lo antes posible.
Conclusión
Komari no es la primera herramienta legítima que termina en este blog, y no será la última. Lo que la hace merecedora de su propia publicación es que el enfoque de "legítima vs. convertida en arma" que solemos usar—el que funciona para Velociraptor, SimpleHelp, y el stack de RMM—no aplica aquí. Con Komari, el plano de control no es una capa secundaria de abuso. Es el conjunto de funciones predeterminado. Los mantenedores etiquetan el repositorio como remote-control. El instalador viene con exec, terminal, y ping habilitados por defecto. No conviertes a Komari en un arma—simplemente la apuntas a un servidor que "controlas" y escribes un comando de instalación.
Un actor de amenazas entró con credenciales de VPN robadas, se movió lateralmente mediante smbexec.py de Impacket, e instaló un agente de monitoreo de código abierto con 4.3k estrellas como puerta trasera a nivel SYSTEM, disfrazado como el "Windows Update Service". Sin cargador personalizado, sin preparación controlada por el atacante—el instalador vino directamente de GitHub.
Komari le da a cualquier operador ejecución arbitraria de comandos, una reverse shell PTY interactiva, y sondeo de red por defecto, a través de un WebSocket con fachada TLS que luce idéntico a cualquier otra sesión HTTPS en la red. Escala eso a través de una flota de endpoints comprometidos, y tienes la arquitectura de un botnet ligero con una interfaz web limpia—y las instrucciones de instalación están en un sitio de documentación público.
Para este socio, quedó contenido. Huntress aisló [REDACTED-WRKSTN], deshabilitó a [User 1] en el controlador de dominio, y cortó el WebSocket antes de que el operador emitiera una sola tarea de ejecución. Sin sesiones de terminal, sin movimiento lateral, sin pérdida de datos. Para los defensores que no detectan el evento de instalación, el resultado se ve muy distinto: un canal de comandos persistente a nivel SYSTEM que tal vez nunca logren identificar únicamente con la telemetría de red.
Comparte los IoC específicos en la tabla a continuación—el nombre del binario, el nombre del servicio, la ruta de instalación, y la huella del registro. Estos atraparán a este operador en esta campaña. Pero construye tu búsqueda duradera en torno a la forma de la herramienta, no a su nombre: cualquier proceso que mantenga un WebSocket saliente de larga duración hacia un destino con el que el entorno no suele comunicarse, y que genere periódicamente shells o sesiones de PowerShell no iniciadas por el usuario. Eso atrapará a Komari hoy, a Nezha mañana, y a cualquier C2 con apariencia de monitoreo que aparezca en GitHub la próxima semana.
El repositorio en sí no es el problema. El patrón de uso malicioso que lo rodea tampoco lo es, porque para Komari, el conjunto de capacidades es el conjunto de funciones. El problema es que, en proyectos como este, el límite entre "monitoreo autoalojado" y "C2 autoalojado" no existe.
Es una herramienta limpia y modular, y justo por eso aparece en la estación de trabajo de alguien más.
Indicadores de compromiso (IoC)
Hashes de archivos (SHA-256)
|
Elemento |
Descripción |
|
039e659ade3aa8ee7758c11fdb8fbfffd2491920046d638413cea2042f6d584c |
komari-agent.exe |
Indicadores de red
|
Elemento |
Descripción |
|
45.153.34[.]132 |
Origen de ingreso SSLVPN |
|
[C2 malicioso redactado]: 55964 |
Servidor Komari del operador |
|
hxxps://raw.githubusercontent[.]com/komari-monitor/komari-agent/refs/heads/main/install.ps1 |
URL del script de instalación del agente Komari |
|
10.212.134[.]200 |
IP del túnel SSLVPN asignada por FortiGate |
|
TCP/25774 |
Puerto predeterminado del servidor Komari; por lo general, los operadores lo redirigen mediante proxy inverso al puerto 443 |
Artefactos del sistema de archivos
|
Elemento |
Descripción |
|
C:\Windows\System32\komari-agent.exe |
Agente de Komari |
|
C:\Windows\Temp\aRhRnnHI.tmp |
RegDump.SA |
Persistencia / registro
|
Elemento |
Descripción |
|
HKLM\System\CurrentControlSet\Services\Windows Update Service |
Entrada de servicio de Windows registrada por NSSM como persistencia para Komari. |
|
...\Windows Update Service\Parameters\Application |
C:\Windows\System32\komari-agent.exe |
|
...\Windows Update Service\Parameters\AppParameters |
-e http://[Malicious C2 Redacted]:55964 -t vomtLDXyggveYfjFxdoo7Z |
|
...\Windows Update Service\Parameters\AppDirectory |
C:\Windows\System32 |
|
...\Windows Update Service\Parameters\AppRestartDelay |
5000 (REG_DWORD-reinicio automático de NSSM). |
|
Service DisplayName |
Komari Agent Service |
|
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\fDenyTSConnections |
Cambiado a 0 (RDP habilitado) mediante una adición de registro impulsada por smbexec.py. |
Indicadores del atacante y de la cuenta
|
Elemento |
Descripción |
|
VM8514 |
Nombre de estación de trabajo controlada por el atacante observado en el campo WorkstationName del Event ID 4624 para los inicios de sesión de [Usuario 1] desde 10.212.134[.]200 |
![Los 36 ciberataques más comunes [2026]](https://images.huntress.com/asset/file/36014deeb67545a0a0d94cdfa4b9b0db)
