Mirai-Like Telnet Surge on 23/TCP: TSUBAME Q2 2026 Detection and Hardening Guide

On April 30, 2026, JPCERT/CC's TSUBAME Internet threat monitoring network observed a sharp increase in packets targeting 23/TCP — Telnet — with characteristics consistent with Mirai-family botnet scanning. According to the TSUBAME Report Overflow covering April–June 2026, packet volume surged abruptly at the end of April before gradually declining, a pattern that mirrors the classic Mirai propagation cycle: a botnet operator spins up a new scanning wave, infected devices hammer random IPv4 space on 23/TCP and 2323/TCP with embedded credential lists, and the wave decays as the botnet stabilizes or moves to its next phase.

This matters to every organization with even a single Telnet-listening device exposed to the Internet — and in our IR casework, that is almost always more devices than the asset inventory admits. Mirai-derived botnets do not exploit a CVE to recruit; they exploit operational hygiene. Default and hardcoded credentials on consumer routers, DVRs/NVRs, IP cameras, industrial gateways, and legacy network equipment remain the single largest recruitment pool for DDoS-for-hire infrastructure. A surge in Mirai-like traffic is a leading indicator that credential-stuffing against your perimeter Telnet services is about to intensify — and that any device answering on 23/TCP with a factory password will likely be conscripted within hours.

This post breaks down what the TSUBAME telemetry tells us, how Mirai-style propagation works from a defender's vantage point, and gives you production-ready Sigma, KQL, and Velociraptor hunts plus hardening scripts to find and close Telnet exposure before the next wave.

Technical Analysis

What TSUBAME Observed

TSUBAME is JPCERT/CC's distributed darknet/sensor monitoring program, with sensors in Japan and overseas. Because these sensors have no legitimate services listening, any packet they receive is, by definition, unsolicited — scanning, backscatter, or attack traffic. That makes TSUBAME telemetry one of the cleanest Internet-scale signals available for tracking botnet reconnaissance cycles.

Key observations from the April–June 2026 window:

• Abrupt surge on April 30, 2026 in packets targeting 23/TCP with Mirai-like characteristics, followed by a gradual decline through May.
• Mirai-like packet fingerprints — Mirai and its descendants (Mukashi, Satori, Mozi-adjacent strains, and dozens of forked variants) exhibit recognizable scan behavior: SYN floods to 23/TCP and 2323/TCP across sequential or randomized IPv4 ranges, fixed or predictable TCP window sizes and TTL patterns in some variants, and source IP distributions dominated by previously compromised consumer and IoT devices.
• Source IP analysis (per the JPCERT/CC write-up) consistent with a botnet-driven campaign rather than a single research scanner — i.e., distributed compromised devices performing the scanning, which is itself evidence of an active, recruiting botnet.

The Attack Chain, Defender's View

No CVE is associated with this activity — and that is precisely the point. The Mirai infection chain is depressingly deterministic:

1. Scan: Infected bots send TCP SYN packets to 23/TCP (and frequently 2323/TCP) across randomized IPv4 space. Mirai historically skips an internal RFC1918/loopback blocklist and certain government ranges, but targets everything else.
2. Brute force: On an open Telnet banner, the bot attempts authentication using a hardcoded credential list — the original Mirai list contained ~60 vendor default pairs (admin/admin, root/12345, support/support, root/xmhdipc, etc.); modern variants carry expanded lists of several hundred pairs harvested from firmware images.
3. Report and loader: Successful logins are reported to a C2/scan receiver. A loader then pushes architecture-specific payloads (MIPS, ARM, x86, SH4, PPC binaries) via wget, tftp, or direct echo-pipe writes to /tmp or /var/run.
4. Persistence and self-defense: The bot kills competing malware, closes or binds 23/TCP to block rival infections, and begins scanning for its own next victims — which is exactly the traffic TSUBAME saw spike on April 30.
5. Monetization: The recruited device joins DDoS-for-hire operations (UDP floods, GRE floods, TCP state-exhaustion, HTTP floods) or is resold as proxy infrastructure.

Exploitation Status

