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.
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.
Prior to testing, I suspected that criminals are actively searching public code repositories such as GitHub for sensitive information and any credentials posted will be used maliciously at least once within a few days.
In order to test this hypothesis I needed two things:
- Bait — A code repository on GitHub.com with a valid username and password for a server
- A honeypot — an internet-accessible server for criminals to access with the ‘leaked’ credentials
Deploying the Honeypot
Using a virtual server on a well known public cloud platform, I set up a default installation of WordPress to imitate a half-finished deployment and give some credibility. Then on port 22, the default port for an SSH remote access server, I installed Cowrie, an excellent SSH honeypot, and configured it to look as legitimate as possible. Next, I opened up the firewall rules to allow access from the entire internet for web traffic using HTTP and HTTPS on ports 80 and 443, and SSH for remote access to Cowrie on port 22. From my own IP address only, I permitted access to the real SSH server which I moved to port 2222.
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
With the honeypot in place, I used an alternative GitHub account I set up years ago to create a new repository. The content was designed to look like a collection of real ‘setup my workstation’ scripts and tools. I ensured that one of the files could be found using a common GitHub dork list and entered the IP address, port, and the uncommon username and password for the SSH honeypot/ Then, I settled down to wait.
Within 68 seconds of starting up the honeypot, the first SSH username and password brute force attempt started. This is so common that I almost didn’t mention it here, but it highlights how important it is to use strong passwords everywhere and always change the defaults.
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
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
The second user logged in a few hours later to test the credentials, then connected with SFTP and tried to download some sensitive files before giving up when it failed. Very similar to User #1 and not worth talking about any further.
Unauthorised User #3
The third user is where it gets a little more interesting.
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.
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.
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.
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, 188.8.131.52 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.
Unauthorised User #4
The fourth user connected for the very first time through a scripted SFTP file transfer, opening files and folders to gather intelligence on the server.
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.
Unauthorised User #5
User number 5 logged in and started exploring the file system, previous command history, and system resources. Then they tried to clear their history and left.
Nothing new or particularly interesting here.
Unauthorised User #6
The sixth and final user attempted to use the server as a denial of service tool to attack https://www.oann.com. Their method, while simple, is very effective.
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
Interestingly, since nothing else is using my dummy repository, all of the traffic my repository has seen is malicious, or at least dangerously curious.
Summary of Findings
Of the 6 users who connected:
- 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
When I get my next opportunity I plan on digging further into the Perl malware and eleethub group to see exactly what is going on there. I’ll post the write-up of that investigation as soon as it’s complete.
Originally published at https://craighays.com on June 10, 2020.