Remote client performs structured MongoDB reconnaissance by initiating a wire-protocol handshake (ismaster / hello), executing the buildInfo command to obtain server version and build characteristics, and subsequently issuing listDatabases to enumerate all databases present on the instance. This sequence reflects systematic service validation and environment mapping activity commonly associated with automated internet-wide scanning, vulnerability assessment tooling, or pre-exploitation reconnaissance workflows.

Identifies Redis service discovery and basic environment enumeration where an actor probes with invalid commands, validates availability using PING, retrieves server metadata via INFO (case variations), and gracefully exits with QUIT. This pattern is commonly used to fingerprint exposed Redis instances before exploitation.

Identifies an automated Redis service probing sequence consisting of PING, INFO (uppercase invocation), execution of a deliberately nonexistent command to assess error handling behavior, and QUIT. This tightly grouped pattern reflects reconnaissance and fingerprinting activity used by scanners and exploitation frameworks to determine Redis version, configuration details, and command availability prior to follow-on exploitation attempts. The inclusion of a nonexistent command indicates capability probing rather than normal client interaction.

Automated SMTP interaction performing a minimal capability check by issuing EHLO followed by a STARTTLS upgrade request and immediately terminating the session. This pattern is commonly associated with internet-wide scanners, security research crawlers, or opportunistic bots verifying whether an SMTP service supports encrypted communication. The absence of authentication attempts or message submission indicates reconnaissance or service fingerprinting rather than active abuse.

Identifies HTTP GET requests directly targeting the /bad-request path, indicating automated or manual probing of application error-handling routes rather than legitimate navigation flow.

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.