Serverless Phishing Kit on GitHub: A UAE Banking Threat

GitHub is now a distribution channel for phishing infrastructure, not just code. Kits originally built to target Mexican and Latin American banks get recycled against Gulf banking brands with nothing more than a swapped logo and a new target list, because the page templates are generic and the hosting is free. The part that matters for UAE and GCC banks is not the specific kit. It is what the delivery method exposes about how most secure email gateways still decide what to block.

How a serverless phishing kit gets built and hosted

Most of these kits start as a clone of the real login page: an attacker pulls the HTML, CSS and client-side JavaScript of a bank's actual portal, strips out anything that would call the real backend, and wires the form submission to a webhook instead. That webhook is often a Telegram bot API endpoint, a Discord webhook, or a small serverless function on the same platform hosting the page. There is no attacker-controlled server for defenders to fingerprint by IP address or WHOIS record, because there is no server at all.

The kit gets pushed to a public repository and served through GitHub Pages (a project's gh-pages branch), or the raw file is pulled through raw.githubusercontent.com inside a short redirect chain that starts on a compromised WordPress site or a malicious ad. If GitHub disables the repository, the operator forks it, changes the account name, and republishes within minutes. Abuse reporting on any large platform runs on a queue, and the turnaround is usually measured in hours to a few days. For a campaign that only needs to run for a weekend to harvest a few hundred credentials, that is enough runway.

Two kit families, and only one of them cares about your MFA

Static harvesters do exactly what the name suggests: clone the page, capture whatever is typed, forward it, redirect the victim to the real site or an error page so nothing looks obviously wrong. Any second factor defeats these, because the attacker only ever gets a password.

Reverse-proxy kits are a different problem. Tools in the Evilginx lineage, along with commodity kits sold as phishing-as-a-service such as Tycoon 2FA and EvilProxy, sit between the victim and the real identity provider and relay every request in both directions. The victim is logging into the actual bank, actual Microsoft 365 tenant, or actual webmail portal in real time, through the attacker's proxy. When the login completes, including the one-time code or push approval, the proxy captures the session token the identity provider just issued. The attacker replays that token and is authenticated without ever knowing the password or the code. This is why one-time codes and push notifications, useful as they are against credential stuffing, do not stop a well-run reverse-proxy campaign. Only a factor bound to the origin, such as a FIDO2 or WebAuthn passkey, blocks it, because the browser will not hand a signed assertion to a domain that is not the one the credential was registered against.

Why domain reputation stops working here

Secure email gateways lean heavily on domain age, categorisation databases and sender reputation to decide whether a link is safe. github.io, pages.dev, vercel.app and similar domains score well on all three, because millions of legitimate portfolios, documentation sites and staging deployments live there. Blocking those domains outright breaks real developer workflows, which is exactly the false-positive complaint that gets a rule quietly disabled after a week.

The control that actually holds up is time-of-click detonation: rendering the destination page in a sandbox at the moment someone clicks, not just checking the domain's history when the email first arrives. A link that was clean at delivery and became a credential harvester six hours later, which is a common pattern with kits redeployed after takedown, only gets caught by re-checking the click, not the message. This is the gap between email security products that scan attachments and links once and those built around continuous URL protection.

Why GCC and UAE banks keep showing up as targets

The kit economy is commodity. A working reverse-proxy phishing kit costs little and gets resold or leaked within weeks of release, and retargeting one at a new brand is a matter of swapping a logo and a domain list, not writing new code. GCC banking brands are attractive targets because the payout per successful compromise is high: corporate banking portals and business email compromise that follows a credential theft can lead directly to fraudulent wire instructions, and correspondent banking relationships raise the value of a single compromised mailbox well beyond what a retail account is worth. When an incident does land at a bank under CBUAE supervision, the reporting and remediation obligations turn what might otherwise be a contained fraud attempt into a formal regulatory event, which is the detail that gets a CISO's attention faster than the phishing kit itself does. The CBUAE cybersecurity expectations are worth reading with this specific scenario in mind, because they assume exactly this kind of fast-moving, low-cost attack chain.

What actually reduces exposure

• Move email security past delivery-time domain checks and onto time-of-click detonation, ideally through a gateway such as Mimecast, so a link that turns malicious after the message lands still gets caught when someone clicks it.
• Put FIDO2 passkeys or hardware security keys in front of anyone with wire-approval or privileged access. It is worth reading why common MFA setups keep failing against exactly this style of attack before assuming OTP or push approval is sufficient.
• Use brand and threat monitoring, such as CloudSEK, that watches source-control platforms and paste sites for forked kits impersonating the bank's login pages, not just typosquat domain registrations.
• Run phishing simulations built on current reverse-proxy kits instead of static five-year-old templates, so the exercise tests what staff will actually face, not what they faced two years ago.
• Treat this as a sector problem rather than a one-off incident specific to whichever brand got cloned this month; the kit and the target list are both disposable and get reused against the next bank within weeks.