A Survey on Honeypot Software and Data Analysis

Marcin Nawrocki; Matthias Wählisch; Thomas C. Schmidt; Christian Keil; Jochen Schönfelder

Source-linked AI summary

A Survey on Honeypot Software and Data Analysis

Marcin Nawrocki, Matthias Wählisch, Thomas C. Schmidt, Christian Keil, Jochen Schönfelder

arXiv:1608.06249v1Aug 22, 2016cs.CRcs.NI

TL;DR

Honeypot research lacks an up-to-date, comprehensive software comparison and a survey centered on honeypot-data analysis. This paper addresses that gap by reviewing honeypot software, analysis methodologies, and related deployment considerations, concluding with broad comparisons of software types, maintenance, and data-analysis practices.

Problem
Existing surveys do not provide an up-to-date comparison and classification of honeypot software or an overview of related data-analysis techniques.
Method
The survey synthesizes honeypot software, data-analysis methodologies, deployment guidance, and related ethical and legal concerns.
Results
The survey presents broad comparisons showing differing maintenance and interaction patterns across server and client honeypots and reviews methods for analysing honeypot data.
Takeaways & Limitations
The review supports choosing honeypot software and log-analysis methods according to the intended application scenario and research objective.

Abstract

from arXiv · show

In this survey, we give an extensive overview on honeypots. This includes not only honeypot software but also methodologies to analyse honeypot data.

I. INTRODUCTION

Honeypot research addresses the need for accurate information about Internet threats through two complementary pillars: developing and deploying honeypot software, then analysing its logs. This survey responds to gaps in current software classifications and data-analysis reviews while positioning honeypots among prevention, detection, and reaction concepts.

Honeypot research combines software development and deployment with structured analysis of acquired log data.
Earlier surveys lacked an up-to-date, comprehensive classification of honeypot software and did not focus on data-analysis techniques.
The survey reviews honeypot software, honeypot-data analysis methodologies, and related ethical and legal concerns.
Honeypots primarily gather information about attackers and attack patterns or distract attackers from actual targets.
Security concepts: Honeypots contribute little directly to prevention but can substantially support detection and accelerate reaction by isolating attack data from production activity.
Security concepts: Security concepts have distinct primary objectives—firewalls prevention, IDSs detection, and honeypots reaction—but can complement one another in hybrid solutions.

B. Taxonomy of Honeypots

Honeypots are classified by interaction level, communication direction, physicality, and intended use. These taxonomies expose trade-offs between deployment simplicity, interaction realism, information richness, and operational risk.

Intended use: Production honeypots prioritize ease of deployment, while research honeypots provide more comprehensive attack information for forensic and countermeasure development.
Interaction level: Low-, medium-, and high-interaction honeypots differ in simulated functionality, attacker interaction, implementation complexity, and information collected.
Interaction level: Low-interaction honeypots provide limited services and minimal responses, supporting statistical evaluation and recognition of request peaks.
Interaction level: High-interaction honeypots provide unrestricted operating-system environments and many services, collecting detailed attack information but requiring complex deployment and maintenance.
Taxonomy limitations: Honeypot classifications are difficult to apply rigidly because many implementations combine characteristics, motivating the common low-versus-high distinction.
Communication direction: Server honeypots wait for attackers, whereas client honeypots actively seek potentially malicious entities, commonly through web browsers.
Advantages and disadvantages: Honeypots offer focused, relatively clean data but have limited visibility without attacks, can be fingerprinted, and may endanger the environment when compromised.

III. HONEYPOT SOFTWARE

The survey classifies available honeypot software by interaction level and communication architecture, covering historical and deployable systems across varied application scenarios. It also considers maintenance status, related tools, and honeypot-detection mechanisms.

The software overview organizes honeypots as client or server systems and as low- or high-interaction systems.
The survey includes current deployable tools alongside outdated but historically influential implementations, explicitly noting release dates and maintenance state.
Early software: Early tools such as DTK, BOF, and CyberCop Sting used deception, service emulation, or virtual networks to distract attackers and record activity.
Virtualization and logging: HoneyD simulated thousands of configurable virtual hosts, while HoneyBOT recorded packet data, keystrokes, and malware for later analysis.
Capabilities: Commercial and research-oriented implementations provided functions including IDS-compatible signatures, packet sniffing, honeypot farms, protocol emulation, and log-analysis support.
Low-interaction systems: Nepenthes used modular vulnerability emulation and malware capture, while Tiny Honeypot listened on unused TCP ports and offered lightweight fake services.

2) Dedicated SMTP Honeypots:

