Rendered at 15:00:17 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
dspillett 17 hours ago [-]
That doesn't look to me like it would find many real credentials. It is collecting the credentials that automated bots are trying to use, some of them, perhaps many of them, will be credentials that someone somewhere is using for something, but unless you are planning an Internet wide scan yourself using those credentials to try login to something is likely to be fruitless.
alexpotato 17 hours ago [-]
I worked at a place that had a lot of baremetal machines on the open internet.
I would occasionally scan the auth.log to see which users the bots were using and it was an interesting mix of:
- service accounts e.g. mysql, admin, etc
- individual names e.g. tom, ankit, alexei etc
ufmace 18 hours ago [-]
I'd be more curious to know what these SSH scanner bots actually do if they manage to log in. Automated recon, install spambot/cryptominer/phishing site, something else?
dspillett 17 hours ago [-]
I'm not sure about less targetted bots, but I gave a friend an account on my media server without locking off shell access (which she had no need for), and it turns out that she used the same password as she used for every other service. Something got hold of those (that something must have run on her machine while she was on my network as it was not an externally connectable service) found the account with that user+pass and got in.
I noticed PDQ because of a sudden and fairly constant flow of upstream data that was unusual from that machine, and finding the account & processes involved was easy. As well as installing something to run SSH scans (presumably for further propagation) and running what looked like a crypto-miner, it seemed to be forwarding HTTP(S) requests in a manner that suggested the machine had become part of a “residential proxy” network or similar. Maybe if it hadn't been so greedy I wouldn't have noticed so soon (it hadn't been able to, or hand't tried to, cover its traces, so I found the time of installation very easily as the account otherwise had no SSH activity).
Luckily there were no open root escalation attacks at the time (at least that it knew about) so I only needed to pave that account to get rid of everything, but combined with one of the LPE attacks that have been around over the years it could have caused me much more of a headache.
Bender 18 hours ago [-]
- Steal application credentials if posix perms or database privs are weak, attempt privilege escalation, install rootkit RATs Remote Access Trojans for persistence and hiding processes.
- If anything looks interesting on their console they will log in and poke around. The order of these events depends on the sophistication of the bot script. Most are very simple.
If you the target look like you have money they may install ransomware and encrypt some of your files. Now I want to watch the Beekeeper again as corny as it was, also a fun movie.
ufmace 15 hours ago [-]
I presume that at least some of them just log the host as accessible and maybe some basic statistics into a list for an actual person to look at later on. That actual person would be the one to look more closely to see if there are any interesting credentials to steal or important data to steal or ransomware.
chaz6 18 hours ago [-]
The most common things I observe:-
- Installing a cryptominer or persistence tool
- Sending spam (smtp)
- Using pre-obtained credentials to log into various ecommerce/social media sites
Seems more entertaining than suitable for real analysis. At least I did not see any collected data. You can just watch what happens at this moment.
From watching it a while I came to the conclusion that adding a new authorized ssh key is a common first step.
daneel_w 18 hours ago [-]
Anonymizing network proxy.
pastage 18 hours ago [-]
Last time I saw this an obscure single letter root password was still "secure", now days seems like almost all non-alphanumeric chars works. % is my new root password it still has not been brute forced.
daneel_w 20 hours ago [-]
No "credentials" are being "harvested" here. It's all worthless data, save for the statistics.
enjaydee 15 hours ago [-]
Is OP here? Curious as to what they used for geolocation
dijksterhuis 14 hours ago [-]
> Been using ipgeolocation.io to fetch the additional information about the GEO locations, ASN information, etc.
whatbackup 14 hours ago [-]
ipgeolocation.io API - should be in the article as well - cheers
0cf8612b2e1e 20 hours ago [-]
Do most installations create a git user account with login permissions?
inigyou 20 hours ago [-]
There's no such thing as an account with or without login permissions. Normally you need a git account. And that means you can log in to it. And then you have to try and configure your ssh server so that after logging into the git account, you can only run the git server (I forget the command). If a mistake is made with this configuration then you can log in or port forward or X forward or file transfer as git.
This is a terrible idea because it's blacklist-based security. Places like GitHub have their own ssh server that only runs the git server and nothing else.
That's a hack. It's a login shell that, once you have already logged in and run the shell, prints a message saying you can't log in or run a shell, and then exits.
It does not stop you from, say, logging in to SSH and then starting a port forward. Or running a command in a way that bypasses the login shell. ssh will always pass it to your login shell but other ways can be vulnerable.
Bender 16 hours ago [-]
Do you have a script to show us how it works? Here, use Claude's login [1]. There's no password. I am not very technical so let me know if I should set a password on that account. I trust everyone here.
[1] - sftp ai@nochan.net
BenjiWiebe 13 hours ago [-]
Doesn't seem to allow port forwarding so I think you're probably good.
trucks-refinish 3 hours ago [-]
git-shell is actually made for this exact situation. it does allow uploading git repos I think so you can't open it to the public, maybe there's a way to configure it though to not allow that.
tuetuopay 19 hours ago [-]
SSH bastions would like a word I guess. You can authenticate, but you definitely can’t login (which is also the case for git over SSH).
kpcyrd 16 hours ago [-]
An SSH bastion host allows to request direct-tcpip channels, but is going to restrict other channel types, like pty requests, shell requests, exec requests or other subsystems.
The "login permission" term is confusing because it's likely supposed to mean "shell requests", but SSH channel requests in general are all post auth, which could also be considered a "login". In OpenSSH you still need to explicitly configure permitted channel requests, which I think is what GP is referring to.
For git specifically I would recommend the ForceCommand feature in OpenSSH, all exec requests are then forwarded to this program, with $SSH_ORIGINAL_COMMAND set to the original command. You may then use an allow-list of commands you want to permit.
16 hours ago [-]
asveikau 20 hours ago [-]
Having a root password of "toor" is very clever. Nobody will figure that one out.
erulastiel 20 hours ago [-]
toor was a default password for many devices for decades.
asveikau 20 hours ago [-]
I've used unix-like OS's for 28 years and I don't remember coming across it as a password.
It was the default password for the root user in Kali Linux for a while.
merpkz 19 hours ago [-]
Back when it was called Backtrack if my memory serves right. I remember being puzzled that it was not the case anymore one day and they even switched to regular user around when Kali became a thing
pudgywalsh 20 hours ago [-]
Slackware used it in the late 90s IIRC.
sisve 20 hours ago [-]
Did you check out the statistics on the site?
They listed 1233456, 12345, 1234,123 and 1 on the toplist of password.
If we are going to be clever we should follow the statistics and go for 12 that where not on the toplist!!
I would occasionally scan the auth.log to see which users the bots were using and it was an interesting mix of:
- service accounts e.g. mysql, admin, etc
- individual names e.g. tom, ankit, alexei etc
I noticed PDQ because of a sudden and fairly constant flow of upstream data that was unusual from that machine, and finding the account & processes involved was easy. As well as installing something to run SSH scans (presumably for further propagation) and running what looked like a crypto-miner, it seemed to be forwarding HTTP(S) requests in a manner that suggested the machine had become part of a “residential proxy” network or similar. Maybe if it hadn't been so greedy I wouldn't have noticed so soon (it hadn't been able to, or hand't tried to, cover its traces, so I found the time of installation very easily as the account otherwise had no SSH activity).
Luckily there were no open root escalation attacks at the time (at least that it knew about) so I only needed to pave that account to get rid of everything, but combined with one of the LPE attacks that have been around over the years it could have caused me much more of a headache.
- Install Proxies, DDoS Agents, Bitcoin mining, proxy to SMTP servers, etc...
- If anything looks interesting on their console they will log in and poke around. The order of these events depends on the sophistication of the bot script. Most are very simple.
If you the target look like you have money they may install ransomware and encrypt some of your files. Now I want to watch the Beekeeper again as corny as it was, also a fun movie.
- Installing a cryptominer or persistence tool
- Sending spam (smtp)
- Using pre-obtained credentials to log into various ecommerce/social media sites
Seems more entertaining than suitable for real analysis. At least I did not see any collected data. You can just watch what happens at this moment.
From watching it a while I came to the conclusion that adding a new authorized ssh key is a common first step.
This is a terrible idea because it's blacklist-based security. Places like GitHub have their own ssh server that only runs the git server and nothing else.
https://www.man7.org/linux/man-pages/man8/nologin.8.html
It does not stop you from, say, logging in to SSH and then starting a port forward. Or running a command in a way that bypasses the login shell. ssh will always pass it to your login shell but other ways can be vulnerable.
The "login permission" term is confusing because it's likely supposed to mean "shell requests", but SSH channel requests in general are all post auth, which could also be considered a "login". In OpenSSH you still need to explicitly configure permitted channel requests, which I think is what GP is referring to.
For git specifically I would recommend the ForceCommand feature in OpenSSH, all exec requests are then forwarded to this program, with $SSH_ORIGINAL_COMMAND set to the original command. You may then use an allow-list of commands you want to permit.
It is a common username (see: https://en.wikipedia.org/wiki/Toor_(Unix) ), the machine I am typing this on has it.
If we are going to be clever we should follow the statistics and go for 12 that where not on the toplist!!
12 - Rank 318
21 - Rank 523
I'm surprised that '12' is so low on the list.