Obfuscated URLs: The Art of Hiding Malicious Links

Introduction

In today's threat landscape, obfuscated URLs are a recurring resource within malicious campaigns. Threat actors use this technique not as an end in itself, but as an evasion and persistence mechanism that allows them to maximize the effectiveness of their attacks.

Link obfuscation makes it easier to bypass traditional security controls such as email filters, antimalware engines, or web gateways and reduces the likelihood that an analyst or end user will identify the risk in a quick inspection. This turns URLs into a flexible and hard-to-manage attack vector that can easily adapt to different scenarios: from targeted phishing campaigns (spear phishing) to covert malware distribution or lateral movement within a compromised infrastructure.

Understanding how attackers exploit obfuscation is fundamental for any cybersecurity-oriented organization: it allows strengthening early detection capabilities, adjusting threat hunting rules, and refining forensic analysis processes. Additionally, making these techniques visible helps anticipate trends in the evolution of digital fraud and the most commonly used evasion mechanisms today.

Most common obfuscation techniques

In this section, we will address some of the most common URL obfuscation techniques, which have represented a constant challenge for security teams over the years. Although they may seem trivial mechanisms at first glance, when applied intentionally they become extremely effective tools in the hands of malicious actors. These techniques not only seek to deceive the end user but also to evade automated controls and complicate the analysis and detection work of corporate defenses.

Use of URL shorteners

Link shorteners are one of those tools that were born with the best intention: to make long and complicated addresses more manageable. Services like bit.ly or tinyurl became very popular because they allow sharing a clean and easy-to-remember link. The problem is that this same feature has been exploited for years by attackers to hide malicious destinations behind an innocuous appearance.

When a link is shortened, it is practically impossible to know at a glance where it will take us. That “veil” is what attackers seek: for the user not to suspect and click without thinking too much. From there, the range of possibilities is wide: from a well-crafted phishing page to a malware download or a series of redirects designed to evade security controls.

For cybersecurity teams, this translates into an additional challenge. Resolving a shortened link takes time and tools, and automating the process at scale is not always trivial.

Multiple redirects

At first glance it may seem unnecessary, but this tactic has a very clear objective: to make detection and analysis difficult. Each hop may be hosted on a compromised legitimate domain, on a lightly monitored cloud service, or on ephemeral pages that disappear after a few hours. Thus, the link becomes a kind of digital “matryoshka”: to reach the final content, several layers must be uncovered.

The problem for security teams is evident. A sandbox or an email filter can detect and block the first hop, but overlook the second or third, which is exactly where the payload or phishing page waits. Additionally, during forensic analysis, reconstructing the entire chain of redirects consumes time and sometimes the intermediate domains are no longer available, complicating the investigation.

Therefore, beyond automated controls, many organizations combine dynamic resolution techniques, threat intelligence, and DNS/HTTP traffic monitoring to identify these patterns. Detecting multiple redirections does not always mean it is malicious, but it is certainly a warning sign that deserves immediate attention.

Use of subdomains

The abuse of subdomains is another common obfuscation technique, and perhaps one of the most effective when it comes to deceiving a distracted user. The idea is simple: insert a legitimate domain within a long URL, but in a position that does not correspond to the main domain, so that at first glance it seems trustworthy.

A classic example is something like:

login.banco.com.seguro-online[.]xyz

At first glance, many only read “login.banco.com” and assume they are facing their bank's portal. However, the real domain is “seguro-online[.]xyz”, and everything before it is just a subdomain designed to generate trust.

Attackers exploit this pattern because they know most users are not trained to read a URL from right to left, which is the correct way to identify the root domain. For security teams, this type of deception represents a challenge because they can coexist with legitimate infrastructures (CDNs, cloud services, or SaaS platforms) that use extensive and confusing subdomains in a completely valid way.

Mitigating this risk requires a combination of user education, automated domain pattern analysis, and strict browsing policies. Additionally, in corporate environments, it is often advisable to apply whitelists of critical domains and strengthen visibility over suspicious subdomains created massively.

Unicode Characters / IDN Homographs

One of the most deceptive and hardest to detect techniques at first glance is the use of Unicode characters in domains, also known as IDN homograph attacks (Internationalized Domain Names). The premise is simple: to take advantage of letters from different alphabets (Cyrillic, Greek, etc.) that visually are almost identical to those of the Latin alphabet.

For example, an attacker can register a domain like:

раypal.com

At first glance, it looks like paypal.com, but the initial “p” is written in Cyrillic, not Latin. To the human eye and often to the most basic automated controls, the difference is almost imperceptible.

This type of obfuscation is particularly dangerous because it directly appeals to visual trust. Users believe they are on a legitimate site, enter their credentials, and don't even suspect the deception. For security teams, detecting these cases means going beyond classic filtering: mechanisms are needed that analyze the punycode underlying (xn--...) and be able to identify suspicious visual similarities.

In corporate environments, homograph attacks can be used to:

• Phishing targeted (spear phishing) against employees. 
• Brand abuse campaigns, registering malicious variants of a legitimate domain. 
• Covert data exfiltration, camouflaging C2 endpoints in apparently legitimate domains.

Mitigating this threat involves a combined approach: active monitoring of similar domain records (typosquatting), internal awareness, and deployment of detection engines capable of recognizing these patterns in web and email traffic.

Encoding in the URL

URL encoding is one of the oldest obfuscation techniques, but still effective. The principle is simple: hide the real destination using alternative text or address representations that browsers know how to interpret, but that are not obvious to the human eye.

Among the most common variants we find:

IP address encoding in alternative formats Instead of using the classic decimal notation (http://192.168.0.1), attackers can write the IP in:

• Hexadecimal →http://0xC0.0xA8.0x00.0x01
• Octal →http://0300.0250.0000.0001
• Single decimal integer (DWORD) →http://3232235521
• Mixed combinations →http://0xC0.0250.0x00.1

All these variants point to the same destination, but make the link much less recognizable.

Character encoding in hexadecimal or UTF-8 Each character of the URL can be expressed as its ASCII or Unicode value, for example:

http://%65%78%61%6D%70%6C%65.com → equals http://example.com

This hinders quick inspection and can confuse systems that do not normalize the URL before analyzing it.

Hybrid combinations A single URL can mix several methods (example: hexadecimal domain + Base64 parameters), making it even harder to read and analyze manually.

The goal of this technique is clear: to make identifying the real destination difficult and gain time against detection mechanisms. For security teams, this implies the need to automatically normalize and decode URLs before analyzing them. Ignoring this step can leave out key indicators, especially in phishing campaigns, web-distributed malware, or C2 communications.

Schema abuse

Another common resource in URL obfuscation is the abuse of the schema (the initial part of the URL that indicates the protocol, such as http://,https://,ftp://, etc.) in combination with the symbol @ Although this symbol has a valid purpose in URL syntax separating user credentials and host, in practice is almost never used in modern web browsing. And precisely that rarity is what makes it an excellent disguise.

Example:

https://banco.com@malicioso.com/login

At first glance, many users read banco.com and assume the link belongs to their bank's legitimate portal. However, everything that appears before the @ is treated as credentials, and the real domain the browser connects to is malicious.com.

This trick has been used in phishing campaigns for years because it exploits a cognitive pattern: the human eye tends to focus on the beginning of the URL and not on the portion that really matters (the root domain on the right).

For security teams, this type of obfuscation poses a challenge because it is not always detected through superficial filtering, and because many users are not trained to recognize the risk. In fact, some modern browsers already show warnings or block links with @ in suspicious contexts, but the technique remains relevant, especially in emails, messaging apps, and obfuscated documents.

Mitigation involves normalizing URLs before analyzing them, training users to read domains from right to left, and blocking usage patterns of @ in links that do not legitimately require it.

Practical example of obfuscation (POC)

Once the most common obfuscation techniques have been described, the next step is to put them into practice. In this section, we will explore how they can be combined or adapted to build more complex and realistic scenarios. The goal is not only to show the creativity of attackers but also to demonstrate that these tactics can go unnoticed by both non-technical users and experienced professionals.

The reality is that, when well applied, many of these techniques are difficult to detect even for trained security teams, which demonstrates their relevance and danger in corporate environments.

As the objective of this POC, we will take as reference the site of the posts, www.flu-project.com, and we will use it as a hypothetical case. In this POC we will not register a real domain but will treat it as if we had. For this, we would simulate the creation of a domain using one of the techniques mentioned in the post: the use of IDN homoglyphs to generate a visually similar domain.

It is worth noting that most modern browsers already include native Punycode decoding, which limits the effectiveness of this type of technique. Consequently, attackers must resort to alternative methods or more sophisticated combinations to achieve the same level of obfuscation.

El domain at the have a dash could be to exploit characters like Figure Dash to replace it:

Original: www.flu-project.com

Malicious domain in real poc we will use (evil.com): www.flu‒project.com

As a second step, it will use a URL shortener to generate a shorter link, which makes it harder to identify at a glance the final domain it points to:

In this case, the generated URL was:

https://rb.gy/4hz4za

An even more effective form of obfuscation would be to abuse the schema, for example:

https://www.flu-project.com@rb.gy/4hz4z

For a better obfuscation you have to understand that before the @ spaces are not allowed in a URL, @, /, ?, #, : nor control characters, which limits our ability to perform a obfuscation "more advanced" in theory.

The better it would be to see parameters GET of the web,

in this case there aren't many since it's a simple blog, so it I would inventory a route the login link for example:

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

Having so many GET parameters, it can be to package our payload more easily in one of them. However, as mentioned earlier, characters like / and ? would break the schema abuse technique using @. Therefore, the smartest thing is to use characters as similar as possible to the originals, avoiding those that interfere with the URL structure.

There are pages where we can find similar characters:

? --> https://symbl.cc/en/003F/

/ -->https://symbl.cc/en/002F/

The interesting thing about these characters is that they can look visually similar to the originals, but they won't break the protocol since they are not exactly the same. With this in mind, we can decide in which GET parameter to obfuscate lthe malicious URL. In this case, will be used the parameter code_challenge.

Next, it will apply URL encoding to the payload so it goes more unnoticed. Also, it will encode the malicious URL leaving the @ and the # final, so that the rest of the parameters after the payload are ignored, which would look like this:

• Malicious URL: rb.gy/4hz4za
• Malicious URL prepared for the GET parameter: @%72%62.%67%79/4hz4za#
• Final parameter:&code_challenge=Z2%21FpJ7nK0qR4xXvT8@%72%62.%67%79/4hz4za#cB1sM6y%2D%5FLdE3wF9oP5hGvQ%28

As you can see, it is quite difficult to detect at a glance. Now, all that remains is to replace the aforementioned characters with their safe equivalents, so the protocol is not broken.

The character ? can be replaced by ‽. Regarding the character /, a dilemma arises: each font or system interprets this type of slash differently, so it is necessary to try several variants to determine which works best in each case. Each platform handles these characters differently, so the choice must adapt to the specific environment.

In this case iit can be observe how they would look in Chrome to determine the closest match:

In this case, it is decided use the last option, "Big Solidus" (https://symbl.cc/en/29F8/). Taking all this into account, it pcan generate the malicious final URL, which would be as follows:

• Malicious Final URL: 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

As it mentioned beforehand, the appearance of the slashes may vary depending on where the URL is displayed. Although it looks correct in Chrome, other platforms could distort it, so it is necessary to test different variants to ensure the best display.

Remaining like this in the browser:

As can be seen in this POC, the resulting final URL is very difficult to trace and practically imperceptible at first glance, even for technical staff. This demonstrates how the combination of obfuscation techniques can effectively hide the real destination of a link..

Demonstration video in Edge:

Conclusion:

In conclusion, throughout this post it has been shown how attackers can employ multiple URL obfuscation techniques to hide the true destination of a link and make its detection difficult. From the use of shorteners and multiple redirects to the manipulation of subdomains, IDN homographs, advanced character encoding, and abuse of URL schemes, each method presents its own advantages and challenges for those seeking to identify malicious behavior.

The included POC practically illustrates how the combination of these techniques can generate links that, at first glance, seem harmless and can even confuse users and cybersecurity professionals. This highlights an important fact: security does not depend solely on user knowledge but also on the implementation of monitoring tools, traffic analysis, and robust URL validation policies within any organization.

In a broader context, understanding and documenting these techniques allows security teams to anticipate sophisticated attacks and design more effective defenses, minimizing risks and strengthening the company's overall cybersecurity posture. Education, controlled experimentation, and documentation of these methodologies are key to staying one step ahead of attackers.

Félix Sánchez, Offensive cybersecurity analyst at Zerolynx by Cybertix.