From Hosting Code to Hosting Scams: Hardening GitHub Repositories After the GitBait Campaign

What the GitBait campaign reportedly did

The public reporting in one sentence

The public write-up I found says attackers used GitHub Pages to host phishing content aimed at financial institutions.

That is the part I am treating as confirmed from the reporting. Anything beyond that needs a primary source before I would state it as fact.

Why financial institutions were a useful target

Financial institutions are useful phishing targets because attackers do not need to fool everyone. They only need a few users who already expect:

• links to internal or vendor portals
• password resets and MFA prompts
• document sharing and wire or payment approvals
• “security notices” that ask them to sign in again

A GitHub Pages URL fits that story better than you might expect. It looks like normal hosted web content, it has TLS, and it sits on a domain family many developers already trust. That is enough to lower suspicion long before the victim reaches the fake form.

Why GitHub Pages is an attractive phishing platform

Trust signals that attackers try to borrow

The main advantage is not technical sophistication. It is borrowed legitimacy.

GitHub Pages gives an attacker several things that help a lure get past the first glance:

• a well-known hosting brand
• HTTPS by default
• stable uptime and fast delivery
• a domain family that many users and filters have seen before
• a story that looks “developer-ish” instead of obviously criminal

None of those are security controls. They are trust signals. Attackers do not need to break them. They only need to use them.

How a legitimate developer platform changes user suspicion

This is the part defenders sometimes underestimate. A legitimate developer platform changes the victim’s mental model.

A user who sees a random domain may hesitate. A user who sees content on a reputable developer platform may think:

• “This is probably a vendor page.”
• “This must be a temporary project site.”
• “It has HTTPS, so it is fine.”
• “The URL is ugly, but that is normal for hosted pages.”

That is why platform trust is not a control. It is a usability feature that can be repurposed for abuse.

What is confirmed, and what is still inference

Facts stated by the source reporting

From the reporting I was given, I would treat these as the safe facts:

• the campaign is being described as “GitBait”
• GitHub Pages was used as the hosting platform
• the target set included financial institutions
• the activity was phishing-related

That is enough to matter operationally. It is also enough to justify hardening the GitHub side of a developer workflow.

Claims that need caution until better primary detail is available

I would be careful about these until a primary write-up or vendor advisory confirms them:

• whether the attackers took over existing repositories or used fresh bait repos
• whether custom domains were involved
• whether the campaign depended on GitHub Pages subdomains only
• how credentials were collected
• whether redirects, embedded forms, or client-side scripts were used
• how long the campaign persisted or how many institutions were affected

Those details are plausible, but plausible is not confirmed.

How repository and Pages abuse usually works

Repository takeover versus freshly created bait repos

There are two broad abuse patterns.

1. Take over something already trusted

   • compromise a repository
   • change the published content
   • reuse an existing repo name, history, or contributor graph

2. Create a fresh bait repo

   • publish a site that imitates a bank, SaaS vendor, or internal portal
   • point a link at the new GitHub Pages site
   • rotate it if it gets reported

The second pattern is easier. The first is more powerful because it can inherit trust, traffic, or domain history.

Content hosting, redirects, and credential collection paths

Phishing content on a static host usually does not need much code.

Common patterns are:

• a login form that posts to an attacker-controlled endpoint
• a page that relays input to a script behind the scenes
• a redirect chain that moves the user from a benign-looking page to the real lure
• a page that harvests credentials and MFA tokens through a fake “re-authenticate” prompt

I am not saying GitBait used all of those. I am saying these are the common mechanics defenders should test for.

Where developer teams accidentally increase exposure

Developer teams often make the abuse path easier without noticing:

• they publish public content from the same org that handles production code
• they reuse the same brand assets across projects
• they leave stale Pages sites online after a project ends
• they keep old collaborators or deploy tokens alive
• they allow multiple branches or workflows to publish without review

That is how a harmless repo becomes a trusted delivery surface for something else.

The security mistakes that make abuse easier

Overly broad write access to repositories and environments

If too many people can push to the branch that publishes Pages, the site is one credential theft away from becoming a lure.

The problem is not only malicious insiders. It is also:

• compromised developer accounts
• stolen personal access tokens
• reused OAuth grants
• CI credentials that were never rotated

If write access is broad, publication is broad too.

Weak branch protection and unchecked publishing workflows

A lot of Pages abuse becomes possible when deployment happens from an unprotected branch with no review gate.

That usually means:

• direct pushes to main
• no required pull request review
• no status checks
• no review of workflow file changes
• no separation between source content and deploy permissions

If an attacker can change both the content and the workflow, they can often make the site say whatever they want.

Stale collaborators, tokens, and automation credentials

Old access is one of the easiest ways in.

The usual leftovers are:

• former contractors still listed as collaborators
• personal access tokens with more scope than they need
• deploy keys that were never disabled
• automation secrets that are still valid long after the project changed

A Pages site does not need many privileges. If your repo still has broad, stale access, the site becomes easier to abuse than it should be.

How to harden a GitHub repository before it becomes a lure

