The Padded Port: Fingerprinting a Reply-Chain Phishing Kit

Between March and July 2026, one email operator ran the same reply-chain phishing kit across six Google Cloud Storage surfaces, then abandoned Google entirely. The kit is unremarkable in its social engineering: disposable consumer freemail accounts, forged reply-chain subjects that imply an open support ticket, and a single link to a one-click redirect page. What makes it worth documenting is the URL. Every link on the Google-hosted phase renders its host authority with 34 zeros padded in front of port 443, a technically valid form that no legitimate sender produces. That one detail turned out to identify this operator exclusively, and it stopped appearing the moment the operator stopped hosting on Google.

Key Takeaways

• The zero-padded port authority form appears on Google Cloud Storage hosts and nowhere else across our full email corpus, which makes it a precise operator fingerprint rather than a generic evasion trick.
• The operator rotated across six distinct Google Cloud Storage object-serving surfaces, not one, and a host-literal monitoring rule keyed to any single surface misses most of the activity.
• Hosting on Google ended in June 2026 and the identical kit resumed the next day on self-registered burner domains and abused marketing-platform tenants, so a campaign that looked retired had only changed landlords.
• Two of the replacement lander domains were registered at the same registrar on the same day and used in blasts the following day, which puts the operator's domain-acquisition lead time at roughly 24 hours.
• The padded port and the path-traversal trick both disappeared on the self-owned infrastructure, because their only purpose was to survive parsing of a URL that had to look like Google.
• The fragment-based tracking schema this kit uses is shared across roughly 450 hosts and multiple unrelated operators, so it identifies a kit family and is worthless for attributing a single actor.

Background

Cloud object storage has been a staple of phishing delivery for years, and the reason is straightforward. A bucket on a provider's own domain inherits that provider's TLS certificate and reputation, spins up in one API call, and can be discarded after a single send. Google Cloud Storage exposes objects through several hostnames under googleapis[.]com, Azure does the same through blob.core.windows[.]net, and Amazon S3 through its regional endpoints. Blocking the parent domain is not an option for a defender, because the parent serves an enormous volume of legitimate traffic. That asymmetry is the whole appeal: the operator gets a trusted domain, and the defender gets a target it cannot afford to touch.

Marketing platforms create a similar problem. Mailchimp's click-tracking and campaign hosts, Klaviyo's click-tracker, and SparkPost's relay all carry the platform's reputation on behalf of whichever tenant is sending. When an operator onboards a throwaway tenant account, its links resolve under a hostname that thousands of real businesses also use. The platform can suspend the tenant, but the hostname stays shared and stays trusted.

This campaign uses both, in sequence. It first surfaced to us as a small cluster of retail-brand impersonation mail pointing at a single Google Cloud Storage hostname, and it read at the time like a brief burst that had already ended. Sweeping the kit's structural signature instead of its hostname produced a different picture: a continuous operation spanning five months, six Google surfaces, and then a clean migration off Google onto infrastructure the operator bought itself. Across that period the operator pushed thousands of messages through 200-plus disposable sending accounts, at a deliberately low daily rate that keeps any single day unremarkable.

Discovery and Infrastructure

The original read of this operation was anchored to two hostnames. That anchor is what concealed it. Matching a host pattern rather than two literal names exposed four further Google Cloud Storage surfaces carrying the same kit, and pushed both ends of the timeline outward: the first activity moved a month earlier, and the last activity moved from early June to late July.

Surface	Random-Token Subhosts	Window	Kit Signature
content-storage-download.googleapis[.]com	34	2026-04-12 to 2026-06-02	Full padded-port form
<token>.storage.googleapis[.]com	6	2026-03-10 to 2026-03-17	Fragment tracking only
commondatastorage.googleapis[.]com	4	2026-04-27 to 2026-06-02	Full padded-port form
content-storage.googleapis[.]com	4	2026-05-03 to 2026-05-18	Full padded-port form
content-storage-p2.googleapis[.]com	3	2026-06-02 to 2026-06-06	Full padded-port form
storage-p2.googleapis[.]com	1	2026-05-17	Fragment tracking only

