July 8, 2026 - 8 min read

By PhishClean Research Team

GitBait: When a Trusted GitHub URL Hosts a Fake Bank Login

Attackers behind a campaign researchers named "GitBait" did not register a shady domain for their fake banking pages. They hosted them on GitHub Pages - so the URL carried GitHub's reputation while the page quietly harvested logins and card numbers.

Reporting in mid-2026 described GitBait, a phishing operation that abused GitHub Pages to deliver fake banking portals - reportedly aimed at Mexico's financial sector - tricking victims into handing over login credentials, payment card details, and other sensitive information. The mechanics matter beyond any one region, because they show a pattern that is getting more common: don't buy a suspicious domain, borrow a trusted one.

Why hosting on a trusted platform works

A lot of phishing advice boils down to "check the domain." GitBait is built to survive that check. A page served from a github.io address inherits a few things attackers want for free: a valid HTTPS padlock, a domain millions of people recognize, and a platform reputation that blocklists are reluctant to flag wholesale. The malicious part is not the host - it is the specific page and the form on it.

This is bigger than GitHub

GitHub Pages is one example, but the same trick shows up across free hosting, cloud storage buckets, form builders, and app-preview domains. Attackers reach for whatever platform is trusted, free, fast to set up, and slow to take down. The lesson is not "avoid GitHub" - it is that the reputation of a hosting provider tells you almost nothing about the safety of a specific page it serves.

How to protect yourself

For anything involving money or identity, navigate there yourself. Type your bank's known address or use a saved bookmark instead of following a link. Let your password manager decide whether to autofill - it is bound to the real domain, so if it refuses to fill your bank credentials on a github.io page, that silence is a warning. And treat any page asking for a full card number plus PIN plus a one-time code as suspicious by default, no matter how legitimate the host looks.

If you already entered details

Contact your bank through the number on the back of your card and tell them; they can watch for or block fraudulent transactions. Change the password for that account and anywhere you reused it, and turn on transaction alerts. If you entered a one-time code, assume the attacker tried to use it immediately - time matters, so call now rather than later.

How to actually read a subdomain

Trusted-host phishing survives the "check the domain" habit because most people read URLs left to right and stop at the first familiar word. The safer way is to read from the right. In an address like something.github.io, the part that determines who controls the content is something - a name any account holder can pick for free. The platform on the right vouches only for the infrastructure, not for the person publishing on it.

• Find the registered domain: the last two or three labels before the first slash. That tells you which platform is serving the page.
• Everything to the left of it is chosen by whoever created the account or project - including your bank's name, which an attacker can type as easily as you can.
• If the registered domain is a hosting platform, a storage service, or a form builder, assume the page belongs to a random account holder until proven otherwise.
• Ignore the padlock as a trust signal. It confirms the connection is encrypted to that host, not that the host's tenant is honest.

This one reading habit defeats most trusted-host lures, because the mismatch - a bank brand living under someone else's account name - becomes visible the moment you look at the right end of the address.

Why these pages stay up longer than you would expect

Free hosting platforms process abuse reports at enormous scale, and takedown is inherently reactive: a page must be published, discovered, reported, and reviewed before it disappears. Attackers plan around that lag. Accounts cost nothing, so a campaign can publish many near-identical pages and rotate to the next one as each is removed. Blocklists face the same asymmetry - flagging an entire trusted platform would break legitimate sites, so blocking has to happen page by page, which is exactly the granularity attackers can outpace. None of this means reporting is pointless. If you find a phishing page on a hosting platform, report it through the platform's abuse channel - it shortens the window for the next victim - but do not assume a page is safe just because it has been up for a while.

A habit checklist for links that ask for money or identity

• Never authenticate from an unsolicited link. Open a new tab and type the bank's address or use your bookmark, every time.
• Slow down on urgency. "Your account will be blocked today" exists to stop you from doing the previous step.
• Cross-check the ask. If a message claims a problem with your account, the same alert should exist inside the app or site you reach directly. If it is not there, the message was the attack.
• Verify before you type, not after. Once credentials or card details are submitted, you are into damage control - see what to do if you clicked a phishing link for that path.
• Learn the broader patterns. Trusted-host abuse is one of several recurring shapes covered in our overview of phishing attacks.

Where the browser fits in

Trusted-host phishing is precisely where reputation-only tools struggle, because the reputation being checked belongs to the host, not the page. PhishClean analyzes the page itself in the browser - the login form, the fields it collects, the brand it imitates, and the mismatch between "this looks like a bank" and "this is served from an unrelated project host" - so a fake bank on a friendly-looking domain still gets flagged.

Last updated: 13 August 2026