• Active, in-the-wild, Internet-scale. This is confirmed observed traffic on a national darknet sensor network, not a theoretical risk.
• No CVE, no CISA KEV entry — the attack vector is default/weak credentials on exposed Telnet services, which is a configuration and asset-management failure, not a software flaw.
• Affected platforms: Anything answering on 23/TCP with guessable credentials — consumer/SOHO routers, IP cameras, DVR/NVR systems, IoT gateways, printers, building-automation controllers, and legacy Unix/Linux systems where telnetd was never disabled. Also any compromised internal host that begins scanning outbound on 23/TCP — that host is already a bot.

Why the Surge Pattern Matters

The sharp-onset/gradual-decay shape is characteristic of a botnet recruitment wave: a new variant or a new operator leases source code, seeds an initial scanner set, and the infected population grows geometrically until target saturation or defender cleanup forces the curve down. The practical implication: if your perimeter was going to be compromised by this wave, it likely happened in the first 72 hours after April 30. If you have not audited Telnet exposure since then, do it now — and assume credential brute forcing already occurred.

Detection & Response

The detections below target the two observable states that matter: (1) inbound Telnet exposure and scanning pressure at the perimeter, and (2) an already-compromised internal device scanning outbound on 23/TCP — which is your highest-severity signal, because it confirms a bot inside the wire.

Sigma Rules

---
title: Outbound Telnet Scanning From Internal Host (Possible Mirai Bot)
id: 3f7c1a92-8e5d-4b6a-9c21-7d4e5f6a8b9c
status: experimental
description: Detects an internal endpoint initiating outbound TCP connections to port 23 or 2323, consistent with Mirai-family botnet propagation behavior. Legitimate outbound Telnet from workstations and servers is rare in modern environments.
references:
  - https://blogs.jpcert.or.jp/en/2026/09/tsubame_overflow_2026-04-06.html
  - https://attack.mitre.org/techniques/T1046/
author: Security Arsenal
date: 2026/09/01
tags:
  - attack.discovery
  - attack.t1046
  - attack.command_and_control
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort:
      - 23
      - 2323
    Initiated: 'true'
  filter_rfc1918_dst:
    DestinationIp|startswith:
      - '10.'
      - '172.16.'
      - '172.17.'
      - '172.18.'
      - '172.19.'
      - '172.20.'
      - '172.21.'
      - '172.22.'
      - '172.23.'
      - '172.24.'
      - '172.25.'
      - '172.26.'
      - '172.27.'
      - '172.28.'
      - '172.29.'
      - '172.30.'
      - '172.31.'
      - '192.168.'
  filter_authorized_scanners:
    SourceIp:
      - '%AUTHORIZED_SCANNER_IP_1%'
      - '%AUTHORIZED_SCANNER_IP_2%'
  condition: selection and not filter_rfc1918_dst and not filter_authorized_scanners
falsepositives:
  - Legacy network administration via Telnet (should be eliminated; treat every hit as actionable)
  - Authorized vulnerability scanners (maintain filter list)
level: high
---
title: Telnet Client or Server Binary Execution on Windows Endpoint
id: 8a2e4d16-5c7b-4f8e-a3d9-2b6c8e1f4a7d
status: experimental
description: Detects execution of the Windows Telnet client or installation/enabling of Telnet components. Mirai-style intrusions and manual attacker pivoting frequently use Telnet for lateral movement against IoT and legacy infrastructure. Telnet client is disabled by default on modern Windows and its presence is anomalous on most endpoints.
references:
  - https://blogs.jpcert.or.jp/en/2026/09/tsubame_overflow_2026-04-06.html
  - https://attack.mitre.org/techniques/T1021/
author: Security Arsenal
date: 2026/09/01
tags:
  - attack.lateral_movement
  - attack.t1021
  - attack.execution
logsource:
  category: process_creation
  product: windows
detection:
  selection_binary:
    Image|endswith:
      - '\telnet.exe'
      - '\tlntsvr.exe'
      - '\tlntsess.exe'
  selection_enable:
    Image|endswith:
      - '\dism.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\pkgmgr.exe'
    CommandLine|contains:
      - 'TelnetClient'
      - 'TelnetServer'
      - 'Enable-WindowsOptionalFeature'
      - '/iu:Telnet'
  condition: selection_binary or selection_enable
