What Happened When I Leaked My Server Password on GitHub.com

Craig Hays
Jun 10 · 7 min read

I deployed a honeypot and ‘accidentally’ leaked a valid SSH username and password into a GitHub repository. This is what happened over the next 24 hours.

Image for post
Image for post
Photo by Arwin Neil Baichoo on Unsplash

Searching for juicy information in GitHub repositories is nothing new. In the past, I’ve written about mining GitHub for sensitive information and contributed to open source projects that help to automate this process. Having used this technique as an ethical hacker, I was curious to see what it looks like when criminals do it for real with malicious intent.

The Experiment

In order to test this hypothesis I needed two things:

  1. Bait — A code repository on GitHub.com with a valid username and password for a server
  2. A honeypot — an internet-accessible server for criminals to access with the ‘leaked’ credentials

Deploying the Honeypot

If you’re looking to replicate my test, I used these two articles as setup guides:

Finally, I created a fake user within Cowrie with an uncommon username and a secure password. The reason for this was to prevent false positives from brute force attacks and to confirm that any logins definitely came from people who took the bait.

Leaving the Bait

The Result

Expecting not to see any activity with my ‘leaked’ username and password for at least a few days, I logged off and decided to check in again the next day. I was surprised to find that the first unauthorised login to my honeypot happened just 34 minutes after I leaked the login credentials. Over the next 24 hours, 6 different IP addresses connected to the honeypot a total of 9 times and performed activities ranging from harmless, curious, manual exploration to sophisticated malware injection.

(Disclaimer — I’ve left the client IP addresses visible but that doesn’t mean the people behind that IP address are responsible for the activities. Viruses and botnets are widespread. Insecure configurations allow criminals to create jump boxes. Everyone is going through unlinked proxies. If you spot your own IP address and you actually did this — you need to improve your operational security. I’m still assuming that all of these IP addresses were innocent victims of malware themselves.)

Unauthorised User #1

Image for post
Image for post
A curious but harmless GitHub user poking around inside my server

The first unauthorised user logged in and had a look around, then logged off without doing anything further, never to be seen again. Nothing malicious here, just someone curious enough to try out GitHub dorks and see if they work. As they now know, they often do. While many of them are real, some of them are honeypots.

Unauthorised User #2

Unauthorised User #3

The first thing they did was log in and unset the users HISTFILE, a standard first move of malicious attackers. The HISTFILE points to the file that stores the list of commands that you’ve entered. Unsetting it prevents the server from logging submitted commands. Once the attacker managed to type it correctly, their history was ‘no longer being stored’. Then they tried to switch from the deployButton user to the root user to gain full administrative access.

Image for post
Image for post
Malicious user first turns off command logging, then tries to gain root access

When that failed, they then opened up a new SSH connection and tried to log in as root with the deployButton user’s password. This also failed here but often works on real systems.

Image for post
Image for post

Going back to the original user session, they then downloaded some malware directly from a webserver running on their own IP address and tried to run it through Perl. After receiving a fake confirmation message showing that their malware was installed, they deleted all of the server logs and cleared their session history from memory before logging off.

Image for post
Image for post

I haven’t reviewed the malware in detail but from a skim through it’s a botnet client written in Perl that communicates back to the command and control server, 62.210.119.142 using IRC.

Interestingly, that IP address routes back to hxxps://eleethub.com/ which claims to be a community of ‘crypto & security enthusiasts’. I’ll explore this and the malware in more detail later on as this ‘community’ is also running the IRC network that drives the botnet.

Image for post
Image for post
Possible malware gang searching GitHub for leaked passwords

Unauthorised User #4

Image for post
Image for post

Next, they logged in and started manually running commands to further explore the system, checking who else is logged in and what was in the root of the file system before leaving. It’s plausible that they detected that they were inside a honeypot and dropped off before exposing their real attack method, but I’ll probably never know.

Image for post
Image for post

Unauthorised User #5

Image for post
Image for post

Nothing new or particularly interesting here.

Unauthorised User #6

Image for post
Image for post
get webpage and get webpage and get webpage and get…

The malware set up an infinite loop where every cycle it would attempt to download the oann.com homepage hundreds of times. For some reason, they used both hxxps://t.co/pWqf41e3no?amp=1 which is a short URL for http://www.oann.com, and the full URL in alternating requests.

When the first attack was blocked by Cowrie, they logged in a few minutes later and tried the exact same attack again before giving up.

Github Leaked Password Statistics

Image for post
Image for post
2 unique repository clones, neither of which were me
Image for post
Image for post
40 views by 17 different people
Image for post
Image for post
18 views of the password file by 11 different people in a browser

Summary of Findings

  • 2 people carried out blatant criminal activities by installing botnet malware of execting DoS attacks
  • 1 person attempted to exfiltrate sensitive information from the server
  • 1 person had a look around then deleted their history to cover their tracks
  • 2 people just fancied a look around my server…

I ended the experiment after just 24 hours as I’d already proven my hypothesis to be more than true. While I expected days before someone would discover my ‘error’ and exploit it, the first occurrence happened in less than an hour.

I think it’s safe to say, if you accidentally leak user credentials and secrets to GitHub.com, there are a significant number of people out there looking to exploit them, and it will happen very quickly.

Follow Up Work



Originally published at https://craighays.com on June 10, 2020.

The Startup

Medium's largest active publication, followed by +707K people. Follow to join our community.

Craig Hays

Written by

Aspiring writer, Cybersecurity Architect, Bug Bounty Hunter, Musician, Movie Producer, Failed Skydiver. https://craighays.com

The Startup

Medium's largest active publication, followed by +707K people. Follow to join our community.

Craig Hays

Written by

Aspiring writer, Cybersecurity Architect, Bug Bounty Hunter, Musician, Movie Producer, Failed Skydiver. https://craighays.com

The Startup

Medium's largest active publication, followed by +707K people. Follow to join our community.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store