Anatomy of a Coined-Brand E-Signature Phishing Kit

Since May 2025, one operator has run more than 20 coined e-signature brands as a single phishing kit whose landing-page fingerprint outlasted four mail rails. Each domain wears an invented signing-service name (bellasign[.]net, voltsign[.]net, swiftverify[.]net) with no real trademark to infringe, so brand-abuse takedowns have nothing to grab. Behind the different names sits one build: the same landing-page host pattern, the same mailing-list header, the same first-name-personalized "your signature is required" template. The operator has swapped email providers three times to stay deliverable, yet the kit underneath never changed. This is a study of that kit: how the domains are coined, how they cluster in registration records, and which signals tie every one of them back to a single hand.

Key Takeaways

• One operator has run more than 20 purpose-built domains as a single e-signature phishing kit since May 2025, using coined *sign and *verify names that carry no real trademark for takedown teams to act on.
• The durable fingerprint is an i.<domain>/<7-character shortcode> landing host paired with a listrequest@<domain> List-Unsubscribe header, present on every domain in the network.
• The operator rotated across four legitimate email providers (Mailjet, Amazon SES, Postmark, Mandrill) for deliverability and takedown resilience while the landing pages and email templates stayed constant.
• Domains were batch-registered in same-day cohorts, first through Namecheap and then Cloudflare Registrar, all behind WHOIS privacy, which is a strong single-operator signal.
• The lure evolved from a plain "sign this document" notice into invoice and funding payoffs carrying fabricated dollar amounts and transaction IDs.

Background

Fake e-signature requests are a well-worn phishing pretext. The Identity Theft Resource Center has warned consumers about emails impersonating "DocuSign Electronic Service" that carry fake notification lures and lead to credential theft, and OneSpan has documented criminals exploiting DocuSign-style envelopes against businesses and government. University IT offices such as Cornell publish standing guidance on verifying whether a signing request is real, Docusign maintains public safety alerts about brand-impersonation, and U.S. healthcare-sector guidance from HHS HC3 has issued its own alert on DocuSign abuse. The pretext is recognized. What makes this network worth a closer look is that it does not impersonate any of those brands by name. It coins its own.

The operator delivers exclusively through legitimate email service providers (ESPs), which is the first piece of context a reader needs. An ESP is a hosted platform that sends mail on a customer's behalf from warmed, reputable IP ranges with valid SPF and DKIM authentication. Scammers onboard to these platforms because a message that authenticates cleanly and originates from a widely-allowlisted sender lands in the inbox rather than the spam folder, and because self-service signup lets them create, burn, and replace accounts faster than abuse teams close them. This operator used four:

• Mailjet, a self-service transactional and marketing API and SMTP relay (Sinch-owned), reached first. Free signup gives immediate access to shared reputable IPs, and each account gets its own click-tracking subdomain on mjt[.]lu with bounce handling on bnc3.mailjet[.]com.
• Amazon SES, AWS's pay-as-you-go email service, which inherits Amazon's IP reputation and wraps links through its own awstrack[.]me tracking domain.
• Postmark, a developer-focused provider known for strong inbox placement, which uses a pm-bounces.<domain> bounce subdomain convention.
• Mandrill, Mailchimp's transactional add-on riding Mailchimp reputation, with tracking served through mandrillapp[.]com.

Every one of those tracking and bounce domains is legitimate ESP infrastructure. Its appearance in a message tells you which rail carried the mail, not who owns the sending domain. The operator registered the sending domains themselves through Cloudflare Registrar and Namecheap, both of which offer cheap bulk registration behind default WHOIS privacy, which is exactly what a throwaway-domain operation wants.

Discovery and Infrastructure