falsepositives:
  - Rare legacy administration workflows; investigate and remediate rather than whitelist broadly
level: medium
---
title: High-Volume Inbound Telnet Connections on Linux Host (telnetd Exposure)
id: 5d9b3e71-2f4a-4c8d-b6e2-9a1c7d5e3f8b
status: experimental
description: Detects inbound network connections to port 23 or 2323 on Linux systems, indicating an exposed Telnet daemon under potential Mirai-style brute force. Correlate with authentication logs for rapid-fire failed logins from rotating source IPs.
references:
  - https://blogs.jpcert.or.jp/en/2026/09/tsubame_overflow_2026-04-06.html
  - https://attack.mitre.org/techniques/T1110/
author: Security Arsenal
date: 2026/09/01
tags:
  - attack.credential_access
  - attack.t1110.001
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    DestinationPort:
      - 23
      - 2323
    Initiated: 'false'
  filter_local_mgmt:
    SourceIp|startswith:
      - '10.'
      - '192.168.'
  condition: selection and not filter_local_mgmt
falsepositives:
  - Legitimate internal management access (narrow the filter to your management VLANs)
level: high

A note on tuning: rule one (outbound 23/TCP) is your crown-jewel detection. In a healthy environment it should fire zero times per quarter. If it fires, you either have a legacy admin habit to kill or an infected host to isolate. Treat every hit as a triage event.

KQL — Microsoft Sentinel / Defender

This hunt identifies internal hosts making outbound connections to 23/TCP or 2323/TCP to public IP space, aggregated to surface scanning volume (a Mirai bot generates hundreds to thousands of distinct destination connections per hour — a human admin generates a handful). It works against both Defender endpoint telemetry and firewall/syslog ingestion via CEF.

let Lookback = 7d;
let SuspiciousPorts = dynamic([23, 2323]);
let DefenderNet =
    DeviceNetworkEvents
    | where TimeGenerated > ago(Lookback)
    | where RemotePort in (SuspiciousPorts)
    | where not(ipv4_is_private(RemoteIP))
    | where ActionType == "ConnectionSuccess"
    | summarize ConnectionCount = count(), DistinctTargets = dcount(RemoteIP),
                FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
                SampleTargets = make_set(RemoteIP, 25), Processes = make_set(InitiatingProcessFileName, 5)
              by DeviceName, LocalIP, InitiatingProcessFileName
    | extend Source = "Defender";
let FirewallNet =
    CommonSecurityLog
    | where TimeGenerated > ago(Lookback)
    | where DestinationPort in (SuspiciousPorts)
    | where DeviceAction in ("allow", "allowed", "Accept")
    | where not(ipv4_is_private(DestinationIP))
    | summarize ConnectionCount = count(), DistinctTargets = dcount(DestinationIP),
                FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
                SampleTargets = make_set(DestinationIP, 25)
              by SourceIP, DeviceName
    | extend Source = "Firewall";
union DefenderNet, FirewallNet
| where DistinctTargets > 50 or ConnectionCount > 200
| order by DistinctTargets desc

Tune the DistinctTargets > 50 threshold to your environment, but keep it low: any host touching more than a few dozen unique public Telnet endpoints in a week is not an administrator — it is a scanner. Pair this with an inbound-side query on your perimeter firewall for DestinationPort == 23 and DeviceAction == "allow" against your public ranges; if anything is permitted inbound on 23/TCP in 2026, that is a finding by itself.

Velociraptor VQL

Use this artifact as a fleet-wide hunt to catch live Telnet sessions and listening Telnet daemons on endpoints — covering both the victim state (something listening on 23) and the bot state (something dialing out on 23/2323):

-- Hunt: Telnet exposure and outbound Mirai-style connections
-- Surfaces listeners on 23/2323 and outbound connections to those ports,
-- enriched with owning process details for triage.

SELECT Pid,
       Name AS ProcessName,
       Exe AS ProcessPath,
       Username,
       Status,
       Laddr.IP AS LocalIP,
       Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP,
       Raddr.Port AS RemotePort,
       netstat().Family AS AddressFamily
