Pith. sign in

REVIEW 4 major objections 5 minor 42 references

Initial Evidence of Elevated Reconnaissance Attacks Against Nodes in P2P Overlay Networks

T0 review · 4 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Running an Ethereum P2P node draws significantly more reconnaissance attacks than a comparable honeypot.

desk verdict A plausible but not airtight measurement study; the port scan is the strongest part, while the GLMM treatment effect is confounded by IP-pool differences. read the letter →

arxiv 2411.14623 v2 pith:XJS3II4Y submitted 2024-11-21 cs.CR cs.NI

Scott Seidenberger , Anindya Maiti This is my paper · ORCID
classification cs.CRcs.NI
keywords P2PoverlaynetworksEthereumnodesreconnaissanceattackshoneypotsportscanningattacksurfaceproof-of-stakenetworkmeasurement
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tests whether joining a public peer-to-peer (P2P) network makes a host a more attractive target for internet attackers. The authors ran real Ethereum beacon nodes next to full-port honeypots on the same machines, and honeypot-only control machines in five world regions, for two months. The Ethereum nodes received a substantially higher volume of attacks than the controls—about three times higher in the fitted model—and the extra traffic aimed at P2P discovery ports, RPC ports, SSH, and cloud-credential endpoints. A port scan of 6,184 live Ethereum nodes found that 25.68% exposed at least one non-P2P port, so the elevated risk is not confined to the authors' own deployment. If the finding holds, operating P2P infrastructure carries a concrete security cost, and node operators should harden their hosts accordingly.

What carries the argument

The load-bearing mechanism is a paired deployment: each experimental server ran a real Ethereum beacon node (a consensus client paired with an execution client) alongside a full-port honeypot platform, while each control server ran only the honeypot platform, with one pair of servers in each of five geographically distributed cloud regions. This makes the presence of the Ethereum node the intended difference between groups and lets every inbound interaction with the honeypot containers be logged as an attack. The statistical workhorse is a generalized linear mixed model with a log-transformed attack count as the response, experimental-versus-control status as a fixed effect, and geographic region as a random effect; the coefficient $\hat{\beta}_1 = 1.111$ is the paper's estimate of the attack increase attributable to running a node. The complement is an external TCP port scan of 6,184 live Ethereum nodes, which extends the exposure finding from the authors' own servers to the wider network.

What would settle it

Repeat the two-month deployment with identical instance types, disk sizes, and randomized IP assignment for experimental and control servers in the same regions; if the attack-count gap disappears or falls to background noise, the claim that the P2P node drives the elevation would be refuted. An independent random sample of live Ethereum nodes, port-scanned by a second party, could also test the 25.68% open-port rate; a rate close to the ordinary cloud-host baseline would undermine the generalization.

Watch

Extended reading notes

Core claim

The central discovery is that Ethereum P2P nodes are disproportionately targeted by reconnaissance, not merely exposed to background internet noise. In a generalized linear mixed model that adjusts for geographic region, the experimental group's log-transformed attack count was significantly higher than the control group's ($\hat{\beta}_1 = 1.111$, $SE = 0.008$, $z = 147.289$, $p < 0.001$), corresponding to roughly three times the attack count. The additional attacks were not generic background traffic: they included HTTP requests for `.env` files and cloud metadata credentials, more concentrated SSH login attempts (Gini 0.43 versus 0.25), and scans of P2P discovery and RPC ports even after Ethereum's shift to proof-of-stake. A TCP scan of 6,184 live beacon nodes showed that 25.68% had at least one open port beyond their P2P ports, most commonly SSH (13.63%) and HTTP/HTTPS (about 12.7% each), with 2.99% exposing the default RPC port (8545). The paper concludes from these results that P2P overlay nodes are treated by attackers as valuable persistent hosts, and that host-level and network-level hardening is warranted.

Load-bearing premise

The claim that the Ethereum node itself causes the elevated attacks assumes the experimental and control servers are otherwise comparable; the experiment gave the node group larger instances with larger disks, so if instance size or cloud-assigned IP reputation changes inbound scan volume, the measured effect would be overstated.

Editorial extensions