Restrict who can publish to Pages and protected branches

My default position is simple: only a small set of maintainers should be able to change what gets published.

That means:

• protect the default branch
• require pull requests for content changes
• restrict who can approve changes to Pages-related files
• keep Pages publishing on a narrow, audited path

If a repo is public and brand-adjacent, I would treat its publishing path like a production deployment path.

Require reviews, signed commits, and environment protection

A good hardening baseline is:

• required review before merge
• required status checks
• signed commits for maintainers who can publish
• environment protection for the deploy step
• no direct pushes to the publishing branch

For GitHub Actions, the key idea is to stop a workflow edit from becoming an instant deployment.

Remove unused secrets, tokens, and stale integrations

If something can still publish, it can still be abused.

I would audit and remove:

• old deploy tokens
• unused GitHub Apps
• stale PATs
• webhook secrets that no longer have a consumer
• service accounts no longer tied to an owner

The quickest way to reduce exposure is usually removing credentials that should not exist anymore.

Separate source content from deploy credentials

Do not let the same person or workflow both edit content and unlock deployment.

A better pattern is:

• content contributors open pull requests
• maintainers review and merge
• a protected environment publishes
• deployment credentials stay outside the repository history

That separation does not stop phishing by itself. It does make silent republishing much harder.

How to harden a GitHub Pages site specifically

Custom domain controls and DNS hygiene

If you use a custom domain, the DNS layer matters as much as the repo.

Check for:

• correct registrar lock and MFA
• access to DNS hosted at a small number of trusted accounts
• stale CNAME or A records pointing at old hosts
• subdomains that were never retired
• TXT records that prove ownership for the right services only

A compromised DNS panel can make a clean repo point at a dirty destination.

Content review for unexpected forms, scripts, and redirects

On a Pages site, the things I inspect first are boring and effective:

• new form elements
• new external action targets
• embedded JavaScript from unfamiliar origins
• meta refresh redirects
• short-lived URL shortening or redirect helper pages
• obfuscated code in otherwise static content

If a static site suddenly needs scripting, that deserves review.

Monitoring for unauthorized page changes and clone sites

I would monitor both the repo and the wider web:

• alert on Pages config changes
• alert on workflow file changes
• diff the published site against the last approved release
• watch for lookalike clone pages on other hosting providers
• track brand-domain registrations that resemble your org

The attack surface is not just your repository. It is the set of places a user might believe is yours.

Practical checks you can run today

Repository audit commands and settings to inspect

These are the first checks I would run in a repo that can publish public web content:

gh repo view OWNER/REPO --json name,defaultBranchRef,visibility,viewerPermission
gh api repos/OWNER/REPO/pages
gh api repos/OWNER/REPO/branches/BRANCH/protection
gh api repos/OWNER/REPO/collaborators?affiliation=direct --jq '.[].login'
git log --oneline --decorate --graph --all -- .github/workflows

What I am looking for:

• whether Pages is enabled at all
• which branch publishes
• whether the publishing branch is protected
• who has direct write access
• whether workflow changes have been reviewed recently

A small checklist for Pages and release workflows

Use this as a quick control list:

• default branch protected
• pull request reviews required
• status checks required before merge
• Pages publishing limited to a small group
• stale collaborators removed
• unused secrets deleted
• deploy workflow separated from content edits
• custom domain ownership confirmed
• DNS access limited and audited

What a suspicious diff or deploy should look like

These are the patterns I would treat as suspicious until proven otherwise:

If I saw any of those in a repo that publishes public content, I would stop and verify the change origin before merging.

Defensive lessons for teams outside finance

Why any trusted developer domain can be abused

This is not a finance-only lesson.

Any organization that publishes public GitHub content, docs, help pages, demo apps, or static marketing sites should assume that those pages can be reused in a lure. The attacker does not need your internal network. They only need your brand shape and a trusted host.

That applies to:

• SaaS vendors
• open-source projects
• consultancies
• startups
• internal platform teams

If your domain is trusted by users, it is a phishing asset if control is weak.

How to brief users without overclaiming the risk

Do not tell users “GitHub Pages links are safe” or “our pages are safe because they are on a reputable platform.”

That is too broad and too false.

A better message is:

• verify the exact domain before signing in
• use bookmarks for critical portals
• treat unexpected login prompts as suspicious even on trusted hosts
• report lookalike pages quickly
• never assume HTTPS means authenticity

That is honest, and it gives users something they can actually do.

Conclusion

The main position: platform trust is not a security control

My view is blunt: if a repository can publish public content, it should be treated as a potential phishing launchpad unless you harden it.

GitHub Pages is not the problem by itself. Weak ownership, broad write access, stale credentials, and unreviewed publishing are the problem. The platform only makes those mistakes easier to exploit.

If you run a repo that can put content on the internet, I would audit it the same way I audit a production release path:

• restrict who can publish
• review every change that affects public content
• remove stale access
• separate source edits from deploy rights
• monitor for unauthorized republishing and clone sites

That is the real defense. The domain name alone will not save you.