Prometei.Radiografía de una
botnet de criptominería.

Módulos, configuración
e infraestructura.

Durante una auditoría de seguridad con Guardian identificamos un despliegue de Prometei en Windows. Analizamos sus módulos de propagación, recolección de credenciales, actualización, comunicaciones y minería.

Una botnet de criptominería utiliza la capacidad de cálculo de equipos comprometidos para minar criptomonedas por cuenta de su operador. En Prometei, la minería se combina con mecanismos para incorporar otros equipos y administrar los componentes instalados. Por eso investigamos tanto el consumo de recursos como las credenciales, los servicios y las comunicaciones que permiten mantener el despliegue.

El conjunto incluye ejecutables PE, ensamblados .NET, scripts, configuraciones y registros de Tor. Seguimos las referencias de código de rdpcIip.exe, reconstruimos la secuencia que procesa walker.ini y clasificamos los destinos de red según el componente que los utiliza.

El análisis se realizó sobre copias de los artefactos adquiridos. Los resultados combinan desensamblado, transformaciones offline y contraste con publicaciones anteriores sobre Prometei. Las direcciones y offsets permiten localizar las funciones descritas en las muestras de referencia; los datos que identifican a la organización se han omitido.

Alcance del cruce público. La búsqueda de 45[.]158[.]14[.]187 en las referencias y consultas realizadas el 13 de octubre de 2026 produjo cero coincidencias asociadas a Prometei. La conclusión se limita a ese corpus. La clasificación de las muestras sigue siendo Prometei; la versión exacta y la atribución a un operador quedan abiertas.

Arquitectura modular.

Prometei tiene una historia pública de varios años. Talos describió en 2020 una operación de minería de Monero con robo de credenciales y propagación; en 2023 documentó cambios en su estructura y actualización. Investigaciones posteriores muestran que el ecosistema mantiene componentes para Windows y Linux y adapta su infraestructura.¹²⁵

En el conjunto analizado, sqhost corresponde al núcleo; rdpcIip, a propagación y gestión de componentes; y miWalk, a recolección de credenciales. smcard proporciona Tor y msdtc contiene el cliente que utiliza el proxy local. Los archivos Desktop.dat conservan parámetros de minería y walker_updater.cmd define una ruta de actualización.

La separación en módulos permite gestionar tareas distintas mediante archivos específicos. El minero puede detenerse mientras un servicio o un actualizador siguen presentes. Esta dependencia explica por qué la recuperación exige revisar qué componente inicia a otro y qué archivos puede volver a instalar.

Funciones de los componentes

Selecciona un componente para consultar su función y la evidencia disponible. Los nombres corresponden a los artefactos analizados; varias denominaciones imitan ejecutables legítimos.

FIG. 02 / Componentes del conjunto analizado. Las funciones combinan análisis de las muestras y correlación con las fuentes públicas citadas.

La revisión de un equipo comprometido debe cubrir los módulos, los scripts que los instalan o actualizan y la configuración que comparten. Para reconstruir esas dependencias registramos rutas, hashes, servicios, procesos escritores y referencias entre archivos.

Análisis estático
de rdpcIip.exe.

El ejecutable rdpcIip.exe utiliza una I mayúscula en la posición de la l minúscula de rdpclip.exe, el componente legítimo de Windows. Para identificar la muestra registramos su contenido, tamaño y SHA-256.

La muestra de referencia es un PE32 x86 de 310.784 bytes, con ImageBase = 0x400000 y SHA-256 39b1042a5b02f3925141733c0f78b64f9fae71a37041c6acc9a9a4e70723a0f1. Las direcciones virtuales (VA) de esta sección corresponden a esa base. El offset de archivo (FO) indica la posición del dato en disco; su correspondencia con una VA depende del mapeo de secciones del PE.

El hash identifica el archivo al que pertenecen estas posiciones, incluso si cambia de nombre. Las referencias cruzadas, o xrefs, indican qué instrucciones utilizan un dato. Seguirlas permite pasar de una cadena encontrada en disco a la función que la recibe como argumento.

El binario contiene órdenes de extracción para updates1.7z y updates2.7z, ambas con la contraseña xinchao123, documentada también por Talos. Sus referencias cruzadas llegan a llamadas a ShellExecuteA mediante la tabla de importaciones (IAT).²

