GitBait: Phishing the Mexican Financial Sector

Introduction

Trusted by millions of developers worldwide, GitHub is often the target of abuse and turned into an unlikely weapon in the hands of financially motivated threat actors; this represents a developing and increasingly well-documented trend. Researchers have previously identified cases in which GitHub’s infrastructure was exploited to distribute phishing pages, deliver stealer payloads, and host malicious content at scale, taking advantage of the platform’s trusted reputation, free HTTPS coverage, and ease of deployment. What this campaign demonstrates is that the tactic has matured: threat actors are now combining GitHub Pages hosting with serverless exfiltration backends and modular kit architectures to conduct large-scale, persistent operations that are significantly harder to detect and dismantle.

What sets this operation apart is its scale, persistence, and operational sophistication. Group-IB researchers identified a large-scale phishing campaign targeting at least 12 financial institutions in Mexico, active for approximately three years and built on a fully serverless architecture that abuses GitHub Pages for hosting and the SheetBest API for credential exfiltration — eliminating the need for any dedicated backend infrastructure. Historical tracking and infrastructure analysis indicate that this campaign, or variations of it, has demonstrated long-term persistence, reuse of components, and continuous operational maintenance throughout this period.

While the exact distribution mechanism has not been confirmed, victims are likely reached through common phishing delivery channels such as SMS, messaging apps, email, or social media platforms. In all cases, the victim receives a fraudulent URL that leads directly to a phishing page impersonating a trusted financial institution.

Group-IB has reported all phishing pages and domains identified from this research to GitHub.

Key discoveries

• Identified a modular phishing kit enabling threat actors to dynamically target at least 12 financial institutions operating in Mexico from a single, reusable infrastructure.
• GitHub commit analysis exposed multiple operator accounts with continuous activity spanning over a year, confirming a collaborative and actively maintained phishing operation.
• The phishing scheme harvests user credentials, payment card details, client identifiers, and passwords through a multi-stage flow that mimics legitimate banking authentication workflows.
• The operation abuses GitHub Pages as a distributed hosting platform, enabling rapid deployment and redundancy.
• Over +100 domains associated with the campaign have been identified, each hosting multiple phishing pages under different paths, reflecting a large-scale and highly distributed infrastructure.
• Credential harvesting is centralized through third-party services (SheetBest API), enabling a scalable, serverless data exfiltration model that stores stolen credentials directly into attacker-controlled Google Sheets in real-time.
• Phishing pages employ obfuscated, externally loaded JavaScript with randomized path structures, complicating static analysis and enabling payload rotation without modifying the phishing page itself.
• An alternative exfiltration method was also identified where credentials were sent in real time to a Telegram bot, demonstrating operational flexibility in the campaign’s backend infrastructure.

Who may find this blog interesting:

• Cybersecurity analysts and corporate security teams
• Malware analysts
• Threat intelligence specialists
• Cyber investigators
• Computer Emergency Response Teams (CERT)
• Law enforcement investigators
• Cyber police forces

Group-IB Threat Intelligence Portal: GitBait

Group-IB customers can access our Threat Intelligence portal for more information about GitBait and the phishing scheme described in this blog.

Phishing Campaign Overview

The analyzed infrastructure corresponds to a modular phishing kit that includes an internal campaign selector used by threat actors to generate institution-specific phishing pages. This selector is not intended for victims but functions as an operational interface that allows attackers to choose targeted institutions and distribute the corresponding fraudulent URLs. Its presence confirms a multi-target phishing infrastructure designed for reuse across multiple campaigns.

Notably, both the phishing kit panel and the impersonated landing pages are developed to support desktop and mobile screens, indicating a deliberate effort to maximize reach and improve the success rate of victim interaction across different devices.

The campaign is hosted across numerous independent GitHub Pages repositories rather than a single domain. Each repository contains duplicated phishing content deployed under different directory paths (e.g., /cancelacion/, /soporte/, /mb1/), reflecting an intentional strategy to distribute the infrastructure, evade takedowns, and rapidly redeploy cloned pages when individual repositories are removed.

