Un correo que dice venir de GitHub puede ser auténtico o una imitación muy convincente. Para distinguirlo con criterio, se analizan sus cabeceras y se comprueban los mecanismos de autenticación del correo. En este caso se revisa un mensaje real con el asunto [GitHub] Claude is requesting updated permissions y se muestra un procedimiento que se puede repetir ante otros mensajes sospechosos.
El caso
El mensaje informa de que una aplicación instalada en una cuenta de GitHub —la app de Claude, de Anthropic— actualiza sus permisos y solicita aprobarlos mediante un botón. El patrón resulta plausible para un ataque de phishing: aparece una marca conocida, existe una petición de acción y se facilita un enlace.
Primero: no pulses el enlace
Antes de analizar el correo, se aplica una regla sencilla: no se utiliza ningún enlace incluido en el mensaje. Se abre el navegador, se escribe directamente github.com y se comprueba allí si existe realmente la solicitud.
- Si el aviso es legítimo, la solicitud aparece en GitHub, por ejemplo en Settings → Applications → Installed GitHub Apps o en los ajustes correspondientes de la organización.
- Si no aparece, se evita interactuar con un posible enlace fraudulento.
El análisis de cabeceras permite estudiar quién firma el mensaje, cómo se transporta y qué mecanismos de autenticación supera, pero no sustituye esta precaución básica.
Lo que ves en pantalla no prueba la autenticidad
El nombre y la dirección que muestra el cliente de correo en el campo remitente pueden falsificarse. Del mismo modo, los logotipos, el diseño o el tono del mensaje tampoco constituyen una prueba suficiente.
Un icono de candado puede indicar que el transporte del mensaje se cifra, pero no demuestra por sí mismo que el remitente sea quien afirma ser. La comprobación útil se realiza en los resultados de autenticación y, en especial, en las firmas criptográficas incluidas en las cabeceras.
Cómo ver las cabeceras
| Cliente | Dónde |
|---|---|
| Proton Mail | Menú ⋯ del mensaje → Ver cabeceras |
| Gmail | Menú ⋮ del mensaje → Mostrar original |
| Outlook (web) | Menú ⋯ → Ver → Ver detalles del mensaje |
| Outlook (escritorio) | Abrir el mensaje → Archivo → Propiedades → Encabezados de Internet |
El resultado contiene muchas líneas técnicas, pero para una primera comprobación se localizan principalmente Authentication-Results, DKIM, SPF, DMARC y, cuando existen reenvíos, ARC.
SPF, DKIM y DMARC sin jerga
| Comprobación | Qué verifica | Analogía | ¿Sobrevive a un reenvío? |
|---|---|---|---|
| SPF | Comprueba si el servidor que entrega el correo está autorizado a utilizar el dominio técnico indicado. | El cartero dispone de acreditación para esa oficina de correos. | No necesariamente: tras un reenvío cambia el servidor que entrega el mensaje. |
| DKIM | Comprueba una firma criptográfica asociada al dominio que aparece en d= y permite detectar modificaciones incompatibles con la firma. |
Un sello digital verificable asociado al dominio firmante. | Sí, siempre que el contenido firmado no se modifique de forma que invalide la firma. |
| DMARC | Comprueba que existe alineación entre el dominio visible del remitente y un identificador autenticado mediante SPF o DKIM. | Se verifica que la identidad autenticada coincide con la que se presenta al usuario. | Depende de que SPF o DKIM sigan ofreciendo una identidad alineada. |
SPF se define en RFC 7208 y DKIM en RFC 6376. DMARC utiliza SPF y DKIM junto con reglas de alineación de dominios; su especificación vigente se recoge en RFC 9989.
Qué buscamos en este mensaje
En una cabecera correcta interesa localizar resultados como los siguientes:
dkim=pass (2048-bit key) header.d=github.com header.i=@github.com
dmarc=pass header.from=github.comUn resultado dkim=pass con header.d=github.com indica que la firma DKIM asociada a ese dominio se verifica correctamente. A continuación se comprueba también que DMARC pasa para el dominio visible esperado.
La trampa de los reenvíos y los alias
En este caso el mensaje no llega directamente al buzón final. El recorrido es:
- GitHub envía el correo a una dirección de Gmail.
- Gmail lo reenvía automáticamente a un alias de Proton Pass.
- El servicio de alias de Proton/SimpleLogin lo reescribe y lo entrega en Proton Mail.
Los intermediarios pueden modificar ciertos campos y complicar la lectura de SPF. Por ese motivo no basta con encontrar un pass: también se comprueba qué dominio obtiene ese resultado.
ARC ayuda a conservar el contexto de autenticación
Cuando existen intermediarios, la cabecera Arc-Authentication-Results puede conservar evaluaciones de autenticación realizadas en etapas anteriores del recorrido. ARC se define en RFC 8617 y funciona como una cadena de resultados autenticados añadidos por los sistemas intermediarios.
En el caso analizado aparece:
Arc-Authentication-Results: i=1; mail.protonmail.ch;
dmarc=pass header.from=github.com;
spf=pass smtp.mailfrom=gmail.com;
dkim=pass (2048-bit key) header.d=github.comLa lectura es coherente con el recorrido observado: DKIM se valida para github.com, DMARC se valida para github.com y SPF refleja a Gmail como sistema que realiza una etapa del reenvío.
Pistas adicionales
DKIM y DMARC proporcionan las evidencias principales de autenticación del dominio. Otras cabeceras ayudan a determinar si el conjunto resulta coherente:
| Cabecera o dato | Qué se observa | Qué aporta |
|---|---|---|
| Message-Id | Formato compatible con la infraestructura de envío utilizada por GitHub. | Aporta coherencia contextual, aunque no prueba autenticidad por sí solo. |
| Date | Zona horaria del mensaje compatible con el sistema de envío observado. | Sirve como pista secundaria. |
| Puntuación de spam | El filtro no detecta anomalías relevantes. | Es una señal complementaria, no concluyente. |
| Contenido | No solicita contraseñas ni pagos y remite a una acción que también puede comprobarse directamente en GitHub. | Reduce inconsistencias, pero no sustituye la autenticación técnica. |
Un hallazgo inesperado: revisar los reenvíos
El análisis también permite detectar algo importante: las cabeceras del reenvío pueden revelar que el correo pasa por una cuenta de Gmail distinta de la esperada.
Cuando aparece una cuenta que no se reconoce, se revisan inmediatamente las opciones de Reenvío y correo POP/IMAP y la sección de Filtros de Gmail. Un atacante que obtiene acceso a una cuenta puede crear reglas de reenvío para seguir recibiendo copias de los mensajes incluso después de un cambio de contraseña.
Checklist para la próxima vez
- No se pulsa ningún enlace ni se cargan recursos innecesarios del correo sospechoso.
- Se entra en la web oficial escribiendo manualmente su dirección y se comprueba si el aviso existe allí.
- Se abren las cabeceras o el mensaje original.
- Se busca
dkim=passy se comprueba el dominio deheader.d=. - Se busca
dmarc=passy se comprueba queheader.from=corresponde al dominio esperado. - Si hay reenvíos o alias, se revisa
Arc-Authentication-Results. - Se comprueba si el resto del mensaje y de las cabeceras resulta coherente.
- Se revisan también los reenvíos y filtros configurados en las cuentas implicadas.
Veredicto del caso
Las cabeceras analizadas muestran una firma DKIM válida de github.com y un resultado DMARC coherente con ese mismo dominio. El recorrido de reenvío también explica los resultados adicionales observados en SPF y ARC.
El mensaje analizado resulta auténtico de GitHub. Aun así, la aprobación o rechazo de la solicitud se realiza entrando directamente en github.com, no utilizando el botón incluido en el correo.
Referencias
Andersen, K., Long, B., Blank, S., & Kucherawy, M. (2019). The Authenticated Received Chain (ARC) Protocol (RFC 8617). RFC Editor. https://www.rfc-editor.org/rfc/rfc8617.html
Crocker, D., Hansen, T., & Kucherawy, M. (2011). DomainKeys Identified Mail (DKIM) Signatures (RFC 6376). RFC Editor. https://www.rfc-editor.org/rfc/rfc6376.html
Herr, T., & Levine, J. (2026). Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (RFC 9989). RFC Editor. https://www.rfc-editor.org/rfc/rfc9989.html
Kitterman, S. (2014). Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (RFC 7208). RFC Editor. https://www.rfc-editor.org/rfc/rfc7208.html
Acerca del autor
