CIRCUITO
CARIOCA TI · DOCUMENTATION
♙
Historical case study · modernized

Kippo → Cowrie

A real production honeypot experiment preserved as historical evidence and converted into a safe, reproducible modern lab.

honeypot://kippo→cowrie
$ original: CentOS 6.5 / Kippo / MySQL
$ period: 23/09/2015 → 03/12/2015
$ login attempts: 44,607
$ unique sources: 1,072_
01 · Original document

What was deployed in 2015/2016

The study “Study and implementation of a Freeware Honeypot in a production environment” deployed Kippo on CentOS 6.5 inside a XenServer VM with a public IP address. The real environment had two dedicated Internet links (120 and 100 Mbit/s), servers, and network equipment with public addressing. The methodology was: research, honeypot selection, VM preparation, installation, observation, statistics generation, and analysis.

Historical value

The figures below belong to the original experiment and are not current Internet statistics. They are preserved as evidence from a real 2015 environment.

44,607recorded login attempts
1,072distinct source IPs observed
229honeypot logins accepted with deliberately weak credentials
~72 dayswindow between the first and last cited attacks
02 · Visual evidence

Original architecture and methodology

The images below were extracted from the original 2016 study and are preserved as historical material.

Flowchart of the methodology used in the Kippo studyMethodologyResearch → deployment → observation → charts → analysis.
Production topology used in the original honeypot studyEnvironmentOriginal topology of the environment where the sensor was deployed.
Historical Kippo configuration screenKippoHistorical SSH honeypot configuration.
03 · Results

What the attackers did

Kippo-Graph showed a predominance of the root username, trivial passwords, and predictable credential combinations. The study also recorded executed commands, file transfers/downloads, session replay, and approximate geolocation of source addresses. These results illustrate why Internet-facing SSH services are rapidly targeted by automated scanning and brute-force activity.

Top usernames observed in the Kippo studyUsernamesroot was the most frequently attempted username.
Top passwords observed in the Kippo studyPasswordsSimple credentials appeared among the earliest attempts.
Accepted and rejected login attempts recorded by KippoControlled success229 authentications were accepted by the honeypot to allow observation.
04 · What aged

Do not reproduce the 2016 installation literally

  • CentOS 6.5, Python 2.5+, PyCrypto, and Kippo's old code.google.com address are legacy.
  • Kippo should not be presented as the current implementation; use Cowrie.
  • Kippo-Graph/LAMP/phpMyAdmin should not be publicly exposed as in the historical design.
  • Weak credentials are deliberate only inside the isolated sensor; they are never a recommendation for a real server.
  • IP geolocation does not identify an attacker and may reflect a VPN, proxy, botnet node, or compromised infrastructure.
05 · Modern architecture

How to deploy the equivalent in 2026

Internet
   │
[Firewall/NAT]
   │  external TCP/22 → sensor TCP/2222
   ▼
[Dedicated VM/Container: Cowrie]
   │  deny-by-default egress
   ├── cowrie.json / tty / downloads
   │
   └──► [remote log collector/SIEM on management network]

Real SSH administration ──► separate network/port ──► host
  1. Create a dedicated VM/host and a dedicated network segment.
  2. Block egress by default; allow only destinations strictly required for operation.
  3. Install Cowrie under a non-root account using virtualenv/pip or the official container image.
  4. Keep the real administrative SSH service away from the honeypot's public-facing port.
  5. Redirect external TCP/22 to Cowrie only after validating an alternate administrative path.
  6. Forward logs to a remote collector and define retention.
  7. Treat downloads as potentially malicious; hash and store them in quarantine.
  8. Run a controlled test session and confirm connection, authentication, command, and session-close events.
06 · Cowrie installation

Flow recommended by the maintainers

sudo adduser --disabled-password cowrie
sudo su - cowrie
mkdir ~/my-honeypot && cd ~/my-honeypot
python3 -m venv cowrie-env
source cowrie-env/bin/activate
pip install cowrie
cowrie init
$EDITOR etc/cowrie.cfg
cowrie start

The pip-based flow is recommended for operators in the current Cowrie 3.x documentation. Before exposing TCP/22, validate the sensor locally on its listening port and configure log collection.

07 · Validation

Lab acceptance test

  1. Connect from a lab IP and confirm the honeypot banner/service.
  2. Perform a test authentication and verify the corresponding JSON event.
  3. Run harmless commands and verify session replay/session logs.
  4. Attempt a controlled file download and confirm quarantine/hash generation.
  5. Confirm the sensor cannot reach arbitrary external destinations.
  6. Confirm the real administrative service is not reachable through the same exposure.
  7. Restart/restore the sensor and verify persistence of the data that must survive.
08 · Brazilian context

Why this is still relevant

In 2026, CERT.br continues to operate the Distributed Honeypots Project for incident detection, event correlation, and analysis of attack trends in the Brazilian Internet space. The project uses distributed low-interaction sensors and publishes malicious-traffic statistics. This supports honeypots as a situational-awareness source when they are deployed with containment and a clearly defined purpose.

09 · References

Sources