Dedicated honeypots target email, remote-login, web, search, and account-abuse activity through protocol-specific emulation and logging. Their designs range from simple collection tools to systems that manipulate interaction to sustain deception.

SMTP honeypots: SMTP honeypots may operate independently of a DNS domain or be linked to one through the DNS MX record.
SMTP honeypots: Jackpot classifies spam using antispam databases, distinguishes spam from relay tests, and delays replies to simulate a slow server.
SMTP honeypots: SpamD separates blacklisted, white-listed, and grey-listed hosts, tar-pitting blacklisted connections and forwarding white-listed hosts to real mail servers.
SMTP honeypots: ProxyPot, SMTPot, Spamhole, and Spampot use simpler strategies such as logging spam, storing messages, silently dropping mail, or retaining 5% of incoming spam.
SSH honeypots: Kippo logs brute-force attacks and shell interactions using a fake Debian filesystem, while later development added SFTP/SCP support through Cowrie.
Web honeypots: Glastopf collects web-application attacks, downloads linked files, and responds to attacker expectations to encourage subsequent attacks.
Web honeypots: HoneyWeb emulates multiple web-server platforms and dynamically assigns platform identities to complicate honeypot detection.
Specialized honeypots: Elastichoney targets remote-code-execution attacks against Elasticsearch, while GHH and Honey Accounts monitor search-engine abuse and compromised webmail activity.

5) Telephone Honeypots:

The survey spans honeypots for telephone, VoIP, mobile, wireless, Bluetooth, IoT, vulnerability-specific, and industrial-control environments. These deployments differ in the technologies they emulate or monitor and in whether they target attacks on services, devices, or networks.

Telephone Honeypots: Sandtrap records incoming calls on up to 16 lines, emulates reachable modems with login prompts, and alerts administrators to suspicious activity.It logs caller IDs and login attempts while addressing war-dialing attacks.
Telephone Honeypots: Artemisa is a SIP-specific VoIP honeypot that registers decoy accounts with service providers and waits for incoming attacks.It includes conversation recording, message-flooding protection, and correlation rules.
Mobile and Wireless Honeypots: Mobile honeypots may run on mobile devices or stationary hardware connected to a mobile operator’s network, while wireless honeypots target wireless technologies.The survey notes that mobile deployments can complicate cross-system measurement and are needed mainly when hardware characteristics matter.
Mobile and Wireless Honeypots: Examples include prototype honeypots for Bluetooth, WiFi, and MMS, virtualized mobile clients, Bluetooth malware capture, and wireless hotspot deception.FakeAP generates random 802.11b beacon frames to confuse wardriving tools, while bluepot accepts and stores malware sent to Bluetooth devices.
IoT and Specialized Honeypots: IoTPOT analyzes Telnet-based attacks against IoT devices, while Shockpot emulates an Apache server to study exploitation of Shellshock.IoT devices range from smartphones to constrained embedded hardware, and Conpot targets adversaries of industrial control systems.
IoT and Specialized Honeypots: HoneyPoint provides fake services, web applications, tracked documents, and emulated ICS devices across several commercial license versions.Its supported targets include Windows systems and SCADA environments.

9) Further Special Purpose Honeypots:

Further special-purpose honeypots support sinkholing, high-interaction deployment, malware collection, browser and client analysis, instant-messaging decoys, and exploit-stage detection. The surveyed systems trade emulation, interaction level, throughput, and analysis depth for different research objectives.

Network and Deployment Tools: HoneySink redirects domains to monitor botnet communication, detect infected internal machines, and disrupt criminals’ control over bots.It emulates DNS, HTTP, FTP, and IRC for configurable protocol-domain combinations.
High-Interaction and Malware Collection: Argos provides a high-interaction Qemu environment that detects zero-day exploits using process- or kernel-aware logging, memory tainting, and intrusion-signature creation.It also injects forensic shellcodes for in-depth analysis.
High-Interaction and Malware Collection: Honeywall simplifies deployment and administration of low- and high-interaction honeypots, with primary emphasis on high-interaction environments.Its CentOS live CD includes Sebek and a GUI for configuration, administration, and data analysis.
High-Interaction and Malware Collection: HIHAT transforms PHP applications into web-based high-interaction honeypots and provides graphical monitoring, geographic IP mapping, and extensive statistics.It supported four major PHP frameworks during active development.
High-Interaction and Malware Collection: Sebek captures attacker activities such as keystrokes and file uploads by monitoring system calls on Win32 and Linux high-interaction honeypots.A client captures and stealthily sends selected activity to a server.
Client Honeypots: Browser honeypots including PhoneyC, HoneyC, Thug, YALIH, and ADSandbox use emulation or dynamic and static analysis to study malicious web content.YALIH reported 15% fewer false negatives than Thug, 80% fewer than HoneyC, and 35% fewer than Monkey-Spider while requiring moderate scanning resources.
Client Honeypots: Trigona improves high-interaction client-honeypot efficiency by visiting multiple URLs in one VM and later extracting exploit kits and malware binaries from packet captures.It avoids repeatedly loading or resetting a VM for each URL, but does not analyze operating-system state information.
Client Honeypots: HoneyIM uses decoy instant-messaging users to receive malicious URLs, while PwnyPot identifies malware during exploitation before system changes or infection occur.PwnyPot’s approach supports recognition of zero-day exploits without signatures.

