How T1690 prevent command history logging hides attacker activity
The first question is whether your team can reconstruct administrative activity at all. On Linux, macOS, ESXi and many network devices, the command history or command audit record is often the only place where an administrator's typed actions are kept, and it is frequently the first evidence an investigator reads. T1690 Prevent command history logging describes an adversary stopping or degrading that recording so that commands run on the system leave little or no trace. ATT&CK v19 split the Defense Impairment tactic (TA0112) out of Defense Evasion, and this technique belongs there because its effect is to blind defenders to what is happening on the host. Before planning detection, confirm which hosts record commands by default, which settings control that recording, and where those records are forwarded.
Defenders cannot trust what they cannot see, and this matters most in intrusions where the command record is the only witness to what was done. An attacker with administrative access to an ESXi host or a switch may make several changes in sequence. If the record is missing or truncated, the team has to rely on indirect evidence such as configuration differences, authentication logs or network flows, and those sources may be incomplete. Silent loss of command logging is hard to notice because nothing alerts when a recorder stops, so the absence of expected events becomes the signal. Illustrative example: a Linux administration host that normally forwards command records every hour shows no records across a window that overlaps an unexpected login. That gap should itself be treated as a finding. Ask your platform owners how gaps in command logs are monitored today.
This technique usually appears after initial access and privilege gain, when the adversary already has the rights to change how the system records activity. It is often one step in a wider effort to degrade defensive tooling, so a review of one Defense Impairment technique should prompt a review of the others on the same hosts. For planning, settle three questions with your platform and security teams: which command records are authoritative, who may change logging configuration and how those changes are audited, and what the response is when a host stops reporting. Check the current detection strategies and data components for this technique on the ATT&CK site against the ATT&CK version you target, since releases can change them.
Which telemetry reveals T1690 prevent command history logging
This table maps the Command Execution and Process Creation data components to each platform in scope for T1690, showing the signal to look for, where it is collected and the open-source tooling that gathers it. Read each row as a starting point: where a platform does not log commands natively, the reader must confirm which collection path exists in their own environment before relying on it.
| Platform | Signal to look for | Collection point and open-source tooling |
|---|---|---|
| ESXi | Changes to shell history settings or log directory configuration, and shell sessions that run without a corresponding audit record | Host syslog forwarded to Wazuh or a Security Onion log pipeline. Confirm whether shell and command activity is logged natively on your ESXi version and build. |
| Linux | Modifications to shell history variables, history files or audit rules, and process creation events for commands that alter history behavior | Auditd execve rules feeding Wazuh, or an Auditd-based pipeline forwarded to Security Onion. Confirm that execve auditing is enabled and that rule changes are themselves logged. |
| macOS | Process creation events for shell processes with altered history settings, and changes to shell profile files | Endpoint telemetry agent or Wazuh agent collecting process events. Confirm which process creation fields your agent captures on your macOS release. |
| Network devices | Configuration changes that disable command accounting or syslog for command execution, and sessions missing expected command records | Syslog and AAA accounting forwarded to Zeek or Security Onion where network traffic is visible. Confirm whether the device exports command accounting at all and which vendor commands are recorded. |
| Other platforms (containers, SaaS consoles, appliances) | Loss of expected command or console logs, and administrative activity without matching audit entries | Platform audit logs shipped to Wazuh or a SIEM. Confirm whether each platform records command execution natively, since many do not. |
Detection logic for command history tampering
Command history tampering rarely shows up as one clean event, so detection works best as a set of overlapping signals. The cards below cover configuration changes, shell sessions that switch recording off, gaps in host command records and interruptions to log forwarding, each with the thresholds to tune and the benign activity that will trigger it.
History configuration changes
Watch for edits to shell history settings in profile and startup files, such as the HISTFILE, HISTSIZE and HISTCONTROL keys in /etc/profile, /etc/bash.bashrc and per-user .bashrc or .zshrc files. Alert on a change that sets history to a null target or a zero size, and on any change made outside a known change window. Tune by baselining which hosts legitimately alter these files. Expected false positives come from administrator hardening baselines and configuration management runs that push shell profiles, so suppress alerts when the change originates from the approved automation account and matches a tracked change ticket.
Shell sessions disabling recording
Look for interactive sessions where history is turned off in the same session that runs other commands, for example an environment variable set to disable history or a history clear issued right after a privileged command. Process Creation and Command Execution telemetry is the main source. Set a rule that fires when history-related variables are changed, or when the history buffer is cleared, within the same session as a privilege change. Expected false positives include scripted maintenance jobs and developers who clear history on shared jump hosts, so tag known service accounts and review the first few weeks of alerts before enabling blocking actions.
Gaps in host command records
A host that normally sends shell activity should not go quiet for long periods, and a sudden drop in command volume can indicate that recording was switched off. Compare each host's command event count against its own rolling baseline, and flag hosts that stop reporting while still sending other logs. Confirm the threshold with your own workload data, since build servers and batch hosts have very different normal patterns. Expected false positives come from scheduled reboots, decommissioned hosts and maintenance windows, so join the alert with the asset inventory and change calendar before escalating.
Log forwarding interruptions
Commands can be recorded locally but lost if the forwarder is stopped, misconfigured or blocked. Monitor agent service state, forwarder process exits and connection failures to the central log store, and alert when a host's forwarder stops while its heartbeat continues. Confirm the expected heartbeat interval and the buffering behavior of your agent in its own documentation before setting limits. Expected false positives include network changes, certificate renewals and agent upgrades, so correlate with change records and treat repeated interruptions on the same host as the higher-priority signal.
How to validate the T1690 detection in a lab
This sequence proves that the T1690 detections fire as designed on each in-scope platform, and it produces a record of time to alert, available fields, false positives and gaps tied to a named ATT&CK version. The result is evidence a CISO can review before the detection is trusted in production.
Define scope and success criteria per platform
The detection owner and the platform leads list the platforms in scope for T1690, such as ESXi, Linux, macOS and network devices, and note which telemetry sources are expected to carry each behavior. For each platform, they write down the expected alert, the expected data fields and the maximum acceptable time to alert. Done means a signed scope sheet exists for each platform, with the ATT&CK version recorded as v20 and the detection identifiers under test listed by name.
Agree the change window and rules of engagement
The range owner, the SOC lead and the system owners agree a change window, the lab hosts that will be touched, the accounts allowed to run the emulation and the stop conditions. The SOC confirms it will treat lab alerts as tagged test events so they do not reach production queues. Done means a written approval exists and the SOC has confirmed the tagging method in the SIEM. Confirm the exact approval workflow with your own change board, since it varies by organization.
Prepare isolated lab hosts and logging baseline
The platform team rebuilds or restores the in-scope lab hosts from known-good images and confirms that the agents or log forwarders send command execution and process creation telemetry to the SIEM. They record a baseline of normal shell history and log events so that later comparisons are meaningful. Done means each host shows a healthy forwarder status and the baseline events are searchable in the SIEM under the lab tag.
Run an approved emulation of the behavior
A tester runs the approved emulation plan for each platform, following the procedure agreed in the scope sheet. The emulation is recorded by a neutral observer who notes the start and end time of each action and any deviation from the plan. The plan itself is kept in the range repository and is not shared outside the approved group. Done means the observer's log matches the plan and every action has a timestamp.
Confirm expected alerts and fields in the SIEM
The detection engineer checks the SIEM for each expected alert, comparing the time of each recorded action with the time the alert was raised. They confirm that the fields the detection logic depends on, such as the host, user, process and command context, are present and populated. Done means each expected alert is either confirmed with its fields or logged as a gap with the missing field named.
Record time to alert, false positives and gaps
The detection engineer writes the results into a validation record that lists time to alert per platform, field completeness, the count of benign events that matched the rule and any behaviors that produced no alert. Each gap is assigned an owner and a follow-up action, such as a telemetry change or a rule adjustment. Done means the record is complete, reviewed by the SOC lead and stored with the detection change history.
Retest after tuning and tie results to ATT&CK v20
After any rule or telemetry change, the same emulation is repeated on the same hosts so that before and after results can be compared. The validation record states the ATT&CK version targeted, which is v20 for this page, because technique content can be renamed or revoked between releases. Done means the retest record shows the change in results and carries the ATT&CK version on its first page. Confirm the current release notes on the official ATT&CK updates page before each validation cycle.
Mitigations that keep command history trustworthy
T1690 succeeds when the logging layer itself is changed, so the mitigations here focus on keeping that layer fixed, owned and reviewed. The two ATT&CK mitigations for this technique, Operating System Configuration and Environment Variable Permissions, sit alongside account and audit controls that make an unexpected change visible.
Operating system configuration
This mitigation covers the settings that decide whether shells and system services record commands at all, and where those records go. Treat the logging configuration as a managed baseline: store it under version control, deploy it through your configuration tooling, and alert when the running state differs from the baseline. Check the settings on Linux, macOS, ESXi and any network device separately, because each platform stores and forwards history differently. Confirm vendor-specific settings with the vendor before relying on them.
Environment variable permissions
Shell history behavior is often controlled through environment variables and profile files that load at login. Restrict who can set or override these values, and who can edit the shell profile files that export them for all users. Compare the effective values for privileged sessions against the approved baseline, since a session that starts with altered history settings may leave no obvious trace afterward. Confirm how your platform inherits these variables for service accounts and automation before setting the policy.
Audit of logging configuration changes
Audit (M1047) makes changes to logging configuration themselves observable. Enable audit records for edits to logging files, service restarts and changes to log forwarding targets, and forward them to a store the host administrators cannot quietly modify. Set alerts for any change outside an approved maintenance window. Without this layer, a silent edit to history settings can look like normal administration.
Privileged account management
Privileged Account Management (M1026) limits who can change logging settings in the first place. Separate administrative roles for system configuration, log management and security monitoring, so no single administrator can disable history collection and erase the evidence. Require named accounts, time-limited elevation and approval for administrative sessions on hypervisors, network devices and Linux hosts. Review these assignments on a schedule your compliance program defines.
Forwarding and tamper-resistant storage
Local history files can be cleared by anyone with enough privilege, so send command records to a central collector as they are created. Confirm the forwarding agent is itself monitored for stopped or reconfigured states, and that the central store enforces retention and write-once or restricted-delete controls. Verify ESXi and network device forwarding options with each vendor, since supported syslog and retention features vary by version and model.
Baseline checks and drills
Build a recurring check that compares live logging configuration against the approved baseline on every in-scope host and device. Record the result as evidence for control reviews. Rehearse the detection in your cyber range by changing a logging setting on a test host and confirming the alert fires, then restore the baseline and document the timing and gaps you found.
Triage steps when a T1690 alert fires
The first decision on a T1690 alert is whether the change to command history logging was authorized. Start by checking the change record, the configuration management history and the on-call log for the affected host or device, then ask the administrator who owns that system to confirm in writing. Changes to shell history variables, history file handling or session logging can be legitimate during troubleshooting, so treat an unexplained change as suspicious until someone with authority says otherwise. Do not assume an authorized change until a named owner confirms it. Record the alert identifier, the detection rule version and the ATT&CK version the rule targets, so the triage notes match the mapping later.
Before anything is changed, preserve what still exists. Export the current value of the relevant configuration keys, copy the surviving shell or device history files and the audit or syslog records that cover the window, and hash the copies so their integrity can be shown later. Capture the account and session that made the change: the user name, source address, terminal or session identifier and the parent process, using the Command Execution and Process Creation records that raised the alert. Then widen the window. Look for file deletions, privilege changes, new scheduled tasks, unusual logins and outbound connections on the same host in the surrounding period, because command history suppression is often one step in a longer sequence. Illustrative example: a single operator account that disables history logging minutes before an unexplained root login is a different case from an administrator's documented change.
Decide on containment based on what the review shows, not on the alert alone. If the change is unauthorized or the related activity is unexplained, isolate the affected session or restrict the account, rotate the credentials it used and escalate to the incident response lead with the preserved evidence, the timeline and the open questions. If the change is authorized, restore the approved configuration, record the exception with an expiry and confirm that logging is working again. After closure, review why the detection fired or failed to fire: whether the relevant logs were forwarded off the host, whether the rule covered the platform involved, and whether the configuration baseline is monitored. Confirm the retention period and log integrity controls with your own platform team, since they determine how much history can be recovered after an incident.
Rehearsing T1690 detection in a private cyber range
The Linux and macOS tab uses a private range with a small set of endpoints enrolled in the monitoring stack, one of them a standard user workstation and one a server with a central log forwarder. Endpoints should forward process creation and command execution telemetry to the SIEM, and the range should include a shell history configuration baseline so defenders know what normal looks like before the exercise starts. The inject is a scripted change to history-related settings on a test host, delivered by the exercise control team and logged with a known timestamp so responders can be scored against it.
- Expected signal: A configuration change alert that references the affected host, the user context and the changed setting, raised within the time window agreed for the exercise.
- Host attribution: The alert should name the correct host and account, with no confusion between the workstation and the server.
- Triage record: The analyst should document the baseline, the observed change, the other activity around it and the decision reached.
- Containment decision: Responders should decide whether to isolate the host, restore the baseline configuration or only monitor, and record the reason.
- Detection tuning: Review whether the rule fired on the expected data component, whether noise from admin tooling was suppressed correctly and whether the ATT&CK version and detection mapping in use are recorded.
Confirm with your platform team which logging agents and auditing facilities are present on each Linux and macOS build in your environment before scheduling the exercise.
The ESXi tab uses a private range with a lab vCenter and at least two ESXi hosts forwarding host logs to a central collector, so responders can compare the same event across hosts. Because ESXi administration is often routed through a management network and jump hosts, the topology should include the bastion path and the identity source used for administrator sign-in. The inject is a change to logging-related host configuration performed through the exercise control channel, timestamped and recorded for scoring.
- Expected signal: An alert that links the configuration change to the specific ESXi host and the administrative session that made it.
- Host attribution: The alert should distinguish between the two hosts and identify the correct management account, not a shared service account.
- Triage record: The analyst should capture the vCenter event, the host log entries and the administrative path used, with timestamps aligned across sources.
- Containment decision: Responders should decide whether to lock the administrative account, restrict the management network path or reapply the approved host configuration, and document who approved the decision.
- Detection tuning: Check whether logging gaps between vCenter and the hosts would have hidden the event, and confirm the retention period for host logs.
Confirm with your virtualization team which ESXi log sources and vCenter audit events are forwarded in your environment and whether your licensing covers them.
The network device tab uses a private range with a lab switch or router, a management server for configuration backups and a syslog collector, with the device's management plane reachable only from the exercise segment. The exercise should test whether the team can see changes to logging behavior on the device as well as on the management server that pushes configuration. The inject is a configuration change on the lab device, made by the control team and logged so responders know the expected event.
- Expected signal: A syslog or configuration management event showing a change to logging settings on the device, with the account and source address.
- Host attribution: The alert should name the correct device and distinguish it from other devices with similar names or templates.
- Triage record: The analyst should compare the running configuration with the most recent backup and note any gaps in logging between the device and the collector.
- Containment decision: Responders should decide whether to restore the configuration from backup, restrict management access or escalate to the network owner, and record the reason.
- Detection tuning: Review whether backup comparisons run often enough to catch the change, and whether syslog delivery was interrupted during the exercise.
Confirm with your network team which devices in your environment can send configuration change logs and how often configuration backups are compared against the running state.
Common questions from SOC leads and detection engineers about T1690
How do you detect command history tampering when the logs themselves are the target?
Do not rely on the shell history file as the only record of what ran. Forward command execution and process creation telemetry off the host in near real time to a central collector, such as a Wazuh manager or a Security Onion deployment, so that a cleared or disabled history file still leaves a trail. Alert on changes to shell profile files and history-related settings, and on gaps in host log sequences where expected telemetry stops. Treat a sudden silence from a high-value host as a signal in its own right. Confirm each rule fires in your cyber range before relying on it, because the exact telemetry available depends on the agent and operating system version in use.
How do you handle platforms that have no native command logging?
Start by confirming, in the vendor documentation for your exact model and firmware, which audit and syslog options exist. Many network devices and hypervisors can export administrative events, but the level of command detail varies, so do not assume it. Where native command logging is missing or thin, place administrative access behind a jump host or bastion that records sessions and forwards authentication and process events to your collector. Document the residual gap in your risk register, name an owner for it, and state the compensating control. Validate that the chosen controls produce usable evidence during a range exercise.
How do you tune T1690 detections for normal administrator activity?
Build a baseline from a defined period of routine administration before enabling alerts, and record which accounts, hosts and automation jobs legitimately touch shell configuration. Scope rules to the assets and roles where a change to history behavior is unexpected, and alert on the change itself rather than on every administrative command. Route approved maintenance through change tickets so analysts can suppress known work with a traceable reason. Review suppression lists on a fixed schedule so that stale exceptions do not hide new activity. Test each tuning change in the range against both benign administration scripts and simulated tampering.
How often should T1690 detections be re-validated?
Re-validate whenever something that changes telemetry or behavior changes: an operating system or logging agent upgrade, a change to the SIEM or collector pipeline, a firmware update on network devices or hypervisors, and each new ATT&CK release that touches the technique. Many teams also schedule periodic validation, and the interval should follow your change policy and risk appetite rather than a fixed number we can supply here. Keep a dated validation record for each rule showing the test scenario, the expected alert and the observed result. Auditors and internal reviewers will ask for that record.
How do ATT&CK v20 changes affect existing T1690 mappings?
Name the ATT&CK version in every detection mapping, because releases can rename, deprecate or revoke techniques. MITRE released v20 on 2026-10-13, and v19 on 2026-04-28 split the Enterprise Defense Evasion tactic into Stealth (TA0005) and a new Defense Impairment tactic (TA0112). Check the release notes on the ATT&CK updates page and compare the technique's detection strategies and data components against the version you map to. Update tags and coverage records in your detection-as-code repository and retest the affected rules before closing the change.
Can our own team implement and validate T1690 detections without a partner?
Yes, many in-house teams can, provided they have engineers who understand the logging stack on each platform and time to test. The work usually covers confirming telemetry sources, writing and tuning rules, building range scenarios and documenting results. DeployOpen works on fixed-scope engagements where scope, deliverables and timelines are agreed in writing before work starts, and it can plan, implement, test and document this detection work inside your environment. Ask a partner to show which tasks they will perform, which remain with your staff, and who owns the evidence afterward.
What drives the cost of a cyber range exercise for this technique?
No researched figure is available for this, so ask for a quote built from written scope. The main cost components are the lab infrastructure that hosts the range, the staff time to build the scenario and capture evidence, the time analysts spend reviewing alerts, and any retainer for ongoing re-validation. Costs rise with the number of platforms covered (ESXi, Linux, macOS and network devices each need their own setup), the depth of scenario, and how many rounds of tuning follow. One-time build work is separate from recurring validation. Request an itemized quote that separates these components and states what is excluded.
Does a working T1690 detection satisfy compliance evidence requirements?
A working detection supports compliance evidence but does not complete it by itself. Auditors and certification bodies decide whether controls meet a standard, and DeployOpen does not issue audit reports, attestations or certifications. What DeployOpen can prepare is the system, the control design and the evidence set, such as rule definitions, validation records, alert samples and response procedures. Map those artifacts to the control IDs in the framework you are assessed against, and confirm with your assessor which evidence format they expect before the assessment begins.
How DeployOpen builds T1690 detections and range scenarios
DeployOpen works on T1690 Prevent command history logging as a fixed-scope engagement inside the client's own infrastructure, starting from a written scope and ending with detections, range exercises and documentation the client's team can run. The work is planned around the telemetry the client already collects, so the output fits their existing logging and response processes.
How we scope
- Confirm which ESXi, Linux, macOS and network device estates fall inside the written scope for T1690.
- Inventory where command execution and process creation telemetry is collected today, and where history settings are managed.
- Agree the ATT&CK version the detections target, since releases can rename or deprecate technique mappings.
How we build
- Write detection logic in Sigma and map it to Wazuh or Security Onion pipelines the client already operates.
- Define the expected baseline for history configuration changes so benign administration does not generate noise.
- Test each rule against replayed telemetry in a private cyber range before it reaches production monitoring.
How we hand over
- Document each detection with its data components, ATT&CK mapping, known false positive sources and tuning notes.
- Deliver range scenarios that rehearse detection and response for T1690 with clear pass and fail criteria.
- Record the Operating System Configuration and Environment Variable Permissions controls in-scope, with evidence locations for the client's auditors.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover re-testing of T1690 detections when ATT&CK releases change related mappings.
- Ask any provider to confirm in writing which parts of the work recur and which are one-time.