ShellExecuteA es una API de Windows que permite iniciar una aplicación con argumentos. Aquí, la asociación entre esa llamada y los parámetros de 7-Zip respalda una función de extracción de paquetes. La IAT contiene los punteros a las funciones importadas; localizar la llamada a través de esa tabla permite identificar la API utilizada.

// Cadena real, recuperada del archivo
x updates1.7z -pxinchao123 -y

FO  0x428cc   →   VA  0x4434cc
                         ↑
                xref VA  0x427a78
                         ↓
                call VA  0x427a89
                ShellExecuteA   [IAT 0x43d18c]

// Segundo paquete, misma ruta de ejecución
updates2.7z   FO 0x428ec   ·   xref VA 0x427ace
             llamada a ShellExecuteA en VA 0x427adf

La plantilla WinRM http://%s:5985/wsman aparece en FO 0x40c14, equivalente a VA 0x441814, con una referencia en 0x417c0b y otros seis usos de formato. El binario también contiene estructuras SOAP Shell, Command y Stream, coherentes con la implementación de ejecución remota mediante WinRM.

WinRM proporciona administración remota de Windows. Las estructuras Shell, Command y Stream encajan con la creación de una sesión, el envío de una orden y el intercambio de su entrada o salida. Su presencia conjunta con la plantilla de conexión sustenta la interpretación de este código como parte de la capacidad de ejecución remota.

Alcance. Las referencias cruzadas documentan las rutas de código disponibles en esta muestra. Para confirmar su uso en el incidente se requieren registros de procesos, autenticación o tráfico del periodo investigado.

Script de actualización
y servidor de descarga.

El script walker_updater.cmd referencia 45[.]158[.]14[.]187 como servidor de distribución. Utiliza Net.WebClient.DownloadFile para obtener update.7z y rutas dwn.php para recuperar 7z32.exe y 7z32.dll.

El actualizador resuelve una necesidad del despliegue: obtener los archivos que faltan y preparar su instalación. Los componentes de 7-Zip extraen el paquete protegido con contraseña, y install.cmd recibe el control después. Este flujo explica el papel de distribución que asignamos al servidor y orienta la búsqueda de procesos y archivos generados durante una actualización.

El flujo comprueba la presencia de sqhost.exe. Si existe, crea una copia de comprobación e invoca -sha1chk con un digest literal; si falta, toma la rama de descarga. También invoca -sha1chk sobre update.7z y -chkxwget para los componentes de 7-Zip, con digests esperados de 64 caracteres hexadecimales. La semántica interna de estos comprobadores queda fuera de esta revisión.

hxxp://45[.]158[.]14[.]187/update.7z
hxxp://45[.]158[.]14[.]187/dwn.php?d=7z32.exe
hxxp://45[.]158[.]14[.]187/dwn.php?d=7z32.dll

Paquete extraído:  update.7z
Contraseña:        horhor123
Siguiente etapa:   install.cmd

La asociación de la IP con el despliegue procede del contenido del actualizador. La clasificamos como servidor de distribución por los recursos y operaciones que referencia el script. La búsqueda pública realizada para esta edición produjo cero coincidencias que la vincularan con Prometei.

El documento OSINT aportado informa de puertos 80 y 443 abiertos el 12 de octubre de 2026. La salida original del escaneo está pendiente de revisión. El dato describe accesibilidad TCP en esa fecha; la disponibilidad de update.7z y el contenido servido requieren evidencias HTTP adicionales.

walker.ini:
RC4 y LZNT1.

La rutina nativa de rdpcIip.exe procesa walker.ini en dos etapas: descifrado RC4 con una clave de 16 bytes y descompresión LZNT1. Aplicamos esa secuencia a dos archivos y recuperamos plantillas de descarga legibles.

El cifrado impide leer directamente las plantillas y sus destinos. La compresión representa ese contenido en menos bytes. Para reconstruirlo hay que reproducir las transformaciones en el orden que utiliza el programa: RC4 recupera el bloque comprimido y LZNT1 expande su contenido. Las direcciones que aparecen al final permiten identificar servidores ausentes en una búsqueda de cadenas sobre el archivo cifrado.

La identificación parte del código que consume el archivo. En VA 0x426647 se referencia el nombre walker.ini. En esa ruta, 0x42673f prepara en ECX el puntero a la clave y 0x426746 llama a la función 0x410c80.

