Link Shield

For part 1 in this series we are going to take a look at a fake phishing login page.

https://gixon[.]sbs/_wildcard_.gixon[.]sbs/views/

Even before looking at the page, the URL gives away several things that deserve immediate scrutiny.

Captured phishing page impersonating Paperless Post on gixon.sbs

Screenshot of the captured page. It presents itself like a Paperless Post invitation flow while pushing the visitor toward mailbox-provider login buttons.

1. The domain does not match the brand being presented

The captured page presents itself like an online invitation flow connected to Paperless Post. But the URL is on gixon.sbs, not on a Paperless Post-controlled domain.

That is the first and most important check in many phishing investigations:

What brand is the page claiming to be?
What domain is the page actually on?
Are those two things supposed to belong together?

In this case, they do not.

Paperless Post’s own help center says legitimate invitation links should be hosted on official Paperless Post domains such as paperlesspost.com, pp.events, or links.paperlesspost.com, and that real invitations do not require users to log in just to view a card. That means a login gate on gixon.sbs is already outside the expected behavior for the brand being impersonated.

2. The path contains a wildcard artifact

The path here is especially telling:

/_wildcard_.gixon.sbs/views/

That is not a normal, user-facing path for a legitimate invitation platform. It looks more like an internal hosting or routing artifact exposed in the final phishing URL.

When you see strings like these, they often point to one of a few patterns:

A phishing kit deployed behind wildcard host routing
A shared hosting or reverse-proxy setup exposing internal routing names
A cloned template dropped into a generic “views” folder
A campaign that was assembled quickly and never normalized into a polished public path

That does not prove maliciousness by itself, but it is exactly the kind of infrastructure clue defenders should log. Clean consumer-facing apps rarely leak wildcard routing details into public paths. Kits and rushed abuse infrastructure do.

3. The page asks for mailbox credentials, not invitation details

The captured page shows a fake invitation experience with multiple buttons:

This is a classic credential-harvest pattern.

A legitimate invitation page should let a recipient view event details, RSVP, or maybe confirm identity through the service that sent the invitation. It should not force the user to choose a generic mailbox provider and enter email credentials just to see a card.

That design choice reveals the real target. The attacker is not trying to verify a recipient. They are trying to steal access to the victim’s email account.

4. It mixes brands in a sloppy way

Another strong indicator in the captured page is brand blending. The screen uses Paperless Post branding, but the supporting copy also references Greenvelope.

That kind of cross-brand contamination happens a lot in phishing kits. Operators recycle templates, screenshots, logos, and text from previous campaigns. The result is often a page that looks convincing at a glance but becomes inconsistent when inspected carefully.

Watch for combinations like:

One brand in the logo and another in the body text
One company in the copyright line and another in the CTA
Mixed product names in headings, buttons, or form labels
Asset filenames or alt text that refer to unrelated brands

Brand inconsistency is one of the fastest ways to distinguish a polished real product from a cloned lure.

5. The page is optimized for compliance, not trust

The layout is built to reduce hesitation:

A blurred invitation-themed background to create context
A centered modal to focus attention
Immediate provider choices so the victim can act quickly
Familiar mailbox brands to lower skepticism

This is not unusual in credential phishing. The page does not need to be perfect. It only needs to feel familiar long enough for a user to type a password.

That is an important reviewing principle: phishing pages often optimize for momentum, not accuracy. If the page is visually persuasive but structurally inconsistent, trust the structure.

6. The live site currently presents a bot challenge

At the time of review, the live URL returns a “Just a moment…” challenge rather than a fully open page. That matters because phishing operators increasingly use interstitials, bot gating, referer rules, or traffic filtering to slow down scanners and researchers.

In practice, that means:

The page a human sees may differ from what a crawler sees
Some kits only fully render for selected user agents, geographies, or referrers
Screenshot evidence becomes valuable when live content changes or hides itself

A challenge page alone is not proof of phishing. Plenty of legitimate sites use them. But when a suspicious domain, fake brand flow, and credential-harvest UX all exist around the same URL, anti-analysis behavior becomes part of the pattern.

7. The TLD is not the verdict, but it is still context

The .sbs TLD does not automatically make a site malicious but it does raise some red flags. Always be weary of lesser known “new TLDs”.

But TLD choice still belongs in the review because attackers often prefer:

Cheap registrations
Fast domain turnover
Registrars or hosting combinations that reduce friction
Naming patterns that can be replaced quickly after takedown

So the right move is not to score .sbs as malicious by default. The right move is to treat it as supporting context when it appears beside brand mismatch, wildcard artifacts, and a fake mailbox login prompt.

8. What to inspect next if you are triaging this technically

If this URL landed in a trust and safety queue, I would want the following evidence immediately:

Full redirect chain, including any intermediate shorteners or tracker domains.
WHOIS and DNS timing, especially registration date, name server reuse, and other domains on shared infrastructure.
TLS certificate metadata, including SANs and issuance timing.
Final HTML, form actions, JavaScript fetch targets, and any exfil endpoints.
Screenshot capture from multiple user agents or geographies.
Historical copies of the page title, favicon, and body text.
Whether the page only renders after email-specific parameters are passed in the URL.

This is how you move from “looks suspicious” to “has structured evidence of credential theft.”

9. Why this URL looks like phishing

When you put the signals together, the case gets strong very quickly:

The page claims a trusted invitation brand, but the domain is unrelated.
The path exposes what looks like wildcard-routing or kit-hosting structure.
The user is pushed into generic mailbox-provider login flows.
The page mixes Paperless Post and Greenvelope references.
The live URL appears to use gating that can complicate automated review.

Each signal matters. Together they form a consistent phishing story.

Final takeaway

One of the biggest risks is how easily an end user can focus on the familiar branding and login flow while missing the URL, wildcard subdomain, and other warning signs. What matters more is understanding why the page feels credible enough for someone to trust it before they stop to inspect where the link really leads.

The value is in the evidence:

brand-domain mismatch
suspicious path structure
credential-harvest intent
mixed-brand artifacts
evasive delivery behavior

That is exactly the kind of review workflow Link Shield is designed to automate. Instead of relying on someone to manually inspect every suspicious link, Link Shield can help resolve the URL, inspect the page, capture structural signals, and turn them into a decision your team can act on quickly. If you want to try that workflow in your own product, sign up for Link Shield.

Start with the URL