E. Honeypot Related Tools

Related tools simplify honeypot deployment, event visualization, packet and malware extraction, sensor distribution, and cross-sensor correlation. The survey also describes tools and techniques that detect whether low- or high-interaction honeypots are being fingerprinted.

Deployment and Management: Bait-n-Switch redirects hostile traffic to a honeypot while allowing regular traffic to continue toward production systems.It was implemented as a Snort extension using Linux iproute2 and netfilter.
Analysis and Visualization: HSC groups and correlates events from Snort, TCPDump, Firewall, Syslog, and Sebek logs for more holistic honeynet analysis.Its primary focus is event visualization and grouping.
Deployment and Management: GSOC-Honeyweb manages client honeypots through a web interface with standardized front-end, communication, persistence, storage, and aggregation layers.The back end collects, stores, and aggregates client-honeypot results.
Analysis and Extraction: Honeysnap diagnoses server-honeypot data from pcap directories by decoding protocols, summarizing connections, extracting binaries, and profiling IRC keywords.It also supports honeypot-specific Sebek keystroke data.
Analysis and Extraction: PE Hunter extracts Windows portable executables from network streams by detecting PE headers, estimating file lengths, and dumping the corresponding bytes.It is designed for use in front of honeypots that trigger executable transfers.
Deployment and Management: HoneyMole tunnels traffic from distributed sensors to a centralized honeypot farm, reducing sensor maintenance and concentrating attack data for analysts.Its sensors operate as encrypted Ethernet bridges over TCP/IP.
Analysis and Correlation: TraCINg accepts structured JSON from honeypots, correlates attacks across sensors, and analyzes sources and timing to identify emerging worm outbreaks.The implementation described currently includes a Dionaea plugin.
Honeypot Detection: Low-interaction honeypots can be fingerprinted through characteristic emulation responses, while high-interaction honeypots can be identified through unusual libraries, debuggers, virtualization artifacts, or slower responses.Examples include Kippo magic numbers, VMware MAC-address ranges, detectable chroot behavior, ptrace, and timing differences.

G. Summary of Honeypot Software

The survey classifies honeypot software by architecture, interaction level, and application area, showing broad protocol coverage and an evolution toward longer-maintained tools. It also reviews long-term projects and presents a step-by-step approach to honeypot data analysis.

Software overview: Different honeypots support different protocols and network types, demonstrating the universality of the honeypot concept.
Server honeypots: Most available honeypots are low-interaction server honeypots because they require less implementation and maintenance effort than client or high-interaction alternatives.
Software evolution: Honeypot development progressed from short-lived proof-of-concept tools to complex, longer-maintained systems such as HoneyD, SpamD, Kippo, Nepenthes-Dionaea, and Honeytrap.
Client honeypots: Client honeypots appeared almost 5 years after server honeypots and increasingly use high interaction because browser environments are more difficult to emulate.
Client honeypots: Low-interaction client honeypots are commonly used in multi-year Internet-wide research because they do not directly improve production-network security.
Scope and analysis: The overview covers classification, maintenance time, service focus, architecture, and application area, but not robustness, data quality, analysis ease, containment, or detection precision.
Projects and analysis: Long-term honeypot projects and alliances aggregate software, data, and research outputs, while the survey introduces honeypot-data analysis through questions, methods, and metrics.

A. Attack Profile

An attack profile organizes honeypot observations around attacker motivation, scope, sophistication, concealment, source, vulnerability, and tools. The review also explains how source identifiers and targets should be interpreted across server and client honeypots.

Attack-profile attributes: An attack profile records motivation, breadth and depth, sophistication, concealment, attacker source or root cause, vulnerability, and tools.
Attack-profile attributes: Breadth measures the number of affected machines, whereas depth measures target analysis or attack impact on a system.
Attack sources: Attack sources can be represented by IP address or prefix, Autonomous System Number, or domain name, URL, and URL type.
Attack sources: Server honeypot source identification is complicated by spoofed or invalid addresses, while changing address assignments and routing can make identifiers unstable.
Attack targets: Server honeypots classify targets by services and ports, whereas client honeypots target software such as emulated or real browsers and plugins.
System effects: High-interaction honeypots require analysis of operating-system changes, including kernel modules and cron jobs on Linux or registry and startup changes on Windows.

D. Attack Frequency

The survey measures attack frequency through source, packet, data, exploitation, session, flow, and temporal-arrival metrics. These measures differ by honeypot type and can expose recurring patterns, attack peaks, and source behavior.

Basic frequency: Internet-accessible honeypots can receive attacks within minutes of activation, whereas firewall-blocked honeypots rarely observe attacks from outside.
Source arrivals: Source-arrival analysis uses temporal source counts, arrival windows, interarrival distributions, and counts of new or aggregated sources over time.
Honeypot-specific metrics: Server honeypots measure packets, received data, messages, URLs, attachments, and exploitations per time unit, while client honeypots focus on exploitations because they initiate communication.
Temporal patterns: Attack-frequency peaks can correspond to service-specific or worm activity; instant messaging spam, for example, shows two daily peaks and one weekly peak.
Sessions and flows: Sessionization groups packets from one source within a time frame or before a timeout, enabling analysis of session counts, intersession times, and known versus unknown sessions.
Source behavior: The source-lifetime analysis distinguishes short-lived botnet or misconfiguration activity from persistent worm activity.
Sessions and flows: Basic flows use source and destination addresses, ports, and protocol as a 5-tuple, while activity flows aggregate basic flows by source and timeout.

E. Attack Evolution

Attack-evolution analysis learns normal temporal and relational behavior, then identifies unusual changes across sources, countries, ports, and honeypots. The surveyed methods include temporal aggregation, regression, graph statistics, and deviation-based detection.

Objective: Attack-evolution analysis seeks to learn normal behavior so changes in temporal patterns can signal important events.This framing applies to behavior associated with a specific source, port, or country.
Temporal analysis: Temporal ratios across multiple time aggregates reveal trends that may be hidden at a single time scale.Smaller time units suit short, high-intensity attacks, while stealthier phenomena may require longer intervals.
Graph-based analysis: Graph-based locality statistics measure structural changes and identify honeypots capturing unique attacking IP addresses.High maximal standardized locality indicates a major topology change, whereas stable edge counts produce values near zero.
Deviation detection: Deviation values identify large-scale unusual events, with β > 10 indicating botnet waves or fast-scanning worms and β > 3 indicating slow-scanning worms.The method uses profiles derived from honeypot and Bro events, but can also be applied to pure honeypot data.
Regression models: 2%-20% of attacks from some countries still produced models strongly correlated with the overall attack dataset.The surveyed linear-regression approach evaluates whether country-specific observations describe complete attack data.

F. Propagation of Attacks

The survey describes propagation analysis as tracking attackers and attack patterns across distributed honeypots using temporal, graph, visual, correlation, and clustering methods. These approaches expose repeated presence, target sequences, topology changes, and common attack patterns, while their effectiveness depends on data and algorithm choices.

Cross-honeypot propagation: Propagation occurs when an attacking IP address appears on one honeypot and subsequently on another within a defined time window.The time constraint improves reoccurrence checks in the presence of IP-address pools.
Propagation graphs: Propagation graphs represent honeypots as nodes and the probability of discovering an IP address at one node after observing it at another as edges.Propagation values tend to be low for nodes outside the same subnet.
Correlation analysis: Attack-origin correlation links attackers to multiple honeypots and measures the ratio of unique attackers observed across sensors.The cited findings report that presence on more than two sensors is very unlikely, while two-dimensional correlation adds time.
Visual analysis: Phase plots show successive targets and coverage, with diagonal lines indicating sequential scans and horizontal lines indicating full coverage.Destination-net footprints count attack sources across targets; hot spots suggest misconfiguration, whereas worms and bots produce even distributions.
Clustering methods: Pattern analysis commonly extracts features, defines a domain-appropriate proximity measure, and groups similar patterns.The survey notes that algorithm choice is difficult because clustering behavior varies with data type, dimensionality, initialization, and parameters.
Pattern detection: Thonnard et al. found three temporal attack patterns: continuous activity, sustained bursts, and ephemeral spikes.Ephemeral spikes can create false similarity under SAX standardization, motivating both global and local similarity measures.
Clustering methods: Unsupervised sub-space clustering and clustering ensembles combine different data-pattern views into a global cluster.The approach is presented as a way to increase clustering robustness and facilitate holistic use of metrics.
Classification: Decision trees performed best for simple suspicious-versus-normal traffic classification, producing few false positives and a moderate number of false negatives.Neural networks performed well but had a high false-negative share, while KNN was too slow for reasonable results.

