Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bad actors are using the 'richard' account to fingerprint the honeypot #1102

Closed
bontchev opened this issue May 1, 2019 · 12 comments
Closed

Comments

@bontchev
Copy link
Contributor

bontchev commented May 1, 2019

I was sent recently a list of some 800+ IP addresses that the botnet herders are circulating among themselves and that contains the IP addresses of known honeypot. The IP address of our honeypot was on it, too.

I asked around how they are detecting the honeypot and, apparently, they use the presence of the /home/richard directory in the file system for this purpose.

I had disabled the richard user in the user database file but had completely forgotten about that user's home directory in the simulated file system. Examining my logs of attack patterns I can indeed see several attempts to detect the honeypot by the presence of this directory. Here are a few examples:

if [ $(uname -m) == "x86_64" ]; then if [ $(ls /home/) == "richard" ]; then echo "" >/dev/null; else echo "GOTCHA"; fi; fi;if [ $(uname -m) == "i686" ]; then if [ $(ls /home/) == "richard" ]; then echo "" >/dev/null; else echo "GOTCHA"; fi; fi

Another:

ls
cd /tmp
ls
ls -a
cd
ls
cd /home
ls -a
ls
cat richard
pwd
rm -rf /

And another:

cd /home/richard/
ls -la
cat .profile 
touch x
rm x
ps
netstat -an
last

Therefore, I am suggesting that you put an explicit warning somewhere in the installation guide to use the bin/fsctl utility to change the name of this directory to something else.

Speaking of which, it would be really nice of the fsctl utility could have the cat command, so that the user can see the contents of the files they are copying/moving/etc.

@ghost
Copy link

ghost commented May 19, 2019

Yeah I was seeing that same issue with "Richard" being scanned. After I used a new fs.pickle (a clone of a VM that I did on CentOS) i've gotten more traffic. From this branch I say the Enhancement should be a more unique OS.

Personally I believe we should have cowrie.cfg be defaulted to use auth_class = AuthRandom and|or having a randomizer for the userDB directory.

@amv42
Copy link

amv42 commented Jul 1, 2019

I am not a big advocate for AuthRandom. Just using root seems more appropriate - is there any (good) reason that Richard is set up?

@EvilOlaf
Copy link
Contributor

It was just a random name I guess to provide an unprivileged user in the system. The downside is that now this is pretty unique. However it is up to the user to individualize the fake system to make it more realistic.

Thanks for the hint, I got rid of richard in my honeypots.

@bontchev
Copy link
Contributor Author

I'm pretty sure I've seen here, on GitHub (or maybe as a Gist) a script that takes an existing Cowrie installation and "randomizes" it, in order to make fingerprinting it difficult. It sets a random non-privileged user, selects randomly one of several possible SSH version strings, varies the content of the emulated file system, that sort of thing. Unfortunately, I can't find it right now...

@dwasss
Copy link
Contributor

dwasss commented Sep 6, 2019

I'm pretty sure I've seen here, on GitHub (or maybe as a Gist) a script that takes an existing Cowrie installation and "randomizes" it, in order to make fingerprinting it difficult. It sets a random non-privileged user, selects randomly one of several possible SSH version strings, varies the content of the emulated file system, that sort of thing. Unfortunately, I can't find it right now...

Was it this? https://github.com/411Hall/obscurer

It's from 2017 :( but I haven't tried it yet.

@bontchev
Copy link
Contributor Author

bontchev commented Sep 6, 2019

I think that's the one, yes. Thanks.

@RunnyRun
Copy link

RunnyRun commented Apr 2, 2020

I think that's the one, yes. Thanks.

Unfortunately, I ran the script (with some modification to the new cowrie file paths), but it didn't work as it stated.

It told me that it was successful. However, after restarting cowrie, nothing changed!

@EvilOlaf
Copy link
Contributor

EvilOlaf commented Apr 2, 2020

The script has not been updated for a while. Maybe try its forks?

@RunnyRun
Copy link

RunnyRun commented Apr 2, 2020

I used one of the other fork.

Once I ran the script, it gave me this "Cowrie Configuration Updated"

However, after restarting cowrie, nothing changed and this output was given:

Failed to import command base: EOL while scanning string literal (base.py, line 278): Traceback (most recent call last):\n File "/home/cowrie/cowrie/src/cowrie/shell/protocol.py", line 33, in HoneyPotBaseProtocol\n globals(), locals(), ['commands'])\n File "/home/cowrie/cowrie/src/cowrie/commands/base.py", line 278\n ('root ', '1277', ' 0.9', ' 0.1', ' 2908', ' 1904', '? ', 'S+ ', '09:04', ' 0:00', '/usr/sbin/sshd: %s@pts/0' % user',),\n

Any suggestion please? Or cam some one provide with a step by step procedure on how to create a fake file system with my own interesting files?

@micheloosterhof
Copy link
Member

Richard has been changed to phil! :)

@EvilOlaf
Copy link
Contributor

Curios to see how long it will take until bad people adjust their scripts accordingly.

@micheloosterhof
Copy link
Member

Curios to see how long it will take until bad people adjust their scripts accordingly.

Yes they will at some point. That's why it's still good practice to customize your own honeypot. Maybe in the future we can have randomly generated usernames, or something else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants