Analyzing FY2025 TSUBAME Data: Countering Active Mirai-Related Telnet Scans

The JPCERT/CC has released its latest TSUBAME Report Overflow, covering observation trends from January to March 2026 (the final quarter of FY2025). For security operations centers (SOCs) and network defenders, the data presents a stark reality: despite being a legacy protocol, Telnet (TCP/23) remains the most frequently targeted port for scanning activity.

Crucially, JPCERT/CC analysis confirms that a significant portion of this traffic exhibits characteristics associated with the Mirai botnet. This is not passive background noise; these are active reconnaissance scans seeking vulnerable IoT devices and unmanaged infrastructure to recruit into a botnet. Defenders must treat TCP/23 exposure as an immediate critical risk, prioritizing the identification and shutdown of Telnet services across the network.

Technical Analysis

Threat Actor/Malware Profile:

Primary Vector: Scanning and exploitation of TCP/23 (Telnet).
Associated Malware: Mirai (and variants).

Mechanism of Attack: The campaign relies on the persistence of Telnet-enabled interfaces on IoT devices, routers, and legacy industrial systems. Mirai variants typically scan the internet for open TCP/23 ports. Upon discovery, they attempt to brute-force default or weak credentials (e.g., root/admin, admin/admin). Once access is gained, the malware downloads a binary, establishes persistence, and adds the device to a C2 network for use in DDoS attacks or further propagation.

Observation Data (FY2025):

Top Targeted Port: 23/TCP.
Characteristics: Packets exhibit specific anomalies and payload structures consistent with Mirai-derived source code.
Scope: Observed globally via TSUBAME sensors, with significant correlation in Japanese IP space.

Exploitation Status:

Active Exploitation: Confirmed. The traffic is not theoretical; it is actively hitting sensors and implies active probing of live infrastructure.

Detection & Response

Given the high volume of scanning traffic observed by TSUBAME, reliance on signature-based blocking alone is insufficient. Defenders must hunt for internal exposure and successful authentication attempts.

SIGMA Rules

YAML

---
title: Potential Mirai Botnet Scanning Activity Inbound
id: 8a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects high volume of inbound connections targeting TCP/23 (Telnet), indicative of Mirai-style scanning waves reported by JPCERT/CC.
references:
 - https://blogs.jpcert.or.jp/en/2026/07/tsubame_overflow_2026-01-03.html
author: Security Arsenal
date: 2026/07/08
tags:
 - attack.initial_access
 - attack.t1190
logsource:
 category: network_connection
 product: windows
detection:
 selection:
  DestinationPort: 23
  Initiated: 'false'
 condition: selection
falsepositives:
 - Legitimate administrative use of Telnet (should be rare)
level: medium
---
title: Linux System Listening on Telnet Port
id: 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6e
status: experimental
description: Detects a Linux system process listening on TCP port 23, indicating a vulnerable Telnet service exposed to the network.
references:
 - https://blogs.jpcert.or.jp/en/2026/07/tsubame_overflow_2026-01-03.html
author: Security Arsenal
date: 2026/07/08
tags:
 - attack.initial_access
 - attack.t1190
logsource:
 category: process_creation
 product: linux
detection:
 selection:
  CommandLine|contains: 'telnetd'
 condition: selection
falsepositives:
 - Authorized administrative Telnet servers
level: high

KQL (Microsoft Sentinel / Defender)

KQL — Microsoft Sentinel / Defender

// Hunt for inbound Telnet connections (TCP/23)
// Focus on high connection counts per source IP to identify scanning sources
DeviceNetworkEvents
| where RemotePort == 23
| summarize ConnectionCount=count(), DistinctLocalIPs=dcount(LocalIP) by RemoteIP, bin(Timestamp, 1h)
| where ConnectionCount > 10
| order by ConnectionCount desc
| extend SuspicionScore = ConnectionCount * DistinctLocalIPs
| project Timestamp, RemoteIP, ConnectionCount, DistinctLocalIPs, SuspicionScore

Velociraptor VQL

VQL — Velociraptor

-- Hunt for processes listening on TCP/23 (Telnet)
-- Immediate identification of exposed internal services
SELECT Fqdn, Pid, Name, Username, CommandLine
FROM listen_addresses()
WHERE Port = 23
	AND Family = 'AF_INET'

Remediation Script (Bash)

Bash / Shell

#!/bin/bash
# Remediation Script: Disable Telnet and Block Port 23
# Author: Security Arsenal
# Date: 2026-07-08

echo "[+] Starting Telnet Hardening Process..."

# 1. Stop and Disable Telnet Services (common service names)
SERVICES=("telnet.socket" "telnet" "inetd" "xinetd")
for service in "${SERVICES[@]}"; do
    if systemctl is-active --quiet "$service"; then
        echo "[!] Stopping active service: $service"
        systemctl stop "$service"
    fi
    if systemctl is-enabled --quiet "$service"; then
        echo "[!] Disabling service: $service"
        systemctl disable "$service"
    fi
done

# 2. Block Inbound Telnet (Port 23) using iptables
# Check if iptables is installed
if command -v iptables &> /dev/null; then
    echo "[+] Applying iptables rules to block TCP/23..."
    iptables -I INPUT -p tcp --dport 23 -j DROP
    # Attempt to persist iptables rules (distro dependent)
    if command -v iptables-save &> /dev/null; then
        iptables-save > /etc/iptables/rules.v4 2>/dev/null || iptables-save > /etc/sysconfig/iptables 2>/dev/null
        echo "[+] iptables rules persisted."
    fi
else
    echo "[!] iptables not found. Please manually configure firewall (nftables/ufw/firewalld) to block TCP/23."
fi

echo "[+] Remediation complete. Verify no processes are listening on port 23."

Remediation

The JPCERT/CC findings make it clear that TCP/23 cannot be exposed to the internet. Follow these steps immediately:

Disable Telnet Globally: Ensure Telnet is not running on any server, IoT device, or router. Replace it with SSH (Secure Shell) for remote administration. If SSH is used, ensure it is configured with key-based authentication and not default passwords.
Network Segmentation & Firewalling:
- Block inbound and outbound TCP/23 at the network perimeter (firewalls, security groups).
- Implement internal segmentation to prevent compromised IoT devices from scanning the internal network.
Credential Hygiene: For devices where remote access is mandatory, enforce strong, unique passwords. Mirai relies heavily on default credentials (root/root, admin/admin).
Asset Inventory: Scan your network for unauthorized IoT devices. Mirai often targets undetected, unmanaged devices (IP cameras, DVRs) that were plugged into the network without IT approval.

Related Resources

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