The phishing operation primarily targets organizations within the banking and financial sector in Mexico, including both local and foreign institutions with operations in the country. Historical tracking suggests that this phishing infrastructure, or variations of it, has been active for over three years, demonstrating persistence, reuse of components, and a structured approach to large-scale financial phishing operations.

Impersonated Financial Institution Landing Pages

The analyzed domains host a modular phishing kit that includes multiple brand-specific landing pages designed to impersonate legitimate financial institutions operating in Mexico. The site structure allows attackers to select a target institution and redirect victims to tailored phishing pages that visually replicate the online presence of official banking or service portals.

Each landing page functions as a trust-building stage, presenting cloned branding, layout, and navigation elements intended to convince victims they are interacting with a legitimate institution before being redirected to credential harvesting forms.

Phishing Credential Harvesting Stage

Following the initial impersonation landing pages, victims are redirected to dedicated phishing pages designed to collect sensitive authentication and financial information. These pages replicate the visual identity and login workflows of legitimate online banking portals, prompting users to enter details such as usernames, customer IDs, passwords, and card information.

Further analysis confirms that the credential harvesting stage contains active input fields requesting sensitive information such as payment card details, client identifiers, and passwords. The structure includes multiple nested forms and generic submission identifiers — common characteristics of cloned phishing kits. This stage represents the final data capture point within a multi-brand phishing operation.

Credential Interception and Exfiltration via SheetBest API

The phishing pages employ a client-side JavaScript script that retrieves login form elements and attaches a submit event listener to intercept the normal submission process. By preventing the default browser behavior, the script captures the credentials entered by the victim before any legitimate request is made.

The collected values are serialized into JSON format and transmitted via a POST request to an external API endpoint — the SheetBest service — confirming active data exfiltration in real-time. After the transmission attempt, the script dynamically replaces the login interface with a verification screen, simulating a legitimate banking workflow to maintain user trust and reduce suspicion.

Figure 4: Script intercepts credentials and infiltrates them via SheetBest API endpoint.

Header analysis & data exfiltration

The phishing kit reuses a consistent HTML form structure across all impersonated institutions:

• Form ID: id=”contact-form”
• Element IDs: id=”registro” and id=”exito” (used for toggling the login vs. verification screen)
• Verification logic: registro.classList.remove(‘activo’); exito.classList.add(‘activo’); triggered post-submission

Network analysis confirms that the phishing form transmits victim credentials via POST requests to the SheetBest API endpoint, which stores the data directly into an attacker-controlled Google Sheet. This technique eliminates the need for a dedicated backend server and is commonly used in modern phishing kits to facilitate rapid deployment and credential collection at scale.

• e.preventDefault() combined with a fetch() call to an external API in a form submit listener
• Request Method: POST
• Request URL: https://api.sheetbest[.]com/sheets/f2958fbe-cdd7-4796-a4e4-19539d759a9f
• Remote Address: 159.89.254[.]93:443
• Allowed Methods: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, JSON body with numeric keys (“1”, “2”, “3”) mapping to credential field values

Network telemetry indicates that multiple phishing pages impersonating different financial institutions leverage this same data exfiltration mechanism. Although each phishing page uses a different SheetBest sheet identifier, all credential harvesting forms submit victim data through HTTP POST requests to the same backend API infrastructure, resolving to the IP address 159.89.254[.]93 over HTTPS.

The following SheetBest API endpoints were identified receiving credential submissions from phishing pages associated with this campaign:

• https://api.sheetbest[.]com/sheets/0e2a1336-e971-496f-9eb2-cd8dcd25565c
• https://api.sheetbest[.]com/sheets/db4a7782-bc66-4a99-875b-ede99744f3fe
• https://api.sheetbest[.]com/sheets/47edba58-31f7-41e6-af18-31c77046dee1
• https://api.sheetbest[.]com/sheets/f2958fbe-cdd7-4796-a4e4-19539d759a9f
• https://api.sheetbest[.]com/sheets/fe9f1e2d-16c9-4d92-9bdf-8425921ac073
• https://api.sheetbest[.]com/sheets/578ad828-fc67-4447-9182-197f92c1f302

