GitHub bloquea a investigador de seguridad que publicó exploits zero-day de Windows

• La cuenta de GitHub de Nightmare-Eclipse fue bloqueada, y él afirma que trasladó su espacio de trabajo a GitLab por una represalia de Microsoft
• El conflicto escaló a inicios de abril con la divulgación del zero-day BlueHammer, y Eclipse asegura que Microsoft ignoró sus reportes y solicitudes de recompensa
• Microsoft no ha explicado el motivo ni el proceso del bloqueo, por lo que no está claro si el problema fue una divulgación no estándar o una falla en los procedimientos de reporte y recompensas
• Eclipse publicó seis zero-days de Windows, incluidos BlueHammer, RedSun y UnDefend, y algunos ya se explotan activamente en entornos reales
• El bloqueo en GitHub difícilmente puede detener código y exploits ya públicos, y en un contexto donde la IA acelera el hallazgo de vulnerabilidades, deja en evidencia los límites de los procesos de divulgación y parchado

---

Bloqueo de la cuenta de GitHub y mudanza a GitLab

• Microsoft bloqueó la cuenta de GitHub del investigador de seguridad Nightmare-Eclipse (Chaotic Eclipse) por una razón que aún no ha hecho pública
• Eclipse trasladó su espacio de trabajo a GitLab y señaló que la cuenta de Microsoft que usaba para reportar bugs también ya fue eliminada
• En una entrada de blog, afirmó que la medida fue represiva y que Microsoft se negó a comunicarse con él y tampoco le pagó ninguna recompensa
• El programa de recompensas de MSRC de Microsoft ofrece, según las condiciones, entre 30 mil y 100 mil dólares por zero-days de endpoint, y hasta 250 mil dólares por vulnerabilidades en Hyper-V
• Eclipse ya publicó seis exploits zero-day y dejó entrever que podría haber nuevas divulgaciones sobre Microsoft el 14 de julio

El conflicto entre Microsoft y Eclipse

• El conflicto se intensificó a inicios de abril, cuando Eclipse publicó el zero-day BlueHammer sin aviso previo
• El blog de Eclipse critica con dureza a Microsoft y a MSRC, y sostiene que Microsoft ignoró o rechazó reportes de zero-days y no pagó la recompensa solicitada, causándole pérdidas económicas
• Eclipse afirmó que desde Microsoft le dijeron que le “arruinarían la vida” y que eso efectivamente ocurrió, además de señalar que existe una especie de dead man switch
• Como Microsoft no ha dado a conocer los detalles del caso, es difícil determinar si se trata de un investigador que no siguió el proceso estándar de divulgación o de una empresa que dificultó el reporte de seguridad

Controversia sobre el proceso de MSRC y presión sobre las políticas de divulgación

• William Dormann, de Tharros, criticó en un texto sobre BlueHammer que MSRC antes era bueno para colaborar, pero que por recortes de costos despidió a personal experimentado y dejó a personas que solo siguen diagramas de proceso
• Dormann considera que ahora MSRC parece exigir el envío de videos del exploit, y que Microsoft podría haber cerrado el caso porque el reportante no presentó uno
• Mientras Microsoft guarda silencio, sigue sin quedar claro si el centro del conflicto está en el funcionamiento real del proceso de divulgación responsable de vulnerabilidades y del programa de recompensas
• Han surgido evaluaciones de que el plazo estándar de 90 días entre divulgación y parche prácticamente ya quedó obsoleto por la investigación de seguridad basada en IA
• En un contexto donde tanto el tiempo hasta crear un exploit como la cantidad de exploits sin uso se están acercando a cero, aumenta la necesidad de que Microsoft y otros proveedores de software ajusten sus políticas

Zero-days de Windows publicados

• Eclipse publicó varios exploits zero-day de Windows
• BlueHammer es una vulnerabilidad que permite obtener privilegios SYSTEM a través de Defender
• RedSun también permite acceso con privilegios de SYSTEM
• UnDefend puede dejar a Defender fuera de línea
• GreenPlasma obtiene acceso SYSTEM a través del servicio CTFMon
• MiniPlasma permite una elevación de privilegios similar mediante una falla en el controlador Windows Cloud Filter
• YellowKey es una vulnerabilidad de BitLocker que permite a un atacante abrir unidades cifradas casi sin esfuerzo, socavando el objetivo central de BitLocker

Explotación real e impacto en seguridad

• BlueHammer, RedSun y UnDefend ya fueron identificados como vulnerabilidades explotadas activamente en entornos reales
• Las demás vulnerabilidades también tienen código de prueba de concepto total o parcial publicado, lo que facilita su uso por parte de atacantes interesados
• El bloqueo de la cuenta de GitHub no basta para eliminar el código ya publicado ni para frenar su explotación, y agrava el choque entre los investigadores y las empresas dueñas de las plataformas
• La combinación de divulgación de zero-days, disputas por recompensas, bloqueos de cuentas y descubrimiento acelerado de vulnerabilidades por IA hace más evidentes los límites de los procesos tradicionales de reporte, validación y parchado de seguridad