Every subhost is a fresh random alphanumeric token, between 15 and 43 characters, and none recurs. The pattern is one blast, one token, one disposable sending account, which neutralizes both sender reputation and URL blocklisting as accumulating defenses.

The March cluster on storage.googleapis[.]com is the same operation at an earlier stage. It carries the fragment tracking and the same health and survey personas on the same freemail rail, but not yet the padded port or the path traversal. Two other senders on that surface were deliberately excluded from this campaign: an adult-content lure and a casino lure from unrelated actors who happened to use the same Google service in the same month. Shared hosting is not shared attribution, and treating it as such would have pushed the campaign's start date two months too early.

After 2026-06-06 the Google surfaces stop appearing entirely. The following day the same kit resumes on four operator-registered apexes, on abused Mailchimp and Klaviyo tenants, on DigitalOcean Spaces, and behind general-purpose URL shorteners. Sending accounts, subject grammar, persona set, and tracking fragments all carry across the seam unchanged.

How It Works

A recipient receives a message from a consumer freemail address with a display name impersonating a retailer, a streaming service, a fabricated health publication, or a mail-infrastructure service. The subject is built to look like the latest reply in an existing thread: a bare six-to-nine digit ticket number, or a bracketed case, invoice, ticket, or watch reference. Nothing in the message is personalized beyond that fabricated reference, which is what lets one template serve a broad blast.

The body carries one call to action. On the Google-hosted phase that link points at an HTML object in a storage bucket, reached through an authority string padded with 34 zeros before the port and a path that walks back on itself with /../ before naming the file. The page behind it does not ask for anything. It is a redirect hub: it reads the fragment appended to its own URL and forwards the visitor to whichever funnel the campaign identifier maps to, which over the observed period included health-supplement offers, streaming-billing pages, and lead-capture forms.

Recipient identity never appears in the queryable part of the URL. It rides in the fragment after the #, which browsers do not transmit to the server on the initial request and which most URL-inspection tooling treats as opaque. The schema is consistent across every sample:

#cl/<campaign id>_smd/<list>/<offer>/<sequence>/<n>/<24-char hex recipient token>

#cl/ marks a click and #un/ an unsubscribe, and both resolve to the same object.

Sample Lures

All recipient identifiers and per-recipient tracking tokens have been replaced with placeholders. Every host is defanged.

Retail reply-chain, April 2026:

From: "COSTCO" <blasokharam8034@outlook[.]com>
To: [recipient email]
Subject: Re: 4122114

CTA: http[:]//1nqi9e8e0zq1i8xw01dic6jv8j3ujt9a08.content-storage-download.googleapis[.]com
     :0000000000000000000000000000000000443/[path]/../[file].html#cl/[campaign id]_smd/[recipient token]

Health-publication persona, the final Google-hosted blast, 2026-06-06:

