Introducción
En el panorama actual de amenazas, las URLs ofuscadas son un recurso recurrente dentro de las campañas maliciosas. Los actores de amenaza recurren a esta técnica no como un fin en sí mismo, sino como un mecanismo de evasión y persistencia que les permite maximizar la efectividad de sus ataques.
La ofuscación de enlaces facilita eludir controles de seguridad tradicionales como filtros de correo, motores antimalware o gateways web y reduce la probabilidad de que un analista o usuario final identifique el riesgo en una inspección rápida. Esto convierte a las URLs en un vector de ataque flexible y difícil de gestionar, que puede adaptarse con facilidad a distintos escenarios: desde campañas de phishing dirigidas (spear phishing), hasta la distribución encubierta de malware o el movimiento lateral dentro de una infraestructura comprometida.
Entender cómo los atacantes aprovechan la ofuscación es fundamental para cualquier organización orientada a la ciberseguridad: permite fortalecer las capacidades de detección temprana, ajustar reglas de threat hunting y refinar los procesos de análisis forense. Además, visibilizar estas técnicas ayuda a anticipar tendencias en la evolución del fraude digital y los mecanismos de evasión más utilizados en la actualidad.
Técnicas más comunes de ofuscación
En este apartado abordaremos algunas de las técnicas de ofuscación de URLs más habituales, las cuales han representado un reto constante para equipos de seguridad durante años. Aunque en apariencia puedan parecer mecanismos triviales, cuando son aplicados de manera intencionada se convierten en herramientas sumamente efectivas en manos de actores maliciosos. Estas técnicas no solo buscan engañar al usuario final, sino también eludir controles automáticos y dificultar la labor de análisis y detección por parte de las defensas corporativas.
Uso de acortadores de URL
Los acortadores de enlaces son una de esas herramientas que nacieron con la mejor intención: hacer más manejables direcciones largas y complicadas. Servicios como bit.ly o tinyurl se volvieron muy populares porque permiten compartir un enlace limpio y fácil de recordar. El problema es que esa misma característica ha sido aprovechada durante años por atacantes para ocultar destinos maliciosos detrás de una apariencia inofensiva.
Cuando un enlace está reducido, resulta prácticamente imposible saber de un vistazo hacia dónde nos llevará. Ese “velo” es lo que buscan los atacantes: que el usuario no sospeche y haga clic sin pensarlo demasiado. A partir de ahí, el abanico de posibilidades es amplio: desde una página de phishing bien montada, hasta una descarga de malware o un salto por varias redirecciones diseñadas para esquivar controles de seguridad.
Para los equipos de ciberseguridad esto se traduce en un desafío adicional. Resolver un enlace acortado implica tiempo y herramientas, y no siempre es trivial automatizar el proceso a escala.
Redirecciones múltiples
A simple vista puede parecer innecesario, pero esta táctica tiene un objetivo muy claro: dificultar la detección y el análisis. Cada salto puede estar alojado en un dominio legítimo comprometido, en un servicio en la nube poco vigilado o en páginas efímeras que desaparecen después de unas horas. Así, el enlace se convierte en una especie de “matrioska” digital: para llegar al contenido final hay que destapar varias capas.
El problema para los equipos de seguridad es evidente. Un sandbox o un filtro de correo puede detectar y bloquear el primer salto, pero pasar por alto el segundo o tercero, que es justo donde espera el payload o la página de phishing. Además, durante el análisis forense, reconstruir toda la cadena de redirecciones consume tiempo y a veces los dominios intermedios ya no están disponibles, lo que complica la investigación.
Por eso, más allá de los controles automatizados, muchas organizaciones combinan técnicas de resolución dinámica, inteligencia de amenazas y monitoreo de tráfico DNS/HTTP para identificar estos patrones. Detectar una redirección múltiple no siempre significa que sea maliciosa, pero sin duda es una señal de alerta que merece atención inmediata.
Uso de subdominios
El abuso de subdominios es otra técnica frecuente de ofuscación, y quizás una de las más efectivas a la hora de engañar a un usuario distraído. La idea es sencilla: insertar un dominio legítimo dentro de una URL larga, pero en una posición que no corresponde al dominio principal, para que, a simple vista, parezca confiable.
Un ejemplo clásico es algo como:
login.banco.com.seguro-online[.]xyz
A primera vista, muchos solo leen “login.banco.com” y dan por hecho que están frente al portal de su banco. Sin embargo, el dominio real es “seguro-online[.]xyz”, y todo lo que está antes no es más que un subdominio diseñado para generar confianza.
Los atacantes explotan este patrón porque saben que la mayoría de los usuarios no está entrenada para leer una URL de derecha a izquierda, que es la manera correcta de identificar el dominio raíz. Para los equipos de seguridad, este tipo de engaños representa un desafío porque pueden convivir con infraestructuras legítimas (CDNs, servicios cloud o plataformas SaaS) que utilizan subdominios extensos y confusos de manera totalmente válida.
Mitigar este riesgo requiere una combinación de educación del usuario, análisis automatizado de patrones de dominio y políticas de navegación estrictas. Además, en entornos corporativos, suele ser recomendable aplicar listas blancas de dominios críticos y reforzar la visibilidad sobre subdominios sospechosos creados de forma masiva.
Caracteres Unicode / IDN homógrafos
Una de las técnicas más engañosas y difíciles de detectar a simple vista es el uso de caracteres Unicode en dominios, también conocida como ataque de homógrafos IDN (Internationalized Domain Names). La premisa es simple: aprovechar letras de alfabetos distintos (cirílico, griego, etc.) que visualmente son casi idénticas a las del alfabeto latino.
Por ejemplo, un atacante puede registrar un dominio como:
раypal.com
A primera vista parece paypal.com, pero la “p” inicial está escrita en cirílico, no en latín. Para el ojo humano y muchas veces para los controles automáticos más básicos la diferencia es casi imperceptible.
Este tipo de ofuscación es particularmente peligrosa porque apela directamente a la confianza visual. Los usuarios creen que están en un sitio legítimo, introducen sus credenciales y ni siquiera sospechan del engaño. Para los equipos de seguridad, detectar estos casos implica ir más allá de un filtrado clásico: se necesitan mecanismos que analicen el punycode subyacente (xn--...) y que sean capaces de identificar similitudes visuales sospechosas.
En entornos corporativos, los ataques con homógrafos pueden utilizarse para:
- Phishing dirigido (spear phishing) contra empleados.
- Campañas de brand abuse, registrando variantes maliciosas de un dominio legítimo.
- Exfiltración encubierta de datos, camuflando endpoints de C2 en dominios aparentemente legítimos.
Mitigar esta amenaza pasa por un enfoque combinado: monitorización activa de registros de dominios similares (typosquatting), concienciación interna y el despliegue de motores de detección capaces de reconocer estos patrones en tráfico web y correo.
Codificación en la URL
La codificación de URLs es una de las técnicas de ofuscación más antiguas, pero todavía efectiva. El principio es sencillo: esconder el destino real utilizando representaciones alternativas de texto o direcciones que los navegadores saben interpretar, pero que no resultan evidentes para un ojo humano.
Entre las variantes más comunes encontramos:
Codificación de direcciones IP en formatos alternativos En lugar de usar la notación decimal clásica (http://192.168.0.1), los atacantes pueden escribir la IP en:
- Hexadecimal →http://0xC0.0xA8.0x00.0x01
- Octal →http://0300.0250.0000.0001
- Entero decimal único (DWORD) →http://3232235521
- Combinaciones mixtas →http://0xC0.0250.0x00.1
Todas estas variantes apuntan al mismo destino, pero hacen que el enlace sea mucho menos reconocible.
Codificación de caracteres en hexadecimal o UTF-8 Cada carácter de la URL puede expresarse como su valor en ASCII o Unicode, por ejemplo:
http://%65%78%61%6D%70%6C%65.com → equivale a http://example.com
Esto dificulta una inspección rápida y puede confundir sistemas que no normalicen la URL antes de analizarla.
Combinaciones híbridas Una misma URL puede mezclar varios métodos (ejemplo: dominio en hexadecimal + parámetros en Base64), lo que la vuelve aún más difícil de leer y analizar manualmente.
El objetivo de esta técnica es claro: dificultar la identificación del destino real y ganar tiempo frente a mecanismos de detección. Para los equipos de seguridad, esto implica la necesidad de normalizar y decodificar automáticamente las URLs antes de analizarlas. Ignorar este paso puede dejar fuera indicadores clave, especialmente en campañas de phishing, malware distribuido vía web o comunicaciones de C2.
Abuso de schema
Otro recurso común en la ofuscación de URLs es el abuso del schema (la parte inicial de la URL que indica el protocolo, como http://,https://,ftp://, etc.) en combinación con el símbolo @ Aunque este símbolo tiene un propósito válido en la sintaxis de las URLs separar credenciales de usuario y host, en la práctica casi nunca se usa en la navegación web moderna. Y justamente esa rareza es lo que lo convierte en un excelente disfraz.
Ejemplo:
https://banco.com@malicioso.com/login
A simple vista, muchos usuarios leen banco.com y asumen que el enlace pertenece al portal legítimo de su banco. Sin embargo, todo lo que aparece antes del @ es tratado como credenciales, y el dominio real al que se conecta el navegador es malicioso.com.
Este truco ha sido usado en campañas de phishing durante años porque aprovecha un patrón cognitivo: el ojo humano tiende a fijarse en la parte inicial de la URL y no en la porción que realmente importa (el dominio raíz a la derecha).
Para los equipos de seguridad, este tipo de ofuscación representa un reto porque no siempre se detecta mediante un filtrado superficial, y porque muchos usuarios no están entrenados para reconocer el riesgo. De hecho, algunos navegadores modernos ya muestran advertencias o bloquean enlaces con @ en contextos sospechosos, pero la técnica sigue vigente, especialmente en correos electrónicos, aplicaciones de mensajería y documentos ofuscados.
La mitigación pasa por normalizar las URLs antes de analizarlas, entrenar a los usuarios para leer de derecha a izquierda los dominios y bloquear patrones de uso de @ en enlaces que no lo requieran de forma legítima.
Ejemplo práctico de ofuscación (POC)
Una vez descritas las técnicas de ofuscación más comunes, el siguiente paso es llevarlas a la práctica. En esta sección exploraremos cómo pueden combinarse o adaptarse para construir escenarios más complejos y realistas. El objetivo no es solo mostrar la creatividad de los atacantes, sino también evidenciar que estas tácticas pueden pasar desapercibidas tanto para usuarios sin formación técnica como para profesionales experimentados.
La realidad es que, bien aplicadas, muchas de estas técnicas resultan difíciles de detectar incluso para equipos de seguridad entrenados, lo que demuestra su vigencia y peligrosidad en entornos corporativos.
Como objetivo de esta POC, tomaremos como referencia el sitio de los posts, www.flu-project.com, y lo utilizaremos como caso hipotético. En esta POC no registraremos un dominio real pero lo trataremos como si lo hubiéramos hecho. Para ello, simularíamos la creación de un dominio utilizando una de las técnicas mencionadas en el post: la utilización de IDN homógrafos para generar un dominio visualmente similar.
Cabe destacar que la mayoría de los navegadores modernos ya incluyen decodificación de Punycode de forma nativa, lo que limita la efectividad de este tipo de técnicas. En consecuencia, los atacantes deben recurrir a métodos alternativos o combinaciones más sofisticadas para lograr el mismo nivel de ofuscación.
El dominio al tener un guion se podrían aprovechar caracteres como Figure Dash para sustituirlo:
Original: www.flu-project.com
Dominio malicioso en poc real utilizaremos (evil.com): www.flu‒project.com
Como segundo paso, se utilizará un acortador de URL para generar un enlace más corto, lo que dificulta identificar a simple vista el dominio final al que apunta:
En este caso, la URL generada fue:
https://rb.gy/4hz4za
Una forma aún más efectiva de ofuscación sería abusar del schema, por ejemplo:
https://www.flu-project.com@rb.gy/4hz4z
Para una mejor ofuscación hay que entender que antes del @ en una URL no se permiten espacios, @, /, ?, #, : ni caracteres de control, lo que nos limita la posibilidad de realizar una ofuscación "más avanzada" en teoría.
Lo mejor sería ver parámetros GET de la web,
en este caso no hay muchos al ser un simple blog, así que se inventaría una ruta o enlace de login por ejemplo:
https://www.flu-project.com/signin/id?as=S33687126557826461780271839
&authuser=0
&client_id=2389046141273-dfgshadfh347828679adap.apps.flu-project.com
&flowName=GeneralOAuthFlow
&response_type=code
&scope=email%20profile%20openid
&state=Af3fG5H7Jk9L1Mn2Op3Q
&nonce=Zx1Cv2Bn3Mq4Lp5R
&redirect_uri=
www.flu-project.com
&session_state=a
idus42
3def456ghi789jkl0
&prompt=select_account
&hd=flu-project.com
&login_hint=user%40flu-project.com
&include_granted_scopes=true
&code_challenge=
Z2!FpJ7nK0qR4xXvT8cB1sM6y-_LdE3wF9oP5hGvQ(
&code_challenge_method=S256
&utm_source=newsletter
&utm_medium=email
&csrf_token=098f6bcd4621d373cade4e832627b4f6
Al contar con tantos parámetros GET, se puede empaquetar nuestro payload con mayor facilidad en alguno de ellos. Sin embargo, como se mencionó anteriormente, caracteres como / y ? romperían la técnica de abuso del schema mediante el @. Por ello, lo más inteligente es utilizar caracteres lo más parecidos posibles a los originales, evitando aquellos que interfieran con la estructura de la URL.
Existen páginas donde podemos encontrar caracteres parecidos:
? --> https://symbl.cc/en/003F/
/ -->https://symbl.cc/en/002F/
Lo interesante de estos caracteres es que pueden parecerse visualmente a los originales, pero no romperán el protocolo al no ser exactamente los mismos. Con esto en mente, podemos decidir en qué parámetro GET ofuscar la URL maliciosa. En este caso, se utilizará el parámetro code_challenge.
A continuación, se aplicará URL encoding al payload para que pase más desapercibido. Además, se encodeará la URL maliciosa dejando sin codificar el @ y el # final, de manera que se ignore el resto de los parámetros después del payload, lo cual quedaría así:
- URL Maliciosa: rb.gy/4hz4za
- URL Maliciosa preparada para el parámetro GET: @%72%62.%67%79/4hz4za#
- Parámetro final:&code_challenge=Z2%21FpJ7nK0qR4xXvT8@%72%62.%67%79/4hz4za#cB1sM6y%2D%5FLdE3wF9oP5hGvQ%28
Como se puede ver, resulta bastante difícil de detectar a simple vista. Ahora, solo queda sustituir los caracteres mencionados anteriormente por sus equivalentes seguros, de modo que no se rompa el protocolo.
El carácter ? puede reemplazarse por ‽. En cuanto al carácter /, surge un dilema: cada fuente o sistema interpreta este tipo de slash de manera distinta, por lo que es necesario probar varias variantes para determinar cuál funciona mejor en cada caso. Cada plataforma maneja estos caracteres de forma diferente, por lo que la elección debe adaptarse al entorno específico.
En este caso se puede observar como se verían en Chrome para determinar la mas parecida:
En este caso, se decide utilizar la última opción, “Big Solidus” (https://symbl.cc/en/29F8/). Teniendo todo esto en cuenta, se puede generar la URL final maliciosa, que quedaría de la siguiente manera:
- URL Final Maliciosa: https://www.flu-project.com⧸signin⧸id‽as=S33687126557826461780271839&authuser=0&client_id=2389046141273-dfgshadfh347828679adap.apps.flu-project.com&flowName=GeneralOAuthFlow&response_type=code&scope=email%20profile%20openid&state=Af3fG5H7Jk9L1Mn2Op3Q&nonce=Zx1Cv2Bn3Mq4Lp5R&redirect_uri=www.flu-project.com&session_state=abc123def456ghi789jkl0&prompt=select_account&hd=flu-project.com&login_hint=user%40flu-project.com&include_granted_scopes=true&code_challenge=Z2%21FpJ7nK0qR4xXvT8@%72%62.%67%79/4hz4za#cB1sM6y%2D%5FLdE3wF9oP5hGvQ%28&tracking_id=UA-12345678-9&utm_source=newsletter&utm_medium=email&csrf_token=098f6bcd4621d373cade4e832627b4f6
Como se mencionó antes, la apariencia de los slash puede variar según dónde se muestre la URL. Aunque en Chrome se ve correctamente, otras plataformas podrían distorsionarla, por lo que es necesario probar distintas variantes para asegurarse de la mejor visualización.
Quedando así en el navegador:
Video demostración en Edge:
Conclusión:
En conclusión, a lo largo de este post se ha mostrado cómo los atacantes pueden emplear múltiples técnicas de ofuscación de URLs para ocultar el verdadero destino de un enlace y dificultar su detección. Desde el uso de acortadores y redirecciones múltiples, hasta la manipulación de subdominios, IDN homógrafos, codificación avanzada de caracteres y el abuso de esquemas de URL, cada método presenta ventajas y retos propios para quienes buscan identificar comportamientos maliciosos.
La POC incluida ilustra de manera práctica cómo la combinación de estas técnicas puede generar enlaces que, a simple vista, parecen inofensivos y que incluso pueden confundir a usuarios y profesionales de ciberseguridad. Esto resalta un hecho importante: la seguridad no depende únicamente del conocimiento del usuario, sino también de la implementación de herramientas de monitoreo, análisis de tráfico y políticas de validación de URLs robustas dentro de cualquier organización.
En un contexto más amplio, entender y documentar estas técnicas permite a los equipos de seguridad anticiparse a ataques sofisticados y diseñar defensas más efectivas, minimizando riesgos y fortaleciendo la postura general de ciberseguridad de la empresa. La educación, la experimentación controlada y la documentación de estas metodologías son clave para mantenerse un paso adelante de los atacantes.
Félix Sánchez, Analista de ciberseguridad ofensiva de Zerolynx by Cybertix.