The reuse of identical submission logic, API infrastructure, and request patterns across multiple phishing pages strongly suggests a centralized credential harvesting backend supporting multiple phishing templates and impersonated brands within the same campaign.

Phishing Infrastructure and Path Patterns

Regardless of the GitHub domain used, all phishing instances follow a consistent multi-stage structure. Victims are first redirected to a landing page impersonating the targeted institution, and then to a final path where credential harvesting occurs.

The following paths represent the primary entry points observed across the phishing infrastructure, including both user-facing lures (e.g., account cancellation or support themes) and internal panel routing paths:

The following paths correspond to the final credential harvesting endpoints, each associated with a specific institution impersonation template. The consistent path naming across deployments serves as a strong infrastructure fingerprint:

• /1023.html
• /index.html
• /login.html
• /h.html
• /159enlace.html
• /login.html
• /ba306.html
• /aztlog.html
• /159bb.html
• /Login.html

This modular path structure — separating luring, routing, and harvesting stages — enables scalable deployment and reuse of the same phishing kit across multiple financial brands with minimal modifications.

Obfuscated External Script Loading

The phishing pages load external JavaScript through highly obfuscated and randomized paths rather than embedding the logic directly in the HTML. This approach hides malicious functionality, complicates static analysis, and enables payload rotation without modifying the phishing page itself.

GitHub Repository Analysis

Analysis of a GitHub repository hosting phishing pages confirmed that credential harvesting is performed through the SheetBest service, and that the infrastructure is actively maintained by multiple contributors.

A review of the commit history revealed that the file responsible for form submissions was recently modified to rotate the SheetBest endpoint used for credential collection — a pattern also observed across multiple other domains associated with the campaign.

Repository metadata confirms an actively maintained operation:

• 66 commits indicating continuous development
• 3 contributors indicating collaborative activity
• Deployment method: Jekyll-based GitHub Pages workflow via GitHub Actions, enabling automated build and publication of phishing infrastructure

The phishing pages also all share an identical front-end technology stack:

• Bootstrap version: [email protected]
• Bootstrap CSS SRI hash: sha384-KK94CHFLLe+nY2dmCWGMq91rCGa5gtU4mk92HdvYe+M/SXH301p5ILy+dN9+nJOZ
• Bootstrap JS SRI hash: sha384-ENjdO4Dr2bkBIFxQpeoTz1HIcje39Wm4jDKdf19U8gI4ddQ3GYNS7NTKfAdVQSZe
• Google Fonts: Kanit (300, 400, 600, 700) and Play (400, 700)
• Custom stylesheet: css/style.css

Examples observed across multiple impersonated institutions:

• Institution A: src=”/Vm7LSL59GGpJ8EK-ew/atw1fpkSb6ai/b3o0AQ/EE4aPHI/MCy8″
• Institution B: src=”ZwiOgC/MDi0/czp/Ecr/GfAoqZgEZg8/OkENmtprk9ipVi/JRJeM1UD/GTZYSjh/gAQc”
• Institution C: src=”hxiGOzOB98/NZ/sLoDRpVx/JuaQJfDNbtO9/dzldXmhnIQk/L1EkIT/BjSBw”

The randomized path structure complicates signature-based detection and allows the attacker to rotate or replace the malicious payload without altering the phishing page itself, significantly reducing the likelihood of detection by automated security scanners.

Operator Accounts and Associated Email Addresses

Analysis of the commit history exposed multiple accounts involved in maintaining the phishing infrastructure, along with associated email addresses:

Notably, the accounts ce-soporte and soporte-s1 share the same email address (jejrvsbdb@gmail[.]com), indicating they are likely controlled by the same operator.

