← Volver al resumen

Safe Links en Exchange (Safe URLs): por qué la reescritura de URL es seguridad ficticia

Safe Links (Safe URLs) en Exchange reescribe los enlaces para el análisis en el momento del clic, pero oculta el destino real y genera seguridad ficticia. Conoce los dilemas y qué deberías hacer tú, como administrador, en su lugar.

Microsoft Defender para Office 365 ofrece Safe Links, en la práctica a menudo llamado "Safe URLs". La función reescribe cada enlace de los correos entrantes hacia una dirección de Microsoft, para que el destino se analice una vez más en el momento del clic. Suena razonable: un control adicional justo antes de llegar a algún sitio. Pero la reescritura elimina precisamente lo que necesitas para juzgar por ti mismo: el destino visible. Te sientes más seguro mientras en realidad ves menos. Y el núcleo de la solución no es que Microsoft deba retirar la función. Es que los administradores deben dejar de activar la reescritura de URL por reflejo y usarla solo cuando hayan sopesado conscientemente las desventajas.

Supón que recibes un correo con un enlace a https://portal-pago.es/acceso. Con Safe Links activado, Microsoft reescribe ese enlace en algo como https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fportal-pago.es%2Facceso&data=05%7C01%7C.... El destino original queda ahora oculto como parámetro dentro de una larga URL de Microsoft ilegible.

Al hacer clic, Microsoft te hace pasar primero por su propio servidor de comprobación. Este coteja la dirección de destino con la inteligencia de amenazas actual (análisis en el momento del clic). Si la dirección es conocida como maliciosa en ese momento, obtienes una página de advertencia en lugar del sitio. Si (todavía) no es conocida, se te reenvía. El control ocurre, pues, en el clic, no al leer el correo.

Por qué parece una buena idea sobre el papel

Safe Links no carece de valor, y conviene decirlo con honestidad. La función ofrece algunas ventajas reales:

  • Protección en el momento del clic: un enlace que estaba limpio en la entrega pero se volvió malicioso después puede bloquearse igualmente en el momento del clic.
  • Bloqueo central: en cuanto Microsoft marca un dominio como malicioso, todos tus usuarios quedan protegidos de golpe, sin que muevas un dedo.
  • Telemetría de clics: tu SOC o equipo de administración ve quién hizo clic en qué enlace. Eso vale oro al investigar un incidente.
  • Barrera baja: la función se activa en minutos y no cuesta ninguna licencia adicional si ya tienes Defender para Office 365.

El problema central: ya no puedes leer el destino real

Una URL no es una cadena técnica impenetrable. Es información. El dominio te dice a quién llegas. La ruta insinúa qué vas a hacer. Los parámetros dan contexto. Un ojo entrenado ve al instante que microsoft-login.secure-verify.ru no es Microsoft, sino un dominio ruso que se hace pasar por Microsoft.

En cuanto Safe Links reescribe el enlace a una dirección safelinks.protection.outlook.com, esa información desaparece. Solo ves ya una URL de Microsoft con una maraña de parámetros. Ya no puedes pasar el ratón por encima del enlace y juzgar tú mismo a dónde va. Lo único que ves es que es "algo de Microsoft", y eso se siente exactamente tan seguro como el atacante espera.

Por qué esto es seguridad ficticia

La seguridad ficticia surge cuando una medida aumenta la sensación de seguridad más que la seguridad real. Safe Links es un ejemplo de manual. Los empleados aprenden inconscientemente: "si el enlace pasa por Microsoft, está comprobado y por tanto es seguro." Así la vigilancia baja justo en el momento en que más se necesita.