FROM netstat()
WHERE (LocalPort in (23, 2323) AND Status =~ 'LISTEN')
   OR (RemotePort in (23, 2323) AND Status =~ 'ESTAB|SYN')

For Linux hosts where you suspect an active Mirai infection, follow up with a second hunt for the classic Mirai tell — processes whose binaries have been deleted from disk after execution (Mirai payloads routinely unlink themselves post-launch):

-- Hunt: Processes running from deleted binaries (Mirai anti-forensics tell)
-- Linux-focused: flags /proc/<pid>/exe links ending in ' (deleted)'
-- and payloads staged in /tmp, /var/run, or /dev/shm.

SELECT Pid,
       Name,
       Exe,
       CommandLine,
       Username,
       CreateTime
FROM pslist()
WHERE Exe =~ '(deleted)'
   OR Exe =~ '^/(tmp|var/run|dev/shm|var/tmp)/'
   OR CommandLine =~ 'wget|tftp|busybox'
ORDER BY CreateTime DESC

Hardening / Remediation Script

The following Bash script audits a Linux host for Telnet exposure and common Mirai infection artifacts, then applies hardening. Run it across your fleet via your configuration management tooling, and adapt the firewall section to your edge devices:

#!/usr/bin/env bash
# Security Arsenal - Telnet/Mirai Exposure Audit & Hardening
# Run as root. Audit first (AUDIT_ONLY=1), then enforce.
set -u

AUDIT_ONLY="${AUDIT_ONLY:-1}"
REPORT="/var/log/telnet_hardening_$(date +%Y%m%d_%H%M%S).log"
exec > >(tee -a "$REPORT") 2>&1

echo "=== [1/6] Checking for listening Telnet services ==="
if command -v ss >/dev/null 2>&1; then
  ss -tlnp | grep -E ':(23|2323)\b' && echo "[!] FINDING: Telnet listener present" || echo "[OK] No listener on 23/2323"
fi

echo "=== [2/6] Checking telnetd / inetd configuration ==="
ps aux | grep -E '[t]elnetd|[i]netd|[x]inetd' || echo "[OK] No telnetd/inetd processes"
grep -RsiE '^\s*telnet\s' /etc/inetd.conf /etc/xinetd.d/ 2>/dev/null | grep -v 'disable\s*=\s*yes' \
  && echo "[!] FINDING: telnet enabled in inetd/xinetd config" || echo "[OK] No enabled telnet in superdaemon configs"

