elasticsearch · ransomware · extortion · data-exposure · on-chain-analysis · bitcoin · cloud-misconfiguration · census
Elasticsearch expuesto: dentro de la economía del borrado con rescate
Kinryū Labs censó 17,043 hosts de Elasticsearch expuestos a internet y descubrió que un cascarón vaciado con una nota de rescate dentro es el estado más común de un clúster expuesto: 5,073 de ellos. Rastrear cada monedero anunciado en las notas arroja cinco actores, once pagos y unos $5,553 de ingresos totales, y demuestra que la promesa de devolver los datos borrados carece de respaldo en la evidencia.
Por Davis Zheng·
TLP:CLEAR. Autorizado para publicación. Los hallazgos proceden de un censo a escala de internet de Elasticsearch expuesto, realizado desde un único punto de observación en la nube, y del análisis en cadena de cada dirección de Bitcoin y Ethereum anunciada en las notas de rescate. Los monederos del atacante, las direcciones de contacto, el texto de las notas y los enlaces son indicadores y se publican aquí; los enlaces y los dominios de contacto están neutralizados (defanged). Las organizaciones afectadas se gestionan bajo divulgación aparte y no se nombran.
Resumen ejecutivo
- 7,648hosts abiertos sin autenticación
- 5,073cascarones vaciados con rescate
- $5,553total pagado, todos los actores, todo el periodo
- 1.2%víctimas que después activaron la autenticación
Apunta un escáner no autenticado al Elasticsearch de internet y la mayor parte de lo que responde son escombros: clústeres vaciados y abandonados con una nota de rescate donde antes estaban los datos. Censamos 17,043 hosts de Elasticsearch desde un único punto de observación en la nube; 11,850 respondieron. De esos, 7,648 estaban abiertos sin autenticación alguna, y 5,073 de los hosts abiertos ya habían sido vaciados y abandonados con una nota en lugar de sus datos. Un cascarón vaciado con una nota dentro es el estado más común de un clúster de Elasticsearch expuesto.
Leer esas notas al completo desde 2,500 hosts las agrupa en siete plantillas gestionadas por cinco actores. Después rastreamos cada monedero anunciado en las notas. Entre los cinco actores, trece direcciones de Bitcoin y una de Ethereum, a lo largo de un periodo de más de un año, las campañas recibieron once pagos que suman 0.06 BTC, por valor de unos $5,553 al precio vigente cuando llegó cada uno. La tasa de pago global entre las víctimas atribuibles es del 0.28%.
El argumento de venta del actor dominante es que tus datos han sido borrados de tu servidor pero se conservan a salvo en su clúster, y vuelven una vez que pagas. La evidencia no lo respalda. El código de recuperación que la nota jura que es único para tu base de datos resulta ser una única cadena fija, idéntica en 1,199 víctimas de 56 países. Las víctimas, por su parte, en su mayoría no corrigen la exposición subyacente. Tras volver a sondearlos siete semanas después del censo, el 52% de una muestra de 2,500 hosts seguían abiertos, seguían vaciados, con la nota todavía presente, y solo el 1.2% había activado la autenticación.
- El borrado con rescate es el estado modal de un clúster expuesto. 5,073 de 7,648 hosts abiertos y sin autenticación (66%) habían sido vaciados y sometidos a rescate. Un Elasticsearch expuesto tiene más probabilidades de ser un cascarón saqueado que una base de datos en funcionamiento. Confianza alta, medido directamente.
- La afirmación de que se conservan los datos carece de respaldo. El actor dominante emite un código de recuperación fijo en 1,199 víctimas y destruye los datos eliminando índices en lugar de exportarlos. Nada en la evidencia indica que se guardara una copia. Confianza alta.
- Esto es automatización oportunista, no intrusión dirigida. Más de nueve de cada diez víctimas ejecutan una versión actual de Elasticsearch; la vía de entrada es un puerto abierto, y un parche no lo habría cerrado. Confianza alta.
- La economía es marginal. $5,553 en once pagos a lo largo de más de un año, con 8 de 13 monederos que nunca recibieron un satoshi. Esto parece un script barato ejecutado a escala, no un negocio organizado de ransomware. Confianza alta.
- Las campañas pequeñas y por víctima superan al rociado masivo. Un actor que extorsionó a tres hosts con monederos por víctima ganó más que el actor que golpeó a 3,730 con uno compartido. Confianza moderada; la muestra es de tres víctimas, así que la dirección es más clara que la magnitud.
El censo: cuántos, y en qué estado
Un barrido con masscan sacó a la luz unos 39,900 endpoints candidatos de Elasticsearch y Kibana. Resolver el lado de Elasticsearch a un veredicto limpio por host desde el punto de observación deja 17,043 hosts con un resultado canónico. De esos, 11,850 respondieron por HTTP y 5,193 no.
Los veredictos sobre los 17,043 completos:
| Veredicto | Recuento | Significado |
|---|---|---|
| Abierto, sin autenticación | 7,648 | GET / devuelve 200 sin credenciales; legible directamente |
| Protegido | 4,026 | 401/403, y las credenciales por defecto conocidas fallan |
| Muerto | 5,193 | sin HTTP desde el punto de observación |
| Requiere autenticación | 71 | 401/403, aún sin probar credenciales |
| Credenciales por defecto | 39 | una credencial por defecto autentica |
| Otro | 66 | accesible pero no es Elasticsearch o un estado extraño |
Casi dos tercios de los hosts accesibles responden sin autenticación alguna. La palabra «abierto», sin embargo, exige cuidado antes de que alguien la convierta en un recuento de víctimas.
De los 7,648 hosts abiertos, 5,073 ya son cascarones vaciados con rescate, y otra porción son señuelos: un grupo de nodos con nombres autogenerados que sirven un esquema enlatado idéntico, más hosts que falsifican sus listados de índices para parecer más llenos de lo que están. Descontando ambos, el residuo de clústeres genuinamente abiertos que aún conservan datos reales y sin rescate es de unos 2,500. Los casos de alto valor dentro de ese residuo se gestionan bajo divulgación aparte y no se nombran aquí.
Geográficamente, la población abierta y sin autenticación es una mayoría relativa china por amplio margen: CN 2,518, luego US 874, DE 731, FR 518, IN 435, MX 277, RU 256, SG 181, JP 131, KR 125, NL 124, GB 120.
Los 39 hosts donde funciona una credencial por defecto son un problema más pequeño y más agudo. Se probaron en modo solo lectura seis pares de credenciales por defecto conocidos (elastic:elastic, changeme, password, bitnami; admin:admin; kibana:kibana), confirmando por host el privilegio que concedía cada uno. Se dividen en dos clases: cuentas kibana_system, que ven metadatos pero reciben un 403 en _search, y superusuarios elastic completos con lectura, escritura y borrado. Un punto de observación residencial más débil se había perdido por completo 26 de los accesos de superusuario, lo cual anticipa el problema del sesgo de punto de observación que se comenta al final. El peor caso individual es una pila EDR y SIEM de Elastic Defend con credenciales por defecto y Fleet acoplado, donde el acceso de superusuario a un producto de seguridad compra la manipulación de alertas y una vía de gestión a agente hacia la ejecución de código en cada host que gestiona.
Las notas de rescate
Las víctimas no son quienes cabría esperar de la historia habitual de la «máquina sin parchear en internet». Por versión mayor, los hosts vaciados ejecutan v8 (2,535), v7 (1,960), v9 (299), v6 (117), v5 (61) y v2 (42). Predominan las versiones actuales: v7, v8 y v9 juntas suman 4,794 de ellos, más de nueve de cada diez. Son clústeres mantenidos y actualizados que resulta que no tienen contraseña en la puerta de entrada. La exposición es el puerto abierto, y parchear no lo habría cerrado.
El alojamiento se concentra en las grandes nubes chinas (Alibaba 730, Tencent 500, Volcano Engine 330, Huawei 84, unas 1,644 combinadas) y luego en los proveedores europeos económicos (OVH 324, Contabo 250, Hetzner 236), con un grupo de un único proveedor en Baja Datacenter en México (231). La geografía de las víctimas sigue a la geografía de la exposición: CN 1,972, US 527, FR 423, DE 360, MX 235, RU 212, y una larga cola.
Lo que dicen las notas
Leer 2,500 hosts al completo recuperó 1,309 notas completas, que se normalizan, una vez descontados el monedero, el contacto, el importe y el código, en siete plantillas distintas. Una de ellas representa casi todo. Los enlaces y los dominios de contacto de abajo están neutralizados.
Actor A, la plantilla dominante, 1,199 de 1,309 notas (92%), en 56 países:
Your database has been deleted from your server, but all the information remains stored on our cluster. The instructions for recovery are as follows: You must send 0.0041 BTC to the following wallet:
bc1q38rjul6gdamfflf6p4ukz0ymtvfgfv2j9saf6r. Then, you must send an email towendy.etabw@gmx[.]comwith the following code: 0SH7HH1Q72JL (it is important that you write it correctly, as it corresponds to your database). You must also attach the txid (the Bitcoin transaction ID) to the message. After following these steps, we will send you a zip file with all your information. You have 48 hours to complete the steps. For More Info - hxxps://tli[.]sh/73x1k
Dentro de esta única plantilla varía el importe (0.0016, 0.0035, 0.0041, 0.0061 BTC), al igual que el monedero, la dirección de contacto (wendy.etabw@gmx[.]com, scandal@onionmail[.]org, bitwezen@cock[.]li) y el código (0SH7HH1Q72JL o BITWEZEN2026). El plazo es siempre de 48 horas.
Una plantilla es lo bastante diferente como para citarla al completo. Es la única de las siete que amenaza con publicar los datos en lugar de borrarlos, ofrece una opción de Ethereum junto a Bitcoin, y pide una suma sustancialmente mayor, unas doce veces la exigencia del Actor A:
Actor E, amenaza de filtración, doble cadena, 3 notas:
Your database was compromised. Pay 0.1 ETH to
0x3C11Cf2974c3Fb4d7ebBfea711a4A0b26989979Dor 0.05 BTC tobc1qu8t03mv2qwjv56gry2ft0qes0xwqhddjhsvkfl. THIS IS A UNIQUE ADDRESS GIVEN TO YOU AND YOUR PAYMENT WILL BE AUTOMATICALLY DETECTED. UPON WHICH WE WILL RESTORE YOUR DATA. IN 48 HOURS IF NO PAYMENT IS MADE WE WILL LEAK YOUR DATA PUBLICLY.
Las plantillas restantes, incluida una variante con combinación de correspondencia defectuosa de la nota del Actor A, se reproducen textualmente abajo para los defensores que las cotejen.
Las otras plantillas de notas, textuales (neutralizadas)
Actor B «sharebot», 101 notas, 15 países:
Your database has been backed up to our secure servers. To recover your data, send exactly 0.0061 BTC to:
bc1quwlw8djc7hfamf3qpspma34uh9dr6w4kudfu8pThen emaildb-recovery@sharebot[.]netwith your server IP and transaction ID. We will reply with a download link within 24 hours. If no payment is received in 48 hours, your data will be permanently deleted.
Actor B «sharebot», variante con código, 2 notas:
Your data has been backed up. To recover it, send 0.0061 BTC to:
bc1qquzg5dg5yfqxlc0fy6pemcwa2xg5mw3l7l2gc4. Then emailes-recovery@sharebot[.]netwith code: 841BEACF110F and attach the transaction ID (txid). You will receive a download link within 24 hours. Do not modify this index.
Actor D, 1 nota:
Your DB has been back up. The only way of recovery is you must send 0.002 BTC to
127ZBzXyLJFc7ShMmzkYFDhSiXXSnR8Jfr. Once paid please emaildatabaserestore32@onionmail[.]orgwith code: omoRmq and we will recover your database. please read hxxps://cutmyurl[.]com/3caF8EkT for more information
Actor A, variante con combinación de correspondencia defectuosa, 3 notas:
Your database has been deleted from your server, but all the information remains stored on our cluster. […] You must send 0.0041 BTC to the following wallet:
bc1qu8t03mv2qwjv56gry2ft0qes0xwqhddjhsvkfl. Then, you must send an email to This is a unique address given to you and your payment will be automatically detected, upon which we will restore your data. with the following code: 0SH7HH1Q72JL […]
La casilla de contacto se ha rellenado con una frase en lugar de una dirección de correo. Esa frase es textual de la plantilla del Actor E, y el monedero es el que usa el Actor E.
El código de recuperación no es por víctima
La nota del Actor A se apoya en una promesa: tus datos están a salvo, y el código demuestra que podemos devolverte los tuyos en concreto. Entre las 1,199 víctimas muestreadas en 56 países, ese código toma exactamente dos valores, 0SH7HH1Q72JL y BITWEZEN2026. Es una constante incrustada en la plantilla en tiempo de compilación, no un identificador ligado a una víctima.
La consecuencia no es sutil. Un operador que no puede distinguir a una víctima de otra no puede devolver los datos de una víctima cuando se lo piden. Combina eso con el hecho de que el borrado es un borrado masivo de índices y no una exportación, y la frase «all the information remains stored on our cluster» no tiene respaldo en nada observable aquí. La variante con código del Actor B sí lleva lo que parecen códigos distintos por víctima, pero esa variante alcanzó 2 hosts de 1,309, y al Actor B nunca le han pagado.
Un kit compartido vincula a dos «actores»
La variante defectuosa de arriba es un pequeño regalo forense. La nota fallida del Actor A y la nota de amenaza de filtración del Actor E comparten un monedero (bc1qu8t03mv2qwjv56gry2ft0qes0xwqhddjhsvkfl) y comparten una frase, palabra por palabra, situada en el campo equivocado de la nota del Actor A. La lectura más económica es un kit compartido de generación de notas con casillas configurables para monedero, contacto, importe y plazo, donde una ejecución escribió el texto del Actor E en la casilla de contacto del Actor A. En términos estimativos, esto es probable: un solo operador ejecutando ambos scripts, o dos operadores compartiendo un kit, ambos encajan, y el texto de las notas por sí solo no puede separarlos. Lo que la evidencia descarta es tratar a estos dos como totalmente independientes.
Los actores
| Actor | Contacto(s) | Tema | Exigencia | Víctimas | Direcciones |
|---|---|---|---|---|---|
| A (dominante) | wendy.etabw@gmx[.]com, scandal@onionmail[.]org, bitwezen@cock[.]li | borrado de tu servidor, almacenado en nuestro clúster; código fijo; enlace tli[.]sh | 0.0016 a 0.0061 BTC | ~3,730 | 4 |
| B «sharebot» | db-recovery@, es-recovery@sharebot[.]net | respaldado en nuestros servidores seguros; enlace a las 24h / borrado a las 48h | 0.0061 BTC | ~262 | 5 |
| C «rambler» | rambler+<id>@onionmail[.]org (única por víctima) | monedero y correo por víctima | ~0.0041 BTC | 3 | 3 |
| D | databaserestore32@onionmail[.]org | monedero P2PKH heredado; enlace cutmyurl | 0.002 BTC | 1 | 1 |
| E | ninguno (solo pago) | amenaza de filtración; BTC o ETH | 0.05 BTC / 0.1 ETH | 3 | 1 BTC + 1 ETH |
El Actor A rocía un único monedero compartido por miles de víctimas. El Actor C hace lo contrario, acuñando un monedero nuevo y un correo rambler+<id> para cada una de sus tres. Esa diferencia de oficio resulta decidir quién cobró de verdad.
Siguiendo el dinero
Cada dirección anunciada se consultó contra un explorador de bloques público, en modo solo lectura. Las cifras en USD son el valor en el momento del bloque de cada pago, no el precio al contado de hoy.
| Métrica | Valor |
|---|---|
| Direcciones de BTC anunciadas | 13 |
| Direcciones que alguna vez recibieron algo | 5 |
| Total recibido | 0.05995249 BTC |
| Valor total en el momento del pago | $5,553.21 |
| Pagos, todos los actores, todo el periodo | 11 |
| Hosts víctima atribuibles | 3,996 |
| Conversión global | 0.28% |
| Direcciones con ingresos nulos | 8 de 13 |
| Primer / último pago | 2025-05-27 / 2026-06-04 |
Desglosado por actor, el orden es el hallazgo:
| Actor | Direcciones | Víctimas | Pagos | BTC recibido | USD en el momento |
|---|---|---|---|---|---|
| A | 4 | 3,730 | 5 | 0.02442141 | $1,686.65 |
| C (rambler) | 3 | 3 | 6 | 0.03553108 | $3,866.56 |
| B (sharebot) | 5 | 262 | 0 | 0.00000000 | $0.00 |
| D | 1 | 1 | 0 | 0.00000000 | $0.00 |
| E | 1 BTC + 1 ETH | 3 | 0 (tramo BTC) | 0.00000000 | $0.00 |
El Actor C extorsionó a tres hosts y se llevó más dinero que el que el Actor A sacó de 3,730. Sus tres víctimas hicieron seis pagos, varios de aproximadamente el doble de la exigencia, que es lo que cabría esperar de notas que amenazan con subir el precio cuando pasa un plazo. El Actor B es el resultado negativo más limpio del conjunto: 262 víctimas en 15 países, una nota de aspecto profesional, una dirección de contacto basada en dominio, y ni un solo satoshi, jamás.
Todos los ingresos de cada campaña aquí son once transacciones. Caben en una sola pantalla:
| # | Hora (UTC) | Actor | Dirección | BTC | USD en el momento | Coincide con la exigencia |
|---|---|---|---|---|---|---|
| 1 | 2025-05-27 16:49 | C | bc1qk2cc4… | 0.00413108 | $455.32 | ~0.0041 |
| 2 | 2025-10-29 12:52 | C | bc1qqmyg9d… | 0.00750000 | $848.68 | no (~2x) |
| 3 | 2025-10-30 18:41 | C | bc1qqmyg9d… | 0.00760000 | $816.67 | no (~2x) |
| 4 | 2025-11-01 20:27 | C | bc1qqmyg9d… | 0.00390000 | $429.99 | ~0.0041 |
| 5 | 2025-11-10 13:42 | C | bc1q5xj2m… | 0.00820000 | $868.57 | no (~2x) |
| 6 | 2025-11-10 14:45 | C | bc1q5xj2m… | 0.00420000 | $447.33 | ~0.0041 |
| 7 | 2026-02-02 05:52 | A | bc1q38rjul… | 0.00410000 | $310.83 | sí |
| 8 | 2026-02-07 00:08 | A | bc1q38rjul… | 0.00372427 | $262.65 | no |
| 9 | 2026-02-14 09:07 | A | bc1q38rjul… | 0.00608500 | $424.20 | no (~0.0061) |
| 10 | 2026-04-07 07:25 | A | bc1q38rjul… | 0.00410000 | $281.14 | sí |
| 11 | 2026-06-04 19:18 | A | bc1qvrryy2… | 0.00639778 | $407.83 | no (~0.0061) |
Solo dos de los once coinciden exactamente con una cifra exigida. Los casi aciertos (0.00372427, 0.006085, 0.00639778) son el aspecto que tiene un «enviar el máximo» con comisión incluida o una conversión de USD a BTC en el momento del envío, más que alguien copiando un importe exacto. La ventana del Actor C (mayo a noviembre de 2025) y la del Actor A (febrero a junio de 2026) no se solapan.
Cómo sale el dinero
Cada pago fue barrido con prontitud. El tiempo mediano desde el pago hasta el barrido es de unas dos horas y media; el más rápido fue de once minutos. Cada barrido es una transacción de una sola entrada, un pago que entra y un gasto que sale, sin consolidación, razón por la cual un análisis de propiedad por entrada común entre las trece direcciones devuelve cero clústeres. Si eso refleja una seguridad operativa deliberada o simplemente el hecho de que ningún monedero llegó a contener dos pagos que consolidar no puede determinarse a partir de once puntos de datos.
Los dos actores que cobraron se comportan luego de maneras opuestas, y la diferencia importa para cualquiera que quiera dar seguimiento. Los ingresos del Actor A fluyen en un único salto hacia infraestructura de custodia de alto volumen, monederos con decenas o cientos de miles de transacciones en toda su vida, el tipo de servicio que plausiblemente conserva registros de conoce a tu cliente. El Actor C envía únicamente a direcciones nuevas de un solo uso que nunca se han reutilizado. Así que el Actor A ha dejado un rastro corto, del largo de una citación judicial, hasta un punto de estrangulamiento con KYC, mientras que el Actor C no. Ninguna dirección de cobro se comparte entre ambos, y ninguna dirección posterior es alcanzada por los dos, de modo que la cadena no los fusiona; el vínculo entre el kit del Actor A y el Actor E se apoya en el texto de las notas y en un monedero anunciado compartido, no en el flujo de dinero. (Las direcciones concretas de servicios posteriores son pivotes de investigación más que indicadores para listas de bloqueo, y las de alto volumen pertenecen a servicios compartidos, así que no se reproducen aquí para evitar manchar a un custodio con la actividad de un operador.)
El tramo de Ethereum
La dirección de Ethereum del Actor E, anunciada en 0.1 ETH, tiene un historial que no coincide en absoluto con la exigencia. Toda su vida sustantiva es una única ráfaga de 108 minutos el 2026-07-27, cinco semanas después del censo: llegan unos 3.97 ETH y luego salen en fragmentos limpios de 0.5 y 1.0 ETH hacia siete contrapartes, por duplicado. Nada en ella es un pago de víctima de 0.1 ETH, y ninguna nota de Elasticsearch exige nada cercano a los ~4 ETH que se movieron. La valoramos como probable: un salto de paso o de estratificación, infraestructura asociada al atacante más que evidencia de ingresos por rescate. Las catorce transferencias de polvo hacia ella son spam de envenenamiento de direcciones de terceros y no dicen nada sobre el operador.
Siete semanas después
Lo más útil de un censo es hacerlo dos veces. El 2026-08-07 volvimos a sondear una muestra aleatoria determinista de 2,500 de los 5,073 hosts sometidos a rescate contra la línea base del censo:
| Resultado | Hosts | Proporción | Significado |
|---|---|---|---|
| Nota aún presente | 1,309 | 52.4% | sigue abierto, sigue vaciado, la nota sigue presente |
| Inaccesible | 829 | 33.2% | sin HTTP: desmantelado, con cortafuegos, o redireccionado |
| Nota desaparecida | 332 | 13.3% | el host responde, pero la nota ya no está |
| Autenticación activada | 30 | 1.2% | ahora se exige autenticación |
Solo el 1.2% de las víctimas cerró la puerta que permitió el incidente. Más de la mitad no cambió nada en absoluto en siete semanas. Incluso interpretando con generosidad cada host «inaccesible» como remediación por desmantelamiento, el techo queda en torno a un tercio, y «inaccesible» también abarca hosts que simplemente se movieron o que ocultó un parpadeo transitorio de la red.
Una cohorte rompe el patrón por completo. De 114 hosts mexicanos muestreados, 113 están vivos con el índice de rescate desaparecido y ninguno sigue llevando una nota, frente a una línea base en la que las víctimas de México se concentraban casi por completo en un único proveedor (Baja Datacenter, 231 hosts). Ningún otro país se ve así. Una limpieza masiva por parte del proveedor de alojamiento o del operador del parque de un único proveedor es la explicación más económica, pero los datos actuales no pueden descartar que un segundo actor haya borrado las notas, y en cualquier caso los hosts siguen siendo accesibles y sin autenticación. Marcado para seguimiento.
Indicadores de compromiso
Los monederos y los códigos son de autoría del atacante y se llevan en vivo para que los defensores puedan cotejarlos y rastrearlos. Los dominios de contacto y los enlaces están neutralizados.
Bitcoin (Actor A):
bc1q38rjul6gdamfflf6p4ukz0ymtvfgfv2j9saf6r (3,705 victims)
bc1qvrryy2vsq4jekejs8z2elkt3sxmhlyad06ymvr (25 victims)
bc1qzkk2cld734njkds9263udc2wqgncp9e3th66ps
bc1qu8t03mv2qwjv56gry2ft0qes0xwqhddjhsvkfl (shared with Actor E)Bitcoin (Actor B, «sharebot»):
bc1quwlw8djc7hfamf3qpspma34uh9dr6w4kudfu8p bc1qvrte050fngjlrmcuptz33259kw3wktkd3uv5hv
bc1qquzg5dg5yfqxlc0fy6pemcwa2xg5mw3l7l2gc4 bc1qt5cq2mnghwyyfl0pkd3086z9cad0m3hspwgl9t
bc1qqy3uegcgqjjncagjnkqgpplyl3k4a00khek5rsBitcoin (Actor C, «rambler»):
bc1qk2cc4ssl9j3d0xu5ljv0prsfzjdulvgvm4u6e7 bc1q5xj2mvtaupy56fff4dsaxwjxm8ftjzxfhw3ylh
bc1qqmyg9d9uj2fm93fjjjfuw2xrq2fwpr53uhf52dBitcoin (Actor D): 127ZBzXyLJFc7ShMmzkYFDhSiXXSnR8Jfr
Ethereum (Actor E): 0x3C11Cf2974c3Fb4d7ebBfea711a4A0b26989979D
Direcciones de contacto (neutralizadas):
wendy.etabw@gmx[.]com scandal@onionmail[.]org bitwezen@cock[.]li
db-recovery@sharebot[.]net es-recovery@sharebot[.]net
rambler+<id>@onionmail[.]org databaserestore32@onionmail[.]orgCódigos de recuperación: 0SH7HH1Q72JL (Actor A, fijo, no por víctima), BITWEZEN2026, 841BEACF110F, BCA95C11355F (Actor B), omoRmq (Actor D).
Enlaces (neutralizados): hxxps://tli[.]sh/73x1k (redirige a una nota de paste[.]sh cuya clave de descifrado se encuentra en el fragmento de la URL, de modo que el contenido se descifra en el navegador y el host nunca lo ve, lo que vuelve inútil una solicitud de retirada basada en el contenido), hxxps://cutmyurl[.]com/3caF8EkT (un acortador de enlaces comercial; su canal de abuso es la vía del enlace del Actor D).
De comportamiento: un clúster de Elasticsearch reducido a un único índice llamado read_me (recuento mediano de documentos residentes de uno, la propia nota); un GET /read_me/_search que devuelve cualquiera de las plantillas de arriba.
Qué hacer al respecto
- Coloca autenticación delante de Elasticsearch y Kibana, y mantén el puerto HTTP fuera de internet público. El Elasticsearch actual se distribuye con la seguridad habilitada por defecto; casi todos los hosts aquí la tenían desactivada o vinculada a una interfaz pública. Ese único control cierra toda la superficie de ataque descrita arriba.
- Si te alcanzan, no pagues. El operador dominante no puede distinguir tus datos de los de nadie más y, según la evidencia aquí, no guardó ninguna copia de ellos. El pago financia el siguiente barrido y no recupera nada. Restaura desde tus propias copias de seguridad y cierra la exposición.
- Da por hecho que un clúster vaciado fue leído antes de ser vaciado. Estuvo abierto a cualquiera, no solo al actor que finalmente lo borró, así que trata lo que contuviera como divulgado y rota cualquier secreto que hubiera en él.
- Revisa tu propio parque como lo haría un atacante. Un
GET /externo y sin credenciales contra tus endpoints de Elasticsearch te dice en una sola solicitud si responden sin contraseña. Ejecútalo desde fuera de tu red, porque una comprobación interna no verá lo que ve internet. - Restablece los valores por defecto. Seis pares de credenciales conocidos funcionaron en 39 hosts aquí, uno de ellos un producto de seguridad. Cambia las contraseñas de
elasticykibanay cualquier valor por defecto del proveedor, y confirma qué privilegio tiene realmente cada cuenta.
Mapeo de MITRE ATT&CK
| Táctica | Técnica |
|---|---|
| Initial Access | T1190 Exploit Public-Facing Application (Elasticsearch abierto y sin autenticación); T1078.001 Valid Accounts: Default Accounts (los 39 accesos por credencial por defecto) |
| Impact | T1485 Data Destruction (borrado masivo de índices); T1491.001 Internal Defacement (la nota read_me dejada en su lugar); T1657 Financial Theft (extorsión) |
Las notas también afirman exfiltración (T1567) y, en el caso del Actor E, amenazan con extorsión basada en filtración (T1657). La evidencia no respalda ninguna de las afirmaciones de una copia conservada; la destrucción es real, la exfiltración está afirmada.
Metodología y notas del analista
- El sesgo del punto de observación es grande, y lo medimos. Un punto de observación residencial o local calificó de «muertos» al 63% de los hosts que de hecho estaban vivos desde un punto de observación limpio en la nube (7,201 de 11,388; 7,113 de ellos completamente abiertos). Cualquier censo de activos expuestos que no controle desde dónde escanea subcuenta por amplio margen. Este censo es de un único punto de observación, una sola ubicación en la nube, con etiquetas de punto de observación y marca de tiempo por registro, y todos los recuentos son cifras de un único punto de observación.
- Los señuelos inflan el recuento bruto de «abiertos». Un conjunto de nodos con nombres autogenerados con un esquema enlatado idéntico, y hosts que falsifican sus listados de índices, tienen que excluirse antes de tratar un host abierto como una víctima. Eso ya está hecho en las cifras de arriba.
- La muestra de notas es de 2,500 de 5,073 hosts (49%), con semilla determinista para que las repeticiones sean comparables. Las proporciones de plantillas conllevan error de muestreo, y las plantillas más raras (de una a tres notas) establecen que algo existe, no cuán común es.
- Los totales en cadena son mínimos. Solo cubren las direcciones anunciadas en las notas que realmente leímos. Las notas no leídas, los hosts no muestreados y cualquier dirección nunca observada no están en el recuento. Las direcciones posteriores de alto volumen pertenecen a servicios compartidos; solo los importes concretos enviados desde los monederos de rescate son atribuibles a un actor, y los totales de por vida de los servicios no lo son.
- Solo lectura en todo momento. Las notas se leyeron de clústeres ya vaciados y sin autenticación con un
GET /read_me/_searchno autenticado por host. La prueba de credenciales fueron seis valores por defecto, unGET /cada uno, con limitación de tasa, en modo solo lectura. Las consultas en cadena solo alcanzaron exploradores públicos. No se recuperó contenido de víctimas, y el paste cifrado del lado del cliente enlazado por el Actor A no se descifró. - El lenguaje estimativo sigue la ICD 203, y la confianza refleja únicamente la evidencia de este conjunto de datos. Las organizaciones afectadas concretas, incluidos los clústeres de alto valor en el residuo sin rescate, se gestionan bajo divulgación responsable aparte y no se nombran.
Los datos subyacentes del censo y el análisis de monederos están disponibles para otros investigadores y defensores que los soliciten. Escribe a [email protected] con una breve nota sobre quién eres y para qué los necesitas.