La función inicializa una permutación de 256 bytes en 0x410c93. El bucle entre 0x410cb0 y 0x410ce9 accede a la clave mediante i & 0x0f, acumula el índice j módulo 256 e intercambia S[i] y S[j]. Es la estructura del key-scheduling algorithm (KSA) de RC4 con una clave de 16 bytes. Entre 0x410d00 y 0x410d6f se ejecutan el generador de flujo (PRGA) y el XOR con los bytes de entrada.

La máscara 0x0f conserva cuatro bits, de modo que el índice recorre las 16 posiciones de la clave de forma cíclica. El KSA prepara el estado interno a partir de esa clave; el PRGA genera los bytes que se combinan con el archivo mediante XOR. Reconocemos RC4 por esa secuencia de operaciones y después comprobamos el resultado con otra implementación.

La llamada desde 0x426778 a 0x4096e0 procesa el bloque resultante. En 0x409701 se lee una cabecera de 16 bits; 0x40970c conserva sus 12 bits inferiores y 0x409715 incrementa el valor para obtener la longitud del contenido del bloque. La prueba de 0x8000 en 0x40973d selecciona la expansión mediante 0x409570. Estas operaciones corresponden a la estructura de bloques LZNT1.

// Rutina 0x410c80
S ← secuencia de 256 valores
S ← permutación con la clave de 16 bytes     KSA
flujo ← generación a partir de S             PRGA
bloque ← bytes de walker.ini XOR flujo

// Ruta posterior: 0x4096e0 → 0x409570
cabecera ← interpretar bloque LZNT1
texto ← expandir literales y referencias

Resultado: plantillas de descarga legibles

Configuración A · servidor de entrega
hxxp://155[.]207[.]200[.]242/k.php

Configuración B · servidor de entrega
hxxp://103[.]41[.]204[.]104/k.php

Operaciones identificadas en las plantillas
DownloadFile → ReadAllBytes → transformación
             → WriteAllBytes → Start-Process

No se incluyen claves, argumentos completos ni
configuración identificativa de la organización.

Validación del descifrado y del formato

El RC4 reconstruido a partir del desensamblado produjo una salida idéntica, byte a byte, a la implementación ARC4 de cryptography en ambos archivos. También se comprobó el flujo inicial de 16 bytes del vector del RFC 6229 con clave de prueba 0102030405.⁸ El descompresor LZNT1 reprodujo el ejemplo de Microsoft: 59 bytes comprimidos se expandieron a los 142 bytes ANSI documentados.⁷

En la primera muestra, 0xB1CA indica un bloque comprimido con 459 bytes de contenido y dos de cabecera. En la segunda, 0xB232 corresponde a 563 bytes de contenido y dos de cabecera. Ambos tamaños coinciden con la longitud total de sus respectivos archivos. La expansión produjo 846 y 1.016 bytes de texto íntegramente imprimible.

Las plantillas recuperadas contienen la secuencia DownloadFile, ReadAllBytes, transformación de bytes, WriteAllBytes y Start-Process. Los destinos 155[.]207[.]200[.]242/k.php y 103[.]41[.]204[.]104/k.php actúan como orígenes de entrega en esas plantillas. El momento de contacto, la respuesta HTTP y el payload servido quedan pendientes de validación con registros de ejecución o red.

Unit 42 documenta la URL 103[.]41[.]204[.]104/k.php como origen de descargas; Trend Micro relaciona esa IP con la distribución de módulos y de walker.ini. La coincidencia de 155[.]207[.]200[.]242 en Trend Micro se limita a la IP. La ruta /k.php procede de la configuración recuperada en este análisis.⁴⁵

Protección por componente. nethelper2.exe contiene metadatos de DESCryptoServiceProvider y DeflateStream. La ruta nativa de rdpcIip descrita aquí conecta la lectura de walker.ini con RC4 y LZNT1. La conclusión criptográfica se limita a los dos archivos procesados y a esa ruta de código.

Infraestructura de
distribución y C2.

El mando y control, o C2, es el canal que utiliza el operador para comunicarse con los equipos comprometidos y dirigir su actividad. Puede transportar instrucciones y devolver los resultados de su ejecución. Identificarlo permite investigar cómo se administra el bot una vez instalado y dónde interrumpir esa comunicación.⁹

En Prometei, Talos documentó órdenes para descargar y ejecutar componentes, cambiar el servidor de control y arrancar o detener la minería. Son funciones descritas en el análisis de la familia de 2020; las rutas y destinos de las muestras actuales se examinan a continuación.¹

