Veilcat

GitHub Pages Hijacking

4 min read

How I Found My Old Domain Hosting Someone Else’s GitHub Pages Site

Discovery & Recon

While reviewing my growing collection of domain names, I realized I had forgotten to remove DNS records for a domain I once used with GitHub Pages. Out of curiosity, I visited the domain — and to my surprise, it was still serving a website… but not mine.

GitHub documents this kind of issue.

To investigate safely, I spun up a VM, took a “clean” snapshot, connected to a VPN, and opened the site in a private Firefox window.

Ummmm…

The page was filled with content promoting UNIKBET and bata[.]com — sketchy.

Using Wappalyzer, I took a look at the stack:

Google Translate detected Indonesian, and I saw prices in Rupiah (Rp), the currency of Indonesia:

The page was 4,223 lines long, with massive inline scripts. Manually auditing the source wasn’t feasible, but the setup screamed “affiliate spam site.”

So… How Is This Site Still Online?

To understand the hosting setup, I ran:

curl https://<domain>/ -i

…and also ran a scan on urlscan.io to archive and analyze the content.

  • https://<username>.github.io/ returned a 404.
  • The GitHub username I used previously is available again.
  • I couldn’t find any public repo using my domain in a CNAME file.

This suggests the site is being served from a GitHub repo that has my domain set as a custom domain, but which isn’t publicly visible. It’s possible the repo belongs to:

  • An organization account (which can host Pages from private repos), or
  • A previously created and now orphaned GitHub account.

I confirmed that my DNS was still configured to point www.<domain> to <username>.github.io:

Using dig, I could see GitHub’s IPs were still in place:

`dig +short 

185.199.109.153
185.199.110.153
185.199.111.153
185.199.108.153`

So to summarize:

  • https://<domain>/ returns 200, served by GitHub
  • curl https://www.<domain>/ = 301 redirect
  • https://<username>.github.io/ = 404

I began to wonder — is this a case of mass-scale squatting? Was this repo preconfigured to serve content on random custom domains in hopes that someone forgot to clean up their records?

Historical Lookups & Dead Ends

I checked the Wayback Machine for past snapshots, but was only able to find a Uniregistry landing page in 2018 and 2019 — long before I purchased the domain.

I also looked up the domain on crt.sh, which only showed SSL certs issued around the time I had originally configured GitHub Pages. No new certs appeared that would suggest a third party had recently configured HTTPS for the domain.

Testing the Theory: Can I Reclaim It?

I decided to test whether I could re-claim the domain by setting up a new GitHub Pages site. Here’s the basic approach:

  1. Created a new GitHub account
  2. Made a random repo
  3. Added a CNAME file with the domain name
  4. Added a basic index.html

I continued seeing the current website, so I tried adding the custom domain to the Pages deployment. Still, this wasn’t enough — since another repo was already using the domain, GitHub wouldn’t let me add it without verifying ownership.

GitHub now enforces domain verification when there’s a conflict. It prompted me to add a TXT record to prove I controlled the domain.

My test index.html was now being served!

My Temp Account Suspension Woes

During the verification process, my new test account got flagged and couldn’t add the custom domain. I had to switch to an established GitHub account that appeared more trustworthy…GitHub probably didn’t appreciate the email alias, hopping off and on VPN, and trying to overtake a custom domain on a newly created account…

Still, out of curiosity I decided to take the opportunity to learn more about GitHub’s abuse detection and common privacy resources, which you can read about in GitHub Privacy

Graph View

Backlinks