Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1297: Analytic 1297

ESXi hosts initiating connections from non-standard daemons mimicking HTTP/HTTPS or SNMP traffic, but with irregular payload formats or expired/unsigned TLS certificates.

EnterpriseAN1297AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic matters because ESXi hosts are high-value infrastructure: unexpected outbound or lateral-looking network connections from non-standard daemons can indicate that virtualization management or host processes are behaving outside normal administrative patterns. For leaders, the key value is not the specific protocol names, but whether the organization can distinguish legitimate ESXi management traffic from suspicious services imitating HTTP, HTTPS, or SNMP with abnormal payloads or weak certificate characteristics.

Executive priority

Prioritize this as a resilience and visibility question for virtual infrastructure. Security leaders should ask whether ESXi network activity is baselined, whether non-standard daemon communications are reviewed, and whether certificate anomalies on infrastructure-to-infrastructure traffic are visible to the SOC. This supports incident decision-making, audit evidence for infrastructure monitoring, and control prioritization around critical virtualization platforms.

Technical view

For SOC and detection teams, validate monitoring for ESXi hosts initiating HTTP/HTTPS-like or SNMP-like connections from unexpected daemons or processes. Since no official detection logic is provided, the practical task is to build environment-specific baselines for normal ESXi services, expected destinations, ports, protocols, certificate properties, and payload formats. Investigations should focus on mismatches: traffic that appears to be web or SNMP but has irregular structure, expired or unsigned TLS certificates, or originates from a daemon not normally associated with that communication pattern.

Likely telemetry

  • ESXi host network connection logs or flow records
  • Firewall, proxy, or network sensor metadata for ESXi-originated traffic
  • TLS certificate metadata including issuer, validity period, and signing status
  • Packet inspection or protocol classification data identifying malformed or irregular HTTP/HTTPS/SNMP-like payloads
  • ESXi process, daemon, or service inventory where available

Detection direction

  • Baseline normal ESXi daemon-to-destination communication before alerting broadly on protocol imitation patterns.
  • Tune for ESXi hosts initiating HTTP/HTTPS or SNMP-like traffic from non-standard daemons, especially where payload structure does not match the claimed protocol.
  • Prioritize events involving expired or unsigned TLS certificates when the connection source is an ESXi host and the daemon is not expected to use that certificate path.
  • Account for false positives from legitimate monitoring agents, backup tools, management integrations, or temporary lab configurations that may use non-standard daemons or certificates.
  • Validate whether network sensors can inspect or classify ESXi-originated traffic sufficiently; encrypted traffic may limit payload-based detection to metadata and certificate features.

Mitigation priorities

  • Maintain an authoritative inventory of ESXi hosts, expected services, management integrations, and approved network destinations.
  • Restrict ESXi host communications to required management, monitoring, backup, and infrastructure endpoints where operationally feasible.
  • Review and remediate expired, unsigned, or unapproved certificates used by ESXi-related services.
  • Ensure SOC playbooks include triage steps for suspicious ESXi-originated network traffic and identification of the responsible daemon or service.
  • Use the analytic as a coverage test for virtualization monitoring rather than assuming existing perimeter or endpoint controls provide visibility into ESXi behavior.
Analyst notes and limits

The supplied ATT&CK object is a detection analytic for ESXi platforms and describes suspicious ESXi-initiated connections from non-standard daemons that mimic HTTP/HTTPS or SNMP while showing irregular payloads or expired/unsigned TLS certificates. No tactics, related techniques, procedures, malware, groups, or official detection logic were supplied, so this take focuses on defensive validation and monitoring implications rather than attribution or threat behavior expansion.

Official detection content and relationship context were not provided. Any production detection must be tailored to local ESXi architecture, approved daemons, management tooling, certificate practices, and network visibility. This summary does not assert active exploitation, guaranteed detection, or applicability beyond ESXi.

Official MITRE ATT&CK definition

Analytic 1297

ESXi hosts initiating connections from non-standard daemons mimicking HTTP/HTTPS or SNMP traffic, but with irregular payload formats or expired/unsigned TLS certificates.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
a150f6a3d5c029f1...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle a150f6a3d5c0…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1297
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.