Commit history also confirms that templates impersonating additional financial institutions were present in earlier versions of the repository and subsequently removed, indicating that the campaign’s target scope has been dynamically adjusted over time.

Distribution Method

Analysis of the repository’s HTML source reveals two corroborating technical indicators that, taken together, identify the campaign’s likely distribution vector.

Figure 5: GitHub repository showing phishing HTML code with Open Graph tags for messaging app

Robots noindex/nofollow directive. The credential harvesting page includes <meta name=”robots” content=”noindex, nofollow”>, explicitly instructing search engine crawlers not to index or follow the page. This confirms the page was never intended to attract organic traffic; it is designed to be reached exclusively via a direct link delivered to the victim.

Crafted Open Graph metadata. The repository’s primary landing pages contain a full set of Open Graph tags (og:title, og:description, og:image, og:site_name), populated with content impersonating a legitimate banking portal. These tags serve no functional purpose in email campaigns or SEO-driven attacks. Their sole utility is to render rich link preview cards — displaying a trusted brand name, description, and logo thumbnail — when a URL is shared through messaging applications such as WhatsApp, Telegram, iMessage, or RCS-enabled SMS. This technique is specifically engineered to make the phishing URL appear completely legitimate before the victim ever taps it.

Alternative Exfiltration: Telegram Bot

For one of the targeted institutions, the campaign used a different exfiltration method from the SheetBest mechanism observed elsewhere. After users entered their credentials, the data was exfiltrated in real time to a Telegram bot using hardcoded token and chat ID values embedded directly in the phishing page’s JavaScript — a common technique in modern phishing kits to collect stolen information without maintaining dedicated backend infrastructure.

Subsequent analysis of the identified bot token and chat ID showed that they were no longer active at the time of analysis, suggesting the exfiltration channel had been disabled or abandoned. However, multiple domains impersonating the same institution’s brand remain active, indicating the campaign continues.

Figure 6: Hardcoded Telegram bot token and chat ID embedded in phishing JavaScript.

Conclusion

By hosting phishing content on GitHub Pages, the threat actor benefits from the inherent trust and HTTPS coverage that these domains carry, making it harder for both victims and automated security tools to flag the content as malicious. By routing stolen credentials through SheetBest rather than maintaining a dedicated command-and-control server, the actor eliminates a critical point of exposure, operating entirely within the boundaries of legitimate cloud services. This serverless approach significantly reduces the infrastructure footprint and complicates attribution efforts.

For the financial sector, this campaign illustrates a broader shift in the threat landscape: attackers no longer need sophisticated malware or complex infrastructure to conduct large-scale credential theft. The abuse of everyday cloud platforms lowers the barrier to entry while increasing operational effectiveness. Organizations that rely solely on traditional phishing detection methods — such as blocklists of known malicious domains — will find this type of infrastructure increasingly difficult to defend against, underscoring the need for behavioral detection, continuous monitoring of brand impersonation activity, and proactive intelligence sharing across the sector.

Recommendations

For financial institutions:

• Monitor GitHub Pages for brand abuse. Proactively search for GitHub Pages repositories impersonating your institution using naming patterns (e.g., [brand]-soporte, [brand]-cancelacion) and common phishing paths identified in this campaign. GitHub’s abuse reporting mechanism can be used to request removal of confirmed phishing repositories.
• Track third-party API usage for data exfiltration. Services such as SheetBest are increasingly abused to route stolen credentials without dedicated backend infrastructure. Network monitoring should flag unexpected outbound POST requests to api.sheetbest.com or similar spreadsheet-as-a-backend services originating from user-facing web sessions.
• Strengthen digital risk monitoring through services such as  Group-IB’s Digital Risk Protection platform, which can detect and dismantle phishing infrastructure impersonating your brand across platforms including free hosting services.
• Educate customers to recognize phishing indicators specific to this type of campaign: URLs hosted on github.io domains, unsolicited account cancellation or support requests, and any web form requesting card details or passwords outside of your official app or website.
• Implement behavioral detection rather than relying solely on domain blocklists. Given that this campaign abuses legitimate platforms with trusted reputations, signature-based detection alone is insufficient.
• Use layered defenses such as multi-factor authentication and real-time transaction alerts to protect clients even if credentials are compromised.
• Share threat intelligence and indicators of compromise with peers, CERTs, and regulators to accelerate coordinated response efforts.

