AN1068: Analytic 1068
Detects encoded PowerCLI or Base64-encoded payloads staged via datastore uploads or shell access (e.g., ESXi Shell or backdoored VIBs).
Analyst context for executives and security teams
This analytic matters because encoded or Base64-staged payloads on ESXi can hide malicious automation or scripts inside virtualization infrastructure where many endpoint controls have limited visibility. For leaders, the practical question is whether datastore activity, ESXi shell access, and VIB-related changes are monitored well enough to support fast investigation if suspicious encoded content appears.
Executive priority
Prioritize this as a virtualization resilience and incident-readiness control gap check. ESXi hosts often support critical workloads, so weak visibility into datastore uploads or shell-based staging can slow containment decisions during an incident. Security leaders should confirm ownership for ESXi logging, retention, review workflows, and evidence availability for compliance or post-incident review.
Technical view
AN1068 is a detection analytic for ESXi focused on encoded PowerCLI or Base64-encoded payloads staged through datastore uploads or shell access, including ESXi Shell or backdoored VIB scenarios. SOC and detection teams should validate whether they can identify suspicious encoded content and correlate it with datastore file creation/modification, shell access, and host configuration or VIB-related activity. Because no official detection logic is provided and no tactics or relationships are supplied, implementation should be locally engineered and tested against approved administrative behavior.
Likely telemetry
- ESXi host logs related to shell access and administrative sessions
- Datastore upload, file creation, and file modification records where available
- VIB installation, update, or package-change evidence
- Command-line or script execution evidence from ESXi Shell where collected
- Authentication and administrative access logs for ESXi management interfaces
Detection direction
- Validate that ESXi telemetry is collected centrally and retained long enough for investigation, especially datastore and shell-access evidence.
- Look for encoded or Base64-like payload content in files uploaded to datastores or introduced through shell activity, while tuning for legitimate scripts and administrative automation.
- Correlate suspicious encoded content with recent ESXi Shell access, privileged authentication, and VIB-related changes to improve triage value.
- Account for blind spots: many environments have limited endpoint-style visibility on ESXi, incomplete datastore auditing, or sparse command history.
- Because ATT&CK provides no analytic logic here, treat this as a detection requirement and coverage validation item rather than a ready-to-deploy rule.
Mitigation priorities
- Restrict and monitor ESXi Shell access, enabling it only when operationally required.
- Limit datastore upload permissions to authorized administrators and service processes.
- Review controls around VIB installation and host package changes, including approval and change evidence.
- Centralize ESXi administrative, shell, datastore, and package-change logs for SOC and incident response use.
- Establish baseline administrative automation patterns so encoded or unusual payload staging can be reviewed with less false-positive noise.
Analyst notes and limits
The supplied object is a detection analytic, not a full ATT&CK technique. It is specific to ESXi and describes detection intent for encoded PowerCLI or Base64-encoded payload staging through datastore uploads or shell access. No tactics, relationships, aliases, or official detection logic were supplied, so the value is primarily in guiding ESXi telemetry validation and detection engineering requirements.
This take is limited to the official STIX fields, external reference, and the absence of relationship context. It does not assert active exploitation, attribution, impact, or guaranteed detection. Local ESXi configuration, logging capability, administrative practices, and retention determine whether this analytic can be implemented effectively.
Analytic 1068
Detects encoded PowerCLI or Base64-encoded payloads staged via datastore uploads or shell access (e.g., ESXi Shell or backdoored VIBs).
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 4a64eefe388e… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1068Open source URL
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.