The Extortion Email That Hid Its Links Inside IPv6 Bracket Notation

The subject line read "Reminder: Service Interruption Scheduled." The sender display name read "PAYMENT/DECLINED." The body contained explicit threats demanding same-day payment to prevent data destruction.

And every link in the email pointed to an IPv6 address wrapped in bracket notation that most URL scanners would never parse correctly.

This attack layered four distinct evasion techniques into a single delivery: a bank-named sending domain with full authentication, IPv6 literal URLs that break standard URL parsing, unrelated Jira ticket fragments injected as content padding, and high-pressure extortion language designed to override critical thinking. Each layer addressed a different defensive control. Together, they created an email that passed technical checks, confused content classifiers, evaded link scanners, and pressured the recipient into acting before thinking.

A Bank That Exists Only on Paper

The email arrived from info@fog[.]chelseagrotonsavings[.]com, a subdomain of chelseagrotonsavings[.]com. The domain was registered on February 12, 2026, less than two months before the attack, with privacy-protected WHOIS data and Cloudflare nameservers. SPF passed. DKIM passed. DMARC passed with a policy of p=QUARANTINE.

The name "Chelsea Groton Savings" evokes a specific type of institution: a small, community-oriented bank. That naming is deliberate. Attackers pick bank-themed domains because financial institution names carry inherent trust signals that survive a quick visual check. The domain has no connection to any real financial institution. It exists solely as authenticated sending infrastructure.

The fog subdomain resolved to 5[.]45[.]87[.]122, an IP address geolocated to the Netherlands, hosted on infrastructure commonly associated with bulletproof hosting. This is not the web presence of a community bank. It is disposable attack infrastructure dressed in a name that sounds legitimate.

According to the FBI IC3 2024 Internet Crime Report, extortion-related complaints exceeded 86,000 in 2024, with losses of over $1.5 billion. Campaigns like this one, combining authenticated domains with urgency-driven extortion, account for a growing share of that volume.

The IPv6 Trick That Breaks URL Scanners

Every clickable link in the email used the same format: http://[::ffff:5ccc:f083]/qs=...

That bracket notation is valid under RFC 2732 and RFC 3986. The address ::ffff:5ccc:f083 is an IPv6-mapped representation of the IPv4 address 92[.]204[.]240[.]131, geolocated to a hosting provider in France. The format is technically correct. It is also functionally invisible to most email security tooling.

Here is why. URL parsers in secure email gateways and reputation services are built to extract domain names from links, then query those domains against threat intelligence feeds, WHOIS databases, and reputation scores. An IPv6 literal URL contains no domain name. The parser encounters a bracket where it expects a hostname, and depending on its implementation, it either skips the link entirely, throws a parsing error, or misclassifies the address format. The reputation lookup never happens.

This is not a theoretical gap. The MITRE ATT&CK framework documents link obfuscation under T1027 (Obfuscated Files or Information), and IPv6 literal encoding is one of the cleaner implementations of that technique. The link is not encoded, encrypted, or hidden behind a redirect. It is sitting in plain text, fully RFC-compliant, pointing at a live IP address. The evasion works because the defensive tooling was never built to handle this format.

The destination IP 92[.]204[.]240[.]131 hosted a landing page designed to collect payment. With no domain name attached, there is no WHOIS record to query, no passive DNS history to evaluate, and no reputation score to check. The attacker eliminated the entire domain-based detection surface by simply not using a domain.

See Your Risk: Calculate how many threats your SEG is missing

Jira Tickets, Salesforce Fragments, and the Noise Floor

The email body was not a clean extortion message. Mixed into the threatening text were unrelated Jira ticket fragments, Salesforce notification snippets, and what appeared to be recycled content from Schwab and Steam communications. The Received headers confirmed this: the message carried remnants of multiple previous message templates stitched together.

This is content padding, a technique designed to manipulate classifiers that evaluate emails based on overall content composition. Natural language processing models trained on phishing corpora look for patterns: urgency language, financial demands, threat indicators. By diluting those signals with legitimate-looking project management and CRM content, the attacker shifted the message's statistical profile toward benign.

The Jira fragments served a secondary purpose. An employee accustomed to receiving automated Jira notifications might perceive the email as partially legitimate, a system-generated message that happens to include a payment reminder. The padding creates a plausible explanation for why the email looks unusual without looking entirely malicious.

The Verizon 2024 Data Breach Investigations Report found that social engineering (including pretexting and phishing) involved the human element in 68% of breaches. Content padding targets this directly. It does not need to fool the security stack completely. It only needs to introduce enough ambiguity that the email reaches the inbox, where the human element takes over.

What the Behavioral Layer Caught

IRONSCALES Adaptive AI flagged this message at 89% confidence with Credential Theft and VIP Recipient labels. The detection was not driven by URL reputation, because no reputation lookup succeeded against IPv6 literal links. It was driven by the behavioral fingerprint of the message itself.

The sender was a first-time contact from a recently registered domain. The display name ("PAYMENT/DECLINED") matched no prior communication pattern. The email targeted a VIP-flagged mailbox. The body contained explicit financial threats with a same-day deadline. And the community intelligence network had already surfaced similar IPv6-literal campaigns from other organizations, providing cross-tenant correlation before any single scanner had evaluated the link format.

One mailbox was quarantined before the recipient could interact with the message.

What Defenders Should Take From This

IPv6 literal URLs have existed for decades, and they remain underaddressed by most email security stacks. A few specific steps apply to this pattern:

1. Audit your URL parser's handling of IPv6 literal notation. Send a test email containing http://[::ffff:7f00:0001]/ (localhost in IPv6-mapped format) through your security stack and check whether it gets parsed, evaluated, and flagged. If it passes through untouched, you have a gap.

1. Treat recently registered domains with bank or financial institution names as high-risk. Domain age combined with financial terminology is a strong signal. The CISA phishing guidance recommends verifying unexpected financial communications through independent channels. That applies doubly when the sending domain did not exist eight weeks ago.

1. Do not rely on content classification alone for extortion detection. Content padding defeats classifiers that evaluate the full message body as a single unit. Effective detection isolates threat-bearing segments (urgency language, financial demands, destructive threats) and evaluates them independently from padding content.

1. Correlate across organizations. A single IPv6-literal extortion email in one inbox is ambiguous. The same format appearing across multiple unrelated organizations within the same week is a campaign. Cross-tenant threat intelligence turns isolated anomalies into confirmed patterns.

Indicators of Compromise

MITRE ATT&CK Mapping