Safe Links en Microsoft Defender para Office 365 comprueba los enlaces del correo en busca de sitios web maliciosos. Esa comprobación es valiosa, pero no exige que Microsoft reescriba cada enlace en una dirección larga en safelinks.protection.outlook.com. Con el ajuste de comprobar mediante la API de Safe Links, el enlace original sigue siendo legible mientras se mantiene la comprobación previa a la entrega. La elección correcta depende del entorno de correo de la organización.
Descubre cómo convertir este tema en un programa de concienciación concreto con formación, simulaciones de phishing e informes claros para la dirección.
Ver la página de phishingUna medida de seguridad debe ayudar a las personas a evaluar un riesgo, y no debe ocultar la información que necesitan para hacerlo.
Microsoft Defender para Office 365 puede comprobar los enlaces del correo con Safe Links. Cuando un destinatario hace clic en un enlace sospechoso, Microsoft puede bloquear el acceso al sitio web. Es una capa adicional de protección útil contra el phishing.
Muchas organizaciones activan además la reescritura de enlaces. La URL original se sustituye entonces por una dirección larga en safelinks.protection.outlook.com. Así Microsoft puede volver a comprobar el enlace en el momento en que alguien hace clic.
El problema es que el destinatario ya no ve con claridad adónde lleva realmente el enlace. Justo cuando se enseña a los empleados a comprobar la dirección antes de hacer clic, la medida técnica de seguridad hace que esa dirección sea más difícil de leer.
El debate, por tanto, no trata de si Safe Links es útil. La verdadera pregunta es si esa protección exige reescribir todos y cada uno de los enlaces.
¿Qué hace exactamente Safe Links?
Safe Links forma parte de Microsoft Defender para Office 365. Aunque la función se presenta a menudo como una función de Exchange, se configura en el portal de Microsoft Defender o mediante Exchange Online PowerShell. Safe Links puede realizar varias comprobaciones:
- Los enlaces se examinan antes de entregar el correo.
- Los enlaces sospechosos y los enlaces a archivos pueden examinarse con más profundidad.
- Microsoft puede retener la entrega del mensaje hasta completar la comprobación.
- El enlace puede comprobarse de nuevo cuando el destinatario hace clic.
- Un sitio malicioso conocido puede bloquearse antes de abrirse.
La comprobación previa a la entrega se realiza con independencia de si el enlace se reescribe. La reescritura no es necesaria, por tanto, para esa primera comprobación.
¿Qué ocurre al reescribir?
Un enlace original puede tener este aspecto: https://www.example.com/iniciar-sesion. Safe Links puede convertirlo en una dirección que empieza por https://eur01.safelinks.protection.outlook.com/. El destino original queda entonces codificado en una larga serie de parámetros detrás de la dirección de Microsoft. Cuando el destinatario hace clic en el enlace, la petición pasa primero por Microsoft, donde se comprueba si el destino ya se conoce como malicioso.
Esta comprobación en el momento del clic es valiosa. Un sitio web puede ser aún inofensivo al recibir el correo y modificarse unas horas después. Esto también se conoce como ataque de phishing diferido. Gracias a la comprobación en el momento del clic, Microsoft puede bloquear igualmente un sitio modificado con posterioridad.
Por qué el destino se vuelve menos reconocible
Una URL contiene información. El dominio muestra qué organización está detrás del sitio web. Un empleado puede, por ejemplo, ver la diferencia entre https://login.microsoftonline.com y https://microsoft.control-acceso.example. En el segundo ejemplo, el visitante no llega a Microsoft. El dominio real es control-acceso.example. La palabra Microsoft solo está ahí para inspirar confianza.
Las autoridades de ciberseguridad aconsejan por ello pasar el cursor sobre un enlace antes de hacer clic y comprobar qué dirección aparece. Fijarse en pequeñas desviaciones de los nombres de dominio también es una parte importante de reconocer el phishing.
Safe Links puede dificultarlo. Al copiar un enlace, en ciertas notificaciones, en texto sin formato y en algunas otras aplicaciones, el destinatario ve sobre todo la larga dirección de Microsoft. El destino real ya no es directamente reconocible.
Microsoft indica que las versiones compatibles de Outlook pueden mostrar la URL original en una ventana al pasar el cursor sobre un enlace reescrito. En la vista normal de Outlook, el destino no tiene por qué estar siempre completamente oculto. La experiencia puede variar, no obstante, según la versión de Outlook, el dispositivo, el formato del mensaje y la aplicación en la que se abra el correo.
La objeción a la reescritura no es, por tanto, que el destino original sea invisible en todas las circunstancias. La objeción es que un enlace sencillo y reconocible se sustituye por una construcción técnica compleja cuya legibilidad depende de la aplicación utilizada.
La medida de seguridad contradice la formación
Muchas organizaciones enseñan a sus empleados a:
- comprobar el dominio antes de hacer clic;
- pasar el cursor sobre un enlace para ver el destino;
- fijarse en ortografías inusuales;
- comprobar si la dirección encaja con el remitente;
- en caso de duda, ir directamente al sitio web conocido.
Son consejos sensatos. Ayudan a los empleados a evaluar un riesgo por sí mismos. Sin embargo, cuando todos los enlaces se reescriben hacia una dirección de Microsoft, surge un mensaje contradictorio. La organización dice que los empleados deben comprobar un enlace, pero la configuración técnica dificulta esa comprobación.
Una URL larga de Safe Links también puede inspirar una confianza no deseada. Al fin y al cabo, el destinatario ve una dirección de Microsoft. De ahí puede surgir la conclusión errónea de que el sitio web final tiene que ser seguro.
Safe Links comprueba un enlace, pero no garantiza que un sitio web sea fiable. Los sitios de phishing nuevos pueden ser aún desconocidos. Un sitio legítimo puede haber sido comprometido, y los atacantes pueden usar técnicas para mostrar a las comprobaciones automatizadas un contenido distinto del que ven los visitantes normales. La comprobación técnica sigue siendo, por tanto, una capa adicional de protección y no debe sustituir el juicio propio del destinatario.
Microsoft también puede comprobar sin reescribir
Dentro de una directiva personalizada de Safe Links, Microsoft ofrece el ajuste Do not rewrite URLs, do checks via Safe Links API only (no reescribir las URL, realizar las comprobaciones solo mediante la API de Safe Links). Cuando se usa este ajuste:
- la URL original permanece en el mensaje;
- el enlace se sigue comprobando antes de la entrega;
- Microsoft puede volver a comprobar en el momento del clic en las versiones compatibles de Outlook;
- no es necesario modificar el contenido del correo.
La comprobación en el momento del clic se realiza entonces mediante una función de Outlook en lugar de una redirección en la URL. Microsoft lo admite en Outlook para Windows, Outlook para Mac y Outlook en la web. Esto demuestra que analizar y reescribir son dos decisiones de diseño distintas. Se puede usar Safe Links sin cambiar automáticamente cada URL.
La limitación de comprobar mediante la API de Safe Links
La variante de API también tiene un inconveniente importante. La comprobación en el momento del clic solo funciona en aplicaciones que admiten esta función. Si alguien abre el mensaje en otro programa de correo, la comprobación previa a la entrega se mantiene, pero la comprobación adicional al hacer clic puede faltar. Un enlace que era seguro al recibirse y se vuelve malicioso más tarde podría entonces abrirse igualmente.
El propio Microsoft cita el ejemplo de un usuario que hace clic en un enlace modificado posteriormente desde un cliente de correo alternativo. Como ese cliente no admite la API de Safe Links, el cambio no se detecta en el momento del clic. La decisión de no reescribir debe basarse, por tanto, en el entorno de trabajo real:
- ¿Usan casi todos los empleados una versión compatible de Outlook?
- ¿Se abre el correo de empresa también en otros programas de correo?
- ¿Se reenvían a menudo los mensajes automáticamente a direcciones externas?
- ¿Usan los empleados dispositivos compartidos o versiones anticuadas de Outlook?
- ¿Qué importancia tiene la protección contra enlaces que solo se vuelven dañinos más tarde?
- ¿Cuánto pesa la reconocibilidad del destino original?
No existe, pues, un ajuste que sea automáticamente el mejor en todas las organizaciones.
Microsoft usa por sí mismo ambos modelos
Las configuraciones predeterminadas de Microsoft muestran que no hay una elección unívoca. En la protección básica integrada, Microsoft usa Safe Links sin reescritura de URL. En los niveles de seguridad predefinidos Standard y Strict, los enlaces sí se reescriben.
En una nueva directiva personalizada creada a través del portal de Microsoft Defender, la opción de no reescribir está activada de forma predeterminada. Si la directiva se crea mediante PowerShell, la reescritura no está desactivada de forma predeterminada.
También en Microsoft Teams y en las aplicaciones de Office compatibles, Microsoft puede comprobar enlaces en el momento del clic sin reescribirlos. Eso confirma que la reescritura de URL no es un requisito técnico para toda forma de protección de Safe Links.
¿Cuál es una configuración sensata para la mayoría de las organizaciones?
Para una organización que trabaja principalmente con versiones actuales y compatibles de Outlook, merece la pena considerar la siguiente configuración:
- Activa Safe Links para el correo.
- Activa el análisis en tiempo real de enlaces sospechosos y enlaces de descarga.
- Deja que Microsoft retenga la entrega hasta completar la comprobación.
- Aplica Safe Links también a los mensajes internos cuando el riesgo de cuentas internas comprometidas pese lo suficiente.
- Activa «no reescribir las URL, realizar las comprobaciones solo mediante la API de Safe Links».
- No permitas que los usuarios ignoren sin más una advertencia seria de Safe Links.
- Prueba el funcionamiento en todas las versiones de Outlook utilizadas y en todos los dispositivos relevantes.
Así, el destino original sigue siendo legible, se mantiene la comprobación previa a la entrega y las versiones compatibles de Outlook vuelven a comprobar también en el momento del clic.
Para organizaciones con muchos programas de correo distintos, la reescritura puede ser una opción defendible. La redirección a través de Microsoft garantiza entonces que la comprobación en el momento del clic no dependa de Outlook. La reescritura no es, por tanto, mala por definición. Es mala, sobre todo, cuando se activa sin sopesarla y luego se presenta como pura seguridad añadida.
Considera también los inconvenientes para el correo y las investigaciones
Reescribir los enlaces no solo afecta a la concienciación. También cambia el contenido del mensaje. Eso puede notarse al:
- copiar un enlace en un documento o un aviso;
- reenviar un mensaje;
- archivar el correo;
- comparar un mensaje con el original;
- investigar digitalmente un incidente;
- procesarlo con otros sistemas de correo o de tickets;
- mostrar enlaces en dispositivos móviles;
- la accesibilidad y el uso de tecnología de apoyo.
Además, Microsoft reescribe una URL por destinatario. Cuando un mensaje se reenvía o se responde manualmente, los enlaces ya reescritos pueden permanecer reescritos.
Para la investigación de incidentes, el destino original suele poder extraerse todavía de la URL de Safe Links, pero para un destinatario normal eso no es práctico. Una medida de seguridad descifrable para la investigación técnica no es por ello fácil de usar.
La comprobación humana sigue siendo necesaria
Ninguna comprobación técnica conoce todos los sitios maliciosos. Sobre todo en el phishing dirigido, un dominio puede existir desde hace poco o usarse solo contra un grupo pequeño de víctimas. Los empleados deben, por tanto, seguir mirando el contexto:
- ¿Espero este mensaje?
- ¿Encaja la petición con el remitente?
- ¿Hay una prisa inusual?
- ¿Tengo que volver a iniciar sesión cuando normalmente no hace falta?
- ¿Se pide dinero, datos personales o un cambio de datos de pago?
- ¿Coincide el destino con la organización mencionada en el mensaje?
Una URL reconocible ayuda en esa evaluación, pero no basta. Incluso un dominio de aspecto correcto puede haber sido comprometido. La comprobación de URL debe combinarse, por tanto, con acuerdos de proceso, autenticación multifactor resistente al phishing y una forma sencilla de avisar.
¿Cómo incluir Safe Links en un programa de concienciación?
Explica a los empleados qué hace Safe Links y qué no. Decir solamente que la función existe no es suficiente. El mensaje principal es:
Safe Links puede bloquear sitios maliciosos conocidos, pero un enlace que no se bloquea no es automáticamente seguro.
Muestra en las formaciones:
- cómo se estructura una dirección de internet normal;
- dónde está el dominio real en una URL larga;
- cómo pueden abusarse los subdominios;
- que la dirección de Microsoft de Safe Links no es el destino final;
- cómo avisan los empleados de un correo sospechoso;
- cuándo deben verificar al remitente por otro canal.
Usa las simulaciones de phishing para medir más que solo quién hace clic. Mide también cuántos empleados avisan de un correo sospechoso y con qué rapidez llega el primer aviso. Un empleado que da un buen aviso puede evitar que decenas de compañeros hagan clic en el mismo enlace. En la práctica, eso suele valer más que perseguir una tasa de clics irrealista de cero.
La conclusión
Safe Links es una medida de seguridad valiosa. Analizar los enlaces antes de la entrega y en el momento del clic puede prevenir muchos ataques de phishing. Sin embargo, reescribir automáticamente cada enlace tiene un precio. Hace el destino menos transparente, cambia el contenido del correo y puede socavar el consejo de seguridad de comprobar los enlaces uno mismo.
Como Microsoft también admite la comprobación mediante la API de Safe Links, las organizaciones no tienen que elegir sin más entre protección técnica y legibilidad. Para las organizaciones que usan casi exclusivamente versiones compatibles de Outlook, la comprobación mediante la API de Safe Links sin reescritura de URL es la opción evidente. En un entorno con muchos clientes de correo distintos, la reescritura puede seguir estando justificada.
La elección correcta no empieza, por tanto, con la pregunta de qué botón recomienda Microsoft, sino con la pregunta de qué configuración ofrece, en tu entorno de trabajo, la mejor combinación de protección técnica, transparencia y comportamiento seguro.
Artículos relacionados
- Advertencia de remitente externo en Exchange: ¿qué tan efectivo es el banner?
- Reconocer el phishing: señales importantes
- Por qué funcionan las simulaciones de phishing
- Cómo detectar y prevenir el fraude del CEO
- Seguridad del correo electrónico e ingeniería social: lo que los empleados deben saber
Fuentes
- Microsoft Learn: Safe Links en Microsoft Defender para Office 365
- Microsoft Learn: Configurar directivas de Safe Links
- Microsoft Learn: Configuración de seguridad recomendada para Microsoft 365
- NCSC (Países Bajos): ¿Cómo reconozco un correo de phishing?
- NCSC (Países Bajos): Manos a la obra contra el phishing
FAQ
¿Es Safe Links lo mismo que Exchange Online Protection?
No. Safe Links es una función de Microsoft Defender para Office 365. La función trabaja junto con la protección habitual contra el correo no deseado y los archivos maliciosos, pero requiere una licencia adecuada de Defender para Office 365.
¿Se comprueban los enlaces también con la reescritura desactivada?
Sí. Microsoft comprueba los enlaces antes de la entrega aunque la reescritura de URL esté desactivada. En las versiones compatibles de Outlook puede realizarse además una comprobación adicional mediante la API de Safe Links en el momento del clic.
¿Por qué reescribe Microsoft los enlaces?
Al hacer pasar el clic por Microsoft, el destino puede comprobarse de nuevo justo antes de abrirse. Esto protege, entre otras cosas, contra sitios web que solo se vuelven maliciosos después de la entrega del correo.
¿Es la reescritura de URL una mala medida de seguridad?
No en todas las circunstancias. En un entorno con clientes de correo variados o no compatibles, la reescritura puede ofrecer una protección valiosa en el momento del clic. El inconveniente es que el destino original se vuelve menos legible y que se modifica el contenido del correo.
¿Cuál es la ventaja de la API de Safe Links?
El enlace original queda intacto. El correo es más legible y el destinatario puede evaluar el dominio de destino con más facilidad. En las versiones compatibles de Outlook sigue siendo posible una comprobación adicional en el momento del clic.
¿Cuál es el inconveniente de la API de Safe Links?
La comprobación adicional al hacer clic depende de la compatibilidad del programa de correo. En un cliente de correo alternativo, solo protege la comprobación realizada antes de la entrega.
¿Puede un empleado suponer que un enlace no bloqueado es seguro?
No. Safe Links reduce el riesgo, pero no puede dar una garantía total. Los sitios de phishing nuevos, dirigidos o técnicamente camuflados pueden ser aún desconocidos. El destinatario debe, por tanto, seguir evaluando el remitente, el contexto y el destino.
¿Qué ajuste es preferible?
Para las organizaciones que usan casi exclusivamente versiones actuales y compatibles de Outlook, es preferible el análisis mediante la API de Safe Links sin reescritura de URL. En un entorno de correo mixto, la ventaja de la comprobación universal en el momento del clic debe sopesarse frente a la legibilidad reducida.