For regulators and policymakers:

• Foster regional collaboration in Latin America to respond more effectively to cross-border phishing campaigns.
• Support awareness initiatives that empower citizens to spot and avoid phishing campaigns.
• Work with digital platforms to hold advertisers accountable, ensuring that phishing campaigns are swiftly taken down.

Group-IB Fraud Matrix

Indicators of Compromise (IOCs)

Network Indicators

• soporte-index25.github[.]io
• soporte-index09.github[.]io
• sntdr-soporte25.github[.]io
• sntdr-soporte25.github[.]io
• 07-soporte.github[.]io
• soporte2507.github[.]io
• soporte160625.github[.]io
• soporte250324.github[.]io
• soporte74.github[.]io
• soporte-bm1.github[.]io
• soporte-r5.github[.]io
• api.sheetbest.com
• api.sheetbest.com
• soporte0625.github[.]io
• soporte160625.github[.]io
• soporte200525.github[.]io
• soporte2650.github[.]io
• soporte-index09.github[.]io
• soporte-bn1.github[.]io
• soporte-r5.github[.]io
• fldsmdfr-94.github[.]io
• soporte2507.github[.]io
• soporte74.github[.]io
• soporte-b2.github[.]io
• soporte-index25.github[.]io
• soporte-index.github[.]io
• soporte-index.github[.]io
• soporte-c1.github[.]io
• soporte-b4.github[.]io
• sntndr25-soporte.github[.]io
• sntndr-soporte0825.github[.]io
• 0825-soporte.github[.]io
• 07-soporte.github[.]io
• soporte-07-25.github[.]io
• soporte-0725.github[.]io
• soporte250324.github[.]io
• fldsmdfr-94.github[.]io
• soporteyatencionf.github[.]io
• sntndr25-soporte.github[.]io
• sntndr-soporte0825.github[.]io
• 0725soporte.github[.]io
• soporte-07-25.github[.]io
• soporte-0725.github[.]io
• 0825-soporte.github[.]io
• 0725-soporte.github[.]io
• soporter03.github[.]io
• soporteyatencionf.github[.]io
• soporte-y-atencion.github[.]io
• soporte-b1.github[.]io
• respaldo94.github[.]io
• respaldo94.github[.]io
• soporte-index05.github[.]io
• 0725-soporte.github[.]io
• 0725soporte.github[.]io
• soporte0725-3.github[.]io
• soporte0725-3.github[.]io
• soporte0725.github[.]io
• soporte0725.github[.]io
• soporte0625.github[.]io
• soporte200525.github[.]io
• soporte74.github[.]io
• soporte74.github[.]io
• soporte-r5.github[.]io
• support-vh.github[.]io

DISCLAIMER: All technical information, including malware analysis, indicators of compromise and infrastructure details provided in this publication, is shared solely for defensive cybersecurity and research purposes. Group-IB does not endorse or permit any unauthorized or offensive use of the information contained herein. The data and conclusions represent Group-IB’s analytical assessment based on available evidence and are intended to help organizations detect, prevent, and respond to cyber threats.

Group-IB expressly disclaims liability for any misuse of the information provided. Organizations and readers are encouraged to apply this intelligence responsibly and in compliance with all applicable laws and regulations.

This blog may reference legitimate third-party services such as Telegram and others, solely to illustrate cases where threat actors have abused or misused these platforms.

This material is provided for informational purposes, prepared by Group-IB as part of its own analytical investigation, and reflects recently identified threat activity.

All trademarks referenced herein are the property of their respective owners and are used solely for informational purposes, without any implication of affiliation or sponsorship.