The network first surfaced as a handful of unrelated-looking signing-notification domains. Clustering them took a fingerprint rather than a shared IP or a shared registrant, because there is neither: the domains sit behind privacy proxies and route through shared ESP infrastructure. What ties them together is the build. Every domain resolves the same three subdomains (app.<domain>, i.<domain>, and the bare apex), serves its landing pages from the i. host under a seven-character shortcode path, and stamps a listrequest@<domain> address into the List-Unsubscribe header. Pivoting on that combination, plus the coined *sign / *verify naming and the first-name signing subject, grew the confirmed set to more than 20 apexes.

The domain inventory, with public WHOIS registration data:

Domain	Registrar	Created	Brand family
miarvo[.]net	Namecheap	2025-05-05	(earliest, outlier)
olesign[.]net	Namecheap	2025-05-06	*sign
signrise[.]net	Namecheap	2025-05-06	*sign
swiftsign[.]net	Namecheap	2025-05-16	*sign
dotsign[.]net	Namecheap	2025-05-16	*sign
servicebeehive[.]com	Cloudflare	2025-05-21	(generic)
upverify[.]net	Cloudflare	2025-06-04	*verify
swiftverify[.]net	Cloudflare	2025-06-04	*verify
aloverify[.]com	Cloudflare	2025-06-30	*verify
suavesign[.]com	Cloudflare	2025-06-30	*sign
voltsign[.]net	Cloudflare	2025-08-13	*sign
sealsnap[.]net	Cloudflare	2025-08-13	(seal metaphor)
bellasign[.]net	Cloudflare	2025-08-19	*sign
sigtouch[.]com	Cloudflare	2025-08-19	(sig metaphor)
unoverify[.]com	Cloudflare	2025-08-19	*verify
monosign[.]net	Cloudflare	2025-09-19	*sign
venusign[.]com	Cloudflare	2025-11-03	*sign
splashsign[.]com	Cloudflare	2025-11-08	*sign
verasign[.]net	Cloudflare	2025-12-08	*sign / *verify
...			verified-malicious subset; the fingerprinted network spans more than 20 operator apexes

Each of these carries a support@ sending address and an i.<domain> landing host. None resolves to a real business. Where a landing page still answers, it renders a thin "Modern E-Signatures for Modern Teams" facade with no contact details, no pricing, no login, and no legal pages, which is the shell, not a product.

How It Works

A representative contact chain runs like this. The target receives a short, personalized email from a support@ or notification@ address on one of the coined domains, delivered through whichever ESP the operator is using that week. The subject carries the recipient's first name and a signing cue: "Review and Sign Document [name]," "Signing notification [name]," "Record ready for digital signature, [name]." The body is a few vague sentences referencing an "application," an "approval," or a "document in the system," ending with a single call-to-action button.

That button points at i.<domain>/<7-character shortcode>, either directly or wrapped through the ESP's click-tracker. The shortcode is unique per recipient, which lets the operator tie a click back to a specific send. The landing host presents the fake signing portal that harvests whatever the victim enters to "sign." The footer offers a listrequest@<domain> unsubscribe and, in many variants, a plain-language opt-out: "reply with 'No longer needed'." That opt-out doubles as an engagement probe, since a reply confirms a live, attentive mailbox.

Sample Lures

Three template families run across the network. All recipient-identifying data has been replaced with placeholders; the fabricated dollar amounts, transaction IDs, and signer names below are attacker-authored lure content, not victim data.

Template A, the standard signing notice (defanged, delivered via Mailjet):

From: "Support" <support@sealsnap[.]net>
Subject: Review and Sign Document [recipient first name]
Reply-To: support@sealsnap[.]net
List-Unsubscribe: <mailto:listrequest@sealsnap[.]net>
Return-Path: <bounce@a3238981.bnc3.mailjet[.]com>

Here is the placed status. Your Document exists in the system. To bring this
process to its conclusion your signature is required.

[ Continue to Signing ]  ->  http[:]//i.sealsnap[.]net/<shortcode>

Grace Morgan

Template B, the more formal "Electronic Signature Processing" variant. Its wording appears verbatim on multiple domains, which is one of the tighter attribution links in the set:

From: "Support Team" <support@bellasign[.]net>
Subject: Document revision inquiry
List-Unsubscribe: <mailto:listrequest@bellasign[.]net>

