Identifying and characterizing ZMap scans: a cryptanalytic approach

Johan Mazel; R\'emi Strullu

REVIEW 4 major objections 5 minor 33 references

Identifying and characterizing ZMap scans: a cryptanalytic approach

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

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

Pith's one-line read A handful of observed probe addresses reveals the multiplicative generator driving a ZMap scan, allowing identification and characterization even when the scanner masks its IP-ID fingerprint.

desk verdict Genuinely new cryptanalytic detector for ZMap scans, but the headline real-world result depends on an unverified historical blacklist match and the abstract overstates the unqualified success rate. read the letter →

arxiv 1908.04193 v2 pith:PEVH2GT5 submitted 2019-08-12 cs.CR

Johan Mazel , Rémi Strullu This is my paper · ORCID

classification cs.CR

keywords ZMapdetectionInternet-widescanningcryptanalysisdiscretelogarithmscancharacterizationnetworktelescopebackbonetrafficgeneratorrecovery

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 tries to establish that a ZMap scan can be identified and dissected from very few observed destination addresses, by treating the scanner's address order as a cryptographic sequence and inverting it. The authors show that whenever the observer's subnet lies wholly inside the scanned set, ZMap's mapping reduces to adding a fixed offset, so the observed addresses reveal the multiplicative generator $g$ that drives the scan. That lets Det2 recover $g$ from 20 packets (or Det1 from three consecutive packets) without relying on ZMap's well-known IP ID value of 54321. On network telescope and backbone traffic from 2014–2017 the method identifies 11,302 of 39,750 scans that carry ZMap's IP ID, and even catches three scans that masked it. If the method holds, operators gain a practical way to predict upcoming probes, identify targeted prefixes, and characterize probing speed and coordination.

What carries the argument

The load-bearing object is ZMap's multiplicative iterator in the finite field $\mathbb{F}_p$: a random primitive root $g$ and a starting state $s_0$ generate each scanned state via $s_i = g\,s_{i-1} \bmod p$, and the actual probe address is $f(s_i)$. The argument lives in Theorem 1's affine collapse: if the observed subnet $O$ lies inside a scanned subnet $I\subseteq S$, then for every observed address $f(x) = x + \mathrm{offset}$ (after host-byte conversion), whether ZMap uses its radix table or its tree mapping. That collapse converts address observations into linear equations in the state sequence, so the generator $g$ can be solved from three consecutive addresses (Det1) or found by a discrete-log search over coprime multipliers (Det2). The machinery is completed by baby-step giant-step or Pohlig–Hellman algorithms to compute logarithms in $\mathbb{F}_p$ with $p\le 2^{32}+15$.

What would settle it

Generate a ZMap scan with a known seed and a custom blacklist over a /24 observation network, record the 20 addresses, and run Det2 with the true offset: it should recover exactly the generator $g$ that ZMap derives from the seed. Then run it with the paper's 2019-archived default-blacklist offsets; if that blacklist version contains an address inside the observed subnet, the affine relation fails and Det2 should return 'not a ZMap scan' or a wrong $g$. Repeating this across the historical datasets with operator-known blacklist versions would settle whether the reported 28.5% is a method limit or an artifact of mismatched offsets.

Watch

Extended reading notes

Core claim

The central discovery is that ZMap's IPv4 iteration is cryptanalytic: each probed address is the output of a deterministic permutation over the finite field $\mathbb{F}_p$ whose internal state advances by $s_i = g\cdot s_{i-1} \bmod p$, and under the paper's observation-network hypothesis the mapping collapses to $f(x) = x + \mathrm{offset}$. Theorems 1–3 turn this into an identification procedure: three consecutive packets yield $g$ by $g = (h_3-h_1)/(h_2-h_1) - 1 \bmod p$ (Det1), and for Internet-wide scans, 20 packets yield $g$ by testing values $k$ coprime with $p-1$ for monotonicity of the discrete-log-derived sequence $e_j = \log_a\!\left((h_j-\mathrm{offset})/(h_1-\mathrm{offset})\right) \cdot k^{-1} \bmod (p-1)$ (Det2). With the correct offset Det2 has false-negative rate 0; with $m=20$ the false-positive bound is $9.3\times10^{-9}$. The same recovered generator lets the authors reorder observed packets into scan order and measure progress, visibility, packet rate, targeted prefix, blacklist use (default vs none), and sharding or generator reuse. In real traffic, 28.5% of IP-ID-tagged ZMap scans are identified: 11,302 of 39,750, mostly with the default blacklist.

