How T1675 ESXi administration command shows up on hypervisors
For a SOC lead, the core question is whether anyone is running administrative commands on your ESXi hosts that nobody approved, and whether you would see it. T1675 ESXi administration command sits under the Execution tactic (TA0002), where ATT&CK describes the adversary goal as running malicious code or instructions on a system. On ESXi, the hypervisor that runs your virtual machines, that goal is reached through administrative command-line interfaces rather than through the guest operating systems inside the VMs. An adversary who can issue those commands can change VM power states, alter virtual networking, copy or snapshot disks, or disable logging, and the effect reaches every workload on the host at once.
This matters most for regulated workloads. Payment processing, patient records and citizen data often sit on the same clusters as ordinary application servers, and the hypervisor is usually outside the view of endpoint tools deployed inside guests. Administrative activity on hosts is also frequently low volume, which makes a single unexpected session easy to miss unless it is deliberately collected and reviewed. In intrusions, hypervisor administration is typically reached after an attacker has already obtained privileged credentials, so the question is less about the initial foothold and more about who can authenticate to the hosts and what they do once connected.
Before you plan detection, confirm three things in your own environment: which ESXi hosts and management paths are in scope, which accounts and roles can administer them, and whether host-side logs are forwarded to a central platform in a form your analysts can query. Ask your platform or hypervisor team to show you the current logging configuration and retention for those hosts. The answers determine what telemetry, such as Application Log Content, you will actually have to work with.
Which telemetry reveals ESXi administration activity
This table maps each telemetry source ATT&CK links to T1675 against the signal it can show on ESXi and the open-source collector that gathers it. Application Log Content is the primary source, while Command Execution and Process Creation only help on hosts that run management tooling against ESXi. Confirm which of these your ESXi version and logging configuration actually produce before you write detections that depend on them.
| Data source | Signal to look for | Open-source collection path | Confirm before relying on it |
|---|---|---|---|
| Application Log Content (DC0038) | Administrative actions and sessions recorded in ESXi host logs, such as logins and configuration changes | Wazuh agent log collection or syslog forwarding to Security Onion, with parsing for ESXi message formats | Which ESXi log facilities and severities your version emits, and whether remote syslog is enabled |
| Command Execution (DC0064) | Commands run through management tooling on a jump host or admin workstation that targets ESXi | Wazuh or Velociraptor collection on the management host, with shell and PowerShell history captured | Whether your management tools write command history and whether it is retained off the host |
| Process Creation (DC0032) | Launch of administrative clients or scripts on hosts that manage ESXi, tied to the user context | Wazuh process monitoring on management hosts, forwarded to Security Onion | Whether management hosts are in scope for endpoint agents and whether process auditing is enabled |
| Network Connection Creation (DC0082) | Management sessions opened from unexpected sources toward ESXi management ports | Zeek connection logs or Suricata flow records captured on the management network segment | Whether the management network is mirrored or otherwise visible to sensors |
| Network Traffic Content (DC0085) | Protocol metadata for administrative sessions, where traffic is readable at the sensor | Zeek or Suricata protocol analysis on the management segment | Whether management traffic is encrypted end to end, which limits content inspection |
| Authentication and account events | Logins to ESXi by local or directory accounts, including failed attempts and new admin accounts | Central log collection through the same syslog path, correlated with the directory service logs | Whether your directory integration forwards authentication events and whether local accounts are enabled |
Detection logic for ESXi administration events
The four detection ideas below target T1675 ESXi Administration Command as mapped in Enterprise ATT&CK v20.0, using the Application Log Content data component (DC0038) as the primary signal. Each card states the logic, the thresholds to set against your own baseline, and the benign activity that will trigger it first.
Administrative actions from unexpected sources
Flag administrative commands on ESXi hosts when the acting account or source address has never appeared in your baseline for that host or cluster. Build the baseline from at least several weeks of Application Log Content covering shell, API and vCenter-initiated actions, then alert on first-seen account and source pairs. Expect false positives from new jump hosts, replacement backup servers and vCenter service accounts that were rotated. Confirm each allowlist entry against your change records before you suppress it.
Administrative activity outside maintenance windows
Compare the time of each administrative event with the maintenance calendar for the host, including time zone normalization across vCenter and ESXi logs. Alert when privileged actions occur outside approved windows and are not linked to an open change ticket. Patch automation and scheduled backup jobs often run at fixed hours, so model those as expected activity rather than as exceptions. Review the schedule each quarter, since windows drift as operations teams change.
Bursts of configuration changes
Count configuration-changing administrative events per host over a short sliding window and alert when the count exceeds the host's normal range. Bursts that touch several hosts in one cluster within minutes deserve priority because they can indicate scripted activity. Bulk configuration pushes from automation tooling, such as host profile remediation, will produce the same pattern. Tune the window and threshold against your own change history, and document the values so reviewers can explain each alert.
New or changed administrative users
Alert when an account is created, added to an administrator role, or has its permissions elevated on an ESXi host or the vCenter that manages it. Compare the event against the identity provider or directory record for that account, because an administrative account with no matching directory change is a strong signal. Expect benign triggers from onboarding of new operators, password resets handled by automation and service account rotations. Pair the alert with a periodic review of the local permission list on each host.
How to validate that the ESXi detection fires
This sequence proves that the T1675 detection on ESXi actually fires when approved administrative activity occurs. It produces a timed record of evidence, gaps and tuning actions that the team can repeat after each change to logging or ESXi versions.
Agree the validation scope in writing
The detection owner, the ESXi platform team, the SIEM administrator and the range operator agree in writing which hosts, accounts, administrative actions and log sources are in scope. The scope names the ATT&CK version the detection maps to, so results can be traced to the right technique definition. It also records who may run the actions and who approves stopping the exercise. The step is done when every named party has signed off on the scope document and the approval is stored with the detection record.
Prepare an isolated ESXi test host
The platform team prepares an ESXi test host that sits on an isolated network segment, is not connected to production vCenter or shared datastores, and forwards its logs to the same SIEM pipeline used in production. Logging configuration on the test host is set to match the production baseline so that the results are representative. Snapshots or a documented rebuild path are confirmed before testing starts. The step is done when the operator confirms the host is isolated, the log forwarding path is in place and a rollback method has been tested.
Run approved administrative actions
The range operator performs a pre-approved set of administrative actions on the test host that match the behavior described in the T1675 technique, such as administrative commands executed through the ESXi management interfaces by a named test account. Each action is logged on a run sheet with its time, the account used and the expected log outcome. Actions are kept to the agreed list, and no exploit code or evasion steps are used. The step is done when the run sheet lists every action and the operator confirms that each one completed.
Confirm log lines reach the SIEM
The SIEM administrator checks that the application log content generated by the test actions arrived in the SIEM with the expected fields, including timestamp, host, account and the administrative message. Parsing failures, dropped messages and delayed delivery are noted. The check compares what was sent on the host with what the SIEM indexed. The step is done when every run-sheet action has a matching indexed event, or when each missing event has a logged reason.
Record alert IDs and detection latency
For each action that should trigger the detection, the analyst records the alert identifier, the time the alert was raised and the time between the administrative action and the alert. Alerts that did not fire are recorded with the rule name checked and the reason it was not matched. The output is a table that links each run-sheet entry to its alert, latency and status. The step is done when the table covers every in-scope action and the analyst has reviewed it with the detection owner.
Document gaps and tuning decisions
The detection owner reviews the table and writes down each gap, such as a missed action, a noisy match on approved administration or a field that the parser did not extract. Each gap receives an owner, a proposed fix and a decision on whether it is accepted for now. Tuning changes are tested in the range before they are moved to production. The step is done when every gap has a recorded disposition and the changes are linked to the detection version in use.
Re-run after log or ESXi changes
The validation is repeated whenever the ESXi version changes, the log format or forwarding configuration changes, or the detection rule is updated. The team reuses the same run sheet so that results can be compared over time. Any new failures are treated as regressions and routed to the detection owner. The step is done when a dated re-run record exists for each change and the comparison against the previous run is filed with the detection documentation.
Preventive controls for ESXi administration
T1675 ESXi administration command depends on who holds administrative rights on the hypervisor and whether those actions leave a complete record. The four cards below cover account scoping, privileged access, log completeness and operator awareness, and each one names a check you can run in your own environment.
Scope ESXi user accounts
Mitigation M1018, User Account Management, limits which accounts can reach ESXi at all. Review local ESXi users, remove unused accounts and confirm that day-to-day administrators sign in with named identities rather than shared logins. Check whether the host is joined to a central directory and whether that directory's group membership is the only route to administrative roles. Ask your team to produce the current list of accounts with administrative roles and compare it against the approved roster. Any account without an owner is a finding.
Restrict privileged administrative roles
Mitigation M1026, Privileged Account Management, governs which administrators can run commands that change VM state, networking or host configuration. Confirm that elevated roles are granted to a small, named group, that standing privilege is avoided where your tooling allows time-bound elevation, and that break-glass accounts are stored under dual control and tested on a schedule. Verify that vCenter-level and host-level roles are not mixed up, since a broad role at one layer can reach the other. Document who approves each elevation.
Keep administrative logs complete
Mitigation M1047, Audit, is what makes T1675 detectable after the fact. Confirm that ESXi and vCenter logs are forwarded to your central platform, that clocks are synchronized, and that log retention meets your policy and any regulatory obligation you carry. Test whether administrative actions, login events and role changes appear in the central store, and whether a silent gap appears when a host reboots or a forwarder fails. Record the retention period as a decision your compliance lead has signed, not as a default you assumed.
Train operators on ESXi change control
Mitigation M1017, User Training, addresses the people who run administrative tasks every day. Brief hypervisor administrators on which actions require a ticket, how to report an unexpected configuration change, and why shared scripts that call administrative interfaces need review. Run a short tabletop exercise where an administrator sees an unfamiliar change on a host and must escalate it. Track completion and refresh the material when your ATT&CK version or platform changes. Training works best when it reinforces the account and log controls above.
Triage steps when an ESXi administration alert fires
The first job when a T1675 alert fires on an ESXi host is to establish whether the administrative action was authorized, and the fastest way to do that is to confirm the account and its source before anyone touches the host. Record the account name, the authentication path (local host account, directory-backed account or vCenter-brokered session), the source address and the time of the event from the ESXi host logs and any Application Log Content your SIEM already ingests. Then compare those details against the change record and the maintenance calendar for that host or cluster. If a ticket, a planned maintenance window and an on-call engineer line up with the event, the alert can be closed with evidence attached. If nothing lines up, treat the event as unexplained until proven otherwise and move to preservation before anyone changes the host.
Preserve evidence first. Export the ESXi host logs and the vCenter Server event and task records for the same window, and hash the exports so their integrity can be shown later. Do not reboot the host, reinstall agents or clear logs as a fix, because those actions overwrite the state you need. Next, check related changes on the virtual machine inventory: new or modified virtual machines, changed resource or snapshot settings, and altered network or datastore assignments in the same window. Pair that with identity events for the account from your directory and vCenter authentication logs, including failed logins, new session origins and password or role changes. Confirm with your platform team which log retention period applies, because the availability of older records depends on how your syslog and vCenter configuration was set up.
Containment should be proportionate and reversible. If the account cannot be tied to an approved change, lock or disable it in the identity source and end its active sessions, and restrict access to the ESXi and vCenter management interfaces to a short list of administrative addresses, so the account cannot reach the host again while the review continues. Record each containment step with a time and an owner, and confirm that the change does not break backups or monitoring that depend on the same account. Once the review is complete, document the incident in your case system: the alert and its trigger, the account and source evidence, the change-record comparison, the preserved artifacts with their hashes, the containment decisions and the final disposition. Note which ATT&CK version your detection mapping targets, and confirm with your own security team how your organization handles that record.
Rehearsing ESXi administration detection in a private cyber range
The range should mirror the client's ESXi estate closely enough that detections are meaningful, but it must be isolated from production networks, management planes and shared credentials. Build a small cluster of ESXi hosts with the same major version, the same vCenter integration pattern and the same identity source used in production. Route host and vCenter logs to a log pipeline, such as Wazuh or Security Onion, so the team tests the same path that real telemetry would follow.
- Isolated network segment: Keep the range off production VLANs, with no routed path to live directories, backups or management jump hosts.
- Log forwarding parity: Configure the ESXi syslog targets and vCenter log export exactly as production does, then confirm that Application Log Content reaches the pipeline with timestamps intact.
- Synthetic identities: Create test administrator and service accounts that exist only in the range, with no reuse of production passwords or keys.
- Baseline capture: Record normal administrative activity for a fixed period before exercises begin, so analysts know what routine looks like.
- Rollback point: Snapshot the hosts and the log store so each exercise starts from the same state.
Confirm with your platform team which ESXi and vCenter versions are in production, and whether your log pipeline supports the event fields you need before you commit to a range design.
Injects are scripted events that the exercise control team introduces into the range at set points. They should be approved in writing by the client, limited to the agreed scope and reviewed for safety before the exercise. The examples below are illustrative only and do not describe any observed activity or a required test. Each inject should have an expected detection, an owner and a stop condition.
- Illustrative inject one: An administrative session on a host occurs outside the approved maintenance window, and the analyst should see it in the log pipeline within the agreed time.
- Illustrative inject two: A service account performs administrative actions that fall outside its documented role, which tests whether the team correlates identity with activity.
- Illustrative inject three: A burst of administrative commands follows a failed authentication sequence, testing the alert threshold and the escalation path.
- Illustrative inject four: Log forwarding is interrupted for a short period, so the team practices recognizing a visibility gap.
- Illustrative inject five: A change occurs with no matching ticket, testing whether change records are checked during triage.
Agree the stop conditions, the timing of each inject and the communication channel with the client before the first event is introduced.
A good detection for ESXi administration activity should produce an alert that an analyst can act on without rebuilding the context from scratch. The SOC should be able to answer who acted, from where, on which host, what changed and whether a documented change explains it. Triage should move from the alert to the host, the identity and the change record in a repeatable order, with clear criteria for escalation to incident response.
- Alert fidelity: Confirm that each alert names the host, the account, the source address and the administrative action, so the analyst does not need to search for the basics.
- Context lookup: Give analysts a short checklist that links the alert to change tickets, identity records and recent authentication events.
- Escalation criteria: Define in advance which combinations of signals move an alert to incident response, and who has authority to isolate a host.
- Documentation of decisions: Require a short note for each alert explaining the disposition, so the team can review reasoning as well as outcomes.
- Playbook review: After each exercise, update the playbook where analysts had to improvise.
Check whether your SOC has access to the vCenter and ESXi logs needed to complete each triage step, and whether that access is documented in your incident response plan.
The value of a range exercise comes from the record it leaves behind. Capture what was injected, what was detected, how long each stage took as recorded by the team's own timestamps, and where the process broke down. Tie each finding to a specific control, detection rule or owner, and state the ATT&CK version the mappings target, since technique content changes between releases. Keep the record factual so that it can support later review by internal audit or an external assessor.
- Detection coverage: Record which injects produced an alert, which produced a partial signal and which were missed.
- Timing records: Log the timestamps for event generation, alert creation, analyst acknowledgment and disposition, using the times the systems recorded.
- Gap register: List each missing field, unparsed log, broken forwarder or unclear ownership, with a named owner and a due date agreed in advance.
- Rule quality: Note false positives and false negatives, and the tuning change made in response.
- Version reference: State the ATT&CK version and the Sigma or detection rule revision used, so results can be reproduced.
Ask your provider to confirm in writing what the final report will contain, who receives it and how the findings will be tracked to closure.
Questions SOC leads ask about T1675 detection
How do I confirm which ESXi log categories are actually forwarded to my SIEM?
Start by checking the syslog configuration on each host and comparing it with what arrives in your SIEM, category by category. Confirm the remote syslog target, transport and port on every host, then check whether the vCenter-managed configuration overrides local settings. Generate a known, harmless administrative action in a lab host and trace it end to end. Record the result per log category, because a host can forward authentication events while silently dropping shell or service activity. Ask your platform team to document the expected categories and to alert when a host goes quiet, since a missing feed looks like a clean environment.
How should my T1675 detection change when moving from ATT&CK v18 to v20?
Pin every detection to the ATT&CK version it targets and record that version in the rule metadata. ATT&CK v18 replaced technique-page detections with detection strategies and analytics, and MITRE deprecated several data sources, so a mapping written against older wording may need rework. Review the release notes for v18, v19 and v20 for any renamed, deprecated or revoked technique or data component that touches your rules. Then compare the data component references in the current STIX bundle for the version you adopt. Treat the migration as a controlled change with a test run against replayed logs, not as a silent update.
How do I tune T1675 alerts against vCenter service accounts without creating blind spots?
Tune by identity and context, not by suppressing the technique. Build an inventory of automation accounts, their source hosts, their typical commands and their schedule, then allow only that exact combination. Keep alerts for the same accounts when they run from an unexpected address, at an unusual hour or with a command outside their baseline. Review every suppression on a fixed cadence and record who approved it. Ask the vCenter owner to confirm which service accounts are used by backup, monitoring and lifecycle tooling, because undocumented accounts are where most false negatives hide.
Do Sigma rules work for ESXi logs, or do I need custom parsers?
Sigma rules can express the detection logic, but they only run once the ESXi log fields are parsed into the schema your backend expects. Check whether your SIEM or log pipeline already has an ESXi parser and whether its field names match the rule's logsource and field selections. Convert the rule for your backend, then test it against captured ESXi events from a range host rather than trusting the conversion. Expect to write a small field mapping for your environment. Keep the rule and its mapping in version control so changes to either are reviewed together.
How do I measure detection coverage for T1675 in a way that holds up in review?
Measure coverage as a set of tested cases, not as a count of deployed rules. For each variant of the technique you intend to detect, record the input you generated in a cyber range, the log category it should appear in, the rule that fired and the time to alert. Track the proportion of cases that fire and the proportion that fail with a documented reason, such as a missing log category. Re-run the same cases after each rule change or ATT&CK version migration. Auditors and leadership can then see what was tested, when and with what outcome.
What should I confirm with VMware or my vendor about ESXi log formats?
Confirm the exact log format, field names and timestamp behavior for each ESXi version in your estate, because these can differ between releases. Ask which log categories are emitted by default, which require configuration, and which are retained locally only. Confirm the timestamp time zone and precision, since correlation with vCenter and network logs depends on them. Ask how log rotation and rate limits behave under load, and whether any events can be dropped. Request written answers and keep them with your detection documentation so the parser and rules are tied to a known format.
How DeployOpen builds ESXi detections and range exercises
DeployOpen is a Chainscore Labs company that plans, implements, hardens and supports self-hosted open-source platforms inside the client's own infrastructure. For T1675 ESXi administration command, we treat the detection as a deliverable that runs on your ESXi hosts and log pipeline, tested against your own administrative workflows before it is trusted.
How we scope
- Confirm which ESXi hosts, vCenter instances and log forwarders fall inside the written scope.
- Record the ATT&CK version the detection targets, since mappings can change between releases.
- Agree in writing which Application Log Content sources will be collected and how long they are retained.
How we build
- Map ESXi shell and administrative activity to Application Log Content events, described in plain logic for review.
- Deploy the collection and rule set on your open-source SIEM stack, such as Wazuh, with its tuning documented.
- Test the rules against recorded benign administration and a controlled range scenario before production use.
How we hand over
- Deliver detection logic, configuration files and runbooks for each ESXi log source in your environment.
- Document the User Account Management checks that support the mitigation, with the evidence each check produces.
- Run a walkthrough with your SOC and platform team so they can triage alerts without DeployOpen involved.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, rule updates and periodic range rehearsals are available as a retainer.
- Ask any provider to confirm how they will update detections when MITRE publishes a new ATT&CK version.