El servidor de distribución entrega archivos que el bot necesita instalar o actualizar. El pool de minería asigna trabajo al minero y recibe sus resultados. Estas funciones explican qué efecto tiene cada bloqueo: cortar una descarga dificulta obtener componentes; cortar el C2 interrumpe la administración por ese canal; cortar el acceso al pool afecta al trabajo de minería. Los componentes ya instalados y otras rutas de comunicación requieren sus propias comprobaciones.

La clasificación de infraestructura se basa en el artefacto que referencia cada destino: descargas HTTP en el actualizador y en walker.ini, servicios .onion embebidos en msdtc y pools stratum+tcp en Desktop.dat. El siguiente esquema representa esas relaciones estáticas.

msdtc: destinos .onion y selección del proxy

Un servicio .onion es accesible a través de Tor, que permite alojarlo sin publicar directamente la dirección IP del servidor. En este conjunto, smcard aporta el cliente Tor y su proxy SOCKS local: un intermediario al que msdtc entrega las conexiones para encaminarlas por esa red. Por eso aparecen juntos un destino .onion y una dirección de loopback como 127.0.0.1.¹⁰

msdtc.exe contiene una dirección .onion de formato v3 y una cadena heredada de formato v2. La primera se encuentra en el offset de archivo 0x23e94, correspondiente a VA 0x424a94; la segunda, en 0x23e7c. También aparecen referencias al proxy local y a los puertos 5053 y 9050. En VA 0x403c2d se carga 0x13bd —5053 en decimal— y se pasa a la rutina de comprobación, llamada en 0x403c32.

La comprobación llama a 0x401e60 y bifurca en 0x403c39. Un resultado falso selecciona el puerto alternativo 9050. Las dos rutas construyen el proxy con la cadena 127.0.0.1:%s; las importaciones curl_easy_setopt en IAT 0x41e198 y curl_easy_perform en IAT 0x41e194 corresponden a la implementación de transporte mediante libcurl.

La bifurcación establece una preferencia: probar la ruta local de 5053 y preparar la alternativa de 9050 si la comprobación falla. Esta lógica explica los dos puertos presentes en el binario. Para investigar su uso conviene relacionar el proceso que escucha en esos puertos con el cliente que se conecta a él.

Los registros de Tor incluyen la apertura de SOCKS en 127.0.0.1:5053 y el mensaje Bootstrapped 100%. También registran un intento a un servicio oculto que termina en resolvefailed, con el destino sustituido por [scrubbed].onion. La evidencia disponible acredita el arranque de Tor y ese fallo de resolución. La correlación con la dirección embebida y la recepción de órdenes quedan abiertas.

El arranque de Tor y la comunicación con el servicio de destino son etapas sucesivas. Bootstrapped 100% describe la preparación del cliente para usar la red. El error de resolución corresponde a un intento posterior. Para acreditar una sesión C2 habría que observar además el intercambio con el servicio y vincularlo al proceso del bot.

Coincidencias con indicadores públicos

El dominio p3[.]feefreepool[.]net figura junto a p1 y p2 en los indicadores de Talos de marzo de 2023. El documento OSINT aportado informa de su resolución a 31[.]56[.]209[.]100 el 12 de octubre de 2026. Conservamos esa IP como dato DNS fechado, pendiente de contraste con la salida original. Una reconstrucción temporal de los cambios requiere resoluciones históricas y fechas de adquisición de las muestras.³

Los dos pools se verificaron en archivos Desktop.dat. 145[.]239[.]200[.]92:3333 coincide exactamente con el análisis de Trend Micro de 2024. La consulta de 103[.]184[.]128[.]140:80 produjo cero coincidencias asociadas a Prometei en el corpus público revisado.⁴

El cruce identifica infraestructura compartida con publicaciones anteriores y destinos adicionales presentes en estas muestras. La atribución del operador requiere evidencia independiente sobre el control de los servicios.

Credenciales
y propagación.

El movimiento lateral consiste en pasar de un equipo comprometido a otros sistemas del entorno. Las credenciales pueden facilitarlo cuando una cuenta tiene acceso a varios equipos o se reutiliza una contraseña. Esto relaciona la recolección de credenciales con los módulos de administración remota y explica por qué la respuesta debe revisar tanto las máquinas como las cuentas utilizadas.

