Reports of Telnet's death have been greatly exaggerated

Source: Hacker News

TL;DR

We see no evidence that specific core‑network autonomous systems have blocked Telnet, contrary to earlier reports. Telnet traffic that GreyNoise reported as having dropped to 0 continues to be observed from the same networks. The original drop‑off is likely a measurement artifact or the result of threat actors deliberately avoiding GreyNoise infrastructure—something we cannot confirm without internal data.

---

Background

• A recent GreyNoise blog post claimed that Telnet sessions from major U.S. ISPs collapsed sharply around the time a CVE‑2026‑24061 affecting GNU Inetutils was disclosed.
• The report sparked intense discussion about the role of core‑network providers and the global security of network services.
• Terrace decided to re‑examine the claim using both internal measurements and publicly available data.

---

What the Original Report Showed

The authors described this as a step‑function collapse—not a gradual decline, scanner attrition, or a data‑pipeline issue.

---

Our Investigation

1. Cross‑checking with Terrace data – We compared GreyNoise’s numbers against our own Telnet observations.
2. Open‑source telemetry – Additional community datasets showed no comparable drop.
3. Routing verification – RIPE Atlas measurements confirmed that the underlying paths to the affected ASes remained unchanged.
4. Active probing – As of 18:47 UTC today, we successfully performed Telnet traceroutes from the allegedly‑affected autonomous systems to our servers.

---

Findings

• No new Telnet filtering is being performed by core ISPs.
• The abrupt decline reported by GreyNoise is not reflected in any independent measurement we could locate.
• Possible explanations:
  • Measurement artifact (e.g., sampling error, data‑pipeline glitch).
  • Threat‑actor behavior—actors may have temporarily avoided GreyNoise sensors.

Without access to GreyNoise’s internal logs, we cannot definitively pinpoint the cause.

---

Conclusion

Our analysis indicates that the reported “silencing” of Telnet traffic was not the result of network‑level blocking by major U.S. ISPs. The observed traffic continues to flow, and the original findings appear to stem from methodological issues rather than a genuine shift in Internet routing or filtering policies.

Evaluating Telnet Scanning

Seeing a dramatic, coordinated drop in traffic—from tens of thousands of connections down to zero—naturally raises the suspicion that the network itself is the common factor. However, as we’ll explain below, this line of thinking can be misleading because sessions can be highly correlated: thousands of scans originating from disparate networks may actually be tied to a single noisy source.

Our Approach

At Terrace we leverage artificial‑intelligence‑driven analytics on a global deployment of network sensors to detect trends in real time. When the drop was first observed, our immediate question was:

“How could we have missed this?”

After digging into the data, the answer turned out to be simple: we didn’t miss anything.

Data‑driven Cross‑Checks

1. GreyNoise vs. Terrace Port‑23 Scans

   • We cross‑checked Autonomous Systems (ASes) reported by GreyNoise against our own port‑23 (Telnet) scanning data.
   • Only traffic that successfully completed the three‑way TCP handshake was retained, eliminating the noise from IP‑spoofed packets.

2. AS‑level Summary

   • We examined:
     • All ASes observed by Terrace
     • The subset of sources that appear in GreyNoise
     • The specific group that experienced a complete drop‑off

   In every case, there was no observable change in Telnet‑scanning behavior that could be attributed to ISP‑level blocking. In fact, January 14 fell within a modest spike in Telnet traffic rather than a dip.

3. External Threat‑Intel Validation

   • We compared our findings with open‑source threat data.
   • For example, Dataplane.org – Telnet Login Statistics shows no correlated drop in Telnet traffic, which aligns with our own observations.

Summary

The evidence collectively indicates that the apparent “drop” was not the result of broad ISP‑level blocking or a network‑wide issue, but rather a normal fluctuation within the background noise of Telnet scanning activity.

Measuring Telnet Routing with RIPE Atlas

To validate our findings, we conducted a RIPE Atlas measurement of Telnet traffic deliverability.

• Measurement link: RIPE Atlas measurement 154286388
• Scope: All ASes cited in the report as being completely blocked were tested with a Telnet traceroute.
• Result: In 55 out of 56 cases, Telnet sessions were successfully established with our server.

Conclusion: Across the referenced ASes, there is no observable widespread blocking of TCP port 23 as of February 11.

It’s Not A, It’s B

Looking at the original report’s data in light of our analysis, we can posit several potential interpretations that align with our observations.

When you see a coordinated drop‑off, there is likely a common factor. One possibility is a core network backbone. However, given the data from Terrace and other sources, we believe a more likely factor is the vantage point itself. Internet scanning often consists of large campaigns coordinated by specific actors, and in this case it is possible that a scanner has fingerprinted GreyNoise’s apparatus and is actively avoiding it. Notably, such apparatus avoidance is something we’ve previously investigated in academic research.

Another confounding factor is the use of total sessions to visualize this trend. Because a single Telnet exploit attempt can generate many sessions, visualizations can overstate the statistical significance of observed trends. In this case, the thousands of observed sessions in GreyNoise’s data may actually be coming from a single coordinated actor—or even just a small handful of IPs.

Recommendation: Analyze trends in terms of unique network endpoints or fingerprintable behaviors rather than raw session counts.

Takeaways

• The sky is not falling.
• Our observations do not support the suggestion that core ISPs are censoring or filtering Telnet traffic.
• We fully support—and echo—GreyNoise’s encouragement to take CVE‑2026‑24061 seriously.
• The lack of core‑network protections further underscores that edge systems must be patched immediately.

Note: Any changes to operations or policy based on the expectation that Telnet is being filtered at the core are not warranted.