[GN⁺]

Comentarios de Hacker News

• Si encuentro un bug de seguridad en una app web, ya no lo reporto. La primera vez que lo hice, casi me arresta la policía; la segunda, ni siquiera me respondieron y en vez de eso contactaron directamente a mi empleador para decir que mi reporte les había molestado y que quería escribir sobre ello después de que lo corrigieran
  Desde entonces decidí que no vale la pena pasar por esas molestias, y si simplemente lo dejo pasar, yo también puedo tener un día tranquilo

  • Si quieres, puedes reportar vulnerabilidades al Finnish Cyber Security Centre, y ellos se encargan del reporte y la mediación con las partes afectadas
    Incluso puede hacerse de forma totalmente anónima, así que no tienes que preocuparte de que una empresa hipersensible te arruine la vida. El FCSC de Traficom es un gran recurso para que los investigadores white hat puedan seguir contribuyendo al bien público
  • Una vez una línea ferroviaria publicó en redes sociales una foto sobre “haber hecho algo bueno por alguien”, pero en la pared de la oficina que salía en la foto había una hoja A4 con nombres de usuario y datos de acceso de varios sistemas
    Lo reporté a tres contactos que pude encontrar, pero solo uno respondió, preguntando qué hacían esos sistemas y cuál era el riesgo. Yo no tenía idea, y desde luego no iba a intentar entrar a sistemas desconocidos para averiguarlo, así que respondí que lo pasaran al equipo interno de IT para que revisaran cambiar o reemplazar eso
    Al final me respondieron agradeciendo la diligencia y diciendo que habían borrado la foto, así que supuse que quedó resuelto. Espero que alguien que sí entendiera realmente lo haya revisado, pero decidí no involucrarme más
  • Es mejor no meterse
    Durante un tiempo trabajé profesionalmente como white hat, pero coincido en que intentar ser honesto y ayudar hoy en día es arriesgado. Si alguien decide vender vulnerabilidades, hasta lo entiendo
  • Algunos criticarán la regulación, pero la Ley de Ciberresiliencia (CRA) obligatoria en la UE hizo que las empresas tengan un canal claro de contacto para recibir reportes de vulnerabilidades y que realmente respondan
  • También podrías intentar reportar el exploit de forma anónima a una agencia gubernamental

• No sé qué está pasando aquí, pero la primera regla de un gran programa de bug bounty es que todas las personas relevantes del lado del proveedor tienen fuertes incentivos para pagar
  En muchos casos hay alguien cuyas métricas internas dependen de los pagos, y en estos programas pagar es motivo de celebración. Casi seguro que no tiene sentido pensar que Microsoft está acosando a quien reclama una recompensa para ahorrarse dinero
  Puede que eso no aplique a empresas pequeñas, y esa es parte de la razón por la que no deberían operar bug bounties, pero definitivamente sí aplica a compañías del tamaño de FAANG/MAG7. Eso no significa que estos programas siempre sean generosos al pagar o que nunca tomen decisiones que hagan enojar a la gente. Solo que no encaja con la idea de retener pagos por rencor
  Dicho eso, hace tiempo que no hablo con gente de Microsoft, así que dejo un pequeño margen de duda

  • Si lees la publicación de YellowKey, parece que al menos en algunos casos reveló una puerta trasera oficial de Microsoft usada por agencias de inteligencia de EE. UU. y otras entidades. La idea es que BitLocker no es seguro y tiene una puerta trasera
    Después de que TrueCrypt cerró de repente de un día para otro, eliminó todas las descargas y recomendó a todos migrar a Microsoft BitLocker, esto no era algo completamente impensable
    [1] - https://www.tomshardware.com/tech-industry/cyber-security/mi...
  • Todo esto empezó cuando la burocracia se negó siquiera a revisar Bluehammer porque no lograron convencer al reportante de publicar un video
    Y en vez de arreglar la burocracia, presionaron más hasta llegar a banear la cuenta, lo cual se ve realmente mal. No entiendo por qué habría que interpretar a Microsoft de buena fe
  • El bug que esta persona planteó parece una puerta trasera de BitLocker bastante evidente, y plantea dudas muy serias sobre lo que Microsoft está haciendo con el cifrado
    Parece bastante posible que se pueda descifrar el volumen sin la clave del usuario, lo cual es extremadamente preocupante. Da la impresión de que quieren fingir que nunca pasó, pero ya se hizo público
  • Si hubieran sido inteligentes después del baneo, le habrían ofrecido un trabajo con mucho dinero. Estas grandes empresas pueden ponerse tensas, pero si no son tontas, pagan
    Como es Microsoft, puede que no sea la empresa más progresista en estas cosas, así que no sé si se habrán dado cuenta
  • Cuando trabajé evaluando bug bounties, nunca vi evidencia de reticencia a pagar. Lo peor que vi del lado de la empresa fue pedir en una prueba de concepto “por favor eviten X” y luego pagar una cantidad mayor a un investigador que ignoró esa instrucción
    Al final fue porque el riesgo demostrado era mayor. En sentido contrario, en un programa grande un investigador convenció hace mucho tiempo a la empresa de que un exploit XSS común podía producir un efecto que correspondía a una categoría de pago más alta, y luego cada vez que encontraba XSS adjuntaba una prueba de concepto con ese mismo efecto y seguía recibiendo una clasificación indebidamente alta. Los XSS de otros investigadores se pagaban según la categoría XSS de la tabla
    Aunque sí se me ocurre una excepción. Alguien logró la especie de santo grial de instalar un web shell en un servidor de la empresa, algo que según los criterios actuales valdría más de 10 mil dólares. Pero dejó el web shell ahí, sin borrarlo, y solo envió el reporte. La persona a cargo del programa se enfureció y dijo específicamente que no quería pagar la recompensa por esa razón. No recuerdo si al final sí se pagó