echo "=== [3/6] Mirai artifact sweep: deleted binaries and payload staging dirs ==="
for pid in $(ls /proc | grep -E '^[0-9]+$'); do
  exe=$(readlink "/proc/$pid/exe" 2>/dev/null) || continue
  case "$exe" in
    *"(deleted)"*|/tmp/*|/var/tmp/*|/dev/shm/*|/var/run/*)
      echo "[!] SUSPICIOUS: PID $pid -> $exe"
      echo "    cmdline: $(tr '\0' ' ' < /proc/$pid/cmdline 2>/dev/null)" ;;
  esac
done

echo "=== [4/6] Outbound Telnet connections (bot behavior) ==="
ss -tnp 2>/dev/null | grep -E ':(23|2323)\b' && echo "[!] FINDING: outbound telnet sessions active" || echo "[OK] No outbound telnet sessions"

echo "=== [5/6] Credential hygiene: accounts with default/empty passwords ==="
awk -F: '($2=="" || $2=="!") && $1!~/^(daemon|bin|sys|sync|games|man|lp|mail|news|uucp|proxy|www-data|backup|list|irc|nobody|systemd)/ {print "[!] WEAK/EMPTY: "$1}' /etc/shadow 2>/dev/null || echo "[OK] No empty-password interactive accounts"

if [ "$AUDIT_ONLY" = "1" ]; then
  echo "=== AUDIT_ONLY=1: no changes applied. Re-run with AUDIT_ONLY=0 to enforce. ==="
  exit 0
fi

echo "=== [6/6] ENFORCING: disable telnetd, block 23/2323 at host firewall ==="
systemctl stop telnet.socket telnetd 2>/dev/null
systemctl disable telnet.socket telnetd 2>/dev/null
if command -v nft >/dev/null 2>&1; then
  nft add table inet telnetblock 2>/dev/null
  nft add chain inet telnetblock input '{ type filter hook input priority 0; }' 2>/dev/null
  nft add rule inet telnetblock input tcp dport { 23, 2323 } drop
  nft add chain inet telnetblock output '{ type filter hook output priority 0; }' 2>/dev/null
  nft add rule inet telnetblock output tcp dport { 23, 2323 } drop
  echo "[OK] nftables rules installed (persist via your distro mechanism)"
elif command -v iptables >/dev/null 2>&1; then
  iptables -C INPUT -p tcp -m multiport --dports 23,2323 -j DROP 2>/dev/null || \
    iptables -A INPUT -p tcp -m multiport --dports 23,2323 -j DROP
  iptables -C OUTPUT -p tcp -m multiport --dports 23,2323 -j DROP 2>/dev/null || \
    iptables -A OUTPUT -p tcp -m multiport --dports 23,2323 -j DROP
  echo "[OK] iptables rules installed (persist with iptables-save / netfilter-persistent)"
fi
echo "=== Done. Review $REPORT and remediate any [!] findings (isolate host if bot indicators present). ==="

Any host flagged with deleted-binary processes or active outbound Telnet in steps 3–4 should be treated as a confirmed compromise: isolate from the network, capture memory if you have the capability, and reimage — Mirai infections on general-purpose Linux frequently coexist with other payloads, and credential theft from the host should be assumed.

Remediation

There is no patch for this campaign because there is no vulnerability — there is only exposed Telnet and guessable credentials. Remediation is architectural, and it is fully within your control:

1. Eliminate Telnet everywhere. Replace with SSH (key-based, password auth disabled). On network infrastructure, enforce transport input ssh (Cisco IOS/IOS-XE), disable the Telnet server entirely on management interfaces, and verify with an external port scan — do not trust configuration intent, verify observable state.
2. Audit your public footprint now. Run an authenticated external scan (or use your attack surface management platform / Shodan/Censys queries against your ASN and domains) for 23/TCP and 2323/TCP exposure. Given the April 30 surge, anything that has been listening since then should be treated as already brute-forced: rotate all credentials on those devices and inspect them for persistence before returning them to service.
3. Block Telnet at the perimeter — inbound AND outbound. Inbound 23/2323 to public ranges should be dropped by default. Outbound 23/2323 from your internal ranges to the Internet should be dropped and alerted on; as covered in the detection section, outbound Telnet scanning is a high-fidelity indicator of an infected internal device.
4. IoT/OT segmentation. Place cameras, DVRs, printers, and building-automation gear in dedicated VLANs with no Internet egress and no lateral reachability to production segments. Mirai bots are only useful to an operator if they can reach C2 and scan outbound — deny both and a compromised camera becomes a local nuisance instead of a DDoS participant.
5. Kill default credentials as a program, not a ticket. Enforce unique credentials at provisioning time for all embedded devices; where a device forces a hardcoded account, that device does not go on the network — escalate to procurement. This is the single control that removes your organization from the Mirai recruitment pool entirely.
6. Egress filtering and anti-spoofing. Implement BCP38/BCP84 source-address validation at your edge so that if an internal device is ever recruited, it cannot contribute spoofed DDoS traffic. This protects the Internet from you — and in many jurisdictions and peering agreements, it is becoming an expectation rather than a courtesy.
7. Monitor the signal. Subscribe to JPCERT/CC's Quarterly Report and the TSUBAME Report Overflow series (source: JPCERT/CC TSUBAME Report Overflow Apr–Jun 2026). Note that starting FY2026, the standalone Internet Threat Monitoring Report has been integrated into the JPCERT/CC Quarterly Report — update your threat-intel intake feeds accordingly. Darknet telemetry like TSUBAME's is one of the cheapest early-warning indicators for botnet recruitment waves; a surge on 23/TCP should automatically trigger the exposure audit in step 2.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub