130.216.217.88

Summary (Bottom Line Up Front)

A host originating from The University of Auckland network (130.216.217.88) conducted targeted Kubernetes API enumeration and reconnaissance activities over a 4-hour period on March 13, 2026. The activity demonstrates medium-severity scanning behavior focused on container orchestration infrastructure discovery. Network defenders should review Kubernetes API exposure and implement enhanced monitoring for similar reconnaissance patterns.

TCP TCP/SYN TLS TLS/1.0 https
Activity Timeline
INITIAL REPORT2026-03-14T17:44:07Z
Source: batch_hunting
A host originating from The University of Auckland network (130.216.217.88) conducted targeted Kubernetes API enumeration and reconnaissance activities over a 4-hour period on March 13, 2026. The activity demonstrates medium-severity scanning behavior focused on container orchestration infrastructure discovery. Network defenders should review Kubernetes API exposure and implement enhanced monitoring for similar reconnaissance patterns.
Technical details
The threat actor generated 52 events between 10:00 and 14:00 UTC, primarily utilizing HTTPS/TLS 1.0 protocols for Kubernetes API enumeration activities. Attack patterns included API resource discovery (4 instances), version disclosure attempts (1 instance), and automated scanning with bot user agents (2 instances). The activity maps to MITRE ATT&CK techniques T1083 (File and Directory Discovery) and T1046 (Network Service Scanning). Key IOC: 130.216.217.88 with open services on ports 22 (SSH) and 6080. The low AbuseIPDB reputation score (4/100) suggests limited prior malicious activity from this source.
IOCs
IP:130.216.217.88
ASN:9431
COUNTRY:NZ
Recommendations
  • Implement network segmentation to restrict external access to Kubernetes API endpoints and limit exposure to authorized networks only
  • Deploy enhanced logging and monitoring for Kubernetes API authentication attempts, resource enumeration, and version disclosure requests
  • Review and harden Kubernetes RBAC policies to ensure principle of least privilege for API access
  • Configure rate limiting and request throttling on Kubernetes API servers to mitigate automated reconnaissance attempts
  • Establish baseline monitoring for TLS 1.0 connections to identify potentially outdated or suspicious client implementations