Y el análisis en el momento del clic dista de ser hermético. Los atacantes saben exactamente cómo funciona y lo eluden de forma rutinaria:

  • Cloaking: el sitio de phishing muestra contenido inofensivo al escáner de Microsoft y la página real, maliciosa, al usuario. El análisis pasa; te engañan igualmente.
  • Páginas zero-hour: un dominio de phishing recién creado no está en ninguna lista de bloqueo. En el momento del clic Microsoft simplemente no lo conoce y te reenvía.
  • Redirecciones abiertas en dominios de confianza: los atacantes abusan de un dominio legítimo que redirige (por ejemplo un servicio de publicidad o de seguimiento) para que la primera comprobación parezca limpia.
  • Enlaces fuera del alcance: las URL en archivos adjuntos, códigos QR o imágenes no se reescriben. Justo ahí trasladan los atacantes sus enlaces.

Los dilemas a los que te enfrentas como administrador

No es una cuestión de "simplemente activado" o "simplemente desactivado". Como administrador estás atrapado entre intereses reales y contradictorios. Esos dilemas rara vez se nombran en voz alta:

  • Ganancia en el momento del clic frente a legibilidad. Activa la reescritura y ganas protección contra enlaces que se vuelven maliciosos, pero pierdes la capacidad de las personas de leer el destino por sí mismas. No puedes maximizar ambas.
  • Capa adicional frente a habituación. Una capa de defensa adicional siempre suena bien, pero cada capa que tranquiliza a las personas reduce su propia alerta. La defensa en profundidad puede erosionar la vigilancia humana.
  • Telemetría frente a ceguera. La telemetría de clics es valiosa para tu SOC, pero compras esos datos con la ceguera de tus usuarios. ¿Es un intercambio justo?
  • Percepción frente a realidad. Desactivar la reescritura le parece "menos seguro" a la dirección y a los auditores, aunque haga a tu gente más resiliente con el tiempo. Debes atreverte a explicar una decisión que parece menos segura.
  • Comodidad frente a dependencia. Cuanto más te apoyes en la comprobación automática, más dependiente te vuelves de un único proveedor que le quita a tu gente el esfuerzo de pensar.

No Microsoft: eres tú, el administrador, quien decide

Es tentador decir "que Microsoft mejore la función". Pero la función no está en la mesa de Microsoft, está en la tuya. Tú decides en la directiva de Safe Links si los enlaces se reescriben, si la URL original permanece visible y qué excepciones se aplican. El poder y la responsabilidad recaen en el administrador.

El mensaje, pues, no es "desactívalo todo", sino: deja de activar la reescritura por reflejo. No la trates como seguridad extra gratuita, sino como una intervención con un precio. Sopesa conscientemente el valor del análisis (momento del clic, telemetría, bloqueo central) frente al precio que pagas: personas que ya no aprenden a mirar. En muchas organizaciones ese precio es mayor que la ganancia, sobre todo si al mismo tiempo inviertes en hacer resiliente a tu gente.

Qué conviene hacer en su lugar

Un enfoque maduro combina técnica y comportamiento en vez de sacrificar el segundo por el primero:

  • Mantén el análisis, reconsidera la reescritura. Usa el valor de detección y bloqueo de Defender, pero cuestiona con seriedad si ocultar la URL vale ese valor.
  • Invierte en alfabetización en URL. Enseña a las personas a leer dominios: dónde termina el dominio real, qué es un subdominio, qué aspecto tiene una extensión anómala. Es una habilidad, no un dato que memorizar.
  • Mide el comportamiento con simulaciones de phishing. No para pillar a la gente, sino para ver si mejora el reconocimiento y la notificación. Dirige por la tasa de notificación, no solo por la tasa de clic.
  • Haz que notificar sea fácil y seguro. Un botón para notificar correo sospechoso, sin que nadie se sienta tonto. Las notificaciones rápidas son tu mejor alerta temprana.
  • Combínalo con autenticación resistente al phishing. Con FIDO2 o passkeys una contraseña robada vale mucho menos, aunque alguien haga clic una vez.

Cómo formar a los empleados en el análisis real de URL

Sé honesto: el análisis de URL no es fácil. Quien grita "que la gente simplemente compruebe el enlace, es sencillo" no lo entiende lo suficiente. Los dominios pueden ser engañosos, los subdominios confusos, y los atacantes juegan deliberadamente con tu expectativa. Fórmalo, pues, como una habilidad, con repetición y ejemplos reales.

