URL Obfuscation aplicando homoglyphs de paths /

Publicado em Julho 6, 2026Julho 6, 2026 por Mr. Cl0wn

Dentro do contexto de ataques usando URL como vetor inicial, uma das técnicas que mais curto é o uso de homóglifos para ludibriar o target. Tal técnica, se bem aplicada, pode explorar o contexto de engenharia social (cujo objetivo principal é manipular a percepção inicial do target), junto com o URL Obfuscation (aka BAD URL), que consiste em abusar da estrutura de autenticação da URL suportada pelos browsers para redirecionar a vítima para um determinado domínio.

Então nesse artigo tratarei da combinação de duas técnicas Homóglifos e URL Obfuscation. meu principal objetivo é criar uma URL perfeita visualmente usando Homóglifos para simular "/" dentro do Obfuscation.

Homóglifos (en: homoglyphs) são caracteres de alfabetos ou conjuntos de caracteres diferentes que parecem visualmente idênticos ou quase idênticos ao olho humano, mas possuem significados e códigos técnicos distintos. Atacantes frequentemente os utilizam em campanhas de “phishing”, substituindo caracteres padrão em URLs por outros de aparência semelhante (por exemplo, trocando um "o" latino por um "ο" grego) para enganar os usuários.

A Ofuscação de URL (en: URL Obfuscation) é uma técnica de engenharia social em que threat actors abusam da sintaxe de URIs (RFC 3986) para mascarar o destino real do link. O truque está no componente userinfo, tudo que vem antes do @ é tratado como informação de usuário e não participa da resolução do host. Em https://[email protected], o google.com é só um rótulo decorativo: o host efetivo é o que aparece depois do arroba. A vítima vê o domínio confiável e clica, mas a resolução DNS e o TLS ocorrem contra o domínio fraudulento.

Não confunda Punycode com Nosso contexto

Punycode é o “tradutor” que permite que o DNS que só entende ASCII carregue domínios escritos com caracteres Unicode. O DNS histórico só aceita o conjunto LDH nos rótulos (labels): Letters (a–z), Digits (0–9) e Hyphen. Nada de acento, cedilha, cirílico, ideograma. Mas as pessoas querem münchen.de, café.fr, 例え.jp. A ponte entre esses dois mundos é o IDNA (Internationalizing Domain Names in Applications), e a peça que faz a conversão de Unicode -> ASCII é o Punycode (RFC 3492).

Todo rótulo que passou por essa conversão ganha o prefixo xn-- o chamado ACE prefix (ASCII-Compatible Encoding). Ou seja: quando você vê xn-- no começo de um pedaço do domínio, aquilo é um rótulo Unicode disfarçado de ASCII.

Anatomia da URL: o componente authority

Para usar Ofuscação de URL, devemos entender a estrutura de authority. Podemos observar que o navegador trata tal formatação de URL como uma tentativa de login no servidor (muito usada no passado para servidores FTP). A resolução DNS e o TLS ocorrem contra o domínio após o @. A trick funciona no userinfo, onde é possível inserir um domínio legítimo, enquanto o host (após o @ ) para resolução é o que recebe o redirect final.

         userinfo         host      port
         ┌──┴───┐ ┌────────┴──────┐ ┌┴┐
 https://[email protected]:123/forum/questions/
 └─┬─┘   └────────────┬───────────────┘└──────┬───────┘
 scheme           authority                  pathCode language: JavaScript (javascript)

Referência: (RFC 3986) é possível usar senha no formato meu.user:senha@……, mas em nosso estudo não precisamos setar :pass.

Três fatos da especificação sustentam as técnicas:

O @ delimita. Havendo um @ na authority, tudo antes dele é userinfo e o host é o que vem depois. Um humano lê da esquerda para a direita e para no primeiro domínio que reconhece; o parser lê o host depois do @.
user:password é obsoleto, mas ainda é parseado (3.2.1: “Use of the format ‘user:password’ in the userinfo field is deprecated.”). Deprecado diferente de rejeitado; navegadores continuam aceitando.
A barra / (U+002F, SOLIDUS) é um gen-delim (delimitadores gerais) e não faz parte do userinfo. Um / real encerra a authority e inicia o path.

7.6 (Semantic Attacks) da própria RFC descreve o abuso: como o userinfo aparece antes do host, dá para construir uma URI que engana o humano, parecendo apontar para uma autoridade confiável enquanto aponta para outra. Exemplo da RFC: ftp://cnn.example.com&[email protected]/top_story.htm.

Formatação da URL em contexto malicioso:

 https://[email protected]
         └─────┬───────┘└─────────┬───────────┘
        Domínio<strong> </strong>legitimo  Host que recebe 
        Isca              RedirectCode language: HTML, XML (xml)

Tabela Homoglyphs `/` que simula paths

Agora entendemos o userinfo, que recebe informações que são basicamente uma string contínua (esquece o :password). Ao tratar userinfo como string, imaginei usar unicodes / homóglifos que representam uma barra. Para ajudar no trabalho, elaborei uma tabela que lista caracteres e homóglifos que podemos usar no userinfo.

Catálogo de homoglyphs de `/`

