Xavier Mertens spotted a phishing email this morning targeting a major Belgian bank. The phishing page itself is classic. The delivery vector is not. The malicious link reads hxxp:// /kWC5PHA1. Brackets tell the URL parser this is a literal IPv6 address. But ::ffff: is the magic prefix that signals an IPv4-mapped IPv6 address, defined in RFC 4291.
Hex To Dotted Quad In Three Seconds ::ffff:5511:74be expands to 0000:0000:0000:0000:0000:ffff:5511:74be. The last two groups 5511 and 74be are simply the four IPv4 octets in hexadecimal. 0x55 = 85, 0x11 = 17, 0x74 = 116, 0xBE = 190. The real URL is hxxp://85.17.116.190/kWC5PHA1. Why bother? Because many security tools run simple regexes to extract domain names or raw IP addresses from emails. A pattern looking for \d+\.\d+\.\d+\.\d+ misses this entirely. The colon-and-bracket syntax also evades parsers that expect a protocol-delimiter like :// followed by a traditional hostname.
No DNS, One Redirect From the attacker's perspective, there's another bonus: no DNS record at all. No A, AAAA, or PTR to triage. When visited, the IPv6-mapped URL redirects to hxxps://3439-aanmelden.verificatie.qzz.io/mon-belfius, where the real phishing kit lives. This technique is not new - RFC 4291 dates to 2006 - but it's rarely exploited in the wild. Most security monitoring pipelines still treat IPv4 and IPv6 as separate channels. That gap is exactly what this campaign rides on. Security teams should extend their URL extraction regexes to handle IPv6 literals, especially the ::ffff: prefix. One overlooked variant can turn a routine phishing block into a successful compromise.
Source: eBanking Phishing Delivered Through IPv4-Mapped IPv6 Address, (Fri, Jun 19th)
Domain: isc.sans.edu
Comments load interactively on the live page.