Un detalle importante: mientras Safe Links reescriba las URL, ni siquiera puedes impartir esta formación correctamente, porque no queda nada que leer para tu gente. Si quieres enseñar a las personas a mirar, la URL real debe ser visible. Empieza poco a poco: en ejercicios breves y recurrentes, muestra cada vez un puñado de URL y haz que señalen el dominio real. Luego sube a casos más difíciles: homóglifos, largas cadenas de subdominios y enlaces que a primera vista parecen correctos pero no lo son del todo.

Cómo disfrazan los atacantes una URL — ejemplos para practicar

Usa este tipo de ejemplo en tu formación. Deja que las personas señalen por sí mismas qué no cuadra:

  • Homóglifos: goog1e.com (un dígito 1 en lugar de la letra l) o g00gle.com (dos ceros). Visualmente casi idéntico, técnicamente otro dominio.
  • Subdominio engañoso: microsoft.login.secure-verify.ru. El dominio real es secure-verify.ru; "microsoft" y "login" son solo subdominios que generan confianza.
  • Extensión equivocada: paypal-secure.com en lugar del real paypal.com. Marca conocida, solo el dominio equivocado.
  • Redirección abierta: un enlace a un dominio de confianza que redirige mediante un parámetro a un sitio malicioso, por ejemplo ...?redirect=https://phish.example.

FAQ

No. El análisis en el momento del clic, el bloqueo central de dominios maliciosos conocidos y sobre todo la telemetría de clics para tu SOC tienen valor real. El problema no es la detección en segundo plano, sino reescribir el enlace visible y la falsa sensación de seguridad que crea. No tiras al niño con el agua del baño; solo reconsideras la reescritura.

¿Debo desactivar Safe URLs de inmediato?

No a ciegas. Pero tampoco lo actives a ciegas. Trátalo como una decisión deliberada: sopesa la ganancia de análisis y telemetría frente al precio de que tu gente ya no pueda leer el destino y se vuelva descuidada. Si eliges la reescritura, hazlo con los ojos abiertos y compénsalo con formación en análisis de URL. En muchas organizaciones la legibilidad y la resiliencia de las personas valen más con el tiempo que la capa automática adicional.

¿Cómo reconozco yo mismo si un enlace es seguro?

Lee hacia el final del dominio: el dominio real está justo antes de la primera barra simple (la extensión como .es o .com y la palabra anterior). Todo lo anterior son subdominios que un atacante puede rellenar libremente. Cuidado con los homóglifos (dígito 1 por letra l, cero por o), las marcas en el dominio equivocado y los parámetros de redirección. ¿Dudas? No hagas clic, ve tú mismo al sitio conocido o llama al remitente a un número que ya tengas.

¿Qué pasa si un empleado hace clic igualmente en un enlace malicioso?

Reacciona rápido y sin culpa. Que el empleado lo notifique a TI de inmediato, desconecta el dispositivo de la red si se sospecha malware, y restablece al instante las contraseñas y las sesiones activas de las cuentas implicadas. Comprueba que la MFA sigue intacta y revisa los registros para ver quién más recibió el mismo correo. Una notificación rápida y serena limita el daño mucho más que un silencio culpable.

¿Dónde está el límite entre prudencia y paranoia?

La prudencia es un hábito fijo en acciones de riesgo: iniciar sesión, pagar o cualquier cosa con datos sensibles. Ahí siempre verificas. La paranoia es congelarte ante cada correo y no atreverte a nada. Traza el límite en el proceso: ante solicitudes financieras o de acceso inusuales verificas por un canal independiente; ante el correo interno corriente confías en tu instinto entrenado. Así sigues siendo operativo y resiliente a la vez.

¿Quiere ayuda con la implementación?

Reserve una breve demo o comente su caso. Respondemos rápido.