From: "US HEALTH DISPATCH" <hinseyabdel1390@hotmail[.]com>
To: [recipient email]
Subject: Re: [Ticket#1320933] Memory Health Weekly Update -06-06-26
Date: Sat, 06 Jun 2026 18:33:25 +0100

CTA: http[:]//iko0606fzrhvalujjyhrdpuil.content-storage-p2.googleapis[.]com
     :0000000000000000000000000000000000443/3opp7bet8ypypowmtoym6rbys2x4d/../bcvihicsayev.html
     #cl/986343_smd/4/[list]/[offer]/[seq]/[recipient token]

Footer decorator: a real healthcare provider's public contact page

Streaming-renewal persona on the post-Google rail, 2026-06-09:

From: "HBO+ Loyalty Program" <vaniakistler9767@hotmail[.]com>
To: [recipient email]
Subject: Re: [Case#7914] Continue Watching with HBO+ Today - (RC987)
Date: Tue, 09 Jun 2026 20:50:57 +0100

CTA:   http[:]//kos465vr7blf0ju1fjqmfyni7.lokzenova[.]cc#cl/1000035_smd/78/[list]/[offer]/[seq]/[recipient token]
Asset: http[:]//kos465vr7blf0ju1fjqmfyni7.lokzenova[.]cc/2100fc800b477c3.png#http[:]//aka[.]ms

Footer decorator: a real clinic's public contact page

The earlier March cluster, before the padded port appeared:

From: "CBSHealth" <ixiidknp@outlook[.]com>
To: [recipient email]
Subject: 60 Minutes exposes the truth about type 2 diabetes - 5836509

Technical Analysis

The Padded-Port Authority Form

The kit's Google-hosted links render the authority as host:0000000000000000000000000000000000443/. Leading zeros in a port are permitted by the grammar and every mainstream parser resolves this to 443, so the URL works. What it defeats is naive extraction. A pattern that expects a hostname followed by /, :443/, or nothing at all will not cleanly recover the host from a 34-zero authority, and a reputation lookup that fails to normalize the port may query a string that matches nothing.

Sweeping the entire email corpus for this authority form, with no date bound and no host restriction, returned matches on Google Cloud Storage hosts only. It appears on none of the Amazon S3, DigitalOcean Spaces, Wasabi, Azure Blob, marketing-platform, or shortener traffic in the same period. That exclusivity is unusual for an evasion technique, and it is what makes this one a durable operator correlator rather than a shared trick. The lesson generalizes past this campaign: the detail an analyst is most likely to write off as a footnote can be the one signal that only one actor produces.

A caution attaches to any regex built on it. One matching pattern also fires on IPv6-literal URLs of the form http[:]//[0000:0000:0000:0000:0000:ffff:...]/, because the mapped-address zeros satisfy a loose :0000 search. Those belong to a different operator running cloud-storage-alert pretexts from algorithmic .org and .info domains. The pretext overlap is genuinely close, but no shared kit signature or shared infrastructure ties the two together, so they are tracked separately. Anchor the pattern to a real port position, not to a run of zeros.

Surface Inventory and Rotation Grammar

Google exposes object content through more hostnames than the two most commonly cited in phishing writeups, and this operator used six of them. Three carry a -p2 suffix or the commondatastorage name that a rule written against content-storage-download will never match. Across the Google phase the operator burned 48 distinct random-token subhosts, none of them reused.

Subhost tokens are flat lowercase alphanumeric with no delimiters and no dictionary content, running 15 to 43 characters. A regex floor set at 20 characters, which the token lengths in the earliest samples might suggest, silently drops the shortest ones. The durable shape is:

^[a-z0-9]{15,}\.(content-storage(-download|-p2)?|commondatastorage|storage(-p2)?)\.googleapis\.com$

Sending accounts sit on four consumer freemail domains, with the pool migrating from one Microsoft domain to another partway through and two single-use national variants appearing once each. Across the operation the same accounts carried 60 distinct display-name personas, which is a high ratio of identities to infrastructure and consistent with a templated mailer rather than hand-built sends.

One earlier assumption did not survive the wider sweep. The pairing is not strictly one sending account per subhost: several subhosts carry three accounts each, including the March health cluster, a mid-May cluster, and the June streaming cluster. Subhost sharing is therefore usable as a clustering signal, which is how the two excluded unrelated actors were separated out from the ones that belong.

Registration Cohorts on the Post-Google Rail

The four apexes that replaced Google are the most legible part of the operation, because unlike a Google bucket they leave a registration record.

Apex	Registrar	Created	Term	First Blast
lokzenova[.]cc	Namecheap	2026-06-08	1 year	2026-06-09
noventis[.]cloud	Namecheap	2026-06-08	1 year	2026-06-09
bestliveorbit[.]live	no WHOIS record	unknown	unknown	2026-06-08
scaregreat[.]com	Namecheap	2023-02-03, lapsed 2025	1 year	2026-06-11

Two of these were registered at the same registrar on the same day and used in blasts the following day, both on minimum one-year terms. That is a purchase batch with a roughly 24-hour lead time to first use, and it is the single most actionable signal in the post-Google phase: a nonsense-label apex on a cheap TLD, registered within days, minimum term, no WHOIS organization, is the operator's build pattern. The fourth apex is a different acquisition mode. Its registration dates to 2023 with an expiry that has already passed, so it lapsed and was picked up again later, which is the aged-stash pattern operators use when they want a domain whose creation date looks reassuring.

Labels across all four are algorithmic compounds with no brand token and no legitimate web presence. That absence matters in both directions, and it is why three other apexes seen in the same traffic are not named here. Those three are 20-plus-year-old registrations on real dictionary words, serving operator-shaped random-token subhosts. An aged real-word apex hosting a scam subdomain is at least as likely to be a compromised legitimate small business as it is to be operator-owned, and flagging the apex in that case takes down a real company. Host-level action is appropriate there; apex-level action is not.

Fragment-Based Recipient Tracking

The tracking fragment is the kit's most distinctive content-level artifact:

#cl/986343_smd/4/1063688/1514/74/[24-char hex]

The leading value is a campaign identifier, and the trailing 24-character hexadecimal string is a per-recipient token whose length and character set match a MongoDB ObjectId. Two samples three days apart carried campaign identifiers of 986343 and 1000035. If that counter is sequential and platform-wide, roughly 13,700 identifiers were consumed in three days, which is far more campaign activity than this operator's own sending accounts for. Both observations point toward a shared multi-tenant mailer with a Mongo-backed store rather than a tool this operator built and runs alone. They rest on two decoded samples and are offered as leads, not conclusions.

That reading is reinforced by how widely the schema travels. Sweeping the _smd/ fragment convention across the corpus returns roughly 450 distinct hosts over seven months, spanning Amazon S3, DigitalOcean Spaces, Wasabi, Azure Blob, Google Cloud Storage, abused CRM and site-builder tenants, developer-platform pages, and several marketing-platform click-trackers. The pretexts on those hosts have nothing in common with each other. A signal that broad identifies a kit family or an affiliate platform, and using it to attribute a single actor produces confident nonsense. The padded port is the correlator here; the fragment schema is only the toolchain.

What the Operator Stopped Doing

The most informative change in the post-Google phase is a subtraction. Both signature evasions, the padded port and the /../ traversal, are absent from the self-owned infrastructure. Phase 3 links are plain unencrypted requests to a random-token subhost with the tracking fragment appended and nothing else.

The reason is economic rather than technical. Both tricks existed to make a URL whose host had to read as Google survive parsing and reputation lookup intact. On an apex the operator owns, there is no borrowed reputation to protect, so the obfuscation buys nothing and gets dropped. The practical consequence is that the operation's cleanest fingerprint is gone: the current phase is identified by the freemail rail, the subject grammar, the persona set, and the fragment schema in combination, none of which is individually distinctive. Finding a signature for the current phase as precise as the padded port was for the last one is the open problem this campaign leaves behind.

Decoy Legitimacy Layers

Two smaller techniques recur and are worth naming because both are designed to be read by machines rather than people.

Every decoded sample embeds a real organization's public contact page in the footer, drawn from healthcare providers and clinics. The link is genuine and the organization has no involvement. It is furniture, present so that a message carrying one operator link also carries a link to something verifiably real. Those organizations are victims of reference, and they are not named in this post for that reason.

The second is more pointed. On the post-Google rail, an image asset appears as http[:]//<operator host>/<hex>.png#http[:]//aka[.]ms, appending a well-known Microsoft shortener to the end of a URL as a fragment. The fragment has no effect on where the request goes. Anything that inspects the tail of the string, or splits on the last scheme it finds, sees a Microsoft domain instead of the operator's.

Detection Observations

The behavioral signals that separate this traffic from legitimate mail sit in combinations rather than in any single attribute.

A consumer freemail address whose display name is a retailer, a streaming service, or a news-health publication is the strongest cheap signal, because no genuine brand notification originates from a consumer mailbox. Adding the subject grammar sharpens it considerably: a bare six-to-nine digit number after Re:, a bracketed case or ticket reference, a trailing seven-digit code, or a trailing parenthesized reference code, all on a message with no prior thread and no personalization beyond that reference.

On the URL side, the padded-port authority form is effectively self-identifying and worth normalizing for explicitly rather than pattern-matching, since a parser that resolves the port correctly turns an exotic string into an ordinary host lookup. The random-token subhost shape on cloud object storage is a useful secondary signal, provided the pattern covers every object-serving hostname a provider exposes rather than the one or two that appear in a given sample set, and provided the token-length floor is set from observed data rather than assumed.

Fragment content is a signal that survives infrastructure rotation, because it belongs to the mailer rather than to the hosting. A #cl/ or #un/ fragment carrying a campaign identifier and a 24-character hex recipient token indicates the kit family. Treated as a family-level indicator it is genuinely useful for triage and clustering; treated as an operator identifier it will merge unrelated actors.

For the current phase, registration recency is the most tractable pivot. A nonsense-label apex on a cheap TLD, registered inside a week, on a minimum term, with no WHOIS organization, serving a long random-token subhost, describes the operator's build closely and describes very little legitimate infrastructure.

Two cautions apply to anyone operationalizing the above. Aged real-word apexes serving operator-shaped subhosts should be handled at the host level, since compromised legitimate sites present the same way. And the real organizations linked in the footers will look like campaign infrastructure to any tool that treats every link in a scam message as adversary-controlled, which makes them a source of misattribution rather than a lead.

Indicators of Compromise

All indicators are defanged. Recipient data has been removed.

Senders

Value	Role	Notes
ixiidknp@outlook[.]com	Sender	News-health persona, March cluster
saidaclevelandd1nrn24528@hotmail[.]com	Sender	News-health persona, March cluster
blasokharam8034@outlook[.]com	Sender	Retail persona, reply-chain subject
doshienebeskyf@outlook[.]com	Sender	Retail persona
giedtphlegmh@outlook[.]com	Sender	Retail persona
huxleymorrisamfl@hotmail[.]com	Sender	Health-supplement persona
shelburngocha8309@hotmail[.]com	Sender	News-health persona, full kit signature
lautnerwinett601@hotmail[.]com	Sender	Public-figure health persona
hinseyabdel1390@hotmail[.]com	Sender	Final Google-hosted blast
strauszphomsoukha381@hotmail[.]com	Sender	Memory-health persona
akaolisazcmm266780@hotmail[.]com	Sender	Streaming-loyalty persona
vaniakistler9767@hotmail[.]com	Sender	Streaming-loyalty persona, post-Google rail
ludemanklick799@hotmail[.]com	Sender	Streaming-loyalty persona, post-Google rail
alesciosunford537@hotmail[.]com	Sender	Prize persona, post-Google rail
bowmakell666@hotmail[.]com	Sender	Most recent observed activity
… (representative subset; 200+ verified-malicious senders)

Domains

Value	Role	Notes
lokzenova[.]cc	Landing	Namecheap 2026-06-08, one-year term, first blast 2026-06-09
noventis[.]cloud	Landing	Namecheap 2026-06-08, same purchase batch, first blast 2026-06-09
bestliveorbit[.]live	Landing	No WHOIS record, cloud-storage-upgrade pretext
scaregreat[.]com	Landing	Registered 2023, lapsed and reacquired, prize pretext

MITRE Fight Fraud Framework Mapping

Mapping aligns to the MITRE Fight Fraud Framework (F3) v1.1, https://ctid.mitre.org/fraud. F3 is scoped to post-access fraud behavior, so this mapping of a pre-access lure operation is an alignment by analogy rather than a literal fit, and the stages F3 does not model are noted rather than forced.

F3 Tactic	Technique	ID
Reconnaissance	Phishing for Information	T1598
Resource Development	Establish Accounts	T1585
Resource Development	Acquire Infrastructure: Domains	T1583.001
Resource Development	Create Fake Materials: Fake Website	F1020.002
Initial Access	Phishing	T1660
Initial Access	Impersonate Official	F1032
Stealth	Email Spoofing	T1672
Stealth	Reputable-platform lander hosting and padded-port URL authority; no discrete F3 technique
Monetization	Health-product and streaming-billing funnels reached through the redirect layer; no discrete F3 technique

Conclusion

The useful result here is not the kit, which is ordinary, but the ranking of its signals. The padded port looked like a footnote and identified the operator exactly. The tracking fragment looked like a signature and spans hundreds of hosts belonging to actors with nothing to do with each other. Testing whether a candidate correlator is actually unique, before building attribution on it, cost one query and changed the conclusion twice. The operator has since moved to infrastructure it buys itself on roughly a day's notice, and it dropped the one signal that named it, so the next phase will have to be identified on registration behavior rather than on a clever string.