Qué afirma haber observado Microsoft
Microsoft Threat Intelligence publicó el informe el 5 de noviembre de 2026. La empresa dice que actores maliciosos usaron un framework agentivo para buscar credenciales expuestas en repositorios públicos de GitHub, incluidas claves de aplicaciones e inferencia de IA, analizar resultados y realizar actividades posteriores. Describe un caso en que un agente pasó de buscar en repositorios a extraer datos de Azure Key Vault en cinco minutos. Es el reporte de incidentes de Microsoft; CherTra News no verificó los casos de forma independiente.
Microsoft también informa de inicios de sesión de service principal desde el 28 de octubre para algunos clientes afectados, seguidos de descubrimiento de recursos cloud y acceso a Key Vault y Storage. Según el informe, algunas credenciales comprometidas pertenecían a una aplicación multiinquilino de un proveedor. Esto no implica que toda clave pública sea explotada automáticamente, pero borrar el texto del repositorio no termina la exposición.
Tratar una credencial encontrada como comprometida
Si una credencial aparece en código público, hay que asumir que pudo copiarse aunque el repositorio se privatice o se reescriba el commit enseguida. Revocar o desactivar primero la credencial y después sustituirla mediante el proceso aprobado del proveedor. Actualizar los servicios dependientes de forma segura, confirmar que la anterior ya no funciona y revisar los registros en busca de horas, ubicaciones, identidades o recursos inusuales.
Determinar qué permisos tenía y si se reutilizó entre entornos. Una clave de desarrollo no debería autorizar producción. En el caso de un proveedor o service principal, averiguar qué aplicaciones o inquilinos comparten esa identidad. Conservar las evidencias de auditoría e involucrar al responsable de respuesta a incidentes: un historial Git limpio no demuestra que la exposición haya terminado.
Reducir la probabilidad de otra exposición
Activar secret scanning y push protection en los repositorios compatibles, incluida la vigilancia de repositorios públicos cuando el plan lo permita. Guardar credenciales en un gestor de secretos, conceder a cada identidad solo los permisos necesarios y preferir credenciales de corta duración o workload identity cuando sea viable. Separar pruebas y producción, asignar responsable y vencimiento y alertar ante accesos de autenticación o datos sensibles inusuales.
Revisar también trabajos automatizados, forks, registros de compilación, adjuntos de issues y configuración de despliegue. El escaneo detecta formatos compatibles, pero no prueba que no quede ningún tipo de secreto. Se necesitan un inventario y una revisión periódica de accesos, especialmente para integraciones de proveedores e identidades de máquina.
Lista de respuesta para equipos pequeños
1) Revocar el secreto expuesto. 2) Rotarlo y actualizar el servicio legítimo por un canal fiable. 3) Revisar registros de identidad y cloud para detectar uso de la credencial antigua y cuentas relacionadas. 4) Limitar accesos sospechosos preservando evidencias. 5) Buscar copias en repositorios y sistemas de compilación propios. 6) Añadir escaneo y protección de push y revisar privilegios y vencimientos.
Si pudieron accederse datos o entornos de clientes, seguir el proceso de incidentes y notificación de la organización y recurrir a especialistas de seguridad. El artículo de Microsoft ofrece detecciones técnicas para defensores; este texto se limita deliberadamente a la respuesta defensiva. Un secreto representa una identidad: tras una exposición hay que renovarla e investigar a qué podía acceder.
Fuentes y lecturas adicionales
¿Quieres señalar un error factual o sugerir una fuente? Contactar con la redacción.