If this is right

  • Node operators should treat a P2P beacon node as a public-facing service and apply host hardening—key-only SSH, firewalled RPC, credential hygiene—because the node itself attracts reconnaissance.
  • Because P2P discovery ports are targeted even under proof-of-stake, the node's networking stack is a live attack surface, so client updates and patching matter even when the RPC port is closed.
  • Because attacks originate disproportionately from networks other than those hosting Ethereum nodes, operators can filter or throttle high-scan ASNs without losing many legitimate peers.
  • Exposed administrative ports on 25.68% of live nodes mean many existing operators are one vulnerability away from compromise, making the measured attack premium a practical risk rather than a theoretical one.
  • The observed 20% peer loss during an active attack shows that aggressive scanning alone can disrupt beacon duties, so reconnaissance is itself a denial-of-service vector.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If public visibility in the peer table is what attracts scans, other P2P networks with openly enumerable peer lists—Bitcoin, IPFS, file-sharing overlays—likely carry a similar attack premium; the paper only measured Ethereum, so this is an extrapolation.
  • The ASN-divergence result suggests a concrete, testable defensive rule: block or rate-limit ASNs with heavy scanning but low peer density, then measure how much attack traffic is removed without reducing peer connectivity.
  • The 25.68% figure comes from nodes listed by one popular explorer; an independent random sample of the live network would be a stronger test and could reveal whether open RPC ports correlate with client version or node age.
  • A longitudinal version of this measurement could serve as an early-warning signal for decentralized infrastructure: a sudden rise in nodes with open RPC ports might precede a wave of wallet-draining exploits.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper reports a two-month measurement study in which the authors placed T-Pot honeypots on ten AWS EC2 instances across five regions, with five 'control' honeypots and five 'experimental' honeypots that additionally ran Ethereum beacon nodes. The central claim is that Ethereum P2P nodes receive significantly more reconnaissance and attack traffic than matched controls: Section 4.1 reports a GLMM fixed effect for the experimental group of beta = 1.111 (SE = 0.008, z = 147.289, p < 0.001). The paper also reports targeted HTTP URI requests, a more concentrated distribution of SSH login attempts against the experimental group, and an Internet-wide scan of 6,184 Ethereum nodes showing that 25.68% had at least one open non-P2P port. The authors conclude that running a P2P node increases a host's attack surface and recommend network-layer mitigations for decentralized networks.

Significance. If the causal interpretation is warranted, the finding is of practical interest to operators of Ethereum and other P2P nodes: it would show that merely participating in the P2P overlay attracts materially higher reconnaissance traffic and that many existing nodes expose additional administrative ports. The paper also offers a potentially replicable honeypot-plus-node measurement design and contributes a useful descriptive scan of the live Ethereum node population. However, the headline causal claim rests on the comparability of the experimental and control groups, and the manuscript's own Table 1 shows they differed in instance type and disk size. With only one control and one experimental public IP per region, the GLMM group coefficient is inseparable from IP-pool and instance-reputation effects. The independent port-scan evidence documents exposure but does not by itself establish elevated attack rates. The absence of released data and code also prevents independent verification of IP-pool balance and raw count distributions.

major comments (4)
  1. [Section 4.1, Table 1] The central claim that Ethereum nodes are targeted more than controls is supported by a GLMM whose group fixed effect is fully confounded with differences in instance type and IP-pool reputation. Table 1 shows the experimental group used r7/6i.xlarge instances with 2500 GB disks while the control group used m7/6i.large instances with 128 GB disks. Since there is only one control and one experimental public IP per region, any systematic difference between the two IP allocations—such as different /24 ranges, prior scan history, or cloud reputation—will be absorbed by the 'Group (Experimental)' coefficient. The model adjusts only for region, not for instance type, IP pool, or a per-VP random intercept, so it cannot rule out the most plausible non-Ethereum explanations for the elevated attack counts. This is load-bearing for the paper's headline finding and must be addressed, either with additional data that separate VP-level effects or by reframing the claim as a descriptive association with the specific IPs used.
  2. [Section 4.1, Table 2] The GLMM is reported with 100,000 observations from only 10 VPs over two months, but the manuscript never defines the aggregation unit or the temporal resolution of those observations. With five experimental and five control servers, a z-statistic of 147.289 cannot be taken at face value unless the model properly accounts for repeated measurements within each VP. The paper also uses the random-effects variance (sigma^2 = 0.050, SE = 0.030) to argue that regional variability is small and that the fixed effect explains the variability, but with only five regions this variance estimate is highly uncertain. The authors should report the number of repeated observations per VP, the correlation structure assumed, and sensitivity of the coefficient to excluding individual VPs.
  3. [Section 4.2, Figure 4] The 'targeting ratio' used to compare experimental and control groups for URI request categories is descriptive, with no confidence intervals, significance tests, or adjustment for multiple comparisons. The ratio of experimental to control counts can exceed 1 simply because the control honeypots attract a large baseline of generic scanning traffic, so the numerator and denominator are not independent benchmarks of targeted behavior. Given that the earlier GLMM already reports a strong overall group difference, the URI analysis should at least present per-category tests or a clear statement that the figure is illustrative rather than inferential.
  4. [Section 4.4] The port-scan claim that 25.68% of live Ethereum nodes have at least one open port beyond their P2P ports is based on scanning only the top 100 ports from the authors' honeypot data plus default RPC/P2P ports. The manuscript does not list those 100 ports, and it is unclear whether the scan covered all common administrative and monitoring ports or only a subset. The paper also reports 6,185 nodes identified but uses 6,184 as the denominator, a numerical inconsistency that should be corrected. The scan result supports exposure, but its completeness and precision should be clarified before it is used to generalize the threat assessment to the wider P2P network.