• Creo que Microsoft va a terminar arrepintiéndose de esto
  Si alguien encuentra un zero-day, no recibe recompensa y solo le banean la cuenta. Entonces va a vender ese zero-day en otro lado

  • Pero, ¿no se trata esta historia de que no vendió el exploit zero-day sino que lo publicó? Así dice también el título
    Y también fue baneado en GitLab, que no tiene relación con Microsoft
  • Hay otras personas buscando zero-days. La reputación importa muchísimo
  • Incluso vender zero-days en otro lado probablemente no sería un problema. La CIA puede entregar millones de dólares en lingotes de oro si un alto cargo lo pide, así que me imagino que ni orden de compra necesitan para comprar exploits

• En los últimos meses he tenido muchas respuestas digitales extrañas en varios asuntos relacionados, y me frustraba no poder identificar exactamente qué estaba haciendo mal. Entonces leí esta frase en el artículo
  “Pero para ahorrar costos, Microsoft despidió a la gente capacitada y dejó solo a los seguidores de diagramas de flujo.”
  Vale la pena recordar esa expresión. No les pagan por pensar, sino por seguir procedimientos predefinidos. Parece que en un futuro cercano vamos a tratar mucho más con este tipo de seguidores de diagramas de flujo, ya sean digitales o personas reales

  • La mayoría de las consultoras de seguridad corporativa con las que tuve que lidiar antes operaban con una checklist
  • En muchos oficios de cuello azul, como mecánicos, electricistas y constructores, seguir un flowchart es prácticamente ley, y los procedimientos están escritos con sangre y responsabilidad
    En cambio, la gente de IT, operaciones y desarrollo se ve a sí misma como trabajadores del conocimiento, artesanales y de pensamiento libre. Consideran que los atajos, los hacks y pensar fuera de la caja están más ligados a la habilidad que seguir procedimientos

• ¿Hay alguna postura pública sobre lo que está pasando en Microsoft? ¿Por qué Microsoft y GitLab banearon a ese usuario?
  Yo entendía que ambas plataformas permitían hospedar exploits e investigación de seguridad siempre que se marcara claramente desde el principio, pero supongo que debió haber infringido alguna regla

  • Si se trata de un exploit de cifrado completo de disco que todavía requiere acceso físico al hardware, quizá fue hecho para alguna agencia gubernamental de tres letras

• Supongo que dispararle al mensajero lo resolverá

  • Tal vez quieren empujar a que se vendan a agencias estatales en lugar de parchear la vulnerabilidad

• ¿Microsoft se creó por sí sola una responsabilidad editorial de eliminar zero-days de GitHub?
  Si un zero-day de mi software aparece en GitHub, ¿Microsoft también va a volarle la cuenta?

  • No veo por qué esta medida implicaría una obligación de actuar también contra otras cuentas en el futuro

• Esta situación muestra bien el conflicto de interés estructural de que Microsoft sea dueña de GitHub
  GitHub tiene términos de servicio claros sobre alojar exploits activos y weaponized, pero banear a investigadores que apuntan a Windows, incluso si hubiera una razón legítima, inevitablemente siempre va a parecer una represalia

• Información muy importante:
  https://www.theregister.com/security/2026/05/28/microsoft-0-...
  En la publicación de blog de Microsoft enlazada dice lo siguiente
  “Los detalles de estas vulnerabilidades no fueron compartidos con Microsoft antes de hacerse públicos, y su divulgación expuso a los clientes a un riesgo innecesario.”
  Entonces, ¿Microsoft está mintiendo? Si no, ¿por qué Nightmare-Eclipse no lo reportó? Es una situación bastante extraña

  • Me molesta la frase “su divulgación expuso a los clientes a un riesgo innecesario”
    Haya sido o no una divulgación responsable, quien puso en riesgo a los clientes no fue el investigador, sino Microsoft misma
  • La razón por la que Nightmare-Eclipse no lo reportó podría ser que sea una organización pantalla de una agencia de inteligencia extranjera haciéndose pasar por un investigador resentido
  • Los clientes de los que hablan aquí tal vez no sean las personas o empresas que pagaron por una licencia, sino la parte que pidió este backdoor