Load-bearing premise

The central claim collapses if the affine relation $f(x)=x+\mathrm{offset}$ used by Det2 is wrong for a scan, which happens whenever the observation network contains a blacklisted address or the archived default blacklist does not match the scan's actual blacklist.

Editorial extensions

If this is right

A network operator who sees 20 packets from a single source can decide whether the source is running ZMap and, if so, recover the generator and offset, which identifies the scan even when the IP ID is not 54321.
With $g$ known, addresses that the scanner will probe next inside the observed subnet can be computed in advance, enabling proactive blocking rather than post-hoc detection.
The method attributes a targeted prefix to each identified scan from the precomputed offsets, letting administrators separate indiscriminate /0 probing from scans aimed at their network.
Recovered generators expose coordination: identical $g$ across source IPs indicates sharding or shared seeds, and the paper reports groups of 2–39 IPs sharing a generator, mostly within the same /24.
The characterization metrics (progress, visibility, emitted packet rate) reveal operational choices, including scanning above upstream capacity and probing private or reserved addresses with a blacklist-less sweep.

Reading between the lines

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

Because the method's only requirement is a few destination addresses in arrival order, the same inversion template could be applied to any scanner whose iteration is an affine-masked multiplicative generator; the paper studies ZMap, but the cryptanalytic idea is transportable to similar deterministic permutations.
The reported 28.5% identification rate is a lower bound under the paper's strongest assumption; if blacklist offsets reconstructed for the actual 2014–2017 time periods were used, the identified share should rise, and scans currently attributed to custom blacklists could be re-tested.
A live deployment could turn the recovered generator into early warning: predict which addresses in the observed prefix will be probed next and raise alerts per scanner, since the paper provides the state-index machinery but does not design the alerting system.
If multiple vantage points each recover the same generator and offset, the gap between expected and observed probes at each site localizes packet loss, offering a possible network health probe; the paper only notes this possibility in discussion.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Desk Editor's Note

read the letter

Here's my take on Mazel and Strullu's ZMap cryptanalysis paper. The technique is genuinely new: recovering ZMap's LCG generator and offset from a short sequence of observed addresses via discrete logarithms, with a neat affine mapping result (Theorem 1) over a contained subnet. That's a real step beyond Doerr et al.'s GPU brute force and the IP-ID heuristics of prior work. The synthetic evaluation is clean, and the real-world characterization (targeted prefix, progress, visibility, packet rate, generator reuse) is useful, even if some parts are openly exploratory.

The soft spots are real but addressable. Theorem 3's false-positive bound rests on an unstated independence and equidistribution assumption about discrete logs; the bound looks fine for m=20, but it isn't a proven theorem. The bigger issue is blacklist versioning. Section 4.4 precomputes offsets from the 2019-archived default blacklist and applies them to telescope data from 2014–2015 and backbone data from April 2017. The paper never checks that the blacklist version matches those periods, and [16] documents that the default list grew by thousands of /24 exclusions. A wrong offset shifts the discrete-log ratios, so detection fails or, worse, attributes a spurious generator. That makes the 28.5% headline and the BZMap-vs-/0 attribution in Table 3 conditional on an unverified historical match. The abstract also drops the qualifiers the body states (at least 20 packets, IP-ID labeled, default or empty blacklist).

None of this kills the method. Theorems 1 and 2 hold on their own; the synthetic results show the machinery works when the offset premise holds. The real-world numbers stay credible as estimates of what is detectable under those assumptions. I'd want the authors to re-run with a version-matched blacklist or state clearly that the results are contingent, and I'd want the false-positive bound labeled as an assumption rather than a proven guarantee.

Who's this for? Security analysts and network measurement researchers working on scan detection and attribution. I'd cite it, and I'd send it to a serious referee. The contribution deserves space in a good security venue, provided the empirical claim gets cleaned up.

Referee Report

4 major / 5 minor

Summary. The paper proposes two methods to identify ZMap scans from short sequences of observed IPv4 addresses by recovering the generator g of ZMap's modular iterator. Det1 applies when the observation network contains the whole scanned set and uses three consecutive observed addresses; Det2 applies to Internet-wide scans and uses discrete logarithms combined with a precomputed offset. The authors prove (or sketch) four theorems, validate Det2 on synthetic ZMap output, and apply it to network telescope data (June 2014–January 2015) and MAWI backbone data (April 2017), reporting identification of 28.5% of ZMap-fingerprinted scans with at least 20 packets (11,302 of 39,750 in Table 3). They also characterize targeted prefixes, packet rates, visibility, progress, and generator reuse.

Significance. The core idea is novel and potentially valuable: unlike prior IP-ID-based detection, Det2 works from the address sequence alone and can recover the internal generator state, enabling scan prediction and characterization. Theorem 1, which shows that, under a subnet-containment condition, ZMap's mapping function reduces to an affine offset on the observed subnet, is clean and useful. The synthetic evaluation is thorough and shows perfect detection in the single-threaded, correct-offset case. If the real-world results survive scrutiny, the characterization results (e.g., blacklist usage, sharding, packet-rate estimates) would be a useful addition to the scanning literature. However, the central empirical claim rests on an unverified historical blacklist match and a heuristic false-positive bound, so the significance is conditional on those points being resolved.

major comments (4)

[Abstract; Section 5.2.3, Table 3] The abstract's claim "we manage to identify 28.5% of the ZMap scans in real-world traffic" is unqualified. The 28.5% figure is 11,302 of 39,750 scans that (i) have at least 20 observed packets and (ii) carry the ZMap IP-ID fingerprint (Table 3). Scans with fewer than 20 packets, which the paper itself excludes from Det2, are not in the denominator. The claim should be restated as "28.5% of ZMap-fingerprinted scans with at least 20 observed packets," or the paper should report a properly qualified detection rate over all candidate scans. As written, the headline overstates the method's reach.
[Section 4.4, Section 5.2.1, Section 5.2.3] The offset values fed to Det2 are precomputed from the default ZMap blacklist archived in 2019 (reference [7]), yet they are applied to telescope data from June 2014 to January 2015 and backbone data from April 2017. The default blacklist is not versioned in the paper, and the related work section (and reference [16]) documents that the blacklist grew substantially over time (thousands of /24 exclusions, 5.4 million addresses). Because the offset is the difference between the observed prefix's host-byte position and the number of non-blacklisted addresses before it, any blacklist change before the observed subnet changes the offset. If the offset is wrong, the affine relation f(x)=x+offset collapses and the discrete-log search in Det2 cannot recover the generator. The paper never verifies that the 2019-archived blacklist matches the blacklists actually in force for these historical scans, nor does it test sensitivity to blacklist variations. This is load-bearing: every identification in Table 3 and the BZMap versus /0 attribution depends on this match. The authors should validate the offsets against scans from the same periods with known blacklists, or use date-appropriate blacklist snapshots, or at least quantify how much the offset changes with plausible blacklist differences.
[Section 4.3, Theorem 3] The false-positive bound of Theorem 3 rests on two unproven assumptions: (i) that for any k, the sequence (e_j) defined by e_j = log((h_j-offset)/(h_1-offset)) * k^{-1} mod (p-1) is equidistributed, and (ii) that the events that the sequence is not increasing are independent across different k. These assumptions are not established; for fixed observed values, the events for different k are deterministic functions of the same set of discrete logs and are generally correlated. The independence assumption in particular is used multiplicatively to obtain theta(20, p_4) = 9.3e-9, which the paper cites to justify m=20 and to argue that false positives are negligible across hundreds of thousands of tested scans. As written, this is a heuristic, not a proof. The authors should either provide a rigorous proof of the bound or validate the false-positive rate empirically on non-ZMap traffic (e.g., random address sequences and traffic from other scanners).
[Section 4.3, paragraph after Algorithm 5] The statement "when the offset value is known, the false negative rate is equal to 0" is unqualified and is contradicted by the paper's own experiments: Section 5.1.2 and Figure 3 show success rates below 100% for T=4 and T=10 threads even with known offsets, and Section 5.2.5 demonstrates that packet reordering can defeat detection. The zero false-negative claim holds only for a single-threaded scanner with no packet reordering. It should be reworded to specify these conditions, or the paper should acknowledge that arrival-order perturbations introduce nonzero false negatives.

