eBanking phishing hides its landing-page address in IPv4-mapped IPv6 notation to slip past URL scanners `[SINGLE-SOURCE]`

SANS ISC handler Xavier Mertens documented an active phishing campaign against customers of a major Belgian bank that encodes the destination address as an IPv4-mapped IPv6 literal — the [::ffff:…] bracketed form, where the dotted-decimal IPv4 address is rewritten as its hexadecimal IPv6 representation inside square brackets (SANS ISC, 2026-06-19). Modern browsers resolve the form correctly per RFC 4291 and render the phishing page normally, but two defensive layers fail on it: regex-based URL extractors in email gateways and proxies typically match the dotted-decimal IPv4 pattern (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) and never see the hexadecimal IPv6 form as an address at all, and because no DNS record is involved, domain-reputation lookups return nothing to score. The technique is delivery-agnostic — any link-based vector (spearphishing link, HTML attachment, QR redirect) inherits the same inspection blind spot. The RFC-level notation is old; the operational novelty is its appearance as a live evasion in commodity banking phishing (T1598.003 Spearphishing Link; T1027 Obfuscated Files or Information). [SINGLE-SOURCE] — SANS ISC is the disclosing party (PD-5 national-CERT-equivalent carve-out); see § 7.

Why it matters to us: Swiss cantonal banks, PostFinance, and any organisation running URL-rewriting or reputation-based mail/web inspection should test their stack against a controlled [::ffff:<ipv4>]-style URL and confirm the extractor normalises IPv4-mapped IPv6 to its IPv4 form before the reputation lookup, not after. Hunting: update SIEM/proxy URL-extraction patterns to capture the \[::ffff:[0-9a-fA-F:]+\] shape, and treat bracketed-IPv6 URLs in inbound mail as high-suspicion regardless of reputation verdict.