Electronic Signature Processing request. The relevant documents have been
received related to your application and our team is currently reviewing them.

[ Proceed to Document ]  ->  http[:]//i.bellasign[.]net/<shortcode>

Allen Austin

Template C, the evolved invoice and funding payoff, which adds a fabricated dollar amount and a transaction ID to manufacture financial urgency:

From: "Support" <support@miarvo[.]net>
Subject: Inquiry received successfully
List-Unsubscribe: <mailto:listrequest@miarvo[.]net>

Digital signature needed - $2,520.00 | [recipient name] | Apr 11, 2026 |
V282-52A - Application Verification.

[recipient first name], the inbound funding details for $2,520 reached our
intake system.

[ CONTINUE ]  ->  http[:]//i.miarvo[.]net/<shortcode>

Audrey

Technical Analysis

Coined-Brand Domain Generation

The naming is deliberate. Instead of typo-squatting a real signing service, which invites a fast brand-abuse takedown, the operator coins its own trust-flavored names from a small vocabulary. Two lexical families dominate. The *sign family (bellasign, voltsign, suavesign, olesign, dotsign, monosign, splashsign, swiftsign, signrise, venusign) pairs a short evocative prefix with a signing suffix. The *verify family (swiftverify, unoverify, upverify, aloverify) does the same with a verification suffix. A few sit between the two poles: sigtouch and sealsnap lean on signing and seal metaphors, verasign blends "verify" and "sign," and servicebeehive and the earliest domain miarvo[.]net fall outside the pattern entirely. Every coined name reads as a plausible small SaaS brand, none collides with an existing trademark, and each is short enough to look native inside a support@<brand> sender.

Registration Cohorts and Batch Co-Registration

Registration records are where a single operator becomes hard to argue against. The domains cluster into same-day cohorts, several registered in tight batches alongside one another:

Cohort	Registrar	Domains created together
2025-05-05 to 05-16	Namecheap	miarvo, olesign, signrise, swiftsign, dotsign
2025-06-04	Cloudflare	upverify[.]net + swiftverify[.]net (same day)
2025-06-30	Cloudflare	aloverify[.]com + suavesign[.]com (same day)
2025-08-13	Cloudflare	voltsign[.]net + sealsnap[.]net (same day)
2025-08-19	Cloudflare	bellasign[.]net + sigtouch[.]com + unoverify[.]com (same day)
2025-09 to 12	Cloudflare	monosign, venusign, splashsign, verasign (staggered)

The operator opened on Namecheap in early May 2025, then migrated to Cloudflare Registrar within weeks and stayed there. Same-day pairs and trios of otherwise-unrelated coined names, all behind WHOIS privacy, do not happen by coincidence across independent registrants. The staggered late-2025 additions show the operation restocking its domain inventory on a rolling basis rather than in one burst, consistent with a build that expects steady attrition from takedowns.

Subdomain Grammar and the Landing-Page Fingerprint

Every apex resolves an identical three-subdomain layout: app.<domain>, i.<domain>, and the bare apex. The i. host is the constant that matters. It serves the phishing landers under a seven-character alphanumeric shortcode path (/ppe5sj5, /z2e6sgy, /armpmj6, /tf3gtnb), one per recipient. Paired with the listrequest@<domain> List-Unsubscribe header, this two-part signature (a per-recipient i.<domain>/<shortcode> CTA plus a domain-hosted listrequest@ unsubscribe) is the single most reliable way to recognize the network, because it survives every other rotation the operator performs.

Sender Persona Rotation

Early domains sent from a single support@ mailbox. Later ones spread across multiple personas on the same apex to imitate a staffed operation. olesign[.]net alone sends as support@, details@, notification@, systemnotification@, and update@. servicebeehive[.]com uses support@, solutionsspecialist@, and ccmanager@. upverify[.]net uses assistant@, details@, and notification@. The multi-persona mailboxes cluster on the newer domains, which suggests the kit's mail configuration matured over the campaign. One domain, olesign[.]net, went further and stamped a fabricated corporate identity, "Olesign Group, Inc.," onto a real Los Angeles high-rise address, an invented tenant at a genuine building.