minor comments (5)

[Section 4.1 and Section 6] The probability that a /16 observation network satisfies the no-blacklisted-address hypothesis is given as 72% in Section 4.1 and as 77% in Section 6. These numbers are inconsistent and should be reconciled.
[Throughout] The manuscript contains several typographical errors and misspellings, including "exteremely" and "phenomenom" (Section 2), "probality" (Theorem 3 proof), and "paralellized" (Section 5.2.4). A careful proofreading pass is needed.
[Section 5.2.9, Figure 7] The text says red curves show scans only identified with the sampled sequence and black curves show scans identified with or without sampling, but the figure caption describes "Black (resp. red) curves" in the opposite order. Please make the color convention consistent between the caption and the text.
[Section 4.5] The offset brute-forcing method assumes ZMap supports the radix table, but the paper does not state clearly which ZMap versions this covers. Since the datasets are from 2014-2017 and the radix table was introduced in v1.1.0 (November 2013), the assumption is likely satisfied, but it should be stated explicitly.
[Section 5.2.3, Table 3] The three backbone scans without the ZMap IP-ID fingerprint that are identified as BZMap are interesting but could be false positives from the heuristic bound in Theorem 3. A brief discussion of why these are not attributed to the heuristic's failure would strengthen the paper.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the detection method is derived from ZMap's documented generator and independently validated on synthetic and real traffic, while the historical blacklist-version concern is a validation risk rather than a circular-input construction.

full rationale

The derivation chain is self-contained and not circular. Section 3 specifies ZMap's public iterator (Eq. 1) and its mapping function, and Section 4 proves Theorem 2 and Theorem 3 purely from those definitions plus the affine-offset lemma in Theorem 1. Det2's discrete-log search is not fitted: it computes f_j from observed addresses and a candidate offset, then searches for any k making the sequence increasing; a non-ZMap input or incorrect offset cannot force a positive result except with the bounded probability quantified in Theorem 3, and the paper states the false-negative rate is zero when the offset is known. The synthetic-data experiments (Section 5.1) generate scans with ZMap's -d option and verify that the correct generator is recovered, so the algorithm is externally validated against an independent generator that was not used to fit any parameter. In real traffic, the positive set is labeled by two independent signals (IP ID 54321 and Threshold Random Walk [24]), and Det2 confirms or rejects each candidate scan rather than being regressed to the label. The only substantial concern in the paper, that offsets precomputed from the 2019-archived default blacklist [7] are applied to 2014-2015 and April 2017 traffic without verifying the blacklist version, is a threat to the empirical 28.5% measurement rather than a circularity: an anachronistic offset would break the affine relation and cause missed detections, which is the direction the paper reports for many scans. No load-bearing self-citation is present; [29] is background on scanning trends, and the uniqueness of the recovered generator is argued from the discrete-log distribution in Theorem 3, not from the authors' prior work. No step reduces by construction to its own input.