En miWalk64.exe verificamos las importaciones SAMLIB!SamConnect y MPR!WNetAddConnection2W, relacionadas con acceso a SAM y conexiones a recursos de red. Junto con sus cadenas y el contexto de la familia, respaldan el papel de recolección de credenciales. El alcance de las credenciales expuestas requiere análisis del equipo y su telemetría.

rdpcIip contiene referencias a SMB/RPC, WMIC y WinRM. En los ensamblados nethelper aparecen tipos de Npgsql, entre ellos NpgsqlConnection, NpgsqlCommand y NpgsqlDataReader, coherentes con acceso a PostgreSQL. El papel de propagación SQL de estos módulos está descrito en las investigaciones públicas de la familia.

La configuración del núcleo conserva ip, ParentIp, ParentId y ParentHostname. Estos campos permiten construir un grafo de relaciones declaradas entre instancias y seleccionar pares origen-destino para buscar autenticaciones, creación de procesos y transferencia de archivos.

{
  "ip":             "NODO-B",
  "ParentIp":       "NODO-A",
  "ParentId":       "[omitido]",
  "ParentHostname": "[omitido]"
}

NODO-A ── relación declarada ──▶ NODO-B
Para confirmar el salto: autenticación + proceso + red.

La interpretación del grafo debe considerar configuraciones copiadas, valores antiguos y adquisiciones repetidas. Para confirmar un salto se correlacionan esos campos con tiempos, sesiones y procesos de ambos equipos. La identificación del primer sistema comprometido sigue pendiente de esa reconstrucción temporal.

Archivos .cpass y validación RDP

Talos describe los archivos .cpass como contenedores de contraseñas candidatas para comprobaciones RDP, y los .cpass_good como resultados válidos. Una IP incluida en el nombre de uno de estos archivos puede corresponder al objetivo de la comprobación.¹

La dirección derivada de un nombre .cpass en el material revisado queda excluida de los indicadores de C2 y exfiltración. Su función exacta requiere reconstruir las rutinas que escriben y consumen el archivo, o correlacionar el proceso con tráfico hacia ese destino.

Las relaciones con otras familias o herramientas recuperadas se evalúan mediante su procedencia, el proceso que las escribió y su secuencia de ejecución. La atribución de una entrega concreta a Prometei queda condicionada a esa correlación.

Detección y bloqueo:
YARA y Suricata.

Los hashes permiten buscar las muestras identificadas y los destinos de red sirven para revisar conexiones históricas. La correlación de rutas, servicios, procesos y autenticaciones amplía la búsqueda a componentes con otros nombres o builds.

La regla YARA propuesta para rdpcIip exige la firma MZ, un tamaño inferior a 2 MB, la plantilla WinRM y al menos una orden de extracción. La condición se completa con la ruta PDB o el marcador mshlpda32.dll. Estos requisitos se aplican sobre los bytes del archivo.

YARA compara el contenido de un archivo con condiciones definidas por el analista. En esta regla, la plantilla WinRM aporta una capacidad, las órdenes de extracción concretan los paquetes y el marcador adicional vincula el conjunto con los artefactos analizados. Exigimos esa combinación porque WinRM y 7-Zip también forman parte de software y tareas legítimas.

// Fragmento. Regla completa en la descarga.
strings:
  $archive1 = "x updates1.7z -pxinchao123 -y" ascii
  $archive2 = "x updates2.7z -pxinchao123 -y" ascii
  $wsman = "http://%s:5985/wsman" ascii
  $pdb = "\\walker\\netwalker\\Release\\rdpcIip.pdb" ascii nocase
  $marker = "C:\\windows\\mshlpda32.dll" ascii nocase

condition:
  uint16(0) == 0x5a4d and filesize < 2MB and
  $wsman and 1 of ($archive*) and ($pdb or $marker)

Validación de la regla. YARA produjo coincidencias en tres muestras de rdpcIip con hashes diferentes y cero coincidencias en seis PE de control, correspondientes a lanzadores distintos de setuptools. El conjunto de control es reducido; la tasa de falsos positivos en un parque real queda pendiente de evaluación. El empaquetado o los cambios en las cadenas pueden impedir la coincidencia.

Suricata: bloqueo de C2 y distribución

Las reglas de red actúan sobre los destinos con los que intenta comunicarse un equipo. El archivo descargable contiene siete reglas drop: tres para el dominio p3[.]feefreepool[.]net y cuatro para las IP de control o distribución recogidas en el análisis. Se aplican al tráfico originado en $HOME_NET, la variable que debe representar los equipos protegidos.

