Client performs MongoDB service validation by issuing an initial hello handshake command followed by execution of the buildInfo command against the admin database to retrieve detailed server version and build metadata. This sequence reflects structured deployment fingerprinting and reconnaissance activity commonly associated with automated scanning tools, vulnerability assessment frameworks, or pre-exploitation workflows used to confirm service exposure and identify version-specific attack opportunities.

Client sends RTSP OPTIONS requests to check supported methods and confirm that an RTSP service is exposed, then disconnects without attempting authentication or stream setup. This pattern is typically associated with automated reconnaissance or internet-wide scanning rather than active stream access.

FTP session where the client upgrades to TLS (AUTH TLS) and proceeds to request server capability information using FEAT, HELP, and SYST before cleanly terminating the session. This pattern indicates structured service and feature enumeration rather than file interaction. The sequence is consistent with automated reconnaissance used to fingerprint FTP server configuration, supported extensions, and implementation details

Identifies execution of the Redis INFO command (case-insensitive), which retrieves server configuration, version, memory usage, and runtime statistics. This behavior reflects service interrogation and environment fingerprinting activity. While INFO can be used legitimately by administrators, it is also commonly observed during automated scanning and pre-exploitation reconnaissance of exposed Redis instances.

Identifies HTTP requests targeting the web server root path ("/"), typically used for initial service discovery, host validation, or baseline content inspection prior to deeper enumeration.

Identifies HTTPS requests targeting the web server root path ("/"), typically used for initial service discovery, host validation, or baseline content inspection prior to deeper enumeration

Client repeatedly sends GET requests to the /bad-request Docker API endpoint, indicating malformed or incompatible traffic against the Docker daemon. This pattern is typically associated with generic internet scanning or tools attempting HTTP interaction without speaking the proper Docker API protocol.