Assumptions & free parameters 1 free parameters · 5 assumptions · 0 invented entities

The method is parameter-free with respect to fitting: it recovers (g, offset) rather than estimating them. Design choices are m=20 and the raw/sampled sequence pair. The load-bearing assumptions are the ZMap generator model, the no-blacklist-in-O premise of Theorem 1, the heuristic independence behind Theorem 3, the matching of the 2019 blacklist snapshot to historical traffic, and the arrival-order premise for single-threaded scans.

free parameters (1)

m = 20 (number of observed packets fed to Det2) = 20
Chosen so that the false-positive bound theta(20,p4)=9.3e-9 is small enough for high-volume testing; it is a design threshold, not fitted to the evaluation data.

assumptions (5)

domain assumption Observed ZMap traffic is generated by the documented iteration s_i = g * s_{i-1} mod p with p among {2^8+1, 2^16+1, 2^24+43, 2^28+3, 2^32+15}, g a primitive root, and the mapping f built from whitelist and blacklist (Sections 3.1-3.2).
This is the model of ZMap taken from its source code; if a scanner mimics or modifies the generator, detection assumptions fail.
domain assumption The observation network O is contained in a subnet I of the scanned set S, so no blacklisted address falls inside O's enclosing subnet and Theorem 1's affine relation f(x)=x+offset holds (Section 4.1).
Violated when O contains a blacklisted address; the paper estimates a violation probability of 28% for a /16 based on the blacklist density reported in [16].
ad hoc to paper Discrete logarithms of ZMap state ratios are equidistributed, and the events that a random non-generator k yields an increasing sequence (e_j) are independent across k, giving the false-positive bound of Theorem 3 (Section 4.3).
Justified only by an asymptotic equidistribution citation [20] and an unstated independence assumption; not verified empirically or rigorously for p4.
ad hoc to paper The default ZMap blacklist used to precompute offsets (Section 4.4) matches the blacklist in force for each historical dataset (2014-2015 telescope, April 2017 backbone).
The paper uses the 2019-archived blacklist [7]; [16] shows the blacklist grew over time; no version matching is documented.
domain assumption Arrival order of observed packets equals the order of internal state indices for single-threaded scans; sampling partially mitigates reordering but does not guarantee it (Section 5.2.5).
Multi-threaded scans interleave shards and violate the increasing-sequence property, which Figure 3 shows reduces success.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Identifying and characterizing ZMap scans: a cryptanalytic approach." pith.science (2026). https://pith.science/paper/PEVH2GT5

@misc{pith2026190804193,
  author       = {Pith},
  title        = {Pith review of: Identifying and characterizing ZMap scans: a cryptanalytic approach},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PEVH2GT5}},
  note         = {Machine review of arXiv:1908.04193}
}

read the original abstract

Network scanning tools play a major role in Internet security. They are used by both network security researchers and malicious actors to identify vulnerable machines exposed on the Internet. ZMap is one of the most common probing tools for high-speed Internet-wide scanning. We present novel identification methods based on the IPv4 iteration process of ZMap. These methods can be used to identify ZMap scans with a small number of addresses extracted from the scan. We conduct an experimental evaluation of these detection methods on synthetic, network telescope, and backbone traffic. We manage to identify 28.5% of the ZMap scans in real-world traffic. We then perform an in-depth characterization of these scans regarding, for example, targeted prefix and probing speed.

Figures

Figures reproduced from arXiv: 1908.04193 by the authors.

**Figure 1.** Sharding mechanisms used in ZMap. A primitive root g of Fp and the initial internal state s0 are also randomly generated at the beginning of each scan. If the random generator has good randomness properties, we can suppose that these values are unique and characterize each scan. Then, at each step i in {1,..., p−2}, the state si is updated according to the formula: si = g ·si−1 mod p (1) ZMap supports distributed sc… view at source ↗