H. Attack Root Cause Identification

Attack root-cause identification links honeypot clusters to tools, configurations, or attack stages, but this mapping is difficult because one attacker may generate distinct patterns from different machines and polymorphic worms can change appearance.

Clusters do not necessarily map one-to-one to attack tools because different attack stages may use distinct compromised-machine groups.A single attacker can produce different patterns from machines with different IP addresses and geographic locations.
Meaningful cluster assignment requires validating cluster coherence because identical packet counts and ports can arise from different attacks.Payload-content comparisons can supplement transactional statistics when assessing whether clusters share a mutual payload.
Polymorphic worms challenge root-cause identification by changing exploit vectors or attack bodies through encryption, reordering, or inserted garbage.Substring methods such as LCS are insufficient unless invariant substrings can be found for classification.
Port sequences and TCP Initial Sequence Numbers can reveal attack tools through repetitive connection orders or characteristic sequence values.Some tools use fixed or low-entropy ISNs, while port sequences expose hidden patterns in frequent attacks.
Buffer-overflow analysis can use EIP and faulty EIP values, which evaluations report as characteristic of attack tools.
Root-cause assignment requires current knowledge of black-hat tools and vulnerabilities, while increasingly complex worms make payload analysis more useful than purely statistical evaluation.

I. Attack Risk Assessment

The survey describes risk estimation for honeypot attacks using vulnerability severity and exploit analysis, or communication scope when only low-interaction observations are available.

High-interaction honeypots support risk estimation through vulnerability severity and exploit analysis.
Low-interaction honeypots can estimate risk from packet count, exchanged bytes, and communication duration.
Risk estimation can be extended by multiplying the risk value by the number of affected network-feature sub-spaces.
SweetBait combines low- and high-interaction honeypots to create signatures for IDS/IPS sensors and estimate worm virulence from alert activity.Its virulence estimate uses an exponentially weighted moving average of alerts generated by each signature over time.

J. Exploit Detection

Exploit detection and honeypot-data analysis move beyond direct log descriptions toward derived information, using specialized techniques and interdisciplinary methods to identify compromises and patterns.

High-interaction honeypots analyze exploited vulnerabilities using data-driven detection or operating-system state monitoring.Argos exemplifies dynamic taint analysis, while Capture-HPC exemplifies operating-system state monitoring.
SweetBait extends Argos memory tainting by inserting shellcode into attacked code to gather more memory and process-state information.
Honeypot research commonly measures attack source, target, and frequency because these features are directly recorded in ordinary logs.Typical logs contain source, target, and timestamp information, making these questions straightforward to formulate.
Derived analysis is more complex than descriptive analysis and includes pattern detection through diverse similarity measures and clustering algorithms.The survey links this work to association-rule mining, neuronal networks, memory tainting, and sophisticated honeypot networks.

VI. LEGAL AND ETHICAL CONCERNS

Honeypot deployment raises entrapment, privacy, legal, and liability concerns because systems intentionally expose vulnerabilities and collect data from attackers and potentially affected third parties.

Honeypot legality is country-dependent, and cross-border attacks can make it difficult to determine which laws apply.
Entrapment Challenges: Entrapment concerns arise because honeypots are deliberately configured to receive attacks and may expose known vulnerabilities.The survey distinguishes this from active persuasion, since server honeypots generally wait for incoming connections.
Privacy Challenges: Privacy analysis depends on what honeypots collect and how administrators use the data, including metadata and transmitted content.Low-interaction systems tend to collect metadata, while high-interaction systems focus on larger amounts of content data.
Privacy Challenges: Non-anonymized IP addresses paired with timestamps may be treated as personal data, and some local regulations restrict their storage.The survey gives Germany as an example where such storage is allowed for 7 days to ensure service operation.
Liability Challenges: Honeypot logs require careful handling because they can include victims, spoofed backscatter, and traffic from hijacked systems.The survey states that legal risks seem negligible when tools are used to secure one’s own systems, provided the honeypot causes no harm.
Liability Challenges: Known vulnerabilities can allow low-interaction honeypots to participate in spoofing or amplification attacks and high-interaction systems to execute arbitrary code.The survey identifies greater harmful-utilization risk at higher interaction levels and discusses possible operator liability.
Liability Challenges: Publishing honeypot software may also create legal exposure where laws punish software intended to intercept data or facilitate hacking attacks.