Code point	Char	Escrita	Nome Unicode
`U+30CE`	`ノ`	Katakana (japonês)	KATAKANA LETTER NO
`U+4E3F`	`丿`	Han (CJK)	CJK IDEOGRAPH-4E3F (traço piě)
`U+2F03`	`⼃`	Han (radical Kangxi)	KANGXI RADICAL SLASH
`U+2CC6`	`Ⳇ`	Copta	COPTIC CAPITAL LETTER OLD COPTIC ESH
`U+1735`	`᜵`	Filipina (Baybayin)	PHILIPPINE SINGLE PUNCTUATION
`U+3033`	`〳`	Kana (japonês)	VERTICAL KANA REPEAT MARK UPPER HALF
`U+1D23A`	`𝈺`	Notação musical grega	GREEK INSTRUMENTAL NOTATION SYMBOL-47

Símbolos compartilhados

Code point	Char	Nome Unicode
`U+2044`	⁄	FRACTION SLASH
`U+2215`	`∕`	DIVISION SLASH
`U+27CB`	`⟋`	MATHEMATICAL RISING DIAGONAL
`U+29F8`	`⧸`	BIG SOLIDUS
`U+2571`	`╱`	BOX DRAWINGS LIGHT DIAGONAL (usado no exemplo)
`U+31D3`	`㇓`	CJK STROKE SP
`U+2041`	`⁁`	CARET INSERTION POINT
`U+FF0F`	`／`	FULLWIDTH SOLIDUS
`U+1F67C`	`🙼`	VERY HEAVY SOLIDUS
`U+29F6`	`⧶`	SOLIDUS WITH OVERBAR
`U+2E4A`	`⹊`	DOTTED SOLIDUS
`U+233F`	`⌿`	APL FUNCTIONAL SYMBOL SLASH BAR
`U+2AFD`	`⫽`	DOUBLE SOLIDUS OPERATOR
`U+2AFB`	`⫻`	TRIPLE SOLIDUS BINARY RELATION

Aplicando Homoglyphs `/`

Bom, sabemos os conceitos e já temos uma linda tabela com os homóglifos / unicodes que tem um contexto visual de barra "/" . Vamos relembrar nosso requisito de sucesso para o artigo:

URL perfeita visualmente usando Homóglifos para simular "/" dentro do Obfuscation.

Setarei como algo clonar a URL do Google Gmail. para tal trabalho usarei U+2CC6 -> Ⳇ para representar /.

<a href="https://mail.google.com/mail/u/0/#inbox">https://mail.google.com/mail/u/0/#inbox</a> Code language: HTML, XML (xml)

URL com Homóglifos

        userinfo                             host      
       ┌───┴────────────────────────┐ ┌────────┴─────┐
https://mail.google.comⳆmailⳆuⳆ0Ⳇ[email protected]
                       ┬  ┬  ┬ ┬
                       HomóglifosCode language: JavaScript (javascript)

POC X CURL

Efetuar o teste usando curl está dentro do escopo. Observando abaixo, o dado do request foi tratado como o username de um HTTP Basic Auth, exatamente como o curl avisa na primeira linha (Server auth using Basic with user '…'). O dado passado em userinfo vira um base64 bWFpbC5nb29nbGUu…, e em nenhum momento é efetuada tentativa de conexão ao “mail.google.com”, que basicamente vira um parâmetro de login para o header "authorization: Basic".

osint@brazuca:~/Documentos/url-redirect$ curl https://mail.google.comⳆmailⳆuⳆ0Ⳇ[email protected] -v
* Server auth using Basic with user 'mail.google.comⳆmailⳆuⳆ0Ⳇinbox'
* [HTTP/2] [1] OPENED stream for https://mail.google.comⳆmailⳆuⳆ0Ⳇ[email protected]/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: blog.mrcl0wn.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [authorization: Basic bWFpbC5nb29nbGUuY29t4rOGbWFpbOKzhnXis4Yw4rOGaW5ib3g6]Code language: Bash (bash)

POC X VISUAL

A URL usada foi: https://mail.google.comⳆmailⳆuⳆ0Ⳇ[email protected]/

Aplicativo	Clicável?	Redirect?
Signal Desktop / 8.17.0	NÃO	NÃO
WhatsApp Web	SIM	SIM
Telegram Desktop / 6.9.3	SIM	SIM
Slack Desktop / Flatpak 4.50.136 64-bit	NÃO	NÃO
Mozzila FireFox Desktop / 152.0.3	SIM	SIM
Google Docs Web	SIM	SIM
Chat Instagram Web	SIM	NÃO
Chat Facebook Web	SIM	NÃO
Gmail Web	SIM	SIM, mas visualmente os path de engoscial (userinfo) somente ao colocar o mouse acima da URL.

Conclusão

Dentro de um contexto Desktop, nos principais mensageiros e navegadores, a técnica funciona perfeitamente. Quando chegamos ao contexto mobile, os parsers locais parecem eliminar elementos da URL e forçar a abertura de outros apps locais (testei no Android). Confesso que meu lab para testar no Android não foi muito bom: fiz 3 testes e dropei. Lembrando que meus testes foram estritamente focados em U+2CC6 -> Ⳇ, onde o userinfo tenta simular uma URL completa.

Efetuei testes com outras chars e tive sucesso; exemplos: &, ', ., %*. A isca visual foi bem-sucedida na versão Web do WhatsApp e do Telegram, onde já tenta enviar request para a URL maliciosa final. Isso abre contexto para aplicar a técnica de modificação do header HTML da página de destino, editando: Meta property, Icon, Title. Assim, ao carregar no chat, traz mais contexto de engenharia social. Concatenando tal técnica com o domínio isca, fica visualmente impecável.

Não é uma técnica nova, mas é sempre possível adicionar novos temperos em receitas antigas.

Criei um script que ajuda gerar URLs em massa usando a técnica apresentada no blog post