ESP Rotation Across Four Mail Rails

The clearest sign of an operator optimizing for survival is the mail-provider rotation. The kit opened on Mailjet, with a distinct Mailjet account per domain (each carrying its own mjt[.]lu tracking subdomain and bnc3.mailjet[.]com bounce path), then added three more rails while the lander and templates held constant:

Mail rail	Observed infrastructure	Role in the kit
Mailjet	per-account mjt[.]lu tracker, bnc3.mailjet[.]com bounce	original delivery rail
Amazon SES	amazonses[.]com return-path, awstrack[.]me click-wrap	added for scale and reputation
Postmark	pm-bounces.<domain> bounce subdomain	added for inbox placement
Mandrill	mandrillapp[.]com tracking	added rail

Provisioning a separate ESP account per domain, rather than blasting all domains from one account, is a deliberate blast-radius control: an abuse report against one sending domain burns one account, not the fleet. That the templates and i.<domain> landers did not change across any of these migrations is what confirms the rails are interchangeable plumbing under one unchanged kit.

Template Families and Lure Evolution

The three template families trace the operator's tuning over time. Template A is the plain signing notice. Template B reframes the same ask as a formal "Electronic Signature Processing request," and its verbatim reuse across domains (bellasign[.]net and olesign[.]net carry identical wording) is a direct attribution link. Template C is the escalation: it drops in a fabricated dollar figure and a transaction ID and reframes the signature as the last step to release "inbound funding," moving the pretext from a bureaucratic chore to a financial payoff. The progression from a document chore to a funding hook shows an operator actively testing which framing converts.

Detection Observations

The behavioral signature that separates this traffic from legitimate signing notifications is compact and stable. A message pairing a coined *sign or *verify sending domain with an i.<domain>/<7-character shortcode> call-to-action and a listrequest@<domain> List-Unsubscribe header is characteristic of the network regardless of which ESP delivered it. First-name-only personalization in the subject, vague references to an unnamed "application" or "document in the system," and multiple sender personas on a freshly-registered privacy-proxied domain reinforce the read.

Because the operator rotates mail providers freely, the ESP artifact (a mjt[.]lu, awstrack[.]me, pm-bounces, or mandrillapp[.]com element) is not itself a useful selector: those are legitimate services that carry vast amounts of real mail. The cross-rail constant, the i.<domain> lander fingerprint, is the strongest pivot for defenders, since it is the one attribute the operator has never changed. Notably, the coined domains carried no reputation in public threat-intelligence feeds during their active window, which reflects how new, purpose-built, low-volume infrastructure stays quiet on external sources and argues for behavioral clustering over feed lookups.

MITRE Fight Fraud Framework Mapping

