URL Ofuscades: L'Art d'Amagar Enllaços Maliciosos
Celia Catalán
Introducció
En el panorama actual d'amenaces, les URLs ofuscades són un recurs recurrent dins de les campanyes malicioses. Els actors d'amenaces recorren a aquesta tècnica no com un fi en si mateix, sinó com un mecanisme d'evasió i persistència que els permet maximitzar l'efectivitat dels seus atacs.
L'ofuscació d'enllaços facilita eludir controls de seguretat tradicionals com filtres de correu, motors antimalware o gateways web i redueix la probabilitat que un analista o usuari final identifiqui el risc en una inspecció ràpida. Això converteix les URLs en un vector d'atac flexible i difícil de gestionar, que pot adaptar-se amb facilitat a diferents escenaris: des de campanyes de phishing dirigides (spear phishing), fins a la distribució encoberta de malware o el moviment lateral dins d'una infraestructura compromesa.
Entendre com els atacants aprofiten l'ofuscació és fonamental per a qualsevol organització orientada a la ciberseguretat: permet enfortir les capacitats de detecció primerenca, ajustar regles de threat hunting i refinar els processos d'anàlisi forense. A més, visibilitzar aquestes tècniques ajuda a anticipar tendències en l'evolució del frau digital i els mecanismes d'evasió més utilitzats actualment.
Tècniques més comunes d'ofuscació
En aquest apartat abordarem algunes de les tècniques d'ofuscació d'URLs més habituals, les quals han representat un repte constant per a equips de seguretat durant anys. Tot i que en aparença puguin semblar mecanismes trivials, quan s'apliquen de manera intencionada es converteixen en eines sumament efectives a mans d'actors maliciosos. Aquestes tècniques no només busquen enganyar l'usuari final, sinó també eludir controls automàtics i dificultar la tasca d'anàlisi i detecció per part de les defenses corporatives.
Ús d'escurçadors d'URL
Els escurçadors d'enllaços són una d'aquestes eines que van néixer amb la millor intenció: fer més manejables adreces llargues i complicades. Serveis com bit.ly o tinyurl es van tornar molt populars perquè permeten compartir un enllaç net i fàcil de recordar. El problema és que aquesta mateixa característica ha estat aprofitada durant anys per atacants per ocultar destinacions malicioses darrere d'una aparença inofensiva.
Quan un enllaç està reduït, resulta pràcticament impossible saber d'un cop d'ull cap a on ens portarà. Aquest “vel” és el que busquen els atacants: que l'usuari no sospiti i faci clic sense pensar-s'ho massa. A partir d'aquí, l'abast de possibilitats és ampli: des d'una pàgina de phishing ben muntada, fins a una descàrrega de malware o un salt per diverses redireccions dissenyades per esquivar controls de seguretat.
Per als equips de ciberseguretat això es tradueix en un repte addicional. Resoldre un enllaç escurçat implica temps i eines, i no sempre és trivial automatitzar el procés a escala.
Redireccions múltiples
A simple vista pot semblar innecessari, però aquesta tàctica té un objectiu molt clar: dificultar la detecció i l'anàlisi. Cada salt pot estar allotjat en un domini legítim compromès, en un servei al núvol poc vigilat o en pàgines efímeres que desapareixen després d'unes hores. Així, l'enllaç es converteix en una mena de “matrioska” digital: per arribar al contingut final cal destapar diverses capes.
El problema per als equips de seguretat és evident. Un sandbox o un filtre de correu pot detectar i bloquejar el primer salt, però passar per alt el segon o tercer, que és just on espera el payload o la pàgina de phishing. A més, durant l'anàlisi forense, reconstruir tota la cadena de redireccions consumeix temps i de vegades els dominis intermedis ja no estan disponibles, cosa que complica la investigació.
Per això, més enllà dels controls automatitzats, moltes organitzacions combinen tècniques de resolució dinàmica, intel·ligència de amenaces i monitoratge de trànsit DNS/HTTP per identificar aquests patrons. Detectar una redirecció múltiple no sempre significa que sigui maliciosa, però sens dubte és un senyal d'alerta que mereix atenció immediata.
Ús de subdominis
L'abús de subdominis és una altra tècnica freqüent d'ofuscació, i potser una de les més efectives a l'hora d'enganyar un usuari distret. La idea és senzilla: inserir un domini legítim dins d'una URL llarga, però en una posició que no correspon al domini principal, perquè, a simple vista, sembli fiable.
Un exemple clàssic és alguna cosa com:
login.banco.com.seguro-online[.]xyz
A primera vista, molts només llegeixen “login.banco.com” i donen per fet que estan davant del portal del seu banc. Tanmateix, el domini real és “seguro-online[.]xyz”, i tot el que està abans no és més que un subdomini dissenyat per generar confiança.
Els atacants exploten aquest patró perquè saben que la majoria d'usuaris no està entrenada per llegir una URL de dreta a esquerra, que és la manera correcta d'identificar el domini arrel. Per als equips de seguretat, aquest tipus d'enganys representa un desafiament perquè poden conviure amb infraestructures legítimes (CDNs, serveis cloud o plataformes SaaS) que utilitzen subdominis extensos i confusos de manera totalment vàlida.
Mitigar aquest risc requereix una combinació d'educació de l'usuari, anàlisi automatitzat de patrons de domini i polítiques de navegació estrictes. A més, en entorns corporatius, sol ser recomanable aplicar llistes blanques de dominis crítics i reforçar la visibilitat sobre subdominis sospitosos creats de forma massiva.
Caràcters Unicode / IDN homògrafs
Una de les tècniques més enganyoses i difícils de detectar a simple vista és l'ús de caràcters Unicode en dominis, també coneguda com atac d'homògrafs IDN (Internationalized Domain Names). La premissa és simple: aprofitar lletres d'alfabets diferents (ciríl·lic, grec, etc.) que visualment són gairebé idèntiques a les de l'alfabet llatí.
Per exemple, un atacant pot registrar un domini com:
раypal.com
A primera vista sembla paypal.com, però la "p" inicial està escrita en ciríl·lic, no en llatí. Per a l'ull humà i moltes vegades per als controls automàtics més bàsics la diferència és gairebé imperceptible.
Aquest tipus d'ofuscació és particularment perillós perquè apel·la directament a la confiança visual. Els usuaris creuen que estan en un lloc legítim, introdueixen les seves credencials i ni tan sols sospiten de l'engany. Per als equips de seguretat, detectar aquests casos implica anar més enllà d'un filtratge clàssic: es necessiten mecanismes que analitzin el punycode subjacent (xn--...) i que siguin capaços d'identificar similituds visuals sospitoses.
En entorns corporatius, els atacs amb homògrafs poden utilitzar-se per:
- Phishing dirigit (spear phishing) contra empleats.
- Campanyes de brand abuse, registrant variants malicioses d'un domini legítim.
- Exfiltració encoberta de dades, camuflant endpoints de C2 en dominis aparentment legítims.
Mitigar aquesta amenaça passa per un enfocament combinat: monitorització activa de registres de dominis similars (typosquatting), conscienciació interna i el desplegament de motors de detecció capaços de reconèixer aquests patrons en trànsit web i correu.
Codificació a la URL
La codificació d'URLs és una de les tècniques d'ofuscació més antigues, però encara efectiva. El principi és senzill: amagar el destí real utilitzant representacions alternatives de text o adreces que els navegadors saben interpretar, però que no resulten evidents per a un ull humà.
Entre les variants més comunes trobem:
Codificació d'adreces IP en formats alternatius En lloc d'utilitzar la notació decimal clàssica (http://192.168.0.1), els atacants poden escriure la IP en:
- Hexadecimal →http://0xC0.0xA8.0x00.0x01
- Octal →http://0300.0250.0000.0001
- Enter decimal únic (DWORD) →http://3232235521
- Combinacions mixtes →http://0xC0.0250.0x00.1
Totes aquestes variants apunten al mateix destí, però fan que l'enllaç sigui molt menys reconeixible.
Codificació de caràcters en hexadecimal o UTF-8 Cada caràcter de la URL pot expressar-se com el seu valor en ASCII o Unicode, per exemple:
http://%65%78%61%6D%70%6C%65.com → equival a http://example.com
Això dificulta una inspecció ràpida i pot confondre sistemes que no normalitzin la URL abans d'analitzar-la.
Combinacions híbrides Una mateixa URL pot barrejar diversos mètodes (exemple: domini en hexadecimal + paràmetres en Base64), cosa que la fa encara més difícil de llegir i analitzar manualment.
L'objectiu d'aquesta tècnica és clar: dificultar la identificació de la destinació real i guanyar temps davant de mecanismes de detecció. Per als equips de seguretat, això implica la necessitat de normalitzar i desxifrar automàticament les URLs abans d'analitzar-les. Ignorar aquest pas pot deixar fora indicadors clau, especialment en campanyes de phishing, malware distribuït via web o comunicacions de C2.
Abús d'schema
Un altre recurs comú en l'ofuscació d'URLs és l'abús de l'schema (la part inicial de la URL que indica el protocol, com http://,https://,ftp://, etc.) en combinació amb el símbol @ Tot i que aquest símbol té un propòsit vàlid en la sintaxi de les URLs separar credencials d'usuari i host, a la pràctica gairebé mai s'utilitza en la navegació web moderna. I precisament aquesta estranyesa és el que el converteix en un excel·lent disfressa.
Exemple:
https://banco.com@malicioso.com/login
A simple vista, molts usuaris llegeixen banco.com i assumeixen que l'enllaç pertany al portal legítim del seu banc. Tanmateix, tot el que apareix abans del @ es tracta com a credencials, i el domini real al qual es connecta el navegador és maliciós.com.
Aquest truc ha estat usat en campanyes de phishing durant anys perquè aprofita un patró cognitiu: l'ull humà tendeix a fixar-se en la part inicial de la URL i no en la porció que realment importa (el domini arrel a la dreta).
Per als equips de seguretat, aquest tipus d'ofuscació representa un repte perquè no sempre es detecta mitjançant un filtratge superficial, i perquè molts usuaris no estan entrenats per reconèixer el risc. De fet, alguns navegadors moderns ja mostren advertències o bloquegen enllaços amb @ en contextos sospitosos, però la tècnica segueix vigent, especialment en correus electrònics, aplicacions de missatgeria i documents ofuscats.
La mitigació passa per normalitzar les URLs abans d'analitzar-les, entrenar els usuaris per llegir de dreta a esquerra els dominis i bloquejar patrons d'ús de @ en enllaços que no ho requereixin de forma legítima.
Exemple pràctic d'ofuscació (POC)
Un cop descrites les tècniques d'ofuscació més comunes, el següent pas és portar-les a la pràctica. En aquesta secció explorarem com poden combinar-se o adaptar-se per construir escenaris més complexos i realistes. L'objectiu no és només mostrar la creativitat dels atacants, sinó també evidenciar que aquestes tàctiques poden passar desapercebudes tant per a usuaris sense formació tècnica com per a professionals experimentats.
La realitat és que, ben aplicades, moltes d'aquestes tècniques resulten difícils de detectar fins i tot per a equips de seguretat entrenats, cosa que demostra la seva vigència i perillositat en entorns corporatius.
Com a objectiu d'aquesta POC, prendrem com a referència el lloc dels posts, www.flu-project.com, i l'utilitzarem com a cas hipotètic. En aquesta POC no registrarem un domini real però el tractarem com si ho haguéssim fet. Per això, simularíem la creació d'un domini utilitzant una de les tècniques esmentades al post: la utilització d'IDN homògrafs per generar un domini visualment similar.
Cal destacar que la majoria dels navegadors moderns ja inclouen descodificació de Punycode de forma nativa, cosa que limita l'efectivitat d'aquest tipus de tècniques. En conseqüència, els atacants han de recórrer a mètodes alternatius o combinacions més sofisticades per aconseguir el mateix nivell d'ofuscació.
Eel domini al tenir un guionet es podrien aprofitar caràcters com Figure Dash per substituir-lo:
Original: www.flu-project.com
Domini maliciós en poc real utilitzarem (evil.com): www.flu‒project.com
Com a segon pas, es utilitzarà un escurçador d'URL per generar un enllaç més curt, cosa que dificulta identificar a simple vista el domini final al qual apunta:
En aquest cas, la URL generada va ser:
https://rb.gy/4hz4za
Una forma encara més efectiva d'ofuscació seria abusar de l'schema, per exemple:
https://www.flu-project.com@rb.gy/4hz4z
Per a una millor ofuscació cal entendre que abans del @ en una URL no es permeten espais, @, /, ?, #, : ni caràcters de control, cosa que ens limita la possibilitat de realitzar una ofuscació "més avançada" en teoria.
La millor seria veure paràmetres GET de la web,
en aquest cas no n'hi ha molts per ser un simple blog, així que es inventari una ruta o enllaç d'inici de sessió per exemple:
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
En tenir tants paràmetres GET, es pot empquetar el nostre payload amb més facilitat en algun d'ells. Tanmateix, com s'ha esmentat anteriorment, caràcters com / i ? trencarien la tècnica d'abús de l'esquema mitjançant el @. Per això, el més intel·ligent és utilitzar caràcters el més semblants possibles als originals, evitant aquells que interfereixin amb l'estructura de la URL.
Existeixen pàgines on podem trobar caràcters semblants:
? --> https://symbl.cc/en/003F/
/ -->https://symbl.cc/en/002F/
El més interessant d'aquests caràcters és que poden semblar-se visualment als originals, però no trencaran el protocol en no ser exactament els mateixos. Amb això en ment, podem decidir en quin paràmetre GET ofuscar luna URL maliciosa. En aquest cas, s'utilitzarà el paràmetre code_challenge.
A continuació, es s'aplicarà URL encoding al payload perquè passi més desapercebut. A més, es encodearà la URL maliciosa deixant sense codificar el @ i el # final, de manera que s'ignorin la resta de paràmetres després del payload, que quedaria així:
- URL maliciosa: rb.gy/4hz4za
- URL maliciosa preparada per al paràmetre GET: @%72%62.%67%79/4hz4za#
- Paràmetre final:&code_challenge=Z2%21FpJ7nK0qR4xXvT8@%72%62.%67%79/4hz4za#cB1sM6y%2D%5FLdE3wF9oP5hGvQ%28
Com es pot veure, resulta força difícil de detectar a simple vista. Ara, només queda substituir els caràcters esmentats anteriorment pels seus equivalents segurs, de manera que no es trenqui el protocol.
El caràcter ? pot substituir-se per ‽. Pel que fa al caràcter /, sorgeix un dilema: cada font o sistema interpreta aquest tipus de slash de manera diferent, per la qual cosa cal provar diverses variants per determinar quina funciona millor en cada cas. Cada plataforma gestiona aquests caràcters de forma diferent, així que l'elecció ha d'adaptar-se a l'entorn específic.
En aquest cas ses pot observar com es veurien a Chrome per determinar la més semblant:
En aquest cas, es decideix utilitzar l'última opció, “Big Solidus” (https://symbl.cc/en/29F8/). Tenint tot això en compte, es ppode generar la URL final maliciosa, que quedaria de la següent 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
Com es va mencionar abans, l'aparença dels slash pot variar segons on es mostri la URL. Tot i que a Chrome es veu correctament, altres plataformes podrien distorsionar-la, per la qual cosa és necessari provar diferents variants per assegurar-se de la millor visualització.
Quedant així al navegador:
Vídeo demostració a Edge:
Conclusió:
En conclusió, al llarg d'aquest post s'ha mostrat com els atacants poden emprar múltiples tècniques d'ofuscació d'URLs per amagar la veritable destinació d'un enllaç i dificultar-ne la detecció. Des de l'ús d'acurtadors i redireccions múltiples, fins a la manipulació de subdominis, IDN homògrafs, codificació avançada de caràcters i l'abús d'esquemes d'URL, cada mètode presenta avantatges i reptes propis per a qui busca identificar comportaments maliciosos.
La POC inclosa il·lustra de manera pràctica com la combinació d'aquestes tècniques pot generar enllaços que, a simple vista, semblen inofensius i que fins i tot poden confondre usuaris i professionals de ciberseguretat. Això ressalta un fet important: la seguretat no depèn únicament del coneixement de l'usuari, sinó també de la implementació d'eines de monitoratge, anàlisi de trànsit i polítiques de validació d'URLs robustes dins de qualsevol organització.
En un context més ampli, entendre i documentar aquestes tècniques permet als equips de seguretat anticipar-se a atacs sofisticats i dissenyar defenses més efectives, minimitzant riscos i enfortint la postura general de ciberseguretat de l'empresa. L'educació, l'experimentació controlada i la documentació d'aquestes metodologies són clau per mantenir-se un pas endavant dels atacants.
Félix Sánchez, Analista de ciberseguretat ofensiva de Zerolynx by Cybertix.