drop descarta tráfico cuando Suricata funciona como sistema de prevención de intrusiones (IPS), situado en el camino de los paquetes. Un sensor pasivo analiza una copia del tráfico para generar alertas. El modo de captura y la ubicación del sensor determinan, por tanto, si la regla puede bloquear la conexión.¹¹

Cada SID identifica una regla dentro del sensor y permite localizar sus eventos. La regla DNS compara el nombre completo. Los límites de inicio y fin evitan coincidencias con nombres que solo contienen el indicador, como p3[.]feefreepool[.]net.example.test. En HTTP se trata explícitamente el puerto opcional del campo Host; en TLS se inspecciona el nombre que anuncia el cliente.¹²

drop dns $HOME_NET any -> any any (msg:"LOBERA Prometei historical C2 domain DNS"; flow:to_server; dns.query; content:"p3.feefreepool.net"; nocase; startswith; endswith; reference:url,raw.githubusercontent.com/Cisco-Talos/IOCs/main/2023/03/prometei-botnet-improves.txt; classtype:trojan-activity; sid:9901301; rev:1;)

Las reglas por IP actúan incluso cuando el contenido está cifrado, porque el destino sigue formando parte del encabezado de red. Su alcance comprende todos los servicios alojados en esa dirección. Cada regla conserva en sus comentarios la procedencia del indicador; la vigencia de las asociaciones debe revisarse al integrarlas en otro entorno o periodo.

Cobertura del canal Tor. El nombre .onion queda dentro de las comunicaciones de Tor. Un sensor perimetral observa las conexiones de transporte con esa red y necesita telemetría adicional del equipo para vincularlas al servicio de destino. Estas reglas cubren los dominios e IP indicados en la tabla; la investigación del canal Tor requiere correlacionar msdtc, el proxy SOCKS y sus registros. DNS cifrado, TLS con ECH y QUIC también quedan fuera de la cobertura por nombre probada aquí.

Validación de Suricata. Las siete reglas compilaron con Suricata 7.0.3. Una reproducción de tráfico IPv4 sintético con --simulate-ips produjo la acción blocked en los 27 casos positivos esperados y cero coincidencias en 29 controles. Se comprobaron DNS sobre UDP/TCP, HTTP, SNI, tráfico por IP y nombres similares. La prueba fue offline; la integración del sensor en una red en línea requiere su propia comprobación.

suricata -T --init-errors-fatal -c /etc/suricata/suricata.yaml \
  -s ./prometei-suricata.rules

Correlación en endpoint y red

Para cada archivo se revisan ruta, hash, firma, proceso escritor y procesos derivados. En el caso de msdtc.exe, interesa correlacionar la muestra identificada con conexiones al proxy SOCKS local. Para 7-Zip y PowerShell se buscan los argumentos, archivos de entrada y procesos posteriores relacionados con el actualizador.

La cronología debe registrar el origen y significado de cada marca temporal: adquisición, creación del archivo, inicio del proceso o evento de red. Los valores guardados por el malware requieren correlación con una fuente independiente antes de interpretarlos como fecha de instalación o último contacto.

Indicadores de compromiso.

La tabla separa los indicadores extraídos de scripts y configuraciones, los destinos embebidos, los datos DNS aportados y los hashes de módulos. Las direcciones están desactivadas para evitar navegación accidental. La descarga conserva el rol y las limitaciones de cada indicador.

Los indicadores de red deben evaluarse en la ventana temporal investigada, considerando cambios de propietario o de servicio. Los destinos extraídos del código expresan configuración; su uso efectivo se valida con registros de conexión. Los hashes identifican los archivos concretos incluidos en la tabla.

Contención
y erradicación.

El alcance de la respuesta incluye los módulos instalados, los servicios, el actualizador, las credenciales expuestas y los sistemas relacionados por acceso remoto. Los artefactos descritos permiten orientar las siguientes comprobaciones.

1. Contener y preservar evidencias

   Aislar los sistemas comprometidos y conservar procesos, servicios, conexiones, scripts y configuración. Registrar hashes y procedencia de cada archivo antes de su retirada.

2. Determinar el alcance

   Buscar los hashes, rutas y servicios en el resto del entorno. Revisar las cuentas y destinos relacionados, y contrastar cada relación ParentIp con autenticaciones, procesos y transferencias de archivos.