minor comments (5)
  1. [Throughout] There are several typos and duplicated words, including 'attributable to to geographic differences' and 'variability can can be attributed' in Section 4.1; these should be corrected during revision.
  2. [References] References [9] and [10] cite the same paper in different formats; this duplicate citation should be consolidated.
  3. [Section 4.4] The paper says 'we identified 6,185 active beacon nodes' but then reports the denominator as 6,184 in the 25.68% calculation; the correct count should be stated consistently.
  4. [Appendix C] The figure numbering is confusing: the main text refers to 'Figure 7' for the top-50 ports and then to 'Figure 7 in the Appendix' for the full distribution, and the same figure appears in the supplementary results. The figures should be renumbered and referenced unambiguously.
  5. [Data Availability] The authors state that the AMIs are available as artifacts, but they do not provide a data availability statement for the raw honeypot logs, P2P session data, or scan results. Releasing aggregated count data would substantially strengthen the reproducibility of the main statistical claims.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the central result is a controlled measurement against external honeypot baselines.

full rationale

This paper is a measurement study, not a derivation. The headline claim (Section 4.1) that experimental Ethereum beacon nodes receive more attacks than control honeypots is supported by a GLMM fitted to independently measured attack counts from two groups that differ by whether an Ethereum node runs alongside the honeypot. The response variable, logged honeypot interaction counts, is not defined in terms of the hypothesis, and the group coefficient is estimated from data rather than imposed. The port-scan result (25.68% of scanned live nodes with open ports beyond P2P ports) is likewise a descriptive measurement of external hosts. No fitted parameter is renamed as a prediction, no equation collapses to its own input, and no load-bearing claim is justified only by a self-citation. The most plausible concerns, such as the control and experimental groups using different EC2 instance types and disk sizes (Table 1), so the GLMM group effect may partly reflect IP-pool or instance-reputation differences, are threats to internal validity, not circularity, because the attack counts remain an externally observed benchmark. Accordingly, no circular step is identified.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new theoretical entities, particles, or forces. It relies on existing Ethereum clients, T-Pot honeypots, and standard network metrics. The free parameters listed are hand-chosen analysis thresholds or visualization settings that affect the reported numbers. The axioms are domain assumptions about the measurement environment and statistical model.

free parameters (3)
  • Gaussian smoothing bandwidth (sigma) = 3.5
    Used in Figure 5 to smooth attack and node densities over IPv4 space; chosen by hand for visualization, and different values would change the perceived overlap between attack sources and node locations.
  • Peer tenure top-N cutoff = 1000 peers per region
    The tenure distribution (Figure 2) is computed on the top 1000 peers by data volume per region; changing this threshold alters the distribution and the reported mean tenure (mu = 26.46).
  • Top-100 port list for node scans = Top 100 ports from honeypot data plus default RPC/P2P ports
    Port scans of 6,185 nodes targeted these ports; choosing a different port list would change the fraction of nodes with open ports (25.68%) and the reported prevalence of specific services.
assumptions (4)
  • domain assumption Honeypot interactions represent adversarial attacks
    Section 3.3 defines an 'attack' as any logged interaction with a honeypot container; this includes benign scanners and background internet noise, so the attack counts may overstate true adversarial activity.
  • domain assumption AWS EC2 public IPs are representative of Ethereum node hosting environments
    All vantage points are on AWS EC2; results may not transfer to residential or other cloud providers, as IP reputation and scan patterns differ.
  • domain assumption The node explorer's list of active beacon nodes is complete and unbiased
    Section 4.4 scrapes a popular node explorer to identify 6,185 nodes; if the explorer under- or over-represents certain node types, the open-port statistics may not generalize.
  • domain assumption GLMM distributional and independence assumptions hold
    Section 4.1 uses a log-transformed linear mixed model with 100,000 observations; no autocorrelation or overdispersion checks are reported, so the reported p-values may be anti-conservative.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Initial Evidence of Elevated Reconnaissance Attacks Against Nodes in P2P Overlay Networks." pith.science (2026). https://pith.science/paper/XJS3II4Y

@misc{pith2026241114623,
  author       = {Pith},
  title        = {Pith review of: Initial Evidence of Elevated Reconnaissance Attacks Against Nodes in P2P Overlay Networks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XJS3II4Y}},
  note         = {Machine review of arXiv:2411.14623}
}
read the original abstract

We hypothesize that peer-to-peer (P2P) overlay network nodes can be attractive to attackers due to their visibility, sustained uptime, and resource potential. Towards validating this hypothesis, we investigate the state of active reconnaissance attacks on Ethereum P2P network nodes by deploying a series of honeypots alongside actual Ethereum nodes across globally distributed vantage points. We find that Ethereum nodes experience not only increased attacks, but also specific types of attacks targeting particular ports and services. Furthermore, we find evidence that the threat assessment on our nodes is applicable to the wider P2P network by having performed port scans on other reachable peers. Our findings provide insights into potential mitigation strategies to improve the security of the P2P networking layer.

Figures

Figures reproduced from arXiv: 2411.14623 by the authors.

