Kippo-Scan: Fingerprinting SSH Honeypots and the Arms Race in Deception Detection

Hook

Security teams deploy honeypots to catch attackers, but what happens when attackers learn to recognize the trap? Kippo-scan reveals that honeypots leave fingerprints just like the adversaries they hunt.

Context

In the early 2010s, SSH honeypots became a cornerstone of threat intelligence. Kippo, released in 2009, was a medium-interaction SSH honeypot that emulated a full Linux system to capture attacker behavior, commands, and malware samples. Security researchers deployed thousands of Kippo instances across the internet to study SSH brute-force attacks, credential stuffing, and post-compromise activities.

But honeypots only work if attackers believe they're real systems. Once adversaries can reliably identify honeypots, they simply move on to genuine targets, rendering the intelligence-gathering infrastructure useless. Kippo-scan emerged from this cat-and-mouse dynamic: a tool designed to fingerprint Kippo deployments by exploiting subtle differences between its SSH implementation and legitimate OpenSSH servers. The tool fed detection data to honeydb.com, creating a public database of honeypot locations—effectively turning the watchers into the watched.

Technical Insight

Kippo-scan operates on a fundamental principle of honeypot detection: emulation is never perfect. Even well-crafted honeypots exhibit behavioral quirks that differ from the real systems they imitate. The script exploits these implementation gaps through SSH protocol analysis and response timing.

The core detection methodology involves connecting to SSH services and analyzing several telltale signatures. First, banner analysis—Kippo's default SSH banner often contains specific version strings or formatting differences from stock OpenSSH. Second, authentication timing—Kippo's simulated authentication process has different latency characteristics than real PAM-based authentication. Third, command response patterns—when Kippo executes fake commands in its emulated environment, the responses sometimes contain filesystem inconsistencies or missing kernel details that real systems would provide.

Here's a simplified example of how honeypot fingerprinting might work at the protocol level:

import paramiko
import time

def fingerprint_ssh(host, port=22):
    try:
        client = paramiko.SSHClient()
        client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
        
        # Measure banner retrieval timing
        start = time.time()
        transport = paramiko.Transport((host, port))
        transport.connect()
        banner = transport.remote_version
        banner_time = time.time() - start
        
        # Attempt authentication with fake credentials
        auth_start = time.time()
        try:
            transport.auth_password('root', 'fake_password')
        except paramiko.AuthenticationException:
            pass
        auth_time = time.time() - auth_start
        
        transport.close()
        
        # Kippo typically has faster auth rejection (< 0.1s)
        # Real systems consult PAM, which takes longer
        if auth_time < 0.1 and 'kippo' in banner.lower():
            return {'honeypot': True, 'type': 'Kippo', 'confidence': 'high'}
        elif auth_time < 0.1:
            return {'honeypot': True, 'type': 'Unknown', 'confidence': 'medium'}
        
        return {'honeypot': False}
        
    except Exception as e:
        return {'error': str(e)}

The actual kippo-scan implementation likely goes deeper, potentially testing for filesystem artifacts that Kippo's emulated environment exposes. For instance, Kippo creates a fake filesystem from a pickled Python object—this filesystem is static and doesn't reflect real system changes. Commands that query system state (like uptime, ps, or df) might return suspiciously consistent values across connections or contain impossible combinations of data.

Another detection vector involves protocol compliance edge cases. OpenSSH has decades of development handling unusual protocol sequences, timeout scenarios, and malformed packets. Kippo, being a reimplementation, handles these scenarios differently. Sending deliberately malformed SSH packets or unusual key exchange sequences can reveal implementation differences.

The script's architecture suggests it was designed for mass scanning—likely iterating through IP ranges, testing each SSH service, and reporting positive identifications back to a central database. This crowd-sourced approach to honeypot mapping created a public registry of deception infrastructure, fundamentally challenging the assumption that honeypots could operate invisibly.

The meta-lesson here transcends Kippo specifically: any emulation layer creates observable differences. Whether it's container fingerprinting, virtual machine detection, or honeypot identification, the gap between simulation and reality always leaves traces. Defenders must either accept that sophisticated adversaries will eventually fingerprint their infrastructure, or invest in high-fidelity emulation that eliminates detectable quirks—an expensive and ongoing engineering challenge.

Gotcha

The repository's README is brutally honest: 'extremely messy' with only 'basic detection.' This isn't production-grade software—it's a proof-of-concept that demonstrates vulnerability in honeypot deployments rather than a polished scanner. The detection signatures are almost certainly outdated since Kippo evolved into Cowrie in 2015, which addressed many of the original implementation quirks that made fingerprinting trivial.

More fundamentally, the tool raises ethical considerations that aren't documented. While honeypot fingerprinting serves legitimate purposes—red team assessments, research into deception technology, and validating honeypot deployability—it also enables malicious actors to avoid detection during reconnaissance. Using this tool against infrastructure you don't own or without explicit authorization likely violates computer fraud laws in most jurisdictions. The repository provides no guidance on responsible use, and the automated reporting to honeydb.com means your scans become part of a public dataset without necessarily understanding the implications. Modern security researchers need updated tools targeting current honeypot implementations like Cowrie, T-Pot, or commercial deception platforms, along with clear ethical frameworks for deployment.

Verdict

Use if: You're researching honeypot detection techniques for academic purposes, conducting authorized red team assessments where identifying defensive infrastructure is part of the scope, or studying the historical evolution of SSH honeypots and counter-detection methods. The code provides valuable insight into fingerprinting methodologies even if the specific signatures are obsolete. Skip if: You need a production-ready honeypot detection tool (the signatures are stale and Kippo has been replaced by Cowrie), you're conducting unauthorized reconnaissance (legal and ethical problems), or you expect polished, maintained software (the repository is abandoned and self-described as messy). For current honeypot fingerprinting, you'd need to develop custom signatures targeting modern implementations or use broader SSH fingerprinting tools like HASSH combined with behavioral analysis.