3. Retirar persistencia y revocar accesos

   Eliminar los mecanismos confirmados de instalación y actualización. Aislar o retirar los componentes de recolección antes de rotar credenciales desde sistemas confiables y revocar las sesiones comprometidas.

4. Verificar la recuperación

   Monitorizar la reaparición de servicios y archivos, las conexiones a los destinos investigados y los accesos remotos entre equipos afectados. Definir la ventana de observación y los criterios de cierre según el alcance del incidente.

El análisis dinámico pendiente debe observar las condiciones de activación del actualizador, la construcción de peticiones HTTP, la selección del proxy y los procesos creados. Un entorno aislado con servicios emulados permite registrar argumentos, buffers y resultados de las llamadas sin depender de la infraestructura externa.

La investigación del acceso inicial requiere una cronología correlacionada de autenticaciones, escrituras y ejecuciones. El vector de entrada y el primer sistema comprometido permanecen abiertos en esta edición.

Metodología
y alcance.

Esta investigación combina análisis estático de muestras y scripts, revisión de artefactos recuperados, descifrado y descompresión offline, y contraste con fuentes públicas. Las figuras se han reconstruido para explicar los mecanismos y no contienen capturas, topologías reales, nombres de equipos ni identificadores de la organización.

Los hallazgos de ingeniería inversa se vinculan a hashes y posiciones concretas. Cada indicador conserva el artefacto del que procede y su función inferida. Las referencias públicas aportan contexto de familia; las conclusiones sobre este despliegue se apoyan en las muestras y registros revisados.

Fuentes públicas

Consulta editorial: 13 de octubre de 2026. Las fechas siguientes corresponden a la publicación original. Las coincidencias con fuentes anteriores se indican sin atribuirles los hallazgos obtenidos del corpus local.

1. CISCO TALOS · 22 JUL 2020Prometei botnet and its quest for Monero ↗

   Arquitectura inicial, recolección de credenciales y función de los archivos .cpass.

2. CISCO TALOS · 09 MAR 2023Prometei botnet improves modules and exhibits new capabilities in recent updates ↗

   Módulos, cadenas de actualización y contraseñas de los paquetes.

3. CISCO TALOS · IOC DE LA PUBLICACIÓN DE 2023Apéndice original de indicadores ↗

   Incluye p1, p2 y p3.feefreepool.net. Evidencia histórica, sin vigencia operativa implícita.

4. TREND MICRO · 23 OCT 2024Unmasking Prometei: A Deep Dive Into Our MXDR Findings ↗

   Configuración Desktop.dat, pool 145.239.200.92:3333 y referencias de distribución de componentes.

5. PALO ALTO NETWORKS · UNIT 42 · 20 JUN 2025Resurgence of the Prometei Botnet ↗

   Investigación de actividad Linux observada desde marzo de 2025 y servidor de distribución 103.41.204.104/k.php.

6. CUJO AI · 10 MAR 2021IoT Malware Journals: Prometei (Linux) ↗

   Contexto de los componentes Linux. La publicación no demuestra la versión de las muestras Windows del caso.

7. MICROSOFT · OPEN SPECIFICATIONS[MS-XCA] 2.5.1.2 Buffers and Chunks ↗

   Definición normativa de los campos de la cabecera. Ejemplo oficial utilizado para contrastar la expansión.

8. IETF · RFC 6229 · MAYO 2011Test Vectors for the Stream Cipher RC4 ↗

   Vector de prueba utilizado para comprobar el generador de flujo offline.

9. MITRE ATT&CK · TA0011Command and Control ↗

   Función del mando y control y comunicación con sistemas comprometidos.

10. TOR PROJECT · DOCUMENTACIÓNUnderstanding .onion addresses and how onion services work ↗

    Acceso a servicios .onion mediante Tor. Contexto para interpretar el proxy local y las comunicaciones del cliente.

11. OISF · SURICATAIPS Concept ↗

    Funcionamiento del modo IPS y descarte de tráfico mediante reglas drop.

12. OISF · SINTAXIS DE REGLASDNS Keywords ↗

    Campos de inspección: HTTP Host y TLS SNI. La validación local del archivo se realizó con Suricata 7.0.3.

13. OISF · SURICATA 7.0.3Command Line Options ↗

    Opciones -T, -s, lectura de PCAP y simulación del modo IPS.