**Figure 3.** Det2 success rate for 2, 4 and 10 threads for several sizes of observed prefix O. the sizes of observed prefix O. We observe that the empirical results are similar to those obtained with the formula: t(O) = (m−1)· |S| |O| . This validates the approximation of the probability in Theorem 4. 5.1.2 Number of threads vs detection success ZMap uses an option (-T) to control the number threads that send probing packets. T… view at source ↗

**Figure 2.** Mean number of coprimes tested for several sizes [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗

Figures from the paper (5 more)

**Figure 4.** Figure 4: provide an example of the sampling procedure for a scan with 41 packets. We analyze both the raw sequence {o1 ...o20} and the sampled sequence which contain oi with i = 1...41 and i an odd positive integer [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]

**Figure 5.** Figure 5: Example of scanned network S and observed network O with missing packet for rk = 4 due to packet loss. 5.2.6 Targeted prefix [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]

**Figure 6.** Figure 6: Scatter plot, histograms and ECDF of visibility [PITH_FULL_IMAGE:figures/full_fig_p012_6.png]

**Figure 7.** Figure 7: Emitted packet rate of scans with the ZMap fingerprint and breakdown regarding the use of sampling. Black (resp. red) [PITH_FULL_IMAGE:figures/full_fig_p013_7.png]

**Figure 8.** Figure 8: Stacked histogram of observed packet rate. Attack success is green while failure is red. Dark green represent scans [PITH_FULL_IMAGE:figures/full_fig_p017_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

33 extracted references · 32 canonical work pages

[16]

Alex Halder- man

Zakir Durumeric, Michael Bailey, and J. Alex Halder- man. An internet-wide view of internet-wide scanning. In USENIX Security, pages 65–78, 2014

work page 2014
[2]

https://web.archive.org/web/ 20190116132315/http://mawi.wide.ad.jp/ mawi/

MAWI. https://web.archive.org/web/ 20190116132315/http://mawi.wide.ad.jp/ mawi/. Accessed: 2019-01-28

work page 2019
[4]

https://web.archive.org/web/ 20190116132401/https://www.shodan.io/

Shodan. https://web.archive.org/web/ 20190116132401/https://www.shodan.io/. Accessed: 2019-01-16

work page 2019
[5]

https: //web.archive.org/web/20190122170448/ https://github.com/zmap/zmap/commit/ 0bb01d879ebef2c28f038dd032745c72ad5789e9

Simplify sharding implementation. https: //web.archive.org/web/20190122170448/ https://github.com/zmap/zmap/commit/ 0bb01d879ebef2c28f038dd032745c72ad5789e9. Accessed: 2019-01-22

work page arXiv 2019
[6]

https://web.archive.org/ web/20190405162042/http://researchscan271

University of Michigan. https://web.archive.org/ web/20190405162042/http://researchscan271. eecs.umich.edu/. Accessed: 2019-04-05

arXiv 2019
[9]

Zippier zmap: Internet-wide scan- ning at 10 gbps

David Adrian, Zakir Durumeric, Gulshan Singh, and J Alex Halderman. Zippier zmap: Internet-wide scan- ning at 10 gbps. In WOOT, 2014

work page 2014
[10]

A brief history of scanning

Mark Allman, Vern Paxson, and Jeff Terrell. A brief history of scanning. In IMC, pages 77–82, 2007

work page 2007
[11]

Packet reordering is not pathological network behavior

Jon CR Bennett, Craig Partridge, and Nicholas Shect- man. Packet reordering is not pathological network behavior. Transactions on Networking, 7(6):789–798, 1999

work page 1999

Show all 33 references

[12]

One-way trafﬁc monitoring with iat- mon

Nevil Brownlee. One-way trafﬁc monitoring with iat- mon. In PAM, pages 179–188, 2012

2012
[13]

A course in computational algebraic num- ber theory, volume 138

Henri Cohen. A course in computational algebraic num- ber theory, volume 138. Springer Science & Business Media, 2013

2013
[14]

Scan prediction and reconnaissance mit- igation through commodity graphics cards

Christian Doerr, Mourad el Maouchi, Sille Kamoen, and Jarno Moree. Scan prediction and reconnaissance mit- igation through commodity graphics cards. In CNS, pages 287–295, 2016

2016
[15]

Alex Halderman

Zakir Durumeric, David Adrian, Ariana Mirian, Michael Bailey, and J. Alex Halderman. A search engine backed by Internet-wide scanning. In CCS, pages 542–553, 2015

2015
[17]

Zmap: Fast internet-wide scanning and its security ap- plications

Zakir Durumeric, Eric Wustrow, and J Alex Halderman. Zmap: Fast internet-wide scanning and its security ap- plications. In USENIX Security, pages 47–53, 2013

2013
[18]

A distributed cracker for VoIP

Nicolas Falliere. A distributed cracker for VoIP. https://web.archive.org/web/20190131095815/ https://www.symantec.com/connect/blogs/ distributed-cracker-voip, 2011. Accessed: 2019-01-31

2011
[19]

Scanning the ipv6 internet: towards a comprehensive hitlist

Oliver Gasser, Quirin Scheitle, Sebastian Gebhard, and Georg Carle. Scanning the ipv6 internet: towards a comprehensive hitlist. In TMA, 2016

2016
[20]

Discrete logarithms and their equidis- tribution

D Jason Gibson. Discrete logarithms and their equidis- tribution. Unif. Distrib. Theory, 7:147–154, 2012

2012
[21]

Classi- fying internet one-way trafﬁc

Eduard Glatz and Xenofontas Dimitropoulos. Classi- fying internet one-way trafﬁc. In IMC, pages 37–50, 2012

2012
[22]

MASSCAN: Mass ip port scanner

Robert David Graham. MASSCAN: Mass ip port scanner. https://web.archive.org/ web/20190116132542/https://github.com/ robertdavidgraham/masscan. Accessed: 2019-01- 16

2019
[23]

Measurement and classi- ﬁcation of out-of-sequence packets in a tier-1 ip back- bone

Sharad Jaiswal, Gianluca Iannaccone, Christophe Diot, Jim Kurose, and Don Towsley. Measurement and classi- ﬁcation of out-of-sequence packets in a tier-1 ip back- bone. Transactions on Networking, 15(1):54–66, 2007

2007
[24]

Paxson, AW

Jaeyeon Jung, V . Paxson, AW. Berger, and H. Balakrish- nan. Fast portscan detection using sequential hypothesis testing. In Proc. of SP 2004, pages 211–225, 2004

2004
[25]

Do you see what i see? differential treatment of anonymous users

Sheharbano Khattak, David Fiﬁeld, Sadia Afroz, Mobin Javed, Srikanth Sundaresan, Vern Paxson, Steven J Mur- doch, and Damon McCoy. Do you see what i see? differential treatment of anonymous users. In NDSS, 2016

2016
[26]

Bursty and hierarchical structure in streams

Jon Kleinberg. Bursty and hierarchical structure in streams. Data Mining and Knowledge Discovery , 7(4):373–397, 2003

2003
[27]

Demystifying internet-wide service discovery

Derek Leonard and Dmitri Loguinov. Demystifying internet-wide service discovery. Transactions on Net- working, 21(6):1760–1773, 2013

2013
[28]

Stochastic analysis of horizontal IP scanning

Derek Leonard, Zhongmei Yao, Xiaoming Wang, and Dmitri Loguinov. Stochastic analysis of horizontal IP scanning. In INFOCOM, pages 2077–2085, 2012

2012
[29]

Proﬁling internet scanners: Spatiotemporal structures and measurement ethics

Johan Mazel, Romain Fontugne, and Kensuke Fukuda. Proﬁling internet scanners: Spatiotemporal structures and measurement ethics. In TMA, pages 1–9, 2017

2017
[30]

Observing TCP dynamics in real networks, volume 22

Jeffrey C Mogul. Observing TCP dynamics in real networks, volume 22. 1992

1992
[31]

The state of enter- prise network trafﬁc in 2012

David Murray and Terry Koziniec. The state of enter- prise network trafﬁc in 2012. In APCC, pages 179–184, 2012

2012
[32]

End-to-end internet packet dynamics

Vern Paxson. End-to-end internet packet dynamics. In ACM SIGCOMM Computer Communication Review , volume 27, pages 139–152, 1997

1997
[33]

An improved al- gorithm for computing logarithms over gf (p) and its cryptographic signiﬁcance (corresp.)

Stephen Pohlig and Martin Hellman. An improved al- gorithm for computing logarithms over gf (p) and its cryptographic signiﬁcance (corresp.). IEEE Transac- tions on information Theory, 24(1):106–110, 1978

1978
[34]

Hidden treasures-recycling large-scale internet measure- ments to study the internet’s control plane

Jan Rüth, Torsten Zimmermann, and Oliver Hohlfeld. Hidden treasures-recycling large-scale internet measure- ments to study the internet’s control plane. In PAM, 2019

2019
[35]

Class number, a theory of factorization and genera

Daniel Shanks. Class number, a theory of factorization and genera. In Proc. Symp. Pure Math, 1971, volume 20, pages 415–440, 1971

1971
[36]

A study of internet packet reordering

Yi Wang, Guohan Lu, and Xing Li. A study of internet packet reordering. In ICOIN, pages 350–359, 2004. 15

2004
[37]

Tapdance: End-to-middle anticensorship without ﬂow blocking

Eric Wustrow, Colleen Swanson, and J Alex Halderman. Tapdance: End-to-middle anticensorship without ﬂow blocking. In USENIX Security, pages 159–174, 2014. Supplementary results 7.0.1 Observed packet rate The number of observed packets sent by the scanning IP is m. We note the ...

2014

Pith tools

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

[1] [16]

Alex Halder- man

Zakir Durumeric, Michael Bailey, and J. Alex Halder- man. An internet-wide view of internet-wide scanning. In USENIX Security, pages 65–78, 2014

work page 2014

[2] [2]

https://web.archive.org/web/ 20190116132315/http://mawi.wide.ad.jp/ mawi/

MAWI. https://web.archive.org/web/ 20190116132315/http://mawi.wide.ad.jp/ mawi/. Accessed: 2019-01-28

work page 2019

[3] [4]

https://web.archive.org/web/ 20190116132401/https://www.shodan.io/

Shodan. https://web.archive.org/web/ 20190116132401/https://www.shodan.io/. Accessed: 2019-01-16

work page 2019

[4] [5]

https: //web.archive.org/web/20190122170448/ https://github.com/zmap/zmap/commit/ 0bb01d879ebef2c28f038dd032745c72ad5789e9

Simplify sharding implementation. https: //web.archive.org/web/20190122170448/ https://github.com/zmap/zmap/commit/ 0bb01d879ebef2c28f038dd032745c72ad5789e9. Accessed: 2019-01-22

work page arXiv 2019

[5] [6]

https://web.archive.org/ web/20190405162042/http://researchscan271

University of Michigan. https://web.archive.org/ web/20190405162042/http://researchscan271. eecs.umich.edu/. Accessed: 2019-04-05

arXiv 2019

[6] [9]

Zippier zmap: Internet-wide scan- ning at 10 gbps

David Adrian, Zakir Durumeric, Gulshan Singh, and J Alex Halderman. Zippier zmap: Internet-wide scan- ning at 10 gbps. In WOOT, 2014

work page 2014

[7] [10]

A brief history of scanning

Mark Allman, Vern Paxson, and Jeff Terrell. A brief history of scanning. In IMC, pages 77–82, 2007

work page 2007

[8] [11]

Packet reordering is not pathological network behavior

Jon CR Bennett, Craig Partridge, and Nicholas Shect- man. Packet reordering is not pathological network behavior. Transactions on Networking, 7(6):789–798, 1999

work page 1999