Figure 1
Figure 1. Top 10% of peers by data volume with under [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Peer tenure distribution, measured as non [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Boxplot highlighting increased reconnais [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Significant categories of HTTP URI requests [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 5
Figure 5. Figure 5: Dual-density plot overlaying adjusted attack [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: Lorenz curve showing the greater concen [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: The top 50 open ports by active scanning of [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: Example of an active attack against the Sen [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

42 extracted references · 40 canonical work pages

  1. [1]

    Eric Alata, Vincent Nicomette, Mohamed Kaâniche, Marc Dacier, and Matthieu Herrb. 2006. Lessons learned from the deployment of a high- interaction honeypot. In 2006 Sixth European Dependable Computing Conference. IEEE, 39–46

    work page 2006

  2. [2]

    Hamad Almohannadi, Irfan Awan, Jassim Al Hamar, Andrea Cullen, Jules Pagan Disso, and Lorna Armitage. 2018. Cyber Threat Intelli- gence from Honeypot Data Using Elasticsearch. In 2018 IEEE 32nd International Conference on Advanced Information Networking and Applications (AINA). 900–906

    work page 2018

  3. [3]

    Manos Antonakakis, Tim April, Michael Bailey, Matt Bernhard, Elie Bursztein, Jaime Cochran, Zakir Durumeric, J Alex Halderman, Luca Invernizzi, Michalis Kallitsis, et al . 2017. Understanding the mirai botnet. In 26th USENIX security symposium (USENIX Security 17). 1093– 1110

    work page 2017

  4. [4]

    Arkime Project. 2024. Arkime: Network Analysis & Packet Capture. https://github.com/arkime/arkime. Version 5.2.0

    work page 2024

  5. [5]

    Paul Barford, Yan Chen, Anup Goyal, Zhichun Li, Vern Paxson, and Vinod Yegneswaran. 2010. Employing honeynets for network situ- ational awareness. Cyber Situational A wareness: Issues and Research (2010), 71–102

    work page 2010

  6. [6]

    Shaileshh Bojja Venkatakrishnan, Giulia Fanti, and Pramod Viswanath

    work page

  7. [7]

    Ismail Butun, Patrik Österberg, and Houbing Song. 2019. Security of the Internet of Things: Vulnerabilities, attacks, and countermeasures. IEEE Communications Surveys & Tutorials 22, 1 (2019), 616–644

    work page 2019

  8. [8]

    Zhen Cheng, Xinrui Hou, Runhuai Li, Yajin Zhou, Xiapu Luo, Jinku Li, and Kui Ren. 2019. Towards a first step to understand the cryptocur- rency stealing attack on ethereum. In 22nd international symposium on research in attacks, intrusions and defenses (RAID 2019) . 47–60

    work page 2019

Show all 42 references
  1. [9]

    Kota Chin and Kazumasa Omote. 2021. Analysis of Attack Activi- ties for Honeypots Installation in Ethereum Network. In 2021 IEEE International Conference on Blockchain (Blockchain) . 440–447

    2021

  2. [10]

    Kota Chin and Kazumasa Omote. 2021. Analysis of attack activities for honeypots installation in ethereum network. In2021 IEEE International Conference on Blockchain (Blockchain) . IEEE, 440–447

    2021

  3. [11]

    Cowrie. 2023. SSH/Telnet honeypot. https://github.com/cowrie/cowr ie

    2023

  4. [12]

    Claude Fachkha and Mourad Debbabi. 2015. Darknet as a source of cyber intelligence: Survey, taxonomy, and characterization. IEEE Communications Surveys & Tutorials 18, 2 (2015), 1197–1227

    2015

  5. [13]

    Ethereum Foundation. 2024. Nodes and Clients. https://ethereum.org /en/developers/docs/nodes-and-clients/

    2024

  6. [14]

    Yue Gao, Jinqiao Shi, Xuebin Wang, Qingfeng Tan, Can Zhao, and Zelin Yin. 2019. Topology measurement and analysis on ethereum p2p network. In 2019 IEEE Symposium on Computers and Communications (ISCC). IEEE, 1–7

    2019

  7. [15]

    Glutton. 2023. Generic Low Interaction Honeypot. https://github.com /mushorg/glutton

    2023

  8. [16]

    Dominic Grandjean, Lioba Heimbach, and Roger Wattenhofer. 2023. Ethereum Proof-of-Stake Consensus Layer: Participation and Decen- tralization. arXiv:2306.10777 [cs.DC] https://arxiv.org/abs/2306.10777

    2023 arXiv

  9. [17]

    Hamed HaddadPajouh, Ali Dehghantanha, Reza M Parizi, Mohammed Aledhari, and Hadis Karimipour. 2021. A survey on internet of things security: Requirements, challenges, and solutions. Internet of Things 14 (2021), 100129

    2021

  10. [18]

    Kazuki Hara, Teppei Sato, Mitsuyoshi Imamura, and Kazumasa Omote

  11. [19]

    Honeytrap. 2021. Advanced honeypot framework. https://github.com /honeytrap/honeytrap

    2021

  12. [20]

    Xiaoyan Hu, Cheng Zhu, Zhongqi Tong, Wenjie Gao, Guang Cheng, Ruidong Li, Hua Wu, and Jian Gong. 2022. Identifying Ethereum traffic based on an active node library and DEVp2p features. Future Generation Computer Systems 132 (2022), 162–177

    2022

  13. [21]

    Niclas Ilg, Paul Duplys, Dominik Sisejkovic, and Michael Menth. 2023. Survey of contemporary open-source honeypots, frameworks, and tools. Journal of Network and Computer Applications (2023), 103737

    2023

  14. [22]

    Mitsuyoshi Imamura and Kazumasa Omote. 2019. Network deploy- ments of bitcoin peers and malicious nodes based on darknet sensor. In Information Security Applications: 19th International Conference, WISA 2018, Jeju Island, Korea, August 23–25, 2018, Revised Selected Papers 19 ....

    2019

  15. [23]

    George Kadianakis, Mary Maller, Andrija Novakovic, and Suphanat Chunhapanya. 2023. Proof of Validator: A Simple Anonymous Cre- dential Scheme for Ethereum’s DHT. https://ethresear.ch/t/proof-of- validator-a-simple-anonymous-credential-scheme-for-ethereums- dht/16454

    2023

  16. [24]

    Lucianna Kiffer, Asad Salman, Dave Levin, Alan Mislove, and Cristina Nita-Rotaru. 2021. Under the hood of the ethereum gossip protocol. In Financial Cryptography and Data Security: 25th International Confer- ence, FC 2021, Virtual Event, March 1–5, 2021, Revised Selected Paper...

    2021

  17. [25]

    Seoung Kyun Kim, Zane Ma, Siddharth Murali, Joshua Mason, Andrew Miller, and Michael Bailey. 2018. Measuring ethereum network peers. In Proceedings of the Internet Measurement Conference 2018 . 91–104

    2018

  18. [26]

    Nethermind Project. 2024. Nethermind: The Ethereum Execution Client. https://github.com/NethermindEth/nethermind. Version 1.27.1+d2d5d4ae

    2024

  19. [27]

    Till Neudecker, Philipp Andelfinger, and Hannes Hartenstein. 2015. A simulation model for analysis of attacks on the bitcoin peer-to- peer network. In 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM). IEEE, 1327–1332. 7 Scott Seidenberger and Anindya Maiti

    2015

  20. [28]

    2023.{DScope}: A {Cloud-Native} Internet Telescope

    Eric Pauley, Paul Barford, and Patrick McDaniel. 2023.{DScope}: A {Cloud-Native} Internet Telescope. In 32nd USENIX Security Sympo- sium (USENIX Security 23) . 5989–6006

    2023

  21. [29]

    Eric Pauley and Patrick McDaniel. 2023. Understanding the ethical frameworks of internet measurement studies. In 2nd International Workshop on Ethics in Computer Security

    2023

  22. [30]

    Sigma Prime. 2024. Lighthouse - Attestation Simulator Metrics. https: //lighthouse-book.sigmaprime.io/validator-monitoring.html#attest ation-simulator-metrics

    2024

  23. [31]

    SM Zia Ur Rashid, Ashfaqul Haq, Sayed Tanimun Hasan, Md Hasan Furhad, Mohiuddin Ahmed, and Abu Barkat Ullah. 2024. Faking smart industry: exploring cyber-threat landscape deploying cloud-based honeypot. Wireless Networks 30, 5 (2024), 4527–4541

    2024

  24. [32]

    SentryPeer. 2024. SentryPeer. https://sentrypeer.org/

    2024

  25. [33]

    Sigma Prime. 2024. Lighthouse: An Ethereum 2.0 Client. https: //github.com/sigp/lighthouse. Version v5.2.1-9e12c21

    2024

  26. [34]

    Kiran Deep Singh. 2021. Securing of Cloud Infrastructure using Enter- prise Honeypot. In 2021 3rd International Conference on Advances in Computing, Communication Control and Networking (ICAC3N) . 1388– 1393

    2021

  27. [35]

    Francesca Soro, Thomas Favale, Danilo Giordano, Idilio Drago, Tom- maso Rescio, Marco Mellia, Zied Ben Houidi, and Dario Rossi. 2023. Enlightening the darknets: Augmenting darknet visibility with active probes. IEEE Transactions on Network and Service Management 20, 4 (2023), ...

    2023

  28. [36]

    T-Pot Project. 2024. T-Pot: The All In One Honeypot Platform. https: //github.com/telekom-security/tpotce. Version 24.04.0

    2024

  29. [37]

    Jay Thom, Yash Shah, and Shamik Sengupta. 2021. Correlation of Cyber Threat Intelligence Data Across Global Honeypots. In2021 IEEE 11th Annual Computing and Communication Workshop and Conference (CCWC). 0766–0772

    2021

  30. [38]

    Taotao Wang, Chonghe Zhao, Qing Yang, Shengli Zhang, and Soung Chang Liew. 2021. Ethna: Analyzing the underlying peer-to- peer network of ethereum blockchain. IEEE Transactions on Network Science and Engineering 8, 3 (2021), 2131–2146

    2021

  31. [39]

    Yixin Wu, Cheng Huang, Xing Zhang, and Hongyi Zhou. 2020. Group- Tracer: Automatic attacker TTP profile extraction and group cluster in Internet of things. security and communication networks 2020, 1 (2020), 8842539

    2020

  32. [40]

    Yichi Zhang, Chunhua Yang, Keke Huang, and Yonggang Li. 2022. Intrusion detection of industrial internet-of-things based on recon- structed graph neural networks. IEEE Transactions on network science and engineering 10, 5 (2022), 2894–2905. A ETHICS To mitigate any potential p...

    2022

  33. [2017]

    Proceedings of the ACM on Measurement and Analysis of Computing Systems 1, 1 (2017), 1–34

    Dandelion: Redesigning the bitcoin network for anonymity. Proceedings of the ACM on Measurement and Analysis of Computing Systems 1, 1 (2017), 1–34

    2017

  34. [2020]

    In 2020 IEEE International Conference on Blockchain (Blockchain)

    Profiling of Malicious Users Targeting Ethereum’s RPC Port Using Simple Honeypots. In 2020 IEEE International Conference on Blockchain (Blockchain). 1–8

    2020

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.