The mapping below aligns to the MITRE Fight Fraud Framework (F3) (https://ctid.mitre.org/fraud). The matrix's live technique identifiers could not be independently confirmed at time of writing, so techniques are given by tactic and behavior rather than by a possibly-incorrect ID.

Tactic	Technique / behavior
Resource Development	Acquire purpose-built domains through registrars with WHOIS privacy
Resource Development	Establish multiple ESP sending accounts for rotation and blast-radius control
Initial Access	Deliver personalized phishing email through legitimate mail providers
Initial Access	Impersonate the e-signature service category with coined brand names
Initial Access	Add first-name personalization, fabricated transaction IDs, and dollar amounts as legitimacy cues
Execution	Apply signing-urgency pressure ("your signature is required")
Monetization	Harvest credentials through a fake document-signing portal

Indicators of Compromise

All indicators are defanged. Recipient and victim data has been removed. Shared ESP tracking and bounce subdomains are intentionally omitted, since they belong to legitimate mail providers rather than the operator.

Domains

Value	Role	Notes
miarvo[.]net	Sending / landing	Namecheap, created 2025-05-05 (earliest)
olesign[.]net	Sending / landing	Namecheap, 2025-05-06; verbatim Template B; fabricated "Olesign Group, Inc."
signrise[.]net	Sending / landing	Namecheap, 2025-05-06
swiftsign[.]net	Sending / landing	Namecheap, 2025-05-16
dotsign[.]net	Sending / landing	Namecheap, 2025-05-16
servicebeehive[.]com	Sending / landing	Cloudflare, 2025-05-21; multi-persona senders
upverify[.]net	Sending / landing	Cloudflare, 2025-06-04
swiftverify[.]net	Sending / landing	Cloudflare, 2025-06-04 (same day as upverify)
aloverify[.]com	Sending / landing	Cloudflare, 2025-06-30
suavesign[.]com	Sending / landing	Cloudflare, 2025-06-30 (same day as aloverify)
voltsign[.]net	Sending / landing	Cloudflare, 2025-08-13
sealsnap[.]net	Sending / landing	Cloudflare, 2025-08-13 (same day as voltsign)
bellasign[.]net	Sending / landing	Cloudflare, 2025-08-19; verbatim Template B
sigtouch[.]com	Sending / landing	Cloudflare, 2025-08-19; Template C funding payoff
unoverify[.]com	Sending / landing	Cloudflare, 2025-08-19
monosign[.]net	Sending / landing	Cloudflare, 2025-09-19 (distinct from MonoFor MonoSign)
venusign[.]com	Sending / landing	Cloudflare, 2025-11-03
splashsign[.]com	Sending / landing	Cloudflare, 2025-11-08
verasign[.]net	Sending / landing	Cloudflare, 2025-12-08 (distinct from VeriSign Inc.)
...		(verified-malicious subset; the fingerprinted network spans more than 20 operator apexes)

Landing Hosts

Value	Role	Notes
i.sealsnap[.]net	Landing	Credential-harvest portal, /<shortcode> path
i.bellasign[.]net	Landing	Credential-harvest portal
i.miarvo[.]net	Landing	Credential-harvest portal
i.swiftverify[.]net	Landing	Credential-harvest portal
i.unoverify[.]com	Landing	Credential-harvest portal
i.suavesign[.]com	Landing	Credential-harvest portal
i.voltsign[.]net	Landing	Credential-harvest portal
i.olesign[.]net	Landing	Credential-harvest portal
i.sigtouch[.]com	Landing	Credential-harvest portal
i.verasign[.]net	Landing	Credential-harvest portal
...		(representative subset; dozens of verified-malicious i.<domain> landing hosts across the network)

Senders

Value	Role	Notes
support@sealsnap[.]net	Sender	Template A
support@bellasign[.]net	Sender	Template B
support@miarvo[.]net	Sender	Template C funding payoff
support@swiftverify[.]net	Sender	*verify family
support@unoverify[.]com	Sender	*verify family
support@sigtouch[.]com	Sender	Template C funding payoff
details@olesign[.]net	Sender	Multi-persona domain
notification@olesign[.]net	Sender	Multi-persona domain
systemnotification@olesign[.]net	Sender	Multi-persona domain
assistant@upverify[.]net	Sender	Multi-persona domain
ccmanager@servicebeehive[.]com	Sender	Multi-persona domain
solutionsspecialist@servicebeehive[.]com	Sender	Multi-persona domain
...		(representative subset; 50+ verified-malicious sender addresses across the network)

Conclusion

The lesson of this kit is that a name is disposable but a build is not. By coining its own signing brands, the operator sidesteps the trademark-based takedowns that clip typosquatters, and by swapping ESPs it keeps mail flowing as individual accounts burn. What it cannot easily change is the machine underneath: the i.<domain>/<shortcode> lander, the listrequest@ header, the personalized signing subject. Defenders watching for that fingerprint, rather than for any one domain or mail provider, will catch the next cohort the day it registers.