---

honeypot-detector is a standalone security utility designed to identify and flag honeypot systems within a network environment. The build ships as a self-contained package with all detection features enabled at deployment, requiring no additional configuration or dependency resolution. It operates entirely offline, making it suitable for isolated lab, testing, and infrastructure-assessment scenarios where external connectivity is restricted. Detection logic and signature sets are bundled directly into the installer to ensure consistent behavior across environments.

🔧 Requirements

• OS: Windows 10 / 11
• Shell: PowerShell 5.1+ or PowerShell 7+
• Network: internet access to download the script
• Privileges: standard user

Features

• Passive network reconnaissance that maps reachable hosts, open ports, and exposed services without transmitting probe payloads beyond standard connection handshakes.

• Protocol fingerprinting across common service banners, TLS handshake characteristics, and response timing to distinguish emulated services from production deployments.

• Heuristic scoring engine that aggregates behavioral signals—such as inconsistent stack responses, synthetic latency patterns, and default credential surfaces—into a consolidated risk score per endpoint.

• Signature and rule database maintained within the local build, with deterministic matching against known deception frameworks and instrumentation patterns.

• Offline-first operation: all detection logic, rule sets, and reporting execute locally with no outbound telemetry or third-party dependency at runtime.

• Structured reporting output in machine-readable formats for integration into existing assessment pipelines, including per-host findings, evidence references, and confidence levels.

• Configurable scan profiles to constrain scope, concurrency, and timeout behavior, allowing operation against sensitive or rate-limited network segments.

• Deterministic results: identical inputs and rule versions produce identical outputs, supporting reproducible assessments and audit trails.

• Self-contained runtime with bundled dependencies; no external package resolution or environment provisioning is required after deployment.

• Local logging with configurable verbosity and retention, enabling post-scan review without reliance on remote collection infrastructure.

How it works

The detector operates as a local, self-contained inspection pipeline. No external services are contacted during analysis; all processing occurs on the host machine.

1. Interface enumeration. On launch, the tool enumerates local network interfaces and captures the current link-layer and IP configuration. This establishes a baseline for the host's own addresses so that they are excluded from subsequent inspection results.
2. Passive traffic sampling. The detector attaches a packet capture routine to the active interfaces in promiscuous-free mode. It records only packet headers and protocol metadata by default; payload inspection is opt-in and scoped to the protocols selected in the configuration. Filters are applied at capture time to limit processing to relevant traffic classes.
3. Protocol fingerprinting. For each observed flow, the engine builds a fingerprint from TCP/IP stack characteristics: initial TTL values, TCP window sizes, option ordering, timestamp behavior, ICMP response patterns, and retransmission timing. These observable traits are compared against known stack signatures to estimate the originating operating system and virtualization layer.
4. Service behavior probing. Declared open ports are probed with benign, protocol-conformant requests. The tool records responses that deviate from expected behavior for the advertised service — for example, an SSH banner inconsistent with the port's claimed role, a web server returning synthetic content, or a service that answers identically across distinct protocol probes.
5. Configuration anomaly scoring. Findings are scored against a weighted rule set covering known honeypot and emulation indicators: truncated protocol implementations, missing or inconsistent error responses, uniform latency across unrelated services, and discrepancies between advertised and observed stack behavior. Each rule contributes an explicit weight, and the aggregate score is retained alongside the individual contributing findings.
6. Result reporting. Output is written to a local report containing the observed endpoints, matched signatures, per-rule scores, and the evidence that triggered each match. Reports are generated in structured formats suitable for diffing across runs, allowing repeated scans of the same network segment to be compared over time.
7. Configuration and rule updates. Detection rules and stack signatures are stored as local data files loaded at startup. Operators can inspect, modify, or extend the rule set directly; no network fetch is performed to update rules. All configuration is versioned in plain text for auditability.

Because analysis is deterministic and rule-based, each finding is traceable to a specific observation and a specific rule, which supports independent verification of any reported result.

Privacy

honeypot-detector operates entirely on the local machine. No telemetry, analytics, crash reports, or usage statistics are transmitted to the project maintainers or any third party. The tool does not establish outbound connections during detection, scanning, or analysis operations.

Data handling:

• All scan results, detection logs, and configuration files are written to local disk paths under the user's control. The project defines no remote logging or synchronization endpoints.
• No account, license key, or registration is required. The tool does not generate or store persistent device identifiers.
• Temporary artifacts created during a scan are confined to the working directory and are removed on completion unless the user explicitly enables result retention.

Network behavior:

• Detection logic runs offline; the tool does not submit inspected hosts, addresses, or fingerprints to external services.
• Any network activity is limited to the hosts the user explicitly targets during a scan. No background polling, update checks, or beaconing occurs.
• The project ships no embedded third-party analytics SDKs or tracking libraries.

Configuration and permissions:

• The tool reads only the paths and targets specified in the user's configuration. It does not enumerate unrelated files or directories.
• Elevated privileges are requested only for operations that require them and are documented per feature; the tool degrades gracefully when run unprivileged.

Verification:

• Because all processing is local, privacy properties can be verified directly: inspect process network activity with standard OS tooling and review the local log output. No hidden data flows exist beyond what is observable on the host.

Users are responsible for the sensitivity of the data they choose to scan and for securing local result files according to their own policies.

FAQ

Is honeypot-detector a standalone application or does it require external services?

The tool operates as a self-contained local build. Detection logic, signature sets, and heuristic rules are packaged within the application directory; no remote API calls, telemetry endpoints, or cloud dependencies are required for core operation. Optional update checks are disabled by default and can be enabled explicitly in the configuration file.

Which environments does this build support?

The distribution targets Windows x64 desktop systems. It is validated against standard user and administrator contexts. Running the tool from a non-privileged account limits certain network-level inspection capabilities, but the detection engine itself remains functional; elevated privileges are required only for raw socket capture and host-level adapter enumeration.

How does honeypot-detector identify a honeypot without contacting external intelligence feeds?

Detection relies on local analysis of observable artifacts: anomalous service banners, inconsistent TCP/IP stack fingerprints, port-response timing irregularities, and known deception signatures bundled with the build. Because all evaluation happens on-host, results are reproducible offline and do not depend on third-party reputation data.

Are detection signatures updated, and how stale can they become?

The bundled signature set is versioned and shipped with each release. Signature staleness degrades detection of newly deployed deception frameworks but does not affect heuristic and behavioral analysis layers, which are rule-based rather than signature-matched. The configuration file exposes a signature path so operators can swap in an updated local set without reinstalling.

What data does the tool retain, and where is it stored?

Findings, logs, and configuration state are written to the local application data directory. No outbound transmission occurs unless explicitly configured. Log rotation and retention limits are configurable; by default, records are retained for a bounded window and then purged. Operators in regulated environments should review the retention defaults before deployment.

Can detection results produce false positives?

Yes. Any classification produced by signature or heuristic matching carries a non-zero false-positive rate. Behavioral signals such as timing jitter or banner inconsistency can occur on legitimate, misconfigured, or load-balanced services. Treat output as an indicator requiring analyst review rather than a definitive verdict, and corroborate findings against your own network baselines.

Does running scan activity against third-party hosts require authorization?

Yes. Active probing of systems you do not own or administer may violate law, contractual terms, or acceptable-use policies. The tool is intended for use on infrastructure within your own scope of control or under explicit written authorization. The build includes no mechanism to bypass that requirement, and operators are solely responsible for lawful use.

What are the resource requirements during operation?

Memory and CPU consumption scale with the number of concurrent targets and the depth of inspection enabled. Large-scale scans benefit from the configurable concurrency ceiling in the settings file; reducing it lowers resource pressure at the cost of throughput. The tool does not install persistent background services beyond the optional scheduled-task entry, which is opt-in.

How is the build's integrity verified before execution?

Each release publishes a checksum manifest alongside the package. Verify the archive hash against the manifest before extraction. The application does not self-modify at runtime, and configuration changes are confined to the documented settings file, making post-deployment integrity checks straightforward.

Where should issues be reported?

Report defects through the project's own issue tracker with the build version, operating system, and a minimal reproduction description. Do not include raw capture data or host identifiers in reports unless redacted. Security-relevant findings should follow the project's disclosure guidance rather than public issue threads.

Disclaimer

This document is provided for informational and educational purposes only. The honeypot-detector project is a technical utility intended to assist security researchers, network administrators, and penetration testers in identifying and evaluating honeypot systems within controlled, authorized environments. Nothing in this README constitutes legal advice, a guarantee of detection accuracy, or an endorsement of any particular use case.

Detection results produced by honeypot-detector are probabilistic and heuristic in nature. Honeypot implementations vary widely in sophistication, and no automated tool can reliably identify every honeypot or eliminate all false positives. Findings should be treated as indicators requiring independent validation, not as definitive conclusions. Users are responsible for verifying results against their own threat models, network baselines, and operational context before acting on any output.

The software is designed to be operated only on systems and networks for which the user holds explicit authorization. Scanning, probing, or analyzing infrastructure without proper written permission may violate applicable computer misuse laws, terms of service, or organizational policy. The maintainers assume no liability for misuse, unauthorized deployment, regulatory noncompliance, or any direct or indirect damages arising from the use or inability to use this tool.

honeypot-detector is distributed on an "as is" basis, without warranties of any kind, whether express or implied, including but not limited to merchantability, fitness for a particular purpose, and non-infringement. The maintainers make no commitment regarding the completeness, timeliness, or continued accuracy of detection signatures, indicator lists, or heuristic rules, which may change as honeypot techniques evolve.

No data is transmitted to the maintainers during normal operation. All analysis is performed locally, and any telemetry, logging, or reporting behavior is governed by the configuration chosen by the operator of the tool. Users are solely responsible for the handling, retention, and disclosure of any data collected during operation, including compliance with applicable privacy and data protection requirements.

References to third-party protocols, platforms, or technologies are descriptive only and do not imply affiliation, sponsorship, or endorsement. The honeypot-detector project name and any associated identifiers remain the property of their respective holders. By using this software, you acknowledge that you have read and understood this disclaimer and accept full responsibility for your use of the tool.

License

This project is distributed under the MIT License. The full license text is provided in the LICENSE file at the root of the repository and governs all use, reproduction, modification, and redistribution of the source code and accompanying documentation.

Permission is granted, free of charge, to any person obtaining a copy of this software and associated documentation files, to deal in the software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the software, subject to the conditions that the copyright notice and this permission notice are included in all copies or substantial portions of the software.

The software is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose, and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the software or the use or other dealings in the software.

Third-party dependencies bundled with or referenced by this project remain under their respective licenses. Consult the dependency manifest and the corresponding license files in the vendored directories before redistribution. No additional restrictions are imposed on the core project code beyond those stated in the MIT License.

Contributions submitted to this project are accepted under the same license terms unless explicitly stated otherwise in the contribution itself.