A genuine Carnival Cruise Line booking confirmation routed customers to malware. The mail was authentic and passed SPF, DKIM and DMARC. The failure was a promotional domain Carnival had let lapse, still linked from live marketing mail, re-registered by someone else and wired into a redirection network.
Carnival re-acquired the domain on August 26th, 2026, and I verified the vector dead the next day.
Credit where this work starts
Trinity Cyber documented the redirection technique and the payload family in November 2025, in Blurred Lines: AdTech Abuse Delivers Browser Hijackers Through the Microsoft Store. Tanner Piliego and Jared Grumbein named the redirection layer PseudoTDS and the browser-hijacker family PhantomJack, and traced the initial redirects through the Trillion ad-tech network, formerly Trellian.
Their report describes victims reaching that machinery by mistyping a domain. This report describes the same machinery reached through an authenticated marketing email, which is the part that is new.
Both names in this article are theirs. What I add is the delivery path, a current set of indicators, and one payload behavior their report does not cover.
What I did to confirm it
On June 13th, 2026, I received a Players Club casino email from Carnival Cruise Line. It was a real booking confirmation carrying my own booking number, and all three authentication checks passed.
I clicked one of its links on my own PC, the way any recipient would, and landed on a fake-security page pushing a download. I reread the address bar and ran it again. Same result.
Then I checked it from a second computer and a different inbox belonging to another booked guest who received the same email. Same behavior, so nothing about it was specific to my account.
From there I stopped clicking blind and started capturing, from public scanners, from my own servers in different parts of the world, and from my phone. The same link behaved differently depending on where I loaded it from.
The cloak decides what you see
The landing page fingerprints the visitor and routes on the result, per visit.
Scanners, command-line tools and headless browsers fail that check and receive a benign skeleton. Real browsers on real networks reach a live payload.
Point a scanner or a datacenter IP at that link and you get a clean, empty page. Load it on a phone or a home connection and it drops you into malware installers, scareware and fullscreen lockers.
The public reputation services I checked returned clean verdicts throughout. Those results are consistent with the services having received the same skeleton page my automated checks did.
When I ran the page through urlscan.io it came back flagged as one of "10,000+ similar pages," which points at a templated network rather than a one-off.
What the click bought
Here is what I observed. The domain resolved into a parked-domain monetization service. The content it returned changed with the visitor: automated clients received a compliant parking page, real browsers were handed to an advertiser, and which advertiser changed between visits.
An advertiser network sits behind that domain, and the disclosure record establishes it. I reported individual advertisers to the monetization service and those advertisers came down. Something in that chain decides which advertiser a visitor reaches.
Each removal had to be earned. The service acted on an advertiser once I had captured and handed over proof for that specific advertiser, which leaves the collection work with whoever happened to notice. Reporting a cloaked page is slow work, and doing it per advertiser is the slowest version of it.
The removals did not fix anything. Each one was replaced, the entry domain stayed live, and the email link kept routing into it until Carnival re-acquired the domain on August 26th. Removing an advertiser treats the symptom, and the timeline in the disclosure section shows it.
Why the split happens, as far as I can tell
Why the traffic splits the way it does is my reading rather than a documented fact. The behavior is consistent with parked traffic being sorted by what it is worth: traffic that passes strict quality checks goes to the buyers with the strictest policies, and traffic that fails those checks, by geography, device or automation signals, moves elsewhere.
On that reading, an automated checker resembles traffic the strict buyers accept and receives the compliant page, while a person on a phone is routed further down. It would explain why these domains test clean, and why anyone who checked one and found nothing was reading an accurate result.
The commercial terms are the part I cannot see. I have no contract, no revenue figure and no visibility into what any party knew about a specific buyer, so this report describes what the infrastructure did rather than what anyone intended by it.
What real visitors got
The page fingerprints the device and serves whatever fits it, rotating downstream domains as they get taken down. Every visit could return something different.
Between June 13th and 24th, 2026, this is what came through.
Fake-security installers for Windows
Forced .msix downloads dressed as privacy and antivirus apps, about 148 MB each. Four names rotated: SafeWatch, NetGuard, LeakGuard and PrivacyKeeper.
Each was signed with a certificate naming a bare GUID as the organization, issued by a Microsoft Marketplace CA and valid for three days. Both certificates had already expired before the packages were served.
These are PhantomJack, the browser-hijacker family Trinity Cyber named. SafeWatch, NetGuard and LeakGuard all appear in their report. PrivacyKeeper, SecuriGuard, QuickBrowse, MyConverterHub and SecuredWeb came off the same machinery and do not.
ReversingLabs classifies my SafeWatch sample as Win32.Trojan.PhantomJack, which is a vendor's read on the family rather than mine.
The package size is consistent with padding to exceed the size ceilings that antivirus engines and sandboxes apply before they will scan a file. SafeWatch is 147,724,942 bytes and PrivacyKeeper is 148,652,394 bytes, which a browser rounds to 141 MB in its download bar. I did not test any specific scanner's limit, so treat that as a reading of the size rather than a measurement.
Scareware and fullscreen lockers
Several fake-antivirus landers rotated through the chain, including cloned McAfee "Run Quick Scan" pages.
The lockers worry me more, and both of the ones I caught were absent from prior public reporting. There is no download and no install.
The page goes fullscreen, hides the cursor through the Pointer Lock API, loops a synthesized "your PC is locked" voice over a beeping alarm, and runs a fake scrolling hacker terminal. Each pushed its own scam phone number.
For a non-technical relative, that is harder to escape than an installer and likelier to work.
Different device, different attack
A Firefox search hijacker, an iOS "your iPhone has been hacked" scam, and browser push-notification hijacking all appeared, depending on the device.
Three unrelated advertisers came off that one domain inside 48 hours. The slot simply gets refilled.
PseudoJack: PhantomJack builds that keep a door open
Two of the installers arrived as .appinstaller loaders rather than plain packages. I captured both on June 20th, 2026: BelezaAI.PrivacyKeeper version 1.0.6.0 and BonitoApp.SecuredWeb version 9.0.3.0.
Both manifests carry an identical update block.
<UpdateSettings>
<OnLaunch HoursBetweenUpdateChecks="0" />
<AutomaticBackgroundTask />
<ForceUpdateFromAnyVersion>true</ForceUpdateFromAnyVersion>
</UpdateSettings>Three settings matter here. HoursBetweenUpdateChecks="0" checks on every launch with no delay, <AutomaticBackgroundTask /> checks even when the app is closed, and ForceUpdateFromAnyVersion accepts any version the server offers, including a downgrade.
Together they are a standing channel for the operator to push an arbitrary package at any time. A standard PhantomJack install is a one-time event. A build carrying this block keeps a door open behind it.
I track these builds as PseudoJack: PhantomJack packages that ship a forced auto-update channel. The name records lineage rather than a discovery, because the apps are already PhantomJack and the machinery is already PseudoTDS.
I proved the channel exists. I did not observe it delivering a second stage, and I did not detonate the samples, so every claim about what the installed app does comes from Trinity Cyber's analysis rather than mine.
Both publisher identities are bare GUIDs, CN=31E36F3F-1F26-4209-AA73-9C18172AA2E6 and CN=11069677-9767-4ED4-9C5B-619B79B9FE6B, which are throwaway signing identities rather than vendor names.
There is precedent for the format itself. Microsoft disabled the ms-appinstaller protocol handler by default in December 2023 after tracking abuse by Storm-1113, Storm-0569 and Sangria Tempest, and reported that multiple criminals were selling a malware kit as a service built on the MSIX format and that handler. My captures deliver the file by direct download rather than through an ms-appinstaller: URI, which is consistent with that handler having been off by default since 2023.
It fought back against inspection
The landers ship an anti-analysis layer. Opening developer tools froze the page on a debugger trap built at runtime, with no literal debugger token in the source for a scanner to find.
The same layer hooks DOM query methods and inspects the caller's stack to spot console evaluation or injected extensions. It reports back to the operator's own telemetry endpoint.
That combination explains both halves of the problem. Payloads are hard to reproduce under analysis, and automated scanners only ever capture the skeleton.
The infrastructure is still live
I rescanned the chain on September 10th, 2026. The hosts Trinity Cyber reported have moved on: results.streamio[.]site now returns clean and cint[.]browsingit[.]online is unreachable.
The build I captured is still running. get.privacykeepersite[.]com returns a phishing verdict, securi-guard-browser[.]com is live, and cablegaurdian[.]online, guardianrole[.]online, euob.northwavepoint[.]com, tratobid[.]com and kineticharbor[.]com are all still cloaking.
The naming carries across. Their command-and-control host was cint[.]browsingit[.]online; mine are cint2.scrtgrd[.]online and cinga.ngapp[.]online. Same subdomain grammar, different apexes, rotated infrastructure.
The hop layer is disposable by design. Of 12 redirect-hop domains I scanned, 11 came back as dead parked pages: six lowercase letters plus .com, bulk-registered, all first seen in the same month, all on one parking IP.
All four of my samples were unknown to MalwareBazaar and ThreatFox before I filed them on September 10th, 2026.
The rotation is why this stays open. I mapped 12 of the 33 hop domains I collected, which leaves most of that layer unexamined, and the selection logic inside the redirect itself is still unseen.
I am continuing to track this kit and the domains it moves through, and I will publish what that turns up. Researchers working the same kit, or anyone holding telemetry on the hosts listed below, can reach me at contact@tuxxin.com.
What I could and could not confirm
I resolved the recipient's full 16-year email archive server-side, at a deliberately gentle rate, and validated the resolver against the known-bad link first.
The booking confirmation from June 13th is confirmed to route live to the lapsed domain.
The broader mailstream is clean. Across 541 deduplicated casino tracker links from 2018 to 2026, and 241 emails sent after the domain takeover, none routed to it. Every archived link still live resolves to www.carnival.com.
Older booking emails from 2024 and 2025 are unverifiable. Their tracker tokens have expired and now return an error page, so their original destinations cannot be recovered either way.
The exposure window runs from November 22nd, 2024, when the domain left Carnival's control, to August 26th, 2026. The cloaker is confirmed present by March 12th, 2026, the earliest archived snapshot containing it, and the previous snapshot from July 23rd, 2025, was still benign.
Several things stay out of this report for lack of evidence. I have no victim counts, no dwell time and no install numbers.
The commercial arrangements are also outside what I can observe. I documented what the infrastructure served and how it responded to reports, and I have no contract, no revenue figure and no basis to characterize intent.
How a Carnival link ends up serving malware
The root cause is mundane, which is what makes it worth writing about.
The domain was Carnival's own Players Club casino site. The 2021 Wayback snapshot shows Carnival branding, links to carnival.com, and the same /carnivalplayersclub/ path the malicious email still pointed at.
Content ceased around August 2022 and the domain lapsed. A third party caught it in November 2024.
The rest of the sending setup checks out from outside. The sending domain sits on an enterprise registrar with locks in place and years left on it, and the authentication passed because the mail genuinely was Carnival's.
One brand domain lapsed while live marketing mail still linked to it. That is the root cause visible from the outside, and the internal reason it lapsed is Carnival's record rather than mine.
Whoever holds a domain in that position has no need to build an attack. Pointing it at a monetization service turns leftover traffic into revenue, and the visitor is handed onward from there.
Chasing advertisers one at a time achieves nothing. Every one I reported was removed, and every removal was followed by a replacement, because the domain is the asset and the advertiser is inventory.
The breach question, answered directly
Carnival disclosed a data breach in April 2026, and this infrastructure predates it. Anyone reading the timeline will notice that, so I checked rather than leave it hanging.
I found no evidence connecting the two and I assert no connection. The domain takeover in November 2024 and the cloaker in March 2026 both predate the April breach detection.
What I documented is generic, mass-scale ad-monetization abuse. A targeted intrusion has a different profile. These are two separate events.
Reporting it, and what worked
I reported it the ordinary way first, to everyone who could act on a piece of it. The email provider, the registrars and hosts of the payload domains, Cloudflare, the browser blocklists, IC3 and the FTC.
Reaching Carnival took longer. The abuse and security inboxes I wrote to on June 15th went unanswered. A staff member confirmed the issue had been flagged internally, and no further response followed.
Phone routes ended at general customer service. The hotline stood up for Carnival's earlier breach did not cover this report either.
Meanwhile the parking service removed individual advertisers, each one after I supplied evidence for it. The entry domain stayed live throughout and the email link kept routing into it.
A certified letter is what worked. On August 5th I sent a formal notice with return receipt to Carnival's General Counsel, Global CISO and registered agent.
The Deputy General Counsel engaged on August 13th and moved it to Global Cybersecurity Services. I delivered the full technical package on August 25th, holding the live malware samples back until they asked for them.
Carnival re-acquired the domain on August 26th, moved it onto their own DNS and pointed it at a real Carnival page. I ran a final multi-vantage check on August 27th and confirmed the routing was dead everywhere.
From certified letter to resolved was 22 days. Reaching the letter took seven weeks.
What I take from it
Domain hygiene is a security control. A single expired promo domain, still linked from live authenticated mail, turned a trusted brand channel into a malware delivery system.
Audit the domains your live mail links to against the domains you still own. That is a lifecycle control rather than a mail control, and no amount of email authentication substitutes for it.
Put every brand and marketing domain on auto-renew with a registry lock. Then go looking for the ones that quietly lapsed years ago.
One vantage point tells you what that vantage point sees. Anything built to cloak is built to pass exactly that test.
One last note on the reporting path, for researchers rather than for Carnival. The technical work took days. Reaching a desk that owned the problem took seven weeks and a certified letter, and that is the part worth planning for at any large organization.
Indicators of compromise
Hashes are SHA-256. The two .msix samples are on MalwareBazaar and all four are on ThreatFox.
8a9006cfaee227415eeef0d645183ca423c80b9a8181e35a57bec71468e72daa PrivacyKeeper.msix (148,652,394 bytes)
d66895d8da6d5eb1d8658647c80f66dce40236c06bb600f1c62a44a657f923b3 SafeWatch.msix (147,724,942 bytes)
b8f0c82894032766293b7f6e6feaf287a366edd4886b8e665c41bc5103d512ce PrivacyKeeper.appinstaller
8de1357454488bd0702f0f22e912b412af41d814dffdc7c76f416d75d7dc1dc6 SecuredWeb.appinstallerMalwareBazaar holds the two packages: PrivacyKeeper.msix and SafeWatch.msix. The two .appinstaller manifests are XML rather than binaries, so MalwareBazaar dropped them in processing and only their ThreatFox entries remain. That is why the manifest block is quoted in full above: for those two, the quoted XML is the evidence.
Delivery and update hosts, defanged:
get.privacykeepersite[.]com get.gosecuredweb[.]com file.ngapp[.]online
file.swatchapp[.]online cinga.ngapp[.]online spot.swatchapp[.]online
cint2.scrtgrd[.]online show.ngrapp[.]online spons.lkguard[.]online
cinnabon.pkeeper[.]net lpic.prvbrws[.]com guardianrole[.]online
securi-guard-browser[.]com extensionsnewtab[.]com pkeepers[.]online
pbrowsingapp[.]online cablegaurdian[.]online safe-guard[.]onlineRedirect layer: tratobid[.]com and jubaaa[.]com. Anti-bot and beacon layer: ob.sd559908.js.brandsmat[.]com, euob.northwavepoint[.]com, ob.buzzfighter[.]com, assets.webfervor[.]com and kineticharbor[.]com.
Domains rotate. The delivery-kit path grammar has not, which makes it the more durable signature.
/lps/security-check/
/impression?c=<campaign>&ext_name=<Brand>&cid=<id>
/downloadproxy/<campaign>/<clickid>/?ext_name=<Brand>&cid=<id>&tag=<cid>_<YYYY-MM-DD>&file=true
/event/download /event/download_button_clicked /event/download_xhr_completed
/event/pageload /event/incognito_status
appData=fr2TvjWVEr+MejYst84xw...That appData prefix is a fixed 21 characters and appears unchanged across unrelated brand domains.
Evidence and technical detail
The full findings report documents the de-cloaked redirect chain, every payload variant, the cloaking and anti-analysis techniques, the complete indicators of compromise with hashes, and the disclosure record.
- Whitepaper: Carnival-cclpromos-Security-Findings.pdf (2.9 MB)
SHA-256 BED672E46273F7AFF10E75310600AA4B1C7F28A795A16DC15CDB356669BF3D24 - Evidence package, screenshots and sanitized HAR captures: Carnival-cclpromos-Findings-Evidence.zip (6.9 MB)
SHA-256 F995FCCC77E40EA63E3A842E22796C0FEC07D548E8F05A471EEE884C3C53C3C6 - Checksums, including the sealed priority hash from June 25th, 2026: Carnival-cclpromos-Findings-Evidence.sha256.txt
Check a download against the hash above before opening it.
sha256sum Carnival-cclpromos-Security-Findings.pdf
Get-FileHash Carnival-cclpromos-Security-Findings.pdf -Algorithm SHA256The first line is Linux and macOS, the second is PowerShell.
For context on the technique, the FBI's IC3 published PSA I-061826-PSA on June 18th, 2026, warning about criminals redirecting users through malicious traffic distribution systems. I make no claim that my report prompted it. A federal advisory takes far longer than a few days to prepare, so I note it only as independent confirmation that this attack class was active and recognized in the same window.
All malicious domains in this report are defanged. The original findings were documented and cryptographically hashed on June 25th, 2026, and that timestamp hash is published with the evidence package for verification.
This report is the original work of Tuxxin LLC, published under Creative Commons Attribution-NoDerivatives 4.0. Media and researchers may quote and republish it with attribution to Daniel Jones, Tuxxin LLC. For the full evidence package or coordinated disclosure: contact@tuxxin.com.