HostMimic: An Old URL Evasion Technique Revived

HostMimic: Old Technique Revived – Non-Canonical IP URL Obfuscation

Trustifi observed multiple quarantined phishing emails using a very old but still effective URL evasion technique: Non-Canonical IPv4 URL Obfuscation.

We’re calling this observed phishing pattern HostMimic.

The emails looked like standard “storage almost full” notifications. The visible button was simple:

Manage Storage

But the HTML behind the button pointed to:

hxxp://026250556406/...

At first glance, this does not look like a domain. It also does not look like a standard IPv4 address.

However, Chrome normalizes it to:

hxxp://178[.]162[.]221[.]6/...

Technique: Non-Canonical IPv4 URL Obfuscation
Observed host: 026250556406
Browser-normalized host: 178[.]162[.]221[.]6

What Is Happening?

026250556406 is a dotless octal IPv4 representation.

026250556406 → 178[.]162[.]221[.]6

The attacker is not relying on JavaScript, a URL shortener, or a complex redirect chain. The trick is much simpler: the browser understands the host differently than many security tools, scanners, and human reviewers do.

Browsers normalize the host before connecting. Many detection pipelines still inspect URLs as raw strings first.

What the user sees:       026250556406
What some scanners parse:  Unknown or unsupported host format
What Chrome opens:        178[.]162[.]221[.]6

Why This Still Matters

This class of evasion is not new. Similar DWORD, octal, and hexadecimal IP representations have been documented in malware and spam campaigns for years, including Emotet campaigns that used unconventional IP address formats to evade pattern-based detection.

The problem is that modern defenses do not always parse URLs the same way browsers do.

Important observation: IIn this case, a widely used multi-engine public scanner did not appear to parse the raw non-canonical host as a supported URL format. The same behavior was observed across many online phishing and reputation scanners we tested: the URL was treated as unsupported or not recognized as a valid URL, even though Chrome still resolves it to a real destination.

A cautious recipient may copy the suspicious URL, paste it into a public scanning service, receive no useful result or an unsupported response, and assume the link is safe.

But the browser may still resolve and open the destination successfully.

Submitted by user:  hxxp://026250556406/...
Browser resolves:   hxxp://178[.]162[.]221[.]6/...

Observed Landing Destination

The campaign ultimately led to the following defanged landing destination:

hxxps://www[.]tetraexpobuild[.]com/3ZXF3D6/27KQBZNB/?sub1=1&sub2=343-22718&sub3=204-418131-433805

Detection and Engineering Takeaways

Detection principle: Normalize first. Analyze second.

Security controls should apply browser-equivalent URL parsing before making any verdict on a URL.

Normalize URL hosts before reputation checks
Normalize before URL rewriting and click-time protection
Normalize before sandbox detonation
Normalize before allow/block policy matching
Normalize before IOC extraction
Log both the original and normalized host

Recommended logging fields:

Original host:    026250556406
Normalized host:  178[.]162[.]221[.]6
Technique:        Non-Canonical IPv4 URL Obfuscation

Defanged IOCs

The following indicators were observed in the campaign. Recipient-specific indicators were excluded.

Sender and Envelope Indicators

Storage[@]Clouduzm[.]com
Storage[@]Cloudtv9[.]com
Storage[@]Cloudqdg[.]com
Storage[@]Cloudzyv[.]com
Storage[@]Cloudy6t[.]com
Storage[@]clouduk3[.]com
Storage[@]cloudfbd[.]com

Domains

Clouduzm[.]com
Cloudtv9[.]com
Cloudqdg[.]com
Cloudzyv[.]com
Cloudy6t[.]com
clouduk3[.]com
cloudfbd[.]com
Dai20356215[.]onmicrosoft[.]com
WisokyCN[.]onmicrosoft[.]com
tetraexpobuild[.]com
www[.]tetraexpobuild[.]com

Infrastructure

64[.]120[.]94[.]222
95[.]211[.]43[.]50
178[.]162[.]221[.]6
026250556406

Observed Obfuscated URLs

hxxp://026250556406/4IkDVY22718fXje343cmvmufeytq204WYPZDGDBRNRJNUF418131TMIB433805O1

hxxp://026250556406/4BmSaN22718Ijwf343zsvgrqqnuj204CYDNQTZLZBCHYVC418131OJEL433805a1

hxxp://026250556406/5bzucU22718QHoI343ibsqtsxtjg204CIAUSGTKLMEEZAM418131KMJR433805g1

hxxp://026250556406/4kwNmh22718uMbE343gksxuybrlb204FLRJAFAYVOISHIS418131DYLK433805R1

hxxp://026250556406/4CZmJO22718mawW343sxiuqwsxbr204CBMMKOMTFONXOTK538737BREL433799l1

hxxp://026250556406/4GumCe22718nxdz343xrgehjesju204SRYGXFFYNDQRKBD538737PRSZ433799O1

hxxp://026250556406/4ruRhi22718lvzc343juicygavnc204MXPWVOYFWTAFIOU530779OBGH433799L1

hxxp://026250556406/4QdBll22718beZl343jsdkseatgy204YAUCZOMFZHDHVWV105568RBVQ433799L1

Conclusion

Non-canonical IP URL obfuscation is an old technique, but it remains effective when scanners, email security controls, and URL analysis pipelines parse URLs differently than browsers.

The key lesson is simple: do not trust the raw URL string until the host has been normalized.

Security teams should log both the original and normalized host, apply browser-equivalent parsing, and run downstream reputation, policy, detonation, and verdict logic against the normalized destination.

Protect Your Email Environment From Developer Credential Fallout See how Trustifi helps reduce the business impact of stolen developer credentials with stronger email security, anti-impersonation protection, encryption